Category: User Experience

On Breadth First and Depth First thinking

Great talk by Don Norman, a founder of The Cognitive Science Society, and widely considered to be the first to apply advanced human factors to design via cognitive design on The three ways that good design makes you happy:

The three ways he talks about are:

  • Visceral: How pleasant things seem to work better.
  • Behavioral: How good design lets you feel in control.
  • Reflective: How people prefer design that reflects their personality.

One interesting point he makes is how a happy state of mind is puts the brain in “breadth first search” mode and is more conducive for out of the box thinking, but tension and some pressure puts you in a “depth first search” mode (as dopamine gets added into the system). Moment of self realization here for me personally: as a programmer I have often preferred tighter deadlines (note: not to be confused with unrealistic) to open ended project timelines. I need the pressure to focus. A bunch of my programmer friends say they feel the same way. Thats why the burn down charts for closed work tickets is almost never the ideal one:

ideal_timeline2

(note the change of slope as projects approach end dates = more pressure)

There is often the temptation (by me anyway) to carry the model of deadline driven development to design, but Don Norman’s talk indicates that this would be a bad idea, especially if you are conceptualizing new experiences. How much pressure in terms of deadlines and deliverables can anyone apply on design teams before you kill lateral thinking thats absolutely required for creative teams. However its just as easy to fall into the time sink of finding the perfect experience. Voltaire’s quote about Good being the enemy of Great comes to mind again.

So concept in breadth first mode, execute in depth first.

The concept also seems applicable to application/web design around browse and consume. Browse pages/screens, where there isn’t an end goal really and a user is out looking for “something interesting”, should put people’s brains in breadth first mode, with more emphasis on visuals, etc, but when the user is in content consumption mode, like say on video consumption pages or web search, pages, a muted design may be a better idea. It certainly explains why Google Search pages, which most of us use to get to something we need and not really browse, work so well, but on all their other applications where users are more about entertainment than work, their designs feel awful.

Is the file system an outdated concept?

A rather interesting post by Rob Foster where he observes that no one seems to know how to use the file system, besides the Documents folder and the Desktop, and so arguably, the elimination of the visual file system in favor of “apps and their stuff” in the iPhone/iPad was a good thing (link via Daring Fireball).

As a developer, I am not a big fan of the direction Apple is going with the new locked down OS and I completely echo Alex Payne’s sentiment where he talks about the iPad and the Tinkerer’s sunset:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

However that said, there does seem to be some grain of truth to the idea that I dont really know what half the folders in my file system are. Or, well, I may know theoretically what they are meant for but I dont ever use them myself so do I really need the clutter when I open Finder or Windows Explorer. For example, a while back I went from writing different text files at different locations for different reasons to writing them all in EverNote and tagging them appropriately. I dont care where EverNote is placing my files but I know to find anything I just need to launch it and search either on the text or tag.

I think we need to differentiate the concepts of the file system and the visual file system browser though. An available file system is essential for applications to write sharable data even if as an end user I may never need to see those locations. The problem of the iPad/iPhone OS is that the data produced by an application is not really sharable between applications, except for data produced by (some of) Apple’s own applications which are available as frameworks. Some developers have managed to enable inter application communication using custom URL registrations like Innerfence and their Credit Card Terminal application, but that definitely is a hack. In the linked post, the author mentions:

By registering to handle a URL scheme, an iPhone app becomes a de facto web app, subject to many of the nasty attacks that work on the web. Apps implementing this scheme must be careful to validate any parameters they get from the URL lest they be vulnerable to old friends like SQL injection. Another one to be careful of is unsolicited response attacks.

So locking down the OS seems to make my data even more vulnerable to being compromised since an application developer could have a bug in this code. The available file system enables inter application in a much better way in the Android OS, where an application can write to a location and then trigger another application passing it a reference to that location. That’s how Photoshop for Android allows developers to leverage it as an image editor in their own applications. This seems to be the exact translation of the Unix Philosophy in the mobile space and the philosophy has been validated in the Unix space over time already.

So my points are:

  • The file system itself is not an outdated concept. Applications should still have a file system to write sharable data to.
  • The visual file system showing references to rarely used locations or locations only needed by developers can be evolved to one that doesn’t show those to regular users and only shows items relevant to them (my photos, my videos, etc).

Even more, such a mechanism that could be easily evolved to do this is already available in Windows and Mac OS’s, which involves preceding the file’s name with a period. Such files are not visible to the end user but a developer can enable the “show all” behavior.

[Update] David Shoemaker also talks about Death to filesystems and notes that the Google Chrome OS is also going the same way with no filesystem the user can browse (ink via Karl’s blog), though in that case, the data is all stored on the cloud and can be made accessible via the web service’s APIs. Another aspect of that that would be really cool is that chrome browser extensions could even add custom actions to such files: For example, Picnic could create a browser extension that adds menu items to the browser’s chrome when the user is on Picasa or a new photo service and then when that is clicked on, can pull the data from the Picasa using the web service.

Web applications vs. “real” applications and a thoughts on moving off the webpage browser for apps idea

There is an interesting discussion brewing over a couple of blogs. Part of it began when PPK wrote a rather strongly worded post titled “Apple is not evil. iPhone developers are stupid” where he accused some of the developers jumping into the whole native app for the iphone of not really considering the advantages of HTML5 and the powerful Safari browser on the iPhone for their applications.

Of course the iPhone native app camp had to respond and I am sure there are a few responses now online. The one I found that Aral Balkan linked to was by Faruk AteÅŸ made some points around why the App Store in all its craziness is still worth the pain, but they centered around JavaScript performance (which I dont think is as bad esp for the apps that constitute 90% of the app store), HTML layout issues (which I dont agree with really) and making your application available at a place where users are actually looking for applications (some merit here).

Similar discussions also seem to be happening on the Google Chrome OS front (except that in that case there isnt a real option except web apps). For example, after Chrome’s public demo, in a followup Q and A session, Google’s Sergey Brin responded to a question saying that Chrome OS will not support any native application at all. Apple had encouraged developers to write web apps for the iPhone before the native app SDK was announced, but Sergey seemed to indicate that one reason may have been that Apple’s own native apps seemed to fragment user experience since the native apps felt different than the web ones.

I have to say I have yet to be convinced of the web-apps as native-apps concept. This week I have been halfway in the process of transitioning from one computer to another at work, and I was surprised at how much of my data is already on the cloud, between Google Docs, EverNote, DropBox, Flickr, etc, I had very little actual data to move across. That part of the dream is awesome. But using that data in apps is a different story. For one thing, there are very few guidelines for how web apps should look and work making the look and feel widely different and something that we learn from scrach on every new application. And network latency is often very painfully apparent, and I am not even talking for the data, its probable as you switch from one state of an app to another, you are looking at a blank screen for quite a few seconds before the UI gets loaded in, and then tries to load the data.

In a recent labweek project at CIM, we wrote a web application optimized for the iPhone for browsing Comcast On Demand content. The application, while functional, did not work nearly as elegantly as a native iPhone app especially on a device with spotty connectivity. I shudder to think what would happen if my Google NetBook was on a saturated network like AT&Ts right now. I imagine it would only take a few instances of “waiting…” messages to do something that traditionally was instantaneous to piss of a fair number of users (including me). Add to that html’s behavior of rendering incomplete content which then pops into the final look once images and icons get loaded, poor javascript animation (even if they are because of a poorly written piece of JavaScript code) would make the experience a far cry from what I have gotten used to in native applications like that on OSX or (even) Vista.

Perhaps part of the problem remains that we are trying to overload the browser metaphor. The web browser was written to browse documents, and HTML5 continues to move it in that direction. Maybe what is really needed is what I call an Application Frame, a browser that has no concept of a page. There are a number of features that this would need:

  • A concept of state changes that dont involve the entire page to reload, nor rely on crazy JavaScript dom manipulation. Something that looks, for example, similar to Flex’s States metaphor. The application frame should automatically handle transitions by default unless the developer overrides that.
  • The ability to proactively cache an entire application at the application startup, not just page 1 of a 5 page application
  • Ability to add launch icons to the desktop/start menu (I think JNLP does this right now)
  • Ability to override close action of the window that sends it into a windowless background process mode
  • Notification APIs that allow the application that was set as a background process to be recalled into the window mode
  • Ability to leverage system icons without having to package them into the app

I am sure there are more but these are the ones that come immediately to mind. Note that all this happens without an install process. The end user requests the application from a URI and the server can send back a new HTTP Header (something like Content-Type:Application/FrameContent) and then proceeds to send markup and javascript that defines the app UI. The Application Frame can even keep some browser behavior, like history of recently invoked applications, bookmarks, etc. Also the markup should include html and also higher order markup similar to widgets in, say, XUL or Flex.

Couple these with things that are now becoming part of HTML5 like built in databases and web workers and we could finally realize the dream of a “real” application sent to the end user by a webserver at the time of launch. But until that, I still think the web-application may not do it for me. Chrome may prove me wrong, but thats something time will tell.

Update: PPK has a new post up responding to the avalanche of passionate native app folk. Pretty fair points there.