Universal GUI

[Jan Schenkel]

--- Dan Shafer <dan at shafermedia.com> 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