Citát Jesse Ross <[EMAIL PROTECTED]>: > I've been putting together a chart detailing all of the interactions, > objects, menus and interface components we've discussed. In doing so, > I've run across a few pieces of conflicting and unclear information I'd > like to get your help with. I'm not done yet, so this isn't a complete > view of the system, but getting these details straightened out should > help us have a better view of how all of these pieces are interrelated. > Comments and corrections are welcome, as always. > > > Right Click > ============================== > In various places we have stated that the right-click is responsible > for: > > 1. Repositioning the main (vertical) menu to directly under the mouse > (GNUstep guidelines) > 2. Popping up circular (context) menus (I assume this is accessed via > right click, as context menus often are) (Etoile Flash presentation) > 3. Toggling between Pick and Drop mode and the regular mode (Pick and > Drop guidelines) > > I don't think all of these can be accomplished via a right click, as > they seem incompatible with one another. I would argue against creating > modes as much as possible, so I would prefer that Pick and Drop were > handled via a different type of interaction, perhaps by selecting the > item to be picked and pressing the Pick key (see Dedicated Keys below), > or selecting the item to be picked and dragging it to the Lower Left > corner (see Hot Corners below) to toggle the Shelf on, and releasing > the item over the Shelf. Dropping would be the result of either > pressing the Drop key at the insertion point or dragging the item to be > dropped to the Lower Left corner to toggle the Shelf off and releasing > at the insertion point. > >
I would remove the right-click at all from normal interaction and leave it for advanced users only. Considering mouse as our virtual hand, then the left click should be "use the tool in hand/bare hand". From my point of view, the right-click should be used for one of the following: - bringing up a transient tool palette (circular/rectangular menu) - bringing up a contextual menu (people are used to this from other environments), everything in the menu should be accessible in other means (not like in many GTK/Gnome apps, where there are functions available only through contextual menu) - switch between pointer and another tool (here I am recosidering my thoughts about his behaviour I have mentioned on the Wiki about pick&drop) > Menus > ============================== > There seems to be interest in using both vertical menus and circular > menus. Should we use both types, and, if so, how? > We can also consider the "icon menu" or more "transient palette" element as I have mentioned in my previous email. Anyway, the cicrular menu and transient palette should not contain more than 5-8 items. Also, I think that the transient menu should serve as shortcut to the main menu or other more complex action/tool picker. > Here's my proposal: > Both types have their advantages, so we should use both. Circular menus > should be used for items which don't change regularly and have few > top-level options, vertical menus should be use items which can change > regularly and have a lot of items. It makes the most sense for me to > use vertical menus to manage Component interaction with Objects (Text, > Table, Image, Audio, Person, Video, etc), and use circular menus to > manage interaction with the organizational items, such as Projects, > Documents, and Shelves and Applets. > I am confused here. > Since Components can be installed by the user to suit their methods of > interaction with an Object, a vertical menu gives the most flexibility > in terms of positioning within a list and number of items. It also > makes sense since Objects will be the things most frequently interacted > with to be able to use tear off menus to customize the work > environment. > > Things like Documents and Projects will have well-defined methods of > interaction. They are the prime candidate for circular menus, since > users will likely not be creating Components to interact with them. > No comment at the moment. > Here are my initial ideas for items in the circular menus (I'm sure > there are things I haven't thought of yet): > > Project > ----------------------------- > - New > -- Project > -- Document > -- Object > -- Annotation > - Duplicate > - Hide/Show Annotations > - Preferences > -- Background > -- Metadata > I would remove the "New" item. Creating new object in a project is dragging a prototype/template into the project container. Hide/Show annotations is too specific. I want Hide/Show images or hide/show green text in Lucida font with size <12pt. Or why do you think it should be here? Instead of "Preferences" I would use "Inspect" and the inspector panel will pop-up. So my suggestion for default actions would be: - duplicate - destroy - inspect > Document > ----------------------------- > - New Object > - Duplicate > - Save Checkpoint > - Publish > - View Checkpoint History > - Synchronize (for multi-user documents) > - Preferences > -- Size > -- Margins > -- Metadata > New object - not necessary. What exactly means "Save chackpoint"? I have several interpretations of that, so I would like to know yours. What is "Publish" in this cotnext? What is "View checkpoint history"? My suggestions: - duplicate - destroy - sync - inspect > Shelf > ----------------------------- > - New Applet > What is that? > Applet > ----------------------------- > - Preferences > -- Sticky > -- (Additional Preferences as they relate to the specific Applet) > What is "Sticky"? My suggestion: - destroy - inspect > All Objects would have two default items in their vertical menus: > Install New Component, and Link (to pipe data from one Object to > another). All others would be customizable. > What is "Install new component"? I agree with the "link", however, this is more complicated that it seems to be... > You may notice that some standard menu items are missing: Undo, Redo, > Delete, Pick, Drop (or Cut, Copy, Paste). I suggest that these be made > Dedicated Keys. > Undo/redo/pick/drop/cut/copy/paste... should be global tools in global tool shelf. > > Dedicated Keys > ============================== > Certain actions will be so frequent and/or work on so many types of > items (Objects, Documents, Projects), it makes sense to dedicate > keyboard keys to them rather than take up menu space. I suggest the > following items get dedicated keys (probably F1 - F12): > > - Zoom In > - Zoom Out Global magnifier tool - magnifier mouse cursor, accessible by a key. > - Search (Search Again would be Shift-Search) Global search tool. > - Hide/Show Shelf For advanced users + indicator of hidden shelf. > - Scroll (for moving through a zoomed-in Project, I'll explain below) In old applications it was called "pan" and the tools was "panning tool" indicated by an open hand/palm cursor. > - Pick (Pick a Copy would be Shift-Pick) > - Drop (Drop a Copy would be Shift-Drop) Tool with appropriate mouse cursor. > - Undo > - Redo Global actions. Note: You might notice that there are two kinds of things: Tools and actions. > Shelf > ============================== > We currently have two different Shelf implementation ideas: Tabbed > Shelf and "Dashboard" Shelf. Both are containers for two types of > information: extremely temporary info and extremely permanent info. The > Shelf stores files which need to be transferred between Projects or as > the result of a Pick -- I call this the Buffer portion of the Shelf. > The Shelf also stores Applets and documents which need to be readily > accessed across many Projects -- I call this the Storage portion of the > Shelf. It is unclear to me whether these should be two visually > distinct sections, or even two totally different Shelves. > No comment at this moment. I hope to prepare a short note about this, if not, then here are few random notes for thinking: - on MS windows people maximise their apps - people like to use "docked" panels/inspectors/toolbars/windows - docked panels have fixed position on the screen, between them is a work area - remove the window and allow users to dock to screen corners -> create detachable shelves > I would also like more info on what a Tabbed Shelf offers that a > Dashboard Shelf doesn't. It seems to me to be unnecessary, assuming we > allow Applets to be sticky. > No comment at this moment. > > Folders vs Projects > ============================== > It has been said that we may use Folders as well as Projects. What is > the advantage to having both? Having two types of containers, when > Projects offer much more functionality over Folders, seems like it > would confuse the user. > > What is the difference between project and folder? What are properties of folder and properties of a project? > Hot Corners > ============================== ... for advanced users. > The four corners are good hot spots for frequently used commands. I > would recommend that the corners be activated on click so as to prevent > accidental activation. I have assigned commands to three of the four > corners: > > Upper Left: Zoom Out > Upper Right: Zoom In to current selection Too far away. I want to finetune the zoom, i have to move over a large screen from one corner to another. What about somehow activated slider where one corner means maximum zoom and the other means minimum zoom and i can finetune the zoom level? > Lower Left: Hide/Show Shelf > > for advanced users. > > > That's all for now -- like I said, this outline is incomplete and I'm > sure I've missed a few things here or there, but please weigh in on > these issues because this determines how Etoile will look in the end. > Thanks for the good outline. Perhaps few images can help... Regards, Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
