Attachment 'agenda-7-31-2001.html'

Download

 
The GNOME Usability Project and the Lay of the Terrain
 
A usability / UI project is only as useful if it results in change in the interface. This requires people actually implementing the ideas, concepts, prototypes, etc developed . Given the apparent difficulty (based on past UI initiatives) of attracting hacker support, a lot of our approach has been tuned to encourage hacker involvement. Surprisingly, as we began to play with various ideas for involving hackers, we found that they were more appealing to us too. We believe the fundamental tenant for the success of the project needs to creation rather than conformance.

Conformance means taking principles of usability and attempting to wrangle hackers into following them. The approach this usually entails people with UI interest examining existing applications and either providing revisionary suggestions, or modifying their interfaces to be somewhat easier to use. It is difficult because hackers largely view suggestions without code behind them as clueless crap, or worse if the body claims some official position as the gestapo. A common perception seems to be that usability is about "dumbing interfaces down", and in a sense makes advanced users and hackers feel like that a usability project is attempting to steal the desktop from them in terms of their own enjoyment of it.

The creative process differs in that it attempts to achive a more usable desktop by focusing on enticing hackers by demonstrating cool interactions (and usability) that makes a particular tool or project substantially better. In a sense what we are designing is new software to be written rather than old software that needs to be revised. In my own personal experience it is far more interesting to develop a new tool than to fix on old one (and of course, this is largely true for the usability engineers involved too, we get to start with a blank slate). This fits very well with GNOME's current phase of evolution. We are about to roll out a new, more complete development platform with GNOME2 that should significantly enhance the project's ability and ease in writing new applications.

In many ways, our process seems to be paralleling the historical development of Microsoft Windows which started with extremely little attention to usability issues, did a minor rewrite of the desktop along with a first-reasonable-cut of a development platform producing Windows 3.0. Windows 3.1 was very similar in terms of interface but in terms of the development platform eventually saw the introduction of OLE and the new Win32 API (though it never achieved widespread use under Win 3.1, much as Bonobo has yet to achieve widespread use on the GNOME1 platform). Using their new API and a better understanding of usability, and experience in the mechanics of developing a desktop environment, Microsoft released Windows 95, a near complete interface rewrite based on their new development technologies. Similar processes can be seen to be at work with the Macintosh operating system. What is the point of this? It seems likely that much of GNOME is going to be rewritten in the next year or so. Part of this has already ocurred, that being Nautilus, and part of it is ocurring as we speak (the Control Center). It seems likely that the first major segment of the desktop we can influence from the ground up will be gnome-core (a very fundamental part of the user experience).

Rather than playing catchup and trying to fix the minutia we observe as wrong in other applications we should be leading the effort in prototyping the look-n-feel of the desktop, its access to information, conventions, messages, and other very fundamental aspects of its operation. Within the technical constraints of the development platform we may have the opportunity to essentially start with a blank slate. Do we want a MacOS style menubar? Should a filesystem even be used for storing documents or should documents be persistent like the Apple Newton? Should we use an Application->Document paradigm, or should we attempt to focus the user experience on Documents with Applications being incidental details? Should their be panel, or is there a better central access mechanism? All these questions are potentially open for review (and of course many many more). This is about making the process of designing the GNOME interface explicit rather than the haphazardly dispartate growth it has undergone to this point. Much the same as we recently decided to review how the different aspects and technologies of the GNOME development fit together from a larger perspective, we need to do the same for the interface.

Realistically, we do not have time for all of this within the GNOME2 development frame, but on the other hand if we do not start preparing for post-GNOME2 now we won't have time to drive some of these changes into GNOME2.2 or GNOME3. That said, we cannot entirely shirk our responsibility to deal with pressing interface problems (particularly those that stop user's progress at a very early stage such as logging in or launching basic programs), or those that are very simple to fix implementation wise.

We envision three major areas of focus, perhaps reflected in having three seperate working groups.
  1. Writing a style guide
  2. Fixing the most critical and broken issues facing the GNOME2 desktop
  3. Working on engineering the next generation GNOME interface

These tasks are all integrally related in various ways, so we need to maintain tight communication between them, but a large body of the work can be seen as seperate and very different. For example, the ways we fix the most critical issues will be a part of the formative process of the style guide (as it will give us a realistic flavour of ways hackers might obfuscate their visual interfaces, or common interaction problems across the desktop). Similarly the style guide will need to be in-line with our next generation designs (realistically a style guide will probably not be ready for GNOME2, so it should probably focus more on integrating with the vision for the next generation interface). Also it might be good to publish a shortened form of the style guide within the GNOME2 timeframe that addresses the most pressing issues so the mistakes are not recreated.


Who are We?
a meeting in ten short acts


The Style Guide

Given the short timeframe until the planned GNOME2 release, I am not sure it is possible to achieve a full style guide for such.

Point of discussion 1: Do we want to produce something for the GNOME2 release? Could we finish a complete "basic" style-guide for GNOME2? Would this tie us to ill-chosen conventions we don't want to maintain?

Organizationally, we also need to decide who is going to work on the style guide team. Similar to the organization of most development projects within GNOME a small number of people should probably form the core of the team and will accept patches changes, and hopefully write a great body of the content themselves. We also need a style guide module maintainer.

Point of discussion 2: How many people should be working at the core of the style guide? Who should kick off the style guide?

Additionally there are a few started GNOME style guides we could choose to base off of, and a few completed style guides we could copy wholesale and modify. These include mpt's GNOME style guide, czr's GNOME style guide, the KDE style guide, the MacOS/X style-guide, the Windows style-guide, and a few others I can't remember off the top of my head.

Point of discussion 3: Do we want to start from a completed style guide and make modifications? Start from one of the existing partial GNOME style guides? Start from scratch and draw source material on a case by case basis from other guides?

Fixing BrrR0k3nesS5 for GNOME2

We should probably focus on "major areas of the GNOME desktop" or applications we expect to have a very high percentage of users interacting with. These include the panel (particularly the panel menus and perhaps the applet situation), tweaking various aspects of Nautilus, the control center, and high profile applications like AbiWord, Gnumeric, Galeon (where they are significantly broken, though I can't think of any ways off the top of my head that are must-fix), gdm, the window manager, and task switching.

Point of discussion 4: Lets draft up a must-fix list and start prioritizing it. Bugzilla might be ideal for this, or we could choose our own organizational system.

Another objective we may want to adhere to for GNOME2 is to enhance usability in ways that improves the quality of experience for advanced users and hackers. Why? Many hackers are opposed to usability because they see it as "dumbing down the interface", something obviously treated with scorn. This fails to recognize that good usability will have a positive impact on everyone. Particularly given that most of the existing GNOME audience are fairly computer savvy, it seems important to concentrate on issues that affect this audience. We are not going to make GNOME your mother's desktop without some major rewriting, so lets work on interaction problems that make the experience more comfortable for our existing audience, and save the former for our vision for the future of GNOME. One suggestion, for example, would be to organize the menus in a more easy-to-use way. Even with competence and experience on the GNOME desktop it is sometimes difficult to find things inside the GNOME main menu structure.

Point of discussion 5: What are some big usability / interaction bugs that hackers may not have even noticed that we could potentially eliminate? How can we best serve GNOME's existing userbase?

Designing for the Future

We need to start figuring out how we are going to connect with hackers and excite them about working with us. This is not a single-handed sort of thing, but a collaborative process between designers, artists, and implementors. Particularly in this area its important to have involvement from people who are highly skilled and respected in areas besides usability, as this will shape their aspect of the desktop as well in very significant ways.

Point of discussion 6: How can we excite hackers about working with us? What projects would they be most interested in working on?

In addition to looking at parts and aspects of the GNOME desktop that are likely to be rewritten, we should consider missing pieces that we can design right from the start. One example of this might be a system for managing panel applets that is more intuitive and explorable than the existing method. I suspect that people will be much more interested in writing a new piece of software than fixing on old one, so we can present this as a project unto itself. It is important for a usability project to consider the environment as a whole, as this will allow us to see cross-application interaction problems as well as notice missing pieces.

Point of discussion 7: What are some missing pieces of the desktop that we could design?

Additionally, we should figure out who/what needs to be involved in the process of designing for the future (for example, artists, the foundation board, etc).

Point of discussion 8: Who do we want to engage to move forward on this in a way that is supported by the greatest number of people?

Administrivia

Point of discussion 9: When should we meet next?

Its important that we develop a smooth and sustainable working process (though this may differ between the three major subtasks, as they involve very different processes). We also need to consider ways to best accomodate a broad range of talents, interests, and time commitment. Some of the considerations this brings up is how long we want decision turnaround to be (this alters how often we expect a productive contributor to have to check e-mail, for example), or how/whether we use technologies like CVS for our content.

Point of discussion 10: How do we decompose organizationally? How do we work, how do we collaborate?

--Seth Nickell

(from discussion with Calum Benson and Suzanna Smith)

Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
  • [get | view] (2021-02-25 09:48:56, 7.6 KB) [[attachment:2.7.html]]
  • [get | view] (2021-02-25 09:48:56, 7.9 KB) [[attachment:2.9.html]]
  • [get | view] (2021-02-25 09:48:56, 13.2 KB) [[attachment:agenda-7-31-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 0.7 KB) [[attachment:agenda-8-17-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 0.8 KB) [[attachment:agenda-9-5-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 1.1 KB) [[attachment:checklist.html]]
  • [get | view] (2021-02-25 09:48:56, 9.4 KB) [[attachment:coordination_of_ui_review.html]]
  • [get | view] (2021-02-25 09:48:56, 27.2 KB) [[attachment:gedit.txt]]
  • [get | view] (2021-02-25 09:48:56, 23.0 KB) [[attachment:gucharmap.txt]]
  • [get | view] (2021-02-25 09:48:56, 5.8 KB) [[attachment:howto_write_ui_review.html]]
  • [get | view] (2021-02-25 09:48:56, 12.6 KB) [[attachment:metacity.txt]]
  • [get | view] (2021-02-25 09:48:56, 2.8 KB) [[attachment:minutes-10-17-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 2.1 KB) [[attachment:minutes-10-3-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 6.9 KB) [[attachment:minutes-7-31-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 32.6 KB) [[attachment:minutes-8-17-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 1.1 KB) [[attachment:minutes-9-5-2001.html]]
  • [get | view] (2021-02-25 09:48:56, 6.1 KB) [[attachment:proposal_control_center.html]]
  • [get | view] (2021-02-25 09:48:56, 0.6 KB) [[attachment:proposal_feedback.html]]
  • [get | view] (2021-02-25 09:48:56, 0.6 KB) [[attachment:proposal_logging_in_and_out.html]]
  • [get | view] (2021-02-25 09:48:56, 34.0 KB) [[attachment:proposal_menus.html]]
  • [get | view] (2021-02-25 09:48:56, 4.8 KB) [[attachment:proposal_nautilus.html]]
  • [get | view] (2021-02-25 09:48:56, 23.5 KB) [[attachment:screensaver.txt]]
  • [get | view] (2021-02-25 09:48:56, 25.4 KB) [[attachment:soundjuicer.txt]]
 All files | Selected Files: delete move to page copy to page

You are not allowed to attach a file to this page.