–Engage

“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

Web-apps. Desktop-apps. Huh?

To get the background on this piece, I suggest you jump to the archive page that started the thread. I don’t want to just repeat everything that a lot of great people already said and have a blog of quotes.

The question about the nature of web apps being similar to desktop apps to me is a false question. Anything at some level can be generalized to be similar to something else (within reason). In the end web apps and desktop apps are similar in that they share some pretty important qualities, so it to say that they are the same is like saying that an apple and an orange are both fruits.

Bill Scott from Yahoo, has articulated in this thread really well what is special about thinking about the web, and he re-iterates some important considerations that I’ve made in the past. To sum all this up the most important take away from this list is contextual mindset as triggered by visual cues. To paraphrase, if it floats like a duck, it must be a duck.

Ok, that’s a bit too general … The point is that people respond to different types of cues depending on the visual and social context of what they are using. This design consideration is of paramount importance when thinking about any application design. The example that Bill gives is whether or not desktop metaphors will be accepted when old-style web presentation and interaction models are intermingled with those metaphors?


The answer in my experience is very mixed. While working at Documentum, I logged some hundreds of hours testing our Webtop application which was supposed to model our desktop application but on the web. The UI team presented this as a case study to DUX2003 . (The full DUX case study archive is available on the AIGA web site.) The outcome of the study is that users really don’t know what the heck they want.

I want it to be more like Windows.

A common refrain during user testing sessions, was quickly followed by using the back button. Or users would ignore the web-based file, edit, view menubar that we had and would jump straight up into the browser’s menu bar and try to use that.

The user is not conscious of their environment. They are not aware of the ultimate problem set of web-based applications–they are applications inside of another application (the browser). Unless you are willing to take extreme measures in your application designs, this issue will have to be constantly mitigated through web application design–rich or otherwise:

  • pop open a new window and remove the browser chrome
  • design your application GUI layer to as closely replicate an existing desktop application or OS system

Those two extreme measures have consequences of their own. Lost of brand identity could be one, and the other is dealing with popup blockers and well the uncomfortable reality that you are confusing users by having a weird instance on their taskbar in Windows of their browser.

Of course even if you take out the issue of the app inside of an app problem, there are other considerations that need to be played out when considering the design of web-based applications as opposed to desktop applications. The largest ones of these is that well technologically browsers really weren’t intended to be virtual runtime engines. They weren’t. And the primary language for programming on the client side JavaScript does not have significant memory management controls which makes scale a huge problem that often has to be mitigated way before other similar desktop applications would hit this problem.

That is but one example of where technology pushes back hard on web-based applications. These considerations need to not just be understood by the technical architect, but need to be co-owned by the interaction designer and the engineer so that scalability and other performance considerations can be designed instead of fallen into or hacked later.

Of course you could say that every software environment has its limitation, but again, is an apple the same as an orange?

There are a host of other issues, some mentioned by Bill Scott referenced above, others here, but there is also another issue when speaking about web-app vs. desktop-app and that is YOU, the designer. What is your background? where did you learn interaction design? what concepts are you most familiar with? Most people who I speak with on a day to day basis are NOT from a software background. Meaning, they did not come to web-app design from desktop-app design. The sources of information they encountered were more likely to be Rosenfeld/Morville, Garrett than Schneiderman, Raskin, Tog. Most people encountering web-apps today are doing so coming from an IA related background where information conveyence was their previous primary transactional models. So as much as we would like to just stand up and say, “Look over here, all this information you need already exists in the software design world.” I don’t feel that this tact is useful. Designers like all consumers of information need it to be contextualized to their needs and most web-app designers are placing these apps (usually richening agents in their existing systems) are doing so in the context of information conveyence and need theories, methods, and practice to intermingle the totality of what is still their primary jobs.

It is still incredibly important for all practitioners to look beyond their core and as they grow deeper, also grow broader in their understanding of their discipline. Software design community has been around for decades and has volumes of books out there and really articulate speakers and educators. I said this at the 5-min. madness of the IA Summit 2005, that more of this community needs to engage the world that is already out there. That doesn’t mean that we remove our special contexts and abandon our idiosyncrocies that make us special, but rather we take our strengths and strengthen them with more than what we know.

One place where I do agree with folks who say it is just the same darn thing, is in the overarching process. The specific questions may be different, but the overall methods and process still need to discover user context and enveloped by the business needs and model the end result of doing analysis on that discovery towards designing a relevant tool that fits the user’s goals and motivations while fulfilling the strategic business agenda. Still, pretty high level stuff, eh?

Some resources that I’d recommend for anyone coming from the design or IA worlds into application (web or otherwise) include:

Be Sociable, Share!

Search

The archives run deep. Feel free to search older content using topic keywords.