Re: A New Keyhole Type!

White Wolf <[email protected]> wrote:
> Hendrik Schober <[email protected]> wrote:
> > White Wolf <[email protected]> wrote:
> > > [...]
> > > > Our Open and Save dialogs are still modal.
> > > 
> > > I can see no technical reason why they should be [...]
> > 
> >   I can. Suppose they were modeless. Suppose a
> >   user opened the "Save as" dialog. Suppose they
> >   then open the "Open" dialog, open a document,
> >   and then go back to the "Save" dialog and hit
> >   "OK". What is going to get saved?
> 
> What is in the open window.  Or nothing, if that save as...
> dialog is designed that way.

  Now that's confusing even to me... 

> [...]
> > And,  worst, who is going to explain this to the users?
> 
> The software and its help file, just like anything else.

  Do your helpfiles write themselves magically? 
  Ours don't and the guys doing the work are 
  very keen on getting software that's easy to 
  use. Looking at computer users surrounding me 
  I know why. 

> [...]
> >   Sigh. I looked at OE, because that's what I'm
> >   using for writing this mail.
> 
> OE is a 10 years old design, not maintained anymore for
> years.  I would not try to draw any conclusions about it.

  It's good enough to get a few examples. 

> > In the first menu
> >   item, "Print" seems to be modal. I agree with
> >   this decision for the same reasons as I agree
> >   with making "Save" modal.
> 
> I do not see any sound technical reason why they *must* be
> modal.

  Then you should go back and read my posting
  where I described why I think it must. (And if 
  you don't agree with my reasoning, then please 
  do so by answering that posting.) 

> > Another prominent one
> >   is the account dialog. (Whatever it's called in
> >   non-German versions; I mean the one you manage
> >   your email accounts with.) I wouldn't want to
> >   try to change account settings while users are
> >   allowed to hit the "Receive" buttons.
> 
> And why not?  Because that dialog is *not* built properly,
> it is *not* communicating with the rest of the system using
> messages, but it is fiddling with the data structures
> directly.  Bad design.  A simple observer would solve the
> issues of distributing changes to the interested parties,
> and a simple copy-before-start (or copy-on-write) would
> ensure that nobody will change the data once a send/receive
> tasklist-item started to use it.  I mean that data, what it
> started to use.

  You're way to obsessed with the fact that this 
  is solvable programmatically. In case that's not 
  clear: I don't doubt that this is possible in a 
  technical way. But I seriously doubt that it is 
  a good idea to do this from a usability POV. I 
  don't see the possibility to erase accounts 
  while they are being used a great enough gain 
  to warrant the increase in complexity. 

> > And, again,
> >   neither would I want to explain the logic that I
> >   I settled for.
> 
> It is your decision.  It is the customers decision which
> software they will buy. [...]

  Right. And the company I work for strives to 
  offer those choices which users decide for. 

> [...]
> Attila

  Schobi