[Sigia-l] Re: Designing Web Application Home Pages
Stephen Holmes
sholmes at labyrinth.net.au
Mon Dec 30 20:26:43 EST 2002
Jodi_Bollaert at compuware.com wrote:
> To: "'sigia-l at asis.org'" <sigia-l at asis.org>
> Date: Mon, 30 Dec 2002 08:50:36 -0500
> Subject: [Sigia-l] Designing Web Application Home Pages
>
> Greetings...(please excuse the cross-post to CHI-WEB)
>
> I'm working on the conversion of a Windows app to a web app. In a Windows
> app, it seems that most of the time you start with a blank screen (though MS
> has moved away from this in the latest version of Visio). On the Web,
> however, the practice seems to be to create a home page that acts as a
> gateway/launch pad to the rest of the application. Does anyone have any
> tips, examples, do's and don'ts, etc. for creating a web application home
> page? I'm especially interested in seeing examples if possible. I'd be
> glad to post a summary to the list.
>
> Thanks!
> Jodi
>
>
> ****************************************************
> Jodi Bollaert
> jodi.bollaert at compuware.com
> 248.737.7300 ext. 10370
>
> "Specializing in usability, information architecture, interaction design,
> instructional design and more."
Hi Jodi,
I've designed a number of web-based applications that where originally
desktop-bound; some originally based on Windows applications built in
Access and others in Delphi. I've also worked on WAP and SMS
applications in the telco market and all have different user interaction
targets and limitations.
I'd welcome feedback from the list on my ideas and questions as well, so
here goes!
When translating a desktop application to a web application you have to
go back a little and look first how user task-flow works in each
platform. Graphics are nice but will come after all user tasks are
specified and given their weightings and expected outcomes.
So let's start with our legacy application on the desktop. The blank
page on this desktop application is the "clean slate" on which the user
builds content.
The blank screen in any app on a desktop platform normally has a tool
bar at the top of every new page that is always the first point of
interaction with the application.
MS have added a primary task option window to a lot of their
applications to prompt the user on which task they wish to complete.
This window dressing has been added to get over the old 10/90/10 law
that only 10% of users know about and use 90% of the application and 90%
only use 10% of the application. The window shows all of the features of
the application at the start of each task. These options are also
available from the traditional pull-down menus so selection of the
primary task can be started in more than one way.
A user selects options from the drop-down lists and then uses that tool
in real time. Reaction is instant in the desktop app screen. The next
task is completed in the same way and errors can be instantly recognised
and fixed.
On a web application there is a web pipe to send instructions back to
the server-based application. Interaction is not instant and usually
only small increments of a task can be completed at each step before
sending the changed state(s) back to the app on the server. The result
is sent back to the web browser window of the user and the next action
is then planned and undertaken. Errors are harder to fix, especially if
a change has been made to a database on the server.
Flash and Java get around a lot of these pipe issues but have problems
of their own which I'll not go into here (don't want to start a holy war
here ;-) .
OK, so the first problem you have when designing a web-based application
is not what it looks like, but how fast it loads and how much server
work load is inflicted by a user for each step they take. The bigger in
file size the page is, the bigger the time lag between action and
result. Multiply that by how many sub-tasks are required to complete a
primary task and you will have an idea of the frustration level you are
inflicting on your users.
Broadband helps here, but remember that even in the US only 50% of users
have it (in Australia you are looking at only 10%!) so don't assume you
can load up heaps of graphics to make it look good. Work for inclusion
of as many simultaneous users as possible.
Loading a big "home" page each time a user starts a new primary task is
just not on. I've worked on applications designed to have 2,000 to
20,000 simultaneous users and 60,000 subscribers and you can imagine
what sort of load even a 50k opening page will have on your server(s).
Your server vendor will love you but the beancounters and techs will
hate you ;-)
The web interface to an application has to show the following:
All Primary Tasks - the primary purpose(s) of the application.
All Utility Tasks - membership, administration and preference screens
(or one-click access to these utility tasks)
On-line Help - how-to and demonstration screens are important
since the user doesn't have any printed manuals.
(HTML or PDF - both is better)
Contact Links - access to phone- or e-mail-based help. This is an
application, not a content site, so there may be a
time frame issue with the user's task. Contact with
humans may be vital.
Privacy Policy - people may be entering personal information even
just to register, and most countries - not just the
one you are hosting in - have legislation covering
the use of that information.
I hope this helps
--
_________________________________________________________
* *
* Stephen Holmes sholmes at topladder.com.au *
* Information Architect http://www.topladder.com.au *
* *
* Top O' The Ladder Design Kew, Victoria, *
* "new times, new solutions" Australia 3122 *
*_________________________________________________________*
More information about the Sigia-l
mailing list