Hi, I have been reading the 3.0 roadmap for Gnome, and I found it quite worrying. Essentially it talks about a radical departure from the desktop metaphor. I don't feel that is quite right. [1]
The desktop metaphor is quite useful this days, not for its inherent qualities but because it is familiar. It is no longer a metaphor of a physical desktop, it is a computer desktop per se. Most people, even those unfamiliar with computers, can tell what a desktop is, what the trash can does and what folders are used for. It might not be the best approach, but it is a familiar one. Innovation cannot be held at the cost of usability. There are also talks about a completely user-configurable interface. Let me quote: >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. >From a developer's point of view, this is heaven. From a user's point of view, it is hell. People want their software to work for them, not to work for their software. I think this kind of behaviour and flexibility is already covered by very mature UNIX utilities such as Emacs. That's what the command line and classic unix apps are for. The Desktop is there in order to have something that just-works. And things should be easy to support. If someone asks 'how do I...' the answer cannot be 'it depends on how you configured your <insert app here>'. Not all is bad in ThreePointZero. Although I'm not quite a believer in the document-centric approach (not everything is a document, but everything is a file), i think a hybrid approach could near perfection. The existence of object apps functioning transparently to the user (EyeOfGnome is the example they use) is quite a good idea... for certain apps. I am a user of professional applications (Audio/Midi sequencers, illustration and imaging software) and I am positive that they would not work this way. The application is in many cases almost an OS in itself, providing its own file manager, its own interface, in order to preserve a workflow that is critical. You take that away from Photoshop or Logic and they're dead. Now let me quote again for my favorite part: >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. I totally agree with this, except in the settings manager part. Such an application would surely be bloated and too complex. Options must be given to the user within their context and in small doses. Too many options are confusing. Sorry for being lengthy... [1] http://live.gnome.org/ThreePointZero _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
