В Срд, 05/11/2008 в 21:54 -0500, Philip Ganchev пишет: > On Gnome Live, I read about the the designs for a new Gnome panel: > http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore . > I am not sure where else to discuss the designs, other than the > usability mailing list, so here it goes. > > 1. The new design for context switching replaces the task list in > favor of an overlay showing windows and a side bar showing documents > and applications. The overlay and side bar appear when overlay mode is > invoked by the user. This is a bad idea. It will not work well on > slower computers. Also, switching tasks is done so often that the > list of tasks (windows) should be available to the user at a glance, > without requiring interaction. It is done more often than switching > user or changing status, and even than changing the volume, and > checking the time, the weather, battery status and network connection. > So the task list deserves the space on the panel more than all those > other applets. > > 2. There will be only one panel, placed at the top of the screen. I > applaud the removal of one panel to save screen space, but why should > the remaining panel be at the top? There it will interfere with the > quick un-maximization (or roll-up) of maximized windows, which is now > possible by throwing the mouse to the top and double-clicking. > Similarly, it will interfere with convenient closing of maximized > windows. Neither of those problems exist with the panel at the bottom > of the screen. And, all other operating systems place it at the > bottom. Same here. I always move my top panel to the bottom just in order to have the ability to throw the cursor up the screen and do something with the maximized window. (And I make a sidebar out of the bottom panel obtaining a lot of place for a window list, by the way. I know there are people that hate sidebars, but anyway the top screenwide panel affects window manipulation experience.) Another idea is a not-screenwide panel by default (never used MacOS, but they say they have such a thing). That will at least allow for quick moving to the screen corner(s) and simplify moving to the edge (compared with a screenwide panel). > 3. Activities will be sets of applications to be launched together. > This is too complicated as a UI and approaches the problem in the > wrong way. Instead of starting all applications which I might need at > the start of editing a photo, there should be an easy and seamless way > to start applications as I need them and to pass the photo to them. > That can be done either in the new sidebar, or through the > applications themselves. For example, photo viewers should have a menu > entry to open the photo in the image editor, and a menu entry to post > the photo to a web service. I'd like to add to this, that having a developer framework that facilitates passing documents from one application to another is a good way to facilitate good-old UNIX pipelining of programs. Concerning this, I absolutely love nautilus-sendto application, that allows me to archive selected files to a tarball before sending. The next thing I'd love to see in the same place is signing/encrypting files before sending, so that I never thought of Seahorse (whilst using it, however). In the end, this is a task-oriented approach vs. application-oriented one. > 4. A notification applet on the panel will aggregate all desktop > notifications, such as received email messages, battery status and RSS > feeds. I think this is a good idea, but not if it replaces the > permanent status icons. The actual status of things like battery, > network, weather and mail is what the user usually wants to see. > Trying to discern status from the notifications will be more work for > the user. For example, if you only want to know how many unread email > messages you have, you would have to perform an action to filter the > notifications. It is easier to have a mail applet showing that number > without interaction, and showing the list of latest messages on > mouse-over. I support that. Of course, status area should not be implemented via notifications. -- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=