Blogs

We all have some vague notion that we can’t visually focus on everything in our field of vision at once, but just how little can we really see at once? This is a very important question for web designers and information architects. James and I are working with Andy Edmonds of StomperNet to build a browser type application “that simulates the limited high resolution vision available to humans as they use the computer”, called or
Foveal Gaze Simulation Software Scrutinizer.

Basically the app applies a filter over the web page your viewing that allows the region around your mouse to be in focus, while the rest of the screen is blurred out. This is to illustrate the difference between what your fovea and periphery of your eye see. This way you can see what your users see more or less and apply some usability best practices to improve conversion or generally make your site easier to use. Specifically you can make adjustments like button positions, whitespace, navigation bar headings and typography. The idea is to use the science behind vision to improve your site without really needing to understand it all;-)

James built this app with AIR. Using the HTML functionality to implement a simple browser and Flash to create the filter over the web page. We had a few interesting challenges getting the page interactions and events to work through the Flash filter, but it’s working pretty well now and will only get better:) On interesting feature you might miss is that you can adjust the size of the focused region with the mouse wheel. This simulates the narrow detailed foveal view when zoomed vs the larger less focused foveal view for rapid scanning when zoomed out.

The masses really are starting to think that usability is cool, even Scoble plugged Srcutinizer! Quick buy some shares in user experience!

Scrutinizer is free, so go download it.

[Update] There’s a super handy Top 10 uses for Scrutinizer posted on the site that includes suggestions simulating eye tracking in a usability study, testing findability, assessing the ease of a multi step process and more.

Web designers can watch how visitors behave on sites

What are you looking at?

Sometimes, website designers don’t see the flaw of their own creation that deters a site’s visitors. They are so familiar with the site they built that they think everyone will be able to use it as easily as they do. If you want to see how people are really using your web pages, use Robot Replay to watch them interact with your site.

It’s neat to see RobotReplay picked up by some mainstream media…I wonder is that means it has a much broader appeal than we first thought. I do feel like usability and user experience are hitting main stream vogue, but I may be stuck in an echo chamber. Help;-)

I figured with end of year and holidays approaching we’ve all got a lot of stuff we want/need to get done, here’s how I’m probably going to operate.

Check out more awesome funny graphs: Crappy Graphs! – “Time before deadline / work”

Dave Johnson just put up a post titled “Ajax Alive and Kicking” that looks at where Ajax is today and what some of the new innovations in the space are. He identifies the key factors in why Ajax is still continuing to the be successful versus other RIA technologies and in particular Flex.

An additional benefit to Ajax (HTML + JS) is that its interactions are somewhat measurable, which is much more difficult in the Flash world. If you put Google Analytics on your Flash site and you don’t get much, a little bit more now with “Events” in Google Analytics but not much. How meaning is a page in the historical sense in an RIA? Of course this falls down in Ajax sites too, but tools like our RobotReplay are springing up to fill that void already, but I don’t see the same happening for Flash/Flex. Of course we’re looking at it, but it’s definitely a chicken and egg thing. One might choose Ajax over Flex because they can measure interactions and effectiveness of their public facing Ajax more easily, and we chose to build RobotReplay for Ajax first because more people use it. This is a very important decision if ad revenues and/or conversion rates mean anything to your business.

Old Rules; beg for coverage and beg for each sale;

New Rules: create thought-leadership by participating in a community that helps customers buy.

This is a great quote from on thought leadership — Pragmatic Marketing. And something we’ve been working on for the last couple years at Nitobi. I think we’re getting somewhere. Begging sucks!

Ajax and Beer update: Moving to the Irish Heather

Due to massive response, over 30 people on upcoming, we’re moving the event 30 feet closer to *you*. The Sheebeen Room is accessed by walking past/through the Irish Heather so now you’ll have more time for beer/ajax and less time a walkin. Everybody wins.

The Irish Heather is at the corner of Carall and Water St. We’ll be upstairs starting at 5pm Tomorrow (Dec 11th). Guinness For Strength!

Ryan Stewart pointed out that Yahoo has added charting to their framework:

YUI, one of the most popular Ajax frameworks, has implemented charting functionality using Flash. Using Flash for charting with Ajax isn’t a new concept.

I agree that this is great news for Adobe and the Flash platform. However, I think it’s a little ridiculous Adobe didn’t facilitate this with Flex Charting, FA Bridge and External Interface. It’s been almost 2 yrs since we did this, and it should have been a model for how Adobe should move forward supporting the Ajax community. Instead Adobe has this kick ass charting capability locked up in a component that costs a few hundred dollars and not getting much play. Especially when you see articles like this pitting Adobe against Ajax. Adobe has jumped into the Ajax game with Webkit in AIR, has tooling with JS Eclipse and Dreamweaver but just needs to go a little bit further to really dominate the RIA space. I’ve pondered before on what impact Flash and AIR can have as dominant runtimes, but but the lions share of web apps today are in the Ajax camp, so Adobe has to win there too. We’ll see what happens.

A LinkedIn API is coming soon. I can’t believe it’s taken so long.

LinkedIn hasn’t disclosed exactly when the API will be readily available but the company does say that the API will eventually be accessible to any and all developers sometime in the next year. The API will provide access to information in profiles, connections, search, network updates, and the “company insider” (its news article service).

Considering I have the majority of my important business contacts locked up in LinkedIn I’m very excited about this. We’re going to be looking at this very carefully for at least 2 projects Nitobi is currently working on, JumpNote and Jiibe. Hurry up, knock down those walls and let us into your garden!

Dietrich Kappe has posted a greatGWT Conference: Voices That Matter Summary over on Ajaxian. He has links to all his posts and notes he took at the conference which are a great GWT resource. His three main points are:

# GWT is a compiler. Let me amplify: it is a compiler, not just a Java to JavaScript converter. It inlines methods, removes dead code, optimizes loops, all those things that a compiler can and should do. And if you play by the GWT rules, you will not leak memory. Want a faster, smaller app? Wait 3 months and recompile with the newest version. Eventually, the compiler will produce better, more efficient JavaScript than you can produce by hand.
# The security concerns for GWT are the same as for all sophisticated Ajax applications: the more state and control logic you put in the client, the more you open yourself up to really nasty attacks. In a sense, the fact that GWT makes writing sophisticated client side code so easy and obscures which Java code is in the client and which in the server, it can increase the potential for making these mistakes.
# The surprise? The conference was not attended by that many GWT newbies or web developers looking to bring their Struts apps into the Ajax light. A show of hands brought home the fact that the audience consisted of mostly folks with Swing/AWT/SWT experience (though they also worked with webapps).

Emphasis is mine, because I find this quite interesting. I wonder if the Google brand has anything to do with these developers adopting GWT as they make there first steps on the web. Thoughts?

I just noticed that Ooyala won Amazon’s startup competition, it’s a video management and distribution app. Apparently the team is from AdSense, which is very interesting to me. And the kicker is that it’s built on top of Adobe AIR. I really wish Joost had been built with Flash and AIR, because from the looks of it Ooyala has all the quality and a much lighter download than Joost. Ok time to watch some web tv.

The times are a changing!