Navigator Seamonkey
UI Specification
Navigator Wallet
Last Modification: 08 March 1999
Author German W. Bauer
Initial Creation Date:  08 Mar 1999 
Status: M2
Quick links: 
Design Overview
Design Cheat sheet
Design Details 

Seamonkey Product Requirements Document
Seamonkey Wallet PRD

Wallet Engineering Spec

UE Framework for Seamonkey
Overall Seamonkey UI Specs Page on gooey

Feature Team
 
 
Backend Client Engineer Steve Morse
Marketing wallet Kevin Yen
XPFE ?
QA Manager ?
UI Design German Bauer
 

Older spec, will be updated

Summary/Overview


The wallet is a new feature in Seamonkey which will help end-users
users with the task of filling out forms when buying from e-commerce merchants. Initially this will be a system that works/is triggered through the client, but eventually will be consolidated with the more advanced (merchant)server-to-(AOL)server system that AOL uses (AOL Chick Checkout).

An older ideas document can be found here.

Goals for our end users

Promote pleasant experience of online shopping by convenient re-use of personal data, while providing a sense of privacy and secure handling of this personal data.

Generally simple end-user (no-) interface, things 'should do the right thing automatically' when used first. Adding many screens will negatively impact acceptance of technology.

Take into account that shopping/checkout will be only used in Navigator and only for x% of user's online time, such design so that it does not get in the way of regular Internet browsing.

Minimize user confusion when encountering a site that has another wallet system employed such as AOL Quick Checkout.

Target Audience

The target user for this feature are Communicator Seamonkey users as described in the Seamonkey PRD, in particular those wanting to buy goods on the Internet.

User Tasks

 
Fundamental Tasks Intermediate Tasks Advanced Tasks
  • Fill out forms needed for online shopping
    • Change/Update personal data (e.g. when user has new address)
    • Turn off automatic filling out of forms

  • Design Cheat sheet

    Default look when encountering a wallet-enabled site

    Default look when encountering an AOL Quick Checkout site


    Design Details

    Interaction sequence

    this animated mockup shows the appearance of the toolbar button as users encounter a non-wallet site (Netscape), a wallet enabled site (book.com) and finally a AOL Quick checkout enabled site.


    Positioning of Action Button

    The current thinking is to show the button on the Personal Toolbar, right-aligned with the window border. It is only shown when users are encountering a 'wallet or AQC enabled' site. If the window resizes the button should still be visible. In other words it gets drawn over the current content of the personal toolbar and is not in a fixed position.

    Alternative positioning considered

    positioning it overlaying the content area (using CSS positioning)
    Cons:
    overlaying/compositing may impact rendering performance/ may be costly to implement
    Users may not expect an action button to be located on top of the content area
    Pros:
    positioning is directly related to content displayed

    positioning it on the main navigator toolbar
    Cons:
    main bar is reserved for core navigation functionality
    by default main bar will probably not be positioned close to content area

    positioning it on the taskbar
    Cons:
    the taskbar is reserved for launching apps/services
    the task bar will appear in every C5 app, even though wallet functionality is relevant to Navigator only at this time

    positioning it on the status area at the bottom of the screen
    Cons:
    the status area is reserved for status information
    the status area has a lower discoverability, i.e.. users may not notice the appearance of a button
    the status area is not usually associated with having action buttons, i.e.. users may not click there

    Additional Menu Item

    there will be a menu item in the Edit menu, possibly labeled similarly to the toolbar button to allow for mouse-less access. Decisions wrt. to a keyboard shortcut will be made later.

    Updating user's data

    will be implicit. Whenever the user overrides data in a form, that had been filled out using wallet, he or she will be prompted whether the wallet record should be updated next time.

    Wallet cannot figure out the mapping of a form element

    (Not sure whether this can happen) E.g. when the merchant site updates its form to include a new unknown field we should highlight that field. In addition after the form has been filled out, the client view should scroll back to the unknown form element and let the user fill out the data manually. In addition, we could update the server data to prompt that updating is needed for this merchants form mapping description.

     


    Open Issues


    Menus & Preferences 

    Context Menus


    None planned at this point

    Preferences

    In trying to keep things simple we are hoping to only have one global preference, and that is turn Wallet features on or off.

    Error Messages and Dialogs
     
    Condition
    Message
    User Choices
         
         
         


    Archived Documents

    Examples of special formatting:

    Revisions

    Rev 1: first stab, based on  UI design docs

    Special Notes

    This is a pre-release document based on refined designs