OT: Users and software - desktop and web user mindset differences

[simon.proctor]

Here is a question/meditation I threw together at work but I thought I would throw it into the wider audience:

Why is it that when we use a desktop application we accept that we may need a manual, that we may need training and that practise makes perfect?

Yet when we use a web application we expect it to be obvious? In fact, the more complicated the operation the easier we expect it to be.

We frequently accept that we cannot make software idiot proof yet we attempt to do exactly that when we present an interface through HTML.

The underlying application is probably no different yet by using a web browser we automatically assume a differernt mindset.

More often than not we succeed to some degree but the very lack of this training, manuals and user help means that when a user makes a mistake or assumes behaviour about the software it becomes the developers fault?

Is it not the case that for complex intranet applications that it is fair to expect the user to complete training before becoming a qualified end user?

Of course you should test, debug and usability test but even then is there not a balance between testing for usability and accepting that the user must have at least *some* foreknowledge before being able to understand the application you have built?

Just some thoughts I'm having based on work I'm doing :)

Simon

[matija]

Why is it that people need to get a licence before we will trust them to obey the few simple rules of driving, and yet they are allowed to use a computer when they can't even type?

I think that both problems are of the same cloth. People demand that any work on computers be simpler than driving a car. People demand that using a web application must be simpler than using the same application on the desktop.

One possible reason is that web applications started out by being simpler/doing fewer things than desktop applications.

I think the solution is in not empasizing that something is a web application. It is simply an application that just happens to be accessed through the browser. If you don't follow that philosophy you can get caught in management's method of trying to make a complex problem simple by blindly converting it into a web application.

[simon.proctor]

I agree,

Invariably I think because the simpler applications are simply views of simple database queries then the client base assume you can just *throw html* around your data and everything magically works.

As it happens my current internal client wanted to know why my project would take 30 days instead of 10 for this very reason. Thankfully when I broke the time down they accepted it. Sadly I still only got 15 days to do it (I've just started day 11).

[hardburn]

An unskilled driver is a danger to others, potentially even life-threatening. The worst an unskilled computer user can do is inadvertantly pass around a virus. I don't think it's a fair comparison. Though a virus could have the potential to be life-threatening in some situations (perhaps it jams the bandwidth of a hospital's internal network), it's much rarer.

Besides that, licensing computer users could get to be a thorny issue very quickly. ("You use GNU/HURD? Sorry, it's not on the approved list of operating systems. Your computer license is revoked.")

[jryan]

An unskilled driver is a danger to others, potentially even life-threatening. The worst an unskilled computer user can do is inadvertantly pass around a virus. I don't think it's a fair comparison.

Perhaps in the worst case, yeah. But, I think this is a situation where it is more useful to look at the average case rather than the worst case. In the average case, an unskilled driver is a huge pain in the ass for everybody. The same goes for an unskilled computer user. Unskilled computer users are the reason that many viruses are able to spread as far as they can. Unskilled computer users force designers to dumb down interfaces making it harder for skilled users to do what they need. Unskilled users do create a lot of problems that wouldn't exist if the unskilled set had even the slightest bit of clue.

I agree that "Computer Licenses" (and I think that we're really talking about "Internet Licenses" rather than "Computer Licencing" here. A computer not connected to the internet does no more harm than a car that isn't turned on.) are definitely not the answer, but you can't ignore that unskilled computer users are a problem.

[Juerd]

Yet when we use a web application we expect it to be obvious?

For several reasons, the most important of which probably being the simplicity of web based applications. The user is almost never confronted with two screens at the same time and usually only one thing happens at any given time. With normal GUI applications, often there are many small dialogs and complicated interactive database-driven forms. In the web based world, the user sees a page, does something and gets another page. And usually not more than that.

Another important factor is that in web based applications, it is more common to include user instructions on the form pages. In a GUI, form are usually a crammed together bunch of widgets with no multi line text help. External help doesn't work quite the same as during-the-process instructions. It is a manual and has to duplicate or describe the interface in order to explain.

Does your web application usually run maximized? Does your GUI application? (Not considering document based applications here, but those don't work well with browsers anyway)

[simon.proctor]

... the simplicity of web based applications

I made a distinction here but perhaps I didn't emphasise it enough. I'm referring to predominantly intranet based applications with more complex tasks than fetch-print.

Given the mechanics of HTTP of course there is a single transaction between client server, much like the user being able to only do one thing with the mouse at a time. Of course the gui on the desktop can self update to a degree that is not possible to the same degree in a browser (unless you want to muck around with (i)frames and refreshes et al). However, that is purely a UI decision based on the restrictions of platform.

Invariably on the gui you may have many dialogs but many are modal by nature or present the user with options to change the context of their task. Photoshop is a good example with its toolbar, layer window and history window. However, the user interacts only with one at a time and returns to the main editing window. Not much different from popups and a session (if you're willing to stretch the analogy at all ;) ).

I have commented further above on page by page instructions and how I feel they only go part of the way. However, the replies so far have all indicated there was no help for the given stage in the desktop app. Perhaps I'm lucky because most dialogs in the software I use have a help button on that dialog and the help opens in context. Ok it wouldn't take much to put a few lines on the dialog as well but in the context of my original meditation - ie trained user, included help and frequent links to help - how necessary are verbose instructions when help is only a click away? This help is still *in process*.

In the more useful of cases, the help will be well designed and also cross-reference other material that the user may need and may even offer references to the manual or to the manufacturers website. Or even a tutorial with screenshots (or sometimes all of them).

Does your web application usually run maximized? 
Does your GUI application?

Yes, but that is a user decision and not a distinction on the type of application. Some apps (desktop) I may not run maximised and some I may switch depending on screen estate. It should not affect the application per se.

That is down purely to UI design which is just as complex but is, in my opinion, a different area. You choose the ui based on the audience and the platform. How you present is based on those decisions. How the user interacts is then derived from that. Regardless of browser or custom desktop.

[revdiablo]

Such a long post probably deserves a long reply, but unfortunately this will be neither long nor thorough. I think you're right that desktop apps and web apps are conceptually the same, in terms of complexity. The difference is they are not the same in terms of "physical space." The interface is, by necessity, much different. Dealing with people where I work, it seems interface issues make up a large amount of the problems with traditional desktop apps. By comparison, web interfaces are very simple, and usually fairly similar: fill out a form, click submit; click a few links here and there. There's just not as much there to be confused by. Of course, I'm sure a determined developer could confuse the bejesus out of their users with any interface, whether web-based, desktop-based, or even paper-based, but that's a whole different topic.

[Anonymous Monk]

I'm referring to predominantly intranet based applications with more complex tasks than fetch-print.

Then surely you are not talking about internet applications built in HTML. As you half-said, the HTTP protocol can only provide a fetch-print environment. Anything more requires the addition of client-side scripting or client-side browser plugins (such as flash or java).

[kal]

I think it's just a question of culture. HTML applications - although you're talking about intranet, I'm thinking more about internet - need to be usable by people visiting, people who have come across the application for the first time. If people needed training to use web sites, then the idea of the web would quickly fall apart. I would suggest that it is this cultural idea that you're being affected by; that users should be able to "discover" web apps. Whether or not the app is on the internet or an intranet is probably immaterial; the feeling is that of the internet.

One other difference is that traditional apps tended to perform tasks that were new, or did things in new ways. Web apps tend to be more aimed at supporting existing processes often, and the user would come to the app with a pre-defined expectation of the task. People shopping on an e-commerce site, for example, would have the idea of a cart and a checkout. Intranet users may be in a similar position for many of the tasks they wish to perform too. Again, this is kind of a cultural thing.

I agree with you, to the extent that the UI of the application is likely to make little difference to the training need of the user (by that, I'm talking about technology, not design - design is clearly extremely important), so the fact that one app is coded in W32 Forms and another in HTML doesn't mean the HTML one doesn't require training. But, there is a difference there, in culture and expectation.

[hoycen]

Simon, I would totally agree. I think most users perceive desktop applications to be more complex because they feel that if they know how to use a browser, they should automatically know how to use the web application that it presents.

In a way this is good because it encourages developers to make interfaces as self explanatory and accessible as possible. Intranet and to a certain extent intranet are in a much more exposed competitive environment than desktop applications. If a site doesn't work how you expect it or it is difficult to use, its much easier to go to the competitors offering than it is to swap desktop apps. For example, many people in big organisations have web access but do not the privs to install new software on their machine by themselves.

In an ideal world our web applications would self-customise their interface for the user depending on the users experience, know-how and so on. Many vendors are now adding desktop app style first-use help tips to users which acts as a training course on using the application/site. I think this is a really positive step forward for web applications.

[dragonchild]

This is a maturity thing. There are very few complex applications on the web. Very few. And, most are not used by the average users.

Plus, those few non-trivial sites people do use (Amazon, EBay, Google, Paypal, Yahoo, etc.) have had thousands of man-years devoted to their design, making it as easy and intuitive as possible.

As a web-developer who builds non-trivial apps, I feel your pain. We are simply not provided with the resources to do what we are asked to do. In that, we are not alone. Very few professionals have the luxury to have everything they need (let alone want!) to do what they're asked to do with excellence. *shrugs*

[EvdB]

It may have a lot to do with the fact that websites tend to be more verbose in their instructions, so that traditionally website have had their documentation in place.

For example a desktop app may ask for 'user_id:' where as the web app would ask for 'Your email address:'.

There is alot more space on a web browser's screen for this sort of thing than in an apps dialog box. This does not excuse the mindset but does partly explain it.

This does nothing for the underlying complexity though, if the user does not know what the app is attempting to do then they will probably not be able to use, regardless of the UI.

[simon.proctor]

For example a desktop app may ask for 'user_id:' 
where as the web app would ask for 'Your email address:'.

I'm sorry but I don't quite agree with the above. In the desktop apps that I have written if I wanted their email address I would ask for it.

As to documentation in place. I can see your view point in one respect as we typically allow for instructions above each form (as an example) that explain the processes or requirements of the following immediate action. However, that does not really help to reinforce the process as a whole nor does it really ensure the user is aware of what is happening (which is in reference to your last point).

All that it does is ensure that *at that point* in the application the user *is somehow aware* of the requirements of that *particular form*. Of course whether its the right form for what they want to do is down to the application and the user ;).

I guess ultimately it boils down to how much confidence you have in your user base and how complex the application is (which is in itself a moving target with shifting user requirements).

Thnx - SP

[zentara]

I observe that people "expect more functionality" from a desktop app, than a web app. Why?...because the desktop offers more tools for the developer to use. Web apps are severely limited by the web-browser interface, cgi restristions, etc. Whereas the desktop app has the option of which GUI interface to use, more access to the filesystem, etc. So, with more functionality there should be a "higher learning curve" for the user. I think we've all experienced the dissapointment of starting up a desktop GUI app, and finding it is no more than frontend for running a commandline program, without all the options available on the commandline. So you have to put all those options in a menu, which requires the end-user to know what they mean. I suppose you could design web apps to do this, but I guess the old adage "write for your audience" applies. It does seem that the general consensus is that the average web user is not as competant as the average desktop user.

[fraktalisman]

zentara wrote:

I observe that people "expect more functionality" from a desktop app

The more a web app looks like a desktop app, the more the untrained user expects it to behave like one.
Often customers ask me: why is xyz not possible in this web application? and when I tell them it's maybe possible but hard work to make it work, they would say something like "but windows can already do it" and I start to explain the differences for the x-th time...

[zentara]

Often customers ask me: why is xyz not possible in this web application? and when I tell them it's maybe possible but hard work to make it work, they would say something like "but windows can already do it"

Yeah, but notice how insecure windows is, it's "the bane of the internet". After all my reading about the web and cgi apps, is "Assume the client is evil or stupid". Otherwise, you comprimise security.

I think most intelligent web users realize this, and accept the "strict functionality limits" on CGI apps.

[flyingmoose]

Sort of related -- there is an even greater disparity when it comes to cross-platform apps. While a Unix/Linux app is allowed to be convoluted, typically the Windows apps need to be AOL-user-friendly.

In my organization, this has resulted in the usability-inclined testers hammering hard on even 'normal' Linux operations, causing them to fall out of the Linux idiom -- were are talking about fear of editing text files, fear of RPM's with dependancies, etc -- while this is just an education issue, it's another example of user-friendliness being taken to areas where it is not required (in this case, Linux servers and system administrator tasks). The result is that our Linux apps probably offend hardcore Linux users by trying to do things the wrong way. For instance, our command lines are way too verbose and usually have too many prompts and too much output.

In general, though, I'll say usability is a very good thing for end users...but part of the reason I like Linux is that it *encourages* tinkering under the hood.

As an analogy, suppose Linux is a car and your program is the engine. If you take it apart and reassemble it incorrectly (for example: say you borked a config file), the Linux idiom says this is *your fault*, while the Windows idiom says the you should never have been able to do this in the first place.

The HTML interface versus program GUI interface is a similar issue. Different people think usability means different things, and it always depends on who your audience is. In my case, my code is being tested by folks who like AOL-like interfaces (sigh), thus one has to write Linux apps that behave like Windows apps ("Are you really really sure you want to delete that logical drive?").

Conclusion: usability is something different to everyone. Usually the person writing the requirements has the final straw. Whether the camel's back is broken depends on how much you like to do usability things -- I don't :)

[ryantate]

I disagree with the premise. If I need a manual or, egad, training to make basic use of desktop software, I consider it failed. It may not be the norm on this site, but elsewhere in the world users don't read documentation.

What I do expect to turn to a manual for are particularly complex operations, like multi-layer multi-step image manipulation or writing a spreadsheet macro -- operations that by and large do not and probably should not have a Web app counterpart.

This is because network latency, non-standard UI and other concerns make the Web a pretty crummy environment for complex software operations.