On 3/30/07, Jesse Ross <[EMAIL PROTECTED]> wrote:
So... lots of interface ideas flying back and forth around the list and SILC channel lately. ;) I started doing some mockups of some of these ideas, which you can check out here: http://jesseross.com/clients/etoile/ui/concepts/01/workspace_100.jpg http://jesseross.com/clients/etoile/ui/concepts/01/workspace_200.jpg http://jesseross.com/clients/etoile/ui/concepts/01/workspace_300.jpg http://jesseross.com/clients/etoile/ui/concepts/01/workspace_400.jpg A lot of this stuff hasn't been agreed upon by everyone, but it helps to incite discussion by seeing it in a somewhat realistic form. Here's what the above are:
Those look great, great theme too. 100 is a view of a desktop with a single project on it. This project
has been minimized.
Placing projects like that tends to lead to an overcrowded desktop, making it hard to figure out which is which, naming the minimized projects or labelling of some sort could make it easier. 200 is a view of that same project zoomed in. I haven't determined
how to indicate where you currently are in the hierarchy of projects, if that's even necessary. I also haven't decided how to zoom back out of the project (perhaps double-clicking on the desktop...?). Some additional things you can see from this mockup:
would it be possible to "zoom in" only one object from a project -- in situations where a project has very many objects and you just want one without opening everything in the project. Would it be possible to zoom multiple projects at the same time? How would window management between the different documents and projects be like? Would it be possible to put windows of non-document based apps like configuration tools into a project? - Person icons, with status indicators (differentiated by both
color and shape) - No titlebars. The idea behind this is that we would use a modifier key to indicate small vs large movements on active documents. Small movements are things done _within_ active documents and large movements are things done _to_ active documents as a whole. So, for example, to open a non-active (minimized) document, one could just double click on it (no modifier key necessary as this is on a non-active document). Once it is opened, in order to move it around, one holds down the modifier key and drags it around (large movement). To minimize the window, one holds down the modifier key and double clicks (large movement). I've just started getting some of this into Flash -- all you can do is use Alt to switch between the modes and move the windows while in "Large" mode: http://jesseross.com/clients/ etoile/ui/concepts/01/etoile.html . I still need to add in the minimizing code. - Not all files have file names. Creating a new file does just that -- it makes a blank document in some predefined, user-customizable size. As such, you don't need to necessarily name the document. This is handy for things like photos that are more readily identifiable based on looking at a thumbnail. Some documents, like code, may require a file name in order to compile. This would be set in the Settings... menu option, as seen in the next image.
file names may be a little burden to a user but if done away with, users then _have_ to tag objects with some other info to easily identify that object i.e. when searching or telling an object from a near identical copy. 300 is a sample menu window opened -- this is all subject to change.
400 is a different interpretation of the Shelf. This is something that Nicolas and David and I discussed yesterday. It's kind of a cross between the OS X Dashboard and the pasteboard, and how we had intended to use the shelf-within-the-panel. The Shelf is a place to store things temporarily. When you Pick something, this is where you can Drop it. The advantage over the panelized-shelf is that it's not crowding the screen, and it's 2 dimensional and spatial.
my take on this is that if the shelf is for storing temporary things, it becomes only as useful as a clipboard -- only bigger. One other thing to notice about these is that there is no Panel
representation. I'm still personally a bit uncertain as to how we might use it, other than perhaps as a launcher for shortcuts to Projects... (once we consider that we are removing the concept of applications). I still need to work on a component mockup, which will probably look similar to Michal's, as I like the way he implemented it using a palette/dialog. My version may look a bit more "GORM-ish". There are plenty of other things, too, like annotations and Send to... and Share with... J. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
Here's my little contribution it's not so short but i feel i need to contribute. I've considered suggestions and questions raised by Quentin relating to a previous mockup of the shelf - https://mail.gna.org/public/etoile-discuss/2007-01/msg00011.html
My main suggestion would be to display the Shelf (the part with stacks) horizontally. I have two reasons in mind: - more space - faster visual scanning (we can catch more elements with less eye movement) Unlike for the plugins vertical area, I also think labels are mandatory for the Shelf otherwise you suffer from Mac OS X Dock poor usability.
The shelf can be oriented horizontally or vertically. The plugins determine how to display their content depending on the shelf's orientation. I've also included labels. a user would choose from 3 styles to display shelf objects (see: http://www.flickr.com/photos/[EMAIL PROTECTED]/440737039/ ) - Text only - icons only - icons and text
The recycle bin could be more useful if located in the Shelf.
The recycle bin indeed does make more sense when in the shelf.
How would you call the vertical area where plugins are located? What is the Dock box? How would be used the clipboard plugin? To me, the Shelf plays the role of clipboard in a more generic way (drag/drop, pick/drop), then the clipboard should be represented as a stack rather than a plugin in the vertical area.
not sure what the location for plugins should be called. maybe all of it could just be the shelf. The dock box was supposed to be launch box -- it contains launchers for all installed apps. My idea of a clip board was that it captures objects when a user cuts (ctrl+x) or copies (ctrl+c) the object(s) and has additional features like: - unlimited objects. - a user can set any object on the clipboard to be pasted (ctrl+v) - persistent objects even after shutdown Desktop Layout see: http://www.flickr.com/photos/[EMAIL PROTECTED]/440737049/ There's one new addition. On the right is a strip where minimized windows/documents go. Mixing open windows/documents with other files & folders in the shelf (mixing window management with file management) is very tricky because some windows may be equated to files but others cannot. The ability to minimize them all to the shelf and mix with other files could become weired. Shelf Mockup see: http://www.flickr.com/photos/[EMAIL PROTECTED]/440737039/ see: http://www.flickr.com/photos/[EMAIL PROTECTED]/440737047/ This shelf mockup works a little different from my last. - It can be oriented both vertically and horizontally and plugins would account for the different orientations when displaying content. - it has 3 styles to display shelf objects text only, icons only and icons and text . - a user can create multiple strips of the shelf. (1) when the address book is selected, the shelf retracts to reveal the address book. clicking any other plugin tab shows its content. (2) using a key stroke i.e. ctrl+shift+left_click, to click a plugin tab causes it to migrate to the next strip, if the strip isn't there, it is created. one of the projects/stacks is pushed to another strip. (3) the stack on the second strip can be open at the same time as the address book on the first strip. (4) clicking the open tabs (address book and the project/stack) closes them leaving 2 collapsed strips of the shelf. Another key stroke i.e. ctrl+shift+right_click, pushes the stack on the second strip back to the first strip -- the second strip thereafter vanishes. Component Architecture Here are mockups i did a while ago about a component architecture. I refer to services as tools so just substitute tool with service. http://live.gnome.org/BrianMuhumuza/ToPaZ/ExampleWorkFlow http://live.gnome.org/BrianMuhumuza/ToPaZ/Document The only difference between Michal's task flow and these is that, these have a provision (which i called tool space) along the edges of the document for services/tools to load their interfaces (tool bars, palettes, etc) -- if they want to. There's also a service/tool switcher which is used to switch back and forth between loaded components. I also tried to mockup how services/tools could be loaded on a collection of objects and not just 1 object/document i.e. a cd burner service could be loaded onto a collection of audio files, etc -- Happy day ------------- Brian
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
