[Usability] Re: making the conceptual model more concrete

[Daniel Borgmann <spark-mailinglists web de>]

On Sat, 2003-07-05 at 16:11, David Adam Bordoley wrote:
> No, you're still looking at this wrong. You don't create a new media player, 
> there is no need to have the same interface to play iradio as the one to 
> play mp3's. In rb you have this idea of sources (which seth and I both 
> aren't all that crazy about). Instead in the object world you would have a 
> folder or search folder that contains links to all you iradio stations. 
> Perhaps this folder would have a special view that is presented similar to 
> rb' iradio player. The New Menu would probably be something like 
> New->Music-> Internet Radio Station from which you could create a link to a 
> new station. Also for container views (like the iradio folder) you might 
> have file->new radio station. I'm just conjecturing here to give you a view 
> of what it might look like, not what it has to look like though. 

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
problem to the problem of web content to me. And you can also see this
reflected in real life again. When we listen to music, we operate on
certain objects like a cassette or a CD and it would probably make sense
if we could play those objects directly, instead of putting them into a
device first. But when we want to access radio stations, there is no
other physical connection to it than the radio, so we use this one
directly.


> Well having a folder (or search folder) labeled games where you save your 
> existing games creates an interface that puts the user is far more control. 
> If you want to delete an existing game you simply drag it to the trash for 
> instance. 

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. 


> > Objects sound good to me. Because it would be pretty close to what I'm
> > thinking. If the calender can be an object, why not the media player
> > (radio?) or web browser? I find this a much more natural way to think
> 
> because the calendar is the object you are manipulting. You don't manipulate 
> a browser[1] or a media player, you manipulate web pages and mp3s/oggs 
> (which you just happen to be presented as a collection instead of individual 
> files because it makes manipulation easier). 

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
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 where the magic of processes, swap space etc. all come into play. 
> Notice that it is impossible to "quit" epiphany to free memory. You can only 
> close individual windows, and it just happens that when you close all the 
> browser windows epiphany is removed from memory (but this is not something 
> the user need be aware of at all). In fact a user should never have to be 
> concerned with quiting an application to free memory or other system 
> resources. 

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?



> [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
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. 


Daniel