Last Modification: 08 March 1999
German W. Bauer
Initial Creation Date: 08 Mar 1999
Older spec, will be updated
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.
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.
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.
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
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.
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.
positioning it overlaying the content area (using CSS positioning)
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
positioning is directly related to content displayed
positioning it on the main
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
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
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
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.
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.
(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.
None planned at this point
Condition Message User Choices
Rev 1: first stab, based on UI design docs