On Wed, 13 Jan 1999, Jim Fulton wrote:
Some other ideas to kick around:
- Some additional change buttons:
"Change and View" - saves changes and shows results. This should work nicely with the browsers back button I think.
"Change and Edit" - Returns immediately to the edit screen wo dialog.
"Change and Done" - Saves and displays folder contents.
Hmm. I believe the best way to accomplish this functionality is to *ignore* it! That is, *dont* add more buttons onto each editable screen. If you want a view, then have a 2nd browser open to reload it. Else things get hairy way too fast... Others: comments?
- A status area that gives some feedback on the previous action. The rule that we've followed is that we don't have to show the message dialog if the screen is different after an operation. This is why there's no dialog when adding and deleting items in a folder.
A status line could be blank normally and show something like: "Changes saved at <time>" after a change.
Jim
A policy I've used successfully is to have virtually all apps be one-pagers. That is, the "Fill out Form" and "Oops: please type zipcode again" pages are *the same*; except for a bit of code in the header that says "if there was a status message, show it; otherwise continue." For example, check out this app: http://www.mayohealth.org/cgi-bin/apps/list_mailer2?list=alzupdate Hit the form, type "haha" in the Name form, then press Subscribe. You'll get the same page back with a warning in the top part of the page. All fields remain filled-in, so you the user can just edit his information and continue. Another take: Netscape's Calendar product allows you to create tasks, meeting arrangements, etc. The web version uses a two-step procedure to show you that it accepts what you told it. Click "Create", it shows a small-font, one-line message: "Your note has been successfully created", then sends you to your main Calendar page again. This is more resource-intensive, but for intranet-type apps like this one it's very effective. - j