Re: [Usability] making the conceptual model more concrete

Date: Thu, 03 Jul 2003 12:24:09 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=xdraft; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit 

From: Havoc Pennington <hp redhat com>
> To: usability gnome org
> Subject: [Usability] making the conceptual model more concrete 
> Hi, 
> A random thought I had - we have the "ideal conceptual model"
> (most recently mentioned in Calum's presentation
> If we really think such a model would be easier to use (and perhaps
> also more general/powerful), and I think it might be, perhaps what's
> missing is a translation from the model into concrete changes to be
> made in the code. 
> For example, "allow applets to be dragged to the desktop background"
> would be one, no? Or more generally "make the desktop background and
> the panel the same kind of container" 
> This gives a concrete programming task that someone can hack on. I
> think it might be hard for people to make the leap from the diagram of
> the model to the specific code/UI changes that it implies. 
> So perhaps a simple list of such changes, or even a writeup describing
> the overall utopian desktop (complete with mockup screenshots), 
> would go a long way toward helping the developers visualize the
> suggested changes and encourage them to code it up. 
> In short, a sort of high-level roadmap for desktop design changes over
> the next few years. 
> Havoc 

I'm going to choose the email with the least flames in it to respond to :) 

I think there are some very important issues that need to be resolved before 
we start designing a conceptual model for gnome. 

The biggest of these is probably the documents vs. application debate. This 
is a really important starting point because it affects how the user 
interacts with the ui. Currently we have a ui where users can open a file in 
a proxy application. They're not really editting the document instead they 
are editing a representation of the document within the application. The 
application can be started or quit from the menus etc. This is pretty much 
the model used within mac osX and osX does alot to make the model obvious to 
the user. FWIW, I think the one reason apple can get away with this ui is 
that they have a global menubar which provides a visual connection between 
the different windows. In gnome quit is particularly odd, because there is 
no strong visual connection between different windows, there is only a very 
mentally hidden connection (hence my adversion to the menu item). 

The other option is a document ui. In a document ui, there is a 1-to-1 
relationship between the icon in the file manager and window it is viewed 
in. If the file is moved while open, the window will follow the icon. for 
instance if the file is renamed the window title of the file will change to 
reflect the new name etc. In a document model you don't really have 
applications that you start or quit. Instead you open documents from the 
file manager. Another difference would be the replacement of the 
"Applications" menu with a "New" menu from which users could choose what 
kind of document they wished to create. The use of file selectors in such a 
ui would greatly diminish. 

OK well the theory is all well and great, but what can we do now. Well I 
don't think we can fully do the 1-to-1 mapping of documents to windows at 
this time, but we can use something like nautilus file to allow apps to 
monitor the files they are editting. Nautilus actually already does this 
quite nicely. Open a folder in a new window, rename the icon or even move it 
to another directory, the nautilus window for the icon will change its name 
and path. :) 

Another thing that would be really useful would be a freedesktop spec for 
document templates. I sort of evision a new->document panel menu that opens 
a dialog that lets you choose between the available document templates and 
than opens a new window in which you can do your work. You could similarly 
have new->image which popsup a dialog similar to the gimp new dialog etc. 

Sorry for being vague, unclear, and probably unhelpful... 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]