On Nov 13, 2003, at 10:09 AM, Alan Horkan wrote:
Gnome HIG and Escape, search for the word escape on the following page: http://developer.gnome.org/projects/gup/hig/1.0/windows.html It describes that Escape is used to dimiss message dialogs.
Escape is usually synonymous with Cancel and I would expect Escape to cease the current task in the safest least destructive way (i.e. avoiding data loss).
My mantra will very likely become "If in doubt copy Adobe Illustrator". Consistancy is a poor substitute for well thought out Usability solutions but it is better than making whole new and unusual oddities with which to baffle users.
We've already assessed that these things should no longer be called dialogs, they are instant operators, I prefer palettes, but it honestly doesn't matter.
#3. Alternatives In Illustrator, you can hide all dialogs by hitting "Tab", this provides you with a quick device for previewing your work without interface clutter, or maximizing your work area regardless of tool
An alternative keybinding would definately be preferable to using Escape.
If the purpose of Preview is to have the most possible available space available then also having a Full Screen View would be brilliant. As I recall Adobe use F (and or Shift F) to toggle through Full Screen, Full Screen with Menubar (my personal favourite when using any program extensively focussed on specific dedicated task) and back to normal again.
I was waiting for someone else to bring that up, F to enter fullscreen would be superb!
panels. Tab again will show the dialogs that were hidden in the last operation. I propose that we implement this with one addition: Shift+Tab, or Shift+~ would be used for closing the currently
I would warn you that ~ appears in various different places on peoples (/nationalities) keyboards and could be quite an annoying keybinding.
Perhaps Ctrl+W then, those two keys show up in the same place on most keyboards and it's a standard on the mac to close the window ( well, command+w is anyhow ) windows uses ctrl in place of command. I can't stand that but it's gonna have to do.
We could then provide some form of modality for the dialogs that are left, and windows would behave differently depending on what was to be done.
I think the Gnome HIG encourages the use of non-modal instant-apply dialogs, and I have difficulty imaging or remembering the exceptions where a modal dialog might be really necessary.
The idea as stated above is to make any dialog that operates on shape data a palette or "floater" or "EditBox", functions that produce radically different output ( Transformation, Filters ) could remain dialogs, and be modal, however there are many different methods to use, and I prefer having everything exist in non-modal palettes that can be anchored, or dismissed.
I welcome any further discussion on this, as I could be totally off-base with the entire thing. I guess we really wouldn't know until we could see it implemented both ways and by then all the work would be done.
Hope my comments are of use.
Totally.