... 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
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.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.