On 8/11/07, David Chisnall <[EMAIL PROTECTED]> wrote: > On 11 Aug 2007, at 18:34, Yen-Ju Chen wrote: > > > I think both issues of > > (a) double-click on title bar minimize window > > (b) close button is harder to reach > > depends on how we think about users. > > If we think users are dummy, we do our best to prevent them from > > doing stupid things. > > All users do stupid things. A good UI allows them to recover from > doing stupid things, and makes it hard for them to do stupid things > that they can't recover from. > > > If we think they are geek, we let them do thing fast. > > So accidents do happen (close unsaved document, etc), > > If this can result in data loss, then we have a bad design, but > CoreObject should prevent this. > > > what is our philosophy to prevent accidents and recover from > > accidents ? > > I would like to treate users 'smart'. > > I don't see this as a dichotomy. > > > So for (a), it is easier to minimize on title bar > > so they can work efficiently. > > Fine. > > > And if they do double-click on the title bar accidently, > > just un-minimize it. Nothing loses. > > Depends on what minimise does. If it shades, or minimises in place > (which is what we are suggesting), then another double click fixes > the mistake, which is easy. If we minimise to a dock (or taskbar, or > whatever), then you need to find where the window went, move the > mouse there, click, then move the mouse back to do whatever you were > trying to do when you accidentally double clicked. This is a much > more expensive operation.
So as far as I read, double-click on title bar to shade or minimize-in-place is fine as current behavior ? > > > For (b), many applications do provide mechanism to > > warn users unsaved document, many tab on the web browser, etc. > > We shouldn't warn, we should provide undo. Safari 3 almost does this > right, by the way, and lets you un-close windows that you close by > mistake (but not, for some reason, tabs). > > > In that case, do we really want to make the close button hard to > > reach ? > > No, we want to make it easy to reach, which is why it's in a corner. Well, we are arguing left or right corner. :) While in your another mail, you think "close" is 'back' and should be on the left. I do think it is a matter of convenience. "Left" is harder-to-reach while "Right" is easier to reach and most people of right-hand. > > > I don't think so. Some window are designed to be closed often, > > like buddy window on StepChat. > > You may have noticed that these windows, when re-opened (even after > restarting the application) are in the same place and retain the chat > log from the day (or since the application was restarted, whichever > is further in the past), so closing a StepChat window is something > that is easy to recover from. This doesn't slow down 'smart' users - > there is no 'do you want to close' dialog getting in the way - but if > a smart users makes a mistake (which does happen, no matter how smart > the users is), then they don't lose anything from it. > > > We should let the application prevent accidents, not WM. > > In both cases, we should make avoiding accidents easy. > Yes, we should avoid accidents easily, but not hinder the regular uses. If accidents happen 1% of the time, a harder-reach button (left corner) actually waste users 99% of time. Actually position of these two icons are changable in user defaults. See READE in Azalea for user default 'TitleLayout'. We are just arguing what's the default values. Currently, it is 'NLIMC' (icon - title - minimize - maximize - close0 For Jesse's mockup, just do 'defaults write Azalea TitleLayout 'ILC' (minimize - title - close) Yen-Ju > David > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
