Model
Object Model
Funny i guess you have never heard of http://www.smalltalk.org.br/movies/ I guess I will shock you with this http://eaglemode.sourceforge.net/video.html Such "cutting edge" technologies has been available around for decades! Then I guess i can shock you some more 
http://jnode.svn.sourceforge.net/viewvc/*checkout*/jnode/trunk/docs/presentations/lsm-jul-2005.pdf
AndersFeder: This proposal, which is partially inspired by several ideas already mentioned on this page, revolves around abandoning the old desktop-metaphor entirely in favor of a model where everything is represented in terms of how the user would typically think about it. No more files, no more big directory trees, no more taskbars or applets; just objects and the references between them.
For instance, the user could put a set of task objects on her basic screen (the equivalent of the desktop in the current model) together with a couple of other useful objects such as a clock, a calendar summary etc. When clicking the, say, "Write report" task icon, objects relevant to that particular task, such as a document editor and perhaps a list of recent sales, imported from a database etc. (the exact behaviour would be described in the definition of the task 'class') would come into view. The user could timestamp the report by referencing the clock object (i.e. by drag-and-drop) and easily import details from the list of sales. The document would remember the references to the objects, rather than their values, so when opening the document at a later point, it would reflect any changes made to the list of sales in the meantime, for instance. Objects would have world unique addresses, so even when transferred to a co-worker's computer, the contents of the document would still be dynamic. Only when exported to a traditional document format or printed, the references would be lost and the document made static.
I realize this is a very loose draft for something that deviates so much from the current structure of GNOME but I'm adding it here for inspiration and discussion. I also think there has been some efforts going in this direction (i.e. Bonobo) but to my knowledge, they have never reached the ubiquity suggested here.
Interaction
There has been no significant deviation from the 2.x user interface and general interaction. hp
First Class Objects
<hp> I'd say gnome3 should be motivated by some major UI-type changes
<hp> fundamental simplifications
<hp> and it's probably a 2-year project
<hp> I guess I don't mean simplifications
<hp> I mean shifting complexity to what users want to do instead of computer nonsense
<hp> - first-class user-interesting objects such as "email", "conversation", "document", "contact"
shared between all apps
<hp> - less manual/micromanagey/annoying task switching (right now we have workspaces, tabs, windows,
blah blah, all essentially manual)
<hp> - rethink "extensions" from current many special extension types (applications, applets, etc.)
<hp> - arrange the UI around user-interesting objects instead of files and windowsDavydMadeley: I agree with hp that 3.0 should have a much more increased focus on documents and objects rather then programs or applications. However I also feel this will be a very big paradigm shift for the desktop and could very easily be completely messed up. I'm not entirely sure how I would think in terms of objects rather then programs. I do think that a lot of this technology will rest on top of frameworks like Beagle, Galago and Evo-D-S. I had more, but I've now forgotten it...
JerryHaltom: The "object" paradigm is really pretty well understood. A directory is understood to be an object in another directory, that when you open it, opens it's own window, with it's own state. For the most part we already have that with documents. You double click on an image file, EyeOfGnome (EOG) shows it in it's own window. EOG doesn't feel like an application at all. It's nothing more than it's own documents. Where it gets a bit blurry is something like The Gimp, you open your image, and it opens 4 tool windows along with it. When you close the image, the tool windows stay around, and you have to clean up after them. It "feels" like you are in The Gimp, vs just feeling like you are in the image. Relatively easy to correct: you make the Gimp tool windows disappear when the image isn't focused or closed. Where this hits a wall is providing application functionality that has nothing to do with a document. You want to change some Gimp options... do you have to open an image just to get to the Gimp menu? Apple solved it with their top menu bar. They can provide an application interface without tying it to a particular document. We have to have a floating Gimp window that provides nothing except a File menu.
ThurnerRupert: why would a user bother about "application options", if its only objects? there is the gnome preferences where one could look for it. apps like eclipse have plug-ins exposing their options in the eclipse preferences window, and searching for the options facilitates to find what one is looking for.
RaphaelBosshard: Each EOG has still some EOG options, like "Show menubar" or "Show statusbar", so even EOG does not realy behave like an "object". A global menubar would help, but I guess that the users would reject it. Also the global menu would only be one thing to create "object" feeling. What about other things, like dragging stuff into the waste basket, not only files, but eg. users from the GAIM buddy list?
Another thing are our understanding of folders. Folders up to day are just a representation of the logical folder the operatings system presents. But with the integration of search tools into the desktop a new possibility unfolds; persistent searches.
AlexGraveley: So outside the obvious and necessary first-class object integration hinted at above, I would very much like to see the following:
Better Task-oriented handling - In Tomboy each window maps to a document. It would make sense if I could drag the desktop's representation for this (the task-list entry) around in order to link to it, or print it, or delete it. Currently I'm forced to clutter the Gui with these "meta-task" operations.
AlexGraveley: Come on, no one has thoughts on this? It should be easy enough to support forwarding DND drags/drops from/to the window-list to the entry's app window. In addition to in the future allowing a drag to delete or print for document-oriented apps, it would allow us to support dropping files onto an app's window list entry to have it opened by the application.
FedericoMenaQuintero: I asked OwenTaylor about this once, and he said it could be hard, but I don't remember the reasons. See also the related Old New Thing entry on this issue; it may contemplate stuff that we have not thought of. (Oh, yeah, and there's a new series on dragging shell objects... maybe some of their API concepts would be useful?)
AndyBaxter: Re task-oriented handling, I was thinking about an idea where every open document window relates to an icon in a 'meta-window' which comes up maybe when you roll off the edge of the screen. Then you can do things in the 'meta-window' which work on the document as a whole. E.g. drag it onto a printer icon to print it, at the simplest level, but also to be able to do things similar to what you can do in the shell with pipes - e.g. you write a document in openoffice, and then you can write scripts which have an icon as a front end which do things like convert the document to pdf, or convert it to html and then publish it on your website. You could extend this by having it so when you selected something in the document, it would make a new icon in the metawindow, which you could operate on in the same way - e.g. drag it onto a different program's icon to open it for editing in a different program. I'm thinking of this as a way to try to carry over some of the good things about unix shell prgramming into a graphical environment - e.g. the idea of having lots of simple tools that work on data to do one thing well. Also generally it would be good to design the graphical stuff so that it can easily be extended with scripts, or interfaced to command line programs, rather than just trying to copy the windows/mac approach of making everything graphical.
FedericoMenaQuintero: Working in terms of first-class objects that are useful to users is a good goal, but we should try to move gradually towards that. Maybe 3.0 should start by simply cleaning the platform libraries: gnome-vfs's horrible async APIs, libbonoboui, etc. Then, if we have a plan from how to move from the current state with clean libraries to a state of first-class user objects, we can do things gradually. I once talked about this with JonTrowbridge, and came up with this set of ThreePointZero/FirstClassObjects.
CalumBenson: A more flexible panel area (if the panel is to still exist in something resembling its current form) would be useful... it must be the only resizable layout control on the planet that gives you less space to lay things out on the bigger you make it! See this brief discussion, for example.
DanielEspinosaOrtiz: In my work, and may be in all one, there's alot of task you are working on; in a day you need to switch from one to another. I'm using the workspaces to change from one task to another; I'm put the related apps (Objects?) to that theme I'm working on, but I have a lot and need to open alot too, and the workspaces are insuficient (I don't want to have a workspace for each theme or task becouse the space in the panel). Then How to Allow the User Switch to One Task To Another, and Show The related Apps and Documents?
Application Structure and Notifications
GeertSchuring: I like the idea of a new refreshing Gnome 3. I hope it will be a fork because Gnome 2.x is just way to conservative when talking about application structure, audio/video handling, desktop structure and abstractifying the actual computer structure it runs on... Let me explane this.
Application Structure: Applications in it current form scatter all over the system when being installed. Stuff gets in /bin, /sbin, /usr/share and wherever. When looking at an application as a single object, apps should be in a single file (much like an rpm, except that the files won't be distributed across the system). Applications can indicate what they are capable of in a capabilities.xml or something like that so that the system can index which apps can do what. This will also make it very simple to deactivate a app without deinstalling it. When apps are a single (archive) file, they can very easily be distributed, installed (simply put it in the apps dir using the "Application Manager"), deactivated (click on "deactivate" in the "Application Manager") of removed (you get the idea). Another good point on this is that this makes security much easier, you can simply allow or disallow rights to apps based on their codebase since all bins of an app are in or under 1 dir/archife. Image how easy it would be to limit bandwith to apps, to allow/deny internet access, to allow/deny users to use the app.
Desktop structure: The current generation of desktops really suck hard imho... why on earth does an app need a notification place when it allready has a icon placed in my menu? It would be really simple to use an icon both for starting the app and for notifications. This way my mail client could even tell me that i should start him because there is mail waiting for me. In other words: i see the modern desktop (ignoring 3D ideas) having 1 menubar-kind of thing, showing important icons, which are also used to display notification from these apps. Settings for all apps could me managed by a "Settings Manager" because all apps have a uniform way of storing their preferences. (See Application Structure). This kills the need for settings-menu's in apps, and also voids the need to start the app whitout opening an actual object (picture or music file) which would be confusing for the user.
Ditto. I too have noticed this ridiculous waste of space. (JohnPeterson)
Another thing i was thinking of: when Gnome 3 has a single menu bar showing all apps and their notificatons, i wouldn't really need differend workspaces anymore. You simply click the icon of the app you want, making it visible if it allready runs and otherwise starts it. Then you click it again and it gets minimized to the icon you clicked on to show it, and all notifications are shown in this icon. I think this would work really well.
Abstractifying the actual computer structure it runs on: <computer n00b mode> I really don't like to see all kinds of computer nonsense like mounting disks, starting network interfaces, and generating SSL keys. I really don't care about all this, i just want to read my mail and talk to my (n00b) friends... </computer n00b mode>
This example indicates that current Gnome releases still display way to much bullshit on the screen. I admit that this kind of ExpertMode should be available in Gnome 3 (i would like it), but not by default. That's about it... please comment my ideas. I am aware that my ideas sometimes require the linux system to change, which is outside the scope of this project.
AndyBaxter: On notification, I really hate pop-up windows from a different app that come up in the middle of what you're doing. It would be much better if each app had a region at the bottom of the window where it displayed any notifications that are needed. Or else bring all the notifications from different apps together and put them in a system level window.
You're the second post on GNOME Live! that I've seen requesting something like this. My present ideas on solving this can be found here.
JohnNilsson: I find the use of perspectives in eclipse intriguing as a UI concept. Notice the reuse of components and overlapping functionallity done right.
Does ION provide som insightfull ideas on window managment?
- RuiMatos: I don't think the ION model fits most people's needs. I use it myself sometimes but it's certainly not what I would recomend to someone who just wants to browse email, photos, video and do office work. What IMO is interesting from the GNOME POV is VIS.
RaphaelBosshard: A window management idea. Please comment. ModerateZoomingWindowManagement
Menus, Toolbars and the Desktop Metaphor
As long as we are talking about streamlining the interface, I would like to suggest obliteration of archetypical menus and toolbars. Applications should expose 'actions' to a D-Bus system. Action trees would be object oriented in nature, and user extensible. Developers would be able to write their own modular/extensible interface systems that present those actions to the user in different ways.
A new user with very little technical experience might like an interface that has blocks describing individual actions in simple terms, and a power user might like a tiny, unobtrusive little bar that tells him what keyboard shortcuts are associated with what actions within the current context. The system should provide filtering mechanisms, and show only the actions that are immediately relevant. Keyboard shortcuts, mouse gestures, or panel buttons/menus could be used to expand the current interface and select options that aren't displayed by default.
The system should also be able to filter actions based on relevance to the user. If the user configures the system to tell it that (s)he is a graphic designer or is currently working on a project context (perspective) that involves graphic design, the system should be able to alter the interface to reflect emphasis on graphic design features/actions rather than software development features/actions, etc.
At the most extreme, a developer could go as far as to make a psuedo command line system that exposes the actions as commands. This system could offer graphical command completion, syntax highlighting, etc, and provide an extremely efficient application interface for power users. The beauty is, it sits on top of a dbus service, so you can swap between the excessively user friendly interface and the grossly powerful command interface and it would all be consistantly supported by the applications.
I mentioned that I want the action system to be OO... this means classes. Instead of having an 'open' item on a file menu, you have a File interface class with an 'open' method. You could use inheritance, so you have a base set of generic file actions in a file class that applications can inherit from the base environment, and easily extend. Savvy users could also extend these classes and make their own classes by mixing and matching actions using a simple dynamic language. Say I have an image resizing action, and a 'save as' action. As a user, I could make a new action that resizes an image and then outputs it in a particular image format (say jpg for the sake of argument) using a particular programmatically designated file naming nomenclature. Then, I could use this new action to rapidly perform the other actions. The system would automatically integrate local user actions into it's interface.
By sending a list of files to this new action (either using a command system glob dealie or a graphical multi-file selection widget) I can do some seriously cool automatic bulk processing. You could probably even make this powerful feature accessible to less sophisticated users by making a graphical environment for action production, a la apple's 'Automator'.
I like the action system because it is dynamic, flexible, and extensible. Action information can become a sort of built-in documentation system for applications, and because many of the actions that aren't specific to the individual program can be inherited, it saves developers the trouble of having to deal with providing that kind of information for common things. The other nifty aspect is this: users could start distributing interface extensions and new actions to other users on the internet. It would provide a way to ease users into the development process. Once they have used a simple dynamic language to add new actions, they might take an interest in writing C plugins to make more sophisticated new actions, etc. Everybody loves extensibility, especially when the added features are unobtrusive and don't add complexity to the program. I could also see companies rebranding interfaces or making their own specialized interfaces that emphasize functionality desired by the company for it's employees. Wouldn't it be cool to be able to rapidly produce a nice simple front-end with *only* the features you want, for any standard gnome application?
Expect some commentary from me about window management in the near future.
RaphaelBosshard: It may also be time to think over some of the more traditional concepts. For example the desktop. Many people I know use the desktop to access their folders and launchers. But the desktop ist the least accessible place of the whole user interface; it is mostly hidden beneath many layers of windows.
JustinPealing: It might be the least accessible place of the UI, but its still one of the most accessible places on the computer - It's more accessible than your home directory, for example. At the moment, most users use the desktop as a scratchpad for files, but if you think of a desktop as a part of the UI rather than as a folder, there is no real reason why it should be restricted to just files. If you ask me you should be able to put files, webpages, emails, and even people on the desktop. Consider this: You "put" an important contact - perhaps someone you are expecting an email from - onto the desktop. From this object you are able to access your instant message history, emails, contact details, send them emails and IM's etc... There is no real reason why it needs to be an "icon" either - it could be a box shaped control, with their name, a small photo/icon, and a list of recent activities - emails / IM's received. Perhaps the desktop isn't the place for things like mounted CD-Roms though. Those are objects that should be positioned in an "always accessible" location - like the places menu (I know they are there at the moment, but having them on the desktop as well means that many people see those icons as the primary access point for those devices, despite the fact that the places menu as far easier to get to). I also think that the desktop should be more "available". Symphony keeps a portion of the desktop (at the top and bottom) visible at all times, which makes the desktop *feel* more available (even if it isnt) - perhaps double-clicking on empty desktop space could be a "show desktop" toggle?
NigelTao: I made some mockups based on the First Class Objects concept (see above, and http://tieguy.org/blog/index.cgi/2005/Apr and look for 19 Apr) at http://browserbookapp.sourceforge.net/topaz/ NicolasTrangez: The tagging you use is great, and would be a very good thing in the desktop, if used everywhere (i.e. desktop-wide tags). Currently F-Spot supports tags, Soylent will, maybe other applications already do, but these are all other tagsets. A desktop-wide tag database/infrastructure would be great.
DanBallard: Many people have mentioned that copy/paste/clipboard should be fixed. If we shift to a object/document as first class model this obviously has to be kept in mind. This idea is partly inspired by an entry from p.g.o http://pvanhoof.be/blog/index.php/2005/06/19/38-desktop-integration-tomorrow
One idea would be to split apps into an interface and a daemon half and an app interface half. When a file is loaded the code/daemon responsible for it is also loaded. The daemon should expose all the functionality it can through what ever IPC interface we end up picking (dbus?). Ideally a bunch of functionality could be exposed by document context menus (see how much the gimp can do by image specific menus) so no mater what app is displaying the document some functionality is exposed, but more can be exposed by apps aware of the rest of the interface. Apps that are unaware can still use the object by the standard IPC sytem and some functionality will be avaiable directly from the object context menu and the daemon.
A case example: A movie is loaded. Totemd loads the movie and totemApp pops up on screen and connects to totemd and gets the movie object. totemApp is aware of the totemd functionality so the app will have controls for all the various functions (brightness? etc). Then the movie is drag and dropped into evoApp and totemApp is closed. Totemd stil has the movie. EvoApp is unaware of the extra funcitonality but can still use the standard object interface to get the movie object and place it in the email. With the object context menu you can still stop start the movie but extra features that were exposed through controls in totemApp are unavailable in evoApp. As long as totemd is running the movie can be copy pasted and played etc.
A daemon should be responsible for shuting down when no app is interfacing with it and the clipboard isn't saying "I may need to copy from you". This way the clipboard doesn't need all posible version of the supplied data. The daemon responsible is still around to convert it to what ever the pasted app needs. When something else is copied and no app is interfacing with the daemon it can be shutdown.
Another case example: EvoApp displays an email with a pdf in it. It starts up evinced which renders the pdf and evoApp can place the pdf object in the email.
GabrielHurley: For now, I like the two bars (one at the top of the screen and one at the bottom) because it distinguishes launching of a program (top bar) from managing a program. Also, it distinguishes GNOME from other UIs like Luna (is that what the Windows UI is called?) and KDE. It would be nice if programs could be re-arranged in the taskbar in the way that one can re-arrange tabs in Firefox... or icons in the OS X Dock. Oh dear, it seems that all of the "new" ideas are being taken from OS X. Major reinventive changes are needed for 3.0, but we must try to stay true to the GNOME essence/character (whatever that may be). However Peter Lilburn's mockups (here) are enticing.
GabrielHurley: People spend too much time navigating menus. There ought to be a little box (like a command prompt) where one can type in a task or program and it will be done. Instead of typing "/usr/bin/Firefox", just "Firefox" or "Web Browser".
SergejKotliar: There is such a box. It's called the Deskbar applet
Have fun with it!
GabrielHurley: I decided to have a little fun and make my own desktop mockup using Project Tango as a jumping-point. You can see my UI idea here: http://gabriel.hurley.googlepages.com/userinterface. Another thing that we should consider is hiding the filesystem. The filesystem made sense in "command prompt land" but now we have GUIs, and the array of three-lettered folders confuses/scares the beginner.
SergejKotliar: Well, about using the Deskbar more prominently: yes, definitely. Otherwise - to me, it just looks like a reimplementation of the Apple panel, in which I like the actual Apple panel more.
GabrielHurley: The thing at the top isn't a "dock" like in OS X, it's a grahpic representation of the three menus that are currently in the GNOME desktop (although I think I have the last two in reverse order). Launched programs go to a taskbar at the bottom of the screen.
GabrielHurley: People may have been confused by my original example, so I have uploaded three mockups which can be seen in the same place: http://gabriel.hurley.googlepages.com/userinterface.
LeRandy: Although there is some agreement that the desktop metaphor has had its day, I think it is worthwhile looking at the best-of-breed desktops - I put in this category the Apple Lisa - for example, you didn't "Close" or "Minimise" a window, you "Put Away" or "Set Aside" a document - more obvious as to what the commands do IMHO. The Lisa was much more OO (as far as the user was concerned) than that which followed - you never saw an "Application" - "Tools" appeared when you opened an existing document or created a document by "tearing off" a document from a "stationary pad" (document template).
To an extent the function of the Lisa's Desktop (holding set-aside documents as icons) has been surpassed by Taskbar concepts, although I think the Window List should be a more Document-Centric thing (as suggested by others). Other things the Lisa did well - when you ejected a disk, not only would the volume be unmounted properly, it would automagically "Put Away" any open documents on that volume. Documents were automatically backed up, with the editing (and undo history) saved every 15 minutes, to mitigate against a power cut or crash - so when you came back to it, the system was more-or-less as you left it, including undo history and recent edits.
"Save" was a special function you only did when you had reached a milestone draft stage (ie. you had just finished your first or subsequent draft) - you then used "Revert to Saved" at any point you wanted to abandon your current changes and go back to a known good draft. This has been surpassed in some Office apps by versioning, but it's not as intuitive as the Lisa system to newbies, and it is now an application-specific function rather than a function available generally across the desktop (as in the Lisa).
The other concept I would put among Best-of-breed (although it had issues at the time of implementation) is Apple/IBMs OpenDoc framework which successfully disconnected Applications and Documents, thereby allowing documents to access the functionality of all the OpenDoc applications on your system. Think of it as turbo-charged OLE - but rather than having another app's data embedded in your document, the document was made up of different bits that different apps understood - so there was a common "blank document" which then contained the bits you put there. Perhaps it's a time this concept was revisited as a way of making GNOME more document-centric - so you don't have to think which App would be best for the task, rather you can pick and choose bits of Applications that you want to use for your document, all with one document-centric UI - think of a turbocharged plugins concept - you have your blank document, and you choose the plugins that will do the task best - rather than settling on one Application to do the task, which does some of your tasks well, but not others. The "shared library" model was expensive in terms of memory etc. back in the early 90s, and the basic document format was Binary rather than XML, however it has been proven that the shared library model works very well in Linux, and XML is now readily available, so perhaps we can fix the mistakes Apple/IBM made then. Additionally, the OpenDoc model could be used to create a halfway-house between thick and thin client. You could send away the complex numbercrunching portions of a document for rendering on a server elsewhere, whilst keeping the rest of the document local for ease of editing. Additionally, the file would be on your desktop, not on some other computer system. The same could apply if you had a restricted licence to a "plugin" so it was only installed on one PC, but if you were hot-desking from your normal PC (where this "plugin" is installed), you can use the plugin remotely.
Obviously, these concepts need to be taken fully into the always-on 21st century, but they still have lessons to teach UI designers today - GNOME 3.0 could be an opportunity to really learn the lessons of yesteryears' interfaces - especially we should get away from the idea that Mac OS / Finder was the best UI that Apple made in the 80s - the Lisa was better, but was too feature-rich to be shoehorned into the Mac.
Finally, complex apps like The Gimp should have a "deskbar" type interface available. For simple or quick tasks, just type in what you want to do (eg. "Correct Color"), and it pops up the list of scripts, filters and functions that will do that, rather than having to search through the menu system to find the script or filter you want. Some kind of menu-based interface should be retained to allow power users to continue using it with the minimum of fuss, but also open up the complex and unfriendly interface to those that aren't graphics pros, and just want to tidy up their photo collection. However, these two interfaces should be available simultaneously, the kind of modal interface that Photoshop Elements pushes you into being a bad idea IMHO.