[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