Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

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

by simon.proctor (Vicar)
on Mar 08, 2004 at 11:58 UTC ( #334771=note: print w/replies, xml ) Need Help??

in reply to Re: OT: Users and software - desktop and web user mindset differences
in thread OT: Users and software - desktop and web user mindset differences

... 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.

Replies are listed 'Best First'.
Re: Re: Re: OT: Users and software - desktop and web user mindset differences
by revdiablo (Prior) on Mar 08, 2004 at 19:11 UTC

    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.

Re^3: OT: Users and software - desktop and web user mindset differences
by Anonymous Monk on Mar 08, 2004 at 20:28 UTC
    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).

      Well yes and no. Perhaps I'm being a little vaque here but deliberately so. However, I refer to intranet applications purely because it allows you to make various assumptions about the user base, the method of access, the operating system and even the times of access (yes my company is that controlled).

      I put it across in that manner to (hopefully) avoid arguments about generic sites with generic purposes - forums for example. If I were thinking of general internet apps then I'd be thinking of online tax forms, general internet banking etc.

      These apps have hundreds of thousands of man hours behind them and millions of dollars, pounds (etc) invested in their development. Where I work anything that costs less than £10,000 isn't considered a project. However, that said anything under that value could be a 3 month project for me - a significant investment of my developer time.

      With respect to client side javascript, flash, shockwave etc then sadly that all comes under the same umbrella in the companies where I have worked. As long as it works and doesn't use an applet. In the team I work we stick to server side programs with interface enhancements using javascript. Its not pretty sometimes but it allows us to enhance the ui. Because of our limited audience we can get away with it too.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://334771]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (2)
As of 2023-06-01 16:40 GMT
Find Nodes?
    Voting Booth?

    No recent polls found