[Usability] Re: making the conceptual model more concrete

["David Adam Bordoley" <bordoley msu edu>]

Daniel Borgmann writes: 

> I don't think I'm looking at this wrong but rather that I can't see yet
> what practical advantages the user has from treating each kind of music
> source as a document/object instead of using one player to play all his
> music. Especially the example about radios. Wouldn't it be extremely
> unintuitive to force the user to learn the concepts of creating links to
> radio stations instead of using a radio-like device from where he can
> conveniently switch between available radios? This seems to be a similar

Having a single view of all radio stations in a "folder" (probably a better 
term is "collection") which provides an interface for editing, playing, 
creating new radio stations is good. Forcing the user to think about it as 
an application is wrong. The folder would present the information (the radio 
stations) in a way that users could easily understand. When I say "links" I 
don't mean the literal .desktop file or symlinks. I simply mean objects the 
represent a station, however that may be. 

> Yeah hm, that might be true. But then again, it would force the user to
> understand two different ways to start a game. He need to do New -> Game
> to start it the first time and then open the game from his games
> directory if he wants to continue it? Currently you just run the game
> each time and if it's not the first time, it will often continue where
> you left. That behavior would be a bit weird with New -> Game I assume.  

Not really. It would provide two interfaces that do two seperate things. To 
open an existing game (just as you would open an existing spreadsheet) you 
open the folder containing the existing game, double click it and play. To 
create a new game (just as you would a new text file) you select 
new->game->game title (as an example, the exact gui semantics are open to 
change, i'm just suggesting this as a interaction model). 

> I do not necessarily manipulate something, see calculator. I use a
> calculator like a tool, not as a document itself and not to view other
> documents. It's just what it is, a helpful device. I don't see why we

Yes calculators do fall into that category of useful tools, that would 
require some other type of interface.[1] I don't dispute this. 

> can't take the web browser as such a device to get arbitrary content
> from the entity known as the world wide web. At least until there is a
> way to understand and access web content as objects. What do we gain by
> _forcing_ the web browser to be document centric just for the sake of
> doing it? Would it be easier to understand or more efficient in any way?
> Same questions for radio. 

This is just lack of vision with web browsers and how to integrate them into 
the os as oppose to being some addon app. For instance, I think we should 
pull bookmarks out of the browser and into the desktop. It would be much 
more useful to be able to have a common interface from which to access 
bookmarks of any type, instead of the current nautilus bookmarks, 
gconf-editor bookmarks, yelp bookmarks etc. Epiphany already makes alot of 
strides towards being more document centric and both marco and I feel that 
this is the way to continue.[2] 

> Sure, but if you can "quit" (as in closing or whatever) a calender, how
> do you get it back then? Should this kind of "objects" be files which
> can be executed to "bring them up" like any other document? So in other
> words, should these kind of applications be files? Or maybe rather just
> a generic "calender" object which then gets "opened" by the installed
> calender application? In this case, what would happen with new
> applications of this kind. Where would this object be placed after the
> application is installed?

But this limits the user to only one calendar. I store a calendar as a file, 
clicking on a calendar object opens it in a view (whether this is another 
application, something similar to a nautilus view etc is an implementation 
detail and does not need to be considered in the model). You can manipulate 
this object like any other object, you can copy it, move it to the trash, 
duplicate it etc. Its the data not the view. 

>  
>
>
> > [1] Although I do admit the web does create some interesting problems here 
> > and I've been thinking alot about how to solve them. 
>
> Hmm well, but shouldn't these problems be sorted out BEFORE Epiphany
> becomes even more document centric? :) I wonder how to plan to solve

I think we quite clearly are not moving to quickly here, though we have made 
some strides by doing simple things like removing the evil "quit" menu item. 
These changes will continue as the project matures but clearly we are 
talking about a future model, not gnome 2.4. 

> them anyway. A single website can contain the website itself, a video,
> music, it can transform itself into something completely different, it
> can be a chat or forum, heck it can be a complete application (that's
> what ASP.net is all about anyway). I wonder how you can ever solve this
> without accepting that the data you get is completely arbitrary and the
> URL merely acts as an "entry point" in many cases. 

I recognize these issues and they need to be thought about in depth. We 
should block a sane desktop model though on the fact that the web creates 
interesting problems. They can be solved of course. 

dave 

[1] Other things that fall into this category are the character map, 
gconf-editor(well this is debatable actually but...) etc. 

[2] Hence our interest in a ui similar to the open applet where instead of 
starting a web browser or having to open a new browser window (something 
that has always seemed odd to me), you simply enter the web address, search 
phrase etc from a global desktop object that pops open a view of the 
content.