No subject

Here are some thoughts based on my experiences:

1) List the entry points of the most common tasks on the home page.
2) Usually, there are not a lot of entry points so the home page is quite
empty.  In this case, place  more detailed information for the user to
perform the tasks.  For example, instead of placing "Search for accounts"
link, in addition, you place common search criteria so that the user can
perform the search immediately.  
3)Design some customization areas.  For example, Messages, Reminders, etc.
4)Place navigation links to other applications if it is common that the user
needs to go to other applications from this application.  
5)Some admin links can also be placed on the home page - e.g. preference
settings, technical support, etc.

- Cindy

*****************************************************************
Stephen Holmes [sholmes at labyrinth.net.au]:

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.

*****************************************************************