Re: [Usability] spatial desktop
According to what i understand about spatialness, is about a single object being in one place the way it was when we left it there. I think this is hard to do currently because the difference between files/documents and apps is fuzzy. Almost all the time, we open an app and a new document is there, we open gedit/abiword/gnumeric/etc and a new document is already there. This makes it hard to point out what the object is, is it the app or the file?? Is a window an application or the document??? However, we can start some where. In nautilus to be exact. In spatial nautilus, when we open a folder, it gets shaded/greyed and we cannot open it again. This should be the case for files. We open a file, it gets shaded/greyed and we cannot open it twice. But then again a shaded/greyed icon still represents the file object and we would still have two objects for the same file; an open window and a shaded/greyed icon. And because of this, we hit a wall when we are allowed to move the shaded/grayed icon to somewhere else. What i'm saying is we shouldn't be able to move the shaded/greyed when in this state. After doing this for nautilus, we go ahead to do it everywhere like in the control center, etc. However, we hit a wall when we try to do this for application launchers which would typically allow us to open many windows i.e. firefox. So launchers break the spatial philosophy. Thinking about breaking the spatial philosophy, even the task bar breaks spatial philosopy. What do task bar entries represent, the app open or the document open. If it's the document, that's 3 objects (shaded icon, window, and taskbar entry), if it's the app that's 2/3 objects (launcher, window and taskbar entry). Happy day Brian ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] spatial desktop
Does that mean I won't be able to have both applications open on thesame file on the same screen? we would have both tools open/loaded onto the document but not using both at the same time. When using the text editor, we have the text editor's tool bar and menu bar, etc on the document, then with a key stroke to switch tools, the editor's tool and menu bars are replaced with the hex editor's tool and menu bars. I am completing a topaz mock up for which i'll post a link soon. Happy day Brian ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] spatial desktop
I always like to remember that in usability, a metaphor is a tool that can, frankly, be taken too far. We need to be mindful of the fact that metaphors can reduce usability if applied incorrectly. I think limiting a user's ability to interact with their files in an intuitive manner because we want to stick to the spatial or desktop metaphor would be a mistake. There is a use case I think for a user having a single document open in two apps simultaneously on a screen. Kirk brian muhumuza wrote: Does that mean I won't be able to have both applications open on the same file on the same screen? we would have both tools "open"/loaded onto the document but not using both at the same time. When using the text editor, we have the text editor's tool bar and menu bar, etc on the document, then with a key stroke to switch tools, the editor's tool and menu bars are replaced with the hex editor's tool and menu bars. I am completing a topaz mock up for which i'll post a link soon. Happy day Brian ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] spatial desktop
On 9/15/06, brian muhumuza [EMAIL PROTECTED] wrote: Does that mean I won't be able to have both applications open on the same file on the same screen? we would have both tools open/loaded onto the document but not using both at the same time. When using the text editor, we have the text editor's tool bar and menu bar, etc on the document, then with a key stroke to switch tools, the editor's tool and menu bars are replaced with the hex editor's tool and menu bars. I am completing a topaz mock up for which i'll post a link soon. I'd like to be able to have two applications/windows on the desktop at the same time (one left, one right) with the same document open. Limiting yourself to a single view should not be done. ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] spatial desktop
On 9/15/06, Olaf van der Spek [EMAIL PROTECTED] wrote: I'd like to be able to have two applications/windows on the desktop at the same time (one left, one right) with the same document open. Limiting yourself to a single view should not be done. I believe that multiple views of the same object should be a feature provided by the application when it is useful. The difference to allowing multiple instances of the same object is, that accessing the object again (for example by clicking its desktop icon) would bring all existing views to the front instead of creating yet another one. I also believe that we should always allow a single object to be open in more than one application (handler) at the same time. I could imagine interfaces where data objects and tools are separated, but none that could be realistically implemented anytime soon. Daniel ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
[Usability] Topaz [was Re: spatial desktop]
On Fri, 15 Sep 2006, brian muhumuza wrote: Date: Fri, 15 Sep 2006 13:51:34 +0300 From: brian muhumuza [EMAIL PROTECTED] To: Usability gnome conference usability@gnome.org Subject: Re: [Usability] spatial desktop cannot open it again. This should be the case for files. We open a file, it gets shaded/greyed and we cannot open it twice. This would in some ways be a step backwards from what we currently have. If you are willing to provide the necessary code people could probably be persuaded to try it but without code I do not think that suggestion will be adopted. If you are sure that one step back would allow two other steps forward I would encourage you to think of some other way to achieve similar progress. Why can't I open a file in both a text editor/viewer and a hex editor/viewer at the same time? Going down that road can lead to many places but the road i'll take leads to discussion about gnome 3 (project topaz). If I was being cynical I would say Topaz isn't going to happen and we are going to continue with gradual improvements over many more 6 months cycles. There will eventually come a time when Gnome wants to switch to Gtk 3 and deprecate various old API's and at that point there might also be a Gnome 3 release but the ideas that Topaz would be dramatic change are unlikely. My thinking is that if the Novell Slab start menu were to be adopted, dramatically changing the default layout it would be as good a time as any to declare 3.0 and move on. Back to our desktop, Our desktop is heavily dependant on mouse and keyboard input. I think including a typing tutor by default, and getting users to learn to type could fundamentally improve the experience users have interacting with their computers. It occured to me several times over the past few years that users are not comfortable with the primary input system for their computer so it is no wonder computers are so difficult to use. Imagine driving if you had to look down at your feet and check which pedal was which? We assume a pen or pencil is a comfortable way to work but that is only true because were are all schooled and literate but it was once difficult to learn. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
Re: [Usability] Mac-style menubar in GNOME
On Sep 13, 2006, at 2:47 AM, Zoran Rilak wrote: ... I'm working on a simple panel applet that would provide functionality similar to Mac's menu bar. Adding the applet would cause most menu bars to automagically disappear from their respective windows and migrate into the applet's area. Removing the applet would restore menubars to their parent windows. This is *excellent* news. I warn you, though, it won't be simple. :-) Obvious and contrived implementation issues aside, I would like to probe the list for any and all comments on the potential usability of such an applet (and analogously its potential testing user base). ... Short-term advantages: * Much faster, because the menu target area is near-infinitely high. * More compact, because there is only one menu bar on screen at once. * More predictable, because 99% of menus open down and to the right, regardless of where the window is. * Less confusing, because multiple menu bars on screen simultaneously sometimes result in people clicking the wrong one. Long-term advantages: * More consistent, because Nautilus can provide a menu bar for the desktop just like it does for folder windows. * More consistent, because Edit menu items (Undo, Redo, Cut, Copy, Paste, Delete, Select All, Check Spelling) can be made available for text fields in dialogs as well as for normal windows. * More consistent, because programs won't do things like not having an Edit menu (e.g. Gaim) just to save horizontal space. * More flexible, because programs with narrow windows can introduce full sets of menus without resorting to abbreviations (e.g. Xtns in Gimp), big grey parent windows (e.g. Photoshop for Windows), chevrons, or wrapping. * Simplifies the whole interface, because menus being easier to use reduces the number of controls desired in toolbars and elsewhere. Short-term disadvantages: * Requires clicking in a window before using its menus. * Can be slower, if your pointing device is (mis)configured such that you can't reach the top of the screen in a single motion. * Prevents using hover-to-focus (analogous to how CUA keybindings prevent using Emacs keybindings). Long-term gotcha: * For a global menu bar to achieve widespread use, XUL (Firefox and Thunderbird) and OpenOffice.org will both need to hook in to it. (Fortunately, there is precedent for this in XUL and NeoOffice on Mac OS X.) Suggestion: * When a child window without a menu bar (e.g. a dialog) is focused, instead of blanking the menu bar, show the menus of the parent window but disable them all. This will make the menu bar look more stable. Please keep us up to date with how you're getting on, and/or publish the code so others can help out. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
