--- Dan Shafer <[EMAIL PROTECTED]> wrote: > > On Monday, July 28, 2003, at 09:01 AM, Jan Schenkel > wrote: > > > Now we've settled on a design where the user sees > all > > the fields and option menus and checkboxes, but > > they're all disabled until the user enters 'Edit' > mode > > by clicking the 'Edit button', then they're > enabled > > until the user clicks the 'Save' or 'Revert' > buttons. > > During edit mode, other buttons such as Previous > and > > Next are disabled. > > > IMNSHO, this is just fine. (Not that you -- or > anyone else for that > matter -- really ought to care what I think!) > > This is a case of mode-based interfaces. While I > generally do not like > such interfaces, this is one of the clear > exceptions. As a use, I > *view* the data in one mode and then switch to > *edit* mode to make > changes. > > I presume since you guys have been at this for a > while that there's a > sound reason the user might want *not* to be in > editing mode (or that > your program wants him not in that mode). Otherwise, > I'd eliminate the > "uneditable" view and just put the user in a > position to both view and > edit the content in the same screen/layout. I've > very rarely found a > reasons to do modal programming after thinking about > the situation for > a bit, but I'm sure valid situations exist. >
Well, it started in earlier projects as part of the safety and privileges framework : not everybody can change certain data or even look at it -- yes, an excellent case of progressive disclosure. But what encouraged us to stick with this decision was the time one of our customers was losing data in some of their FileMaker solutions because people would leave their computer focused on a field and then put things on their keyboard and you can guess what happens : lots of random characters in various fields, and no undo is going to revive the record. And because nobody ever did it -- *chuckle* where have I heard that one before? -- these things would only be discovered weeks or even months afterwards. We do allow multiple windows open at the same time, so people can view the data they want, and jump back and forth between the ledger history and customer information, etc. But on edit time, the window becomes modal, and buttons and fields get disabled/enabled. And if you put something on the keyboard, there's still the Revert button. And now that harddrive sizes permit it, we keep the older versions of records around for the administrator to correct accidental changes. But this is digressing from the issue ; I may well be the only one on the planet, but I liked balloon help ; it pointed at the control it belonged to, and a few developers were even nice enough to explain why some controls and menuitems were disabled. Compare that with disappearing menus � la Windows / Office 2000, and tooltips that aren't even displayed for disabled items. At any rate, after reading the many posts in this thread, I think we're all pretty much in agreement here : show what's relevant, hide obscure things, and streamline the process of data input as much as possible. And far more important : have a good manual and help file with a full index so people can find out how to account for the temperature in Dar's lab ;-) Jan Schenkel. ===== "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
