[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: What is obvious?; Context sensitive sidebars.
From:       Sven Burmeister <sven.burmeister () gmx ! net>
Date:       2005-03-12 20:45:26
Message-ID: 200503122145.27514.sven.burmeister () gmx ! net
[Download RAW message or body]

Hi Aaron!

Am Samstag, 12. März 2005 19:41 schrieb Aaron J. Seigo:
> so if we have something that takes up large amount of space and provides a
> LOT of information on screen that is used very rarely, will users actually
> want that? or will they tend to turn it off? i think the latter. so how can
> we present it in a non-obtrusive, but obvious way?

You are absolutely right, users who do not need it will turn it off, users who 
need it will leave it turned on. The problem is that there is not just one 
right way. Beginners have needs that you can put into a GUI, yet then the GUi 
is not that good for advenced users. Hence a GUI must be flexible enough to 
display different things for the same context.

> kmail has integrated instant messaging and address book entries by showing
> this information right _in_ the email header in 3.4 where there used to be
> just blank space! there is no context switching required by the user, and
> no extra screen real estate.

I chose a sidebar because it is very hard to have extra-information and 
functionality right next to the object in question. A small smiley in kmail 
wit online/offline is not that difficult but other things are too big or too 
many. Thus I thought the sidebar would be the thing least intrusive to the 
app thus easy to turn off, yet as close as possible in order to have a clear 
connection between the application's window and the information/functionality 
placed on the sidebar. Further it has the needed space to write out 
functionality.

> so... assuming we have this ocean of related information, how can we give
> nonobtrusive, contextual, obvious access to it? it's a hard question ....
>
> the easy answer is to tack it on the side. that doesn't tend to work well.
> so ... we need the less easy answers =)

The easy was my point because the more complex it gets, the less likely it is 
to be implemented. Especially if you try to introduce new things into apps, 
rather than extend them without causing them any extra-trouble, one will have 
to do a lot of convincing. Even more than now. ;)

> > to get it back, although they have been told many times. These users are
> > all over the place and need written out functionality.
>
> users tend not to read much. in fact, the more text you give them.... the
> less they read!

That is why on the Context Sidebar you just find small phrases like Copy 
To..., or perform Slideshow. Of course they do not like long texts, but that 
is not what this is about, it is about what users look for when searching for 
a functionality. If they have some idea of an icon, they look for an icon, if 
not, they look for a word, i.e. send, or copy, or burn. Having Slideshow pop 
up right next to the window when selecting a picture is certainly more 
obvious then having it in some context-menu or menu.

I thought about it this way:
Sidebar asks konqueror: what file is selected, konqueror sends a filename-list 
of xyz.jpg, the sidebar looks into its repository for konqueror and *.jpg. It 
finds slideshow, edit, rotate... provided by digikam and gimp and displays 
that functionality. So it works like a context-menu, yet without having to 
right-click before being able to see it. So the sidebar pulls information via 
dcop and does everything else itself.

> > Firefox and Thunderbird have that
> > extensions-method which is similar.
>
> so does konqueror. these are application specific and have limited
> genericity. they have well defined and limited APIs to use because of this,
> and this makes it easier.

I thougth theri could be a general way of offering space right next to an 
application, MSN picture extension for kopete for example. Also the differnce 
is the ease of installtion for firefox's extensions which, unless you have 
RPMs, does not hold true for konqueror/kmail.

> computer programs aren't like people: you can't just walk up to a program
> and ask it a question it wasn't built to answer. so saying we can
> communicate with every KDE app via dcop is fine, but saying we can form a
> consistent and meaningful conversation via dcop to populate a sidebar is
> highly non trivial.

I did not think it was trivial. But for most things it would not be that 
complex.
The application sends its name. e.g. konqueror, the sidebar looks through its 
modules if there are any available for that app, if so it pops up displaying 
them. Next the user selects some files, all konqueror has to do is send a 
list of filenames. The Sidebar checks for MIME-types and file-extensions. 
Lets say it finds *.jpg, so it looks through its DB what functionality is 
registered for konqueror + jpg. First there are those general things 
applicable to all file-types, i.e. burn, copy and so on. If the user clicks 
on copy the sidebar pops up a file-dialogue asking for destination and uses 
kio_x the copy the file-list. Installing digikam would register functionality 
such as transform or slideshow, including the necessary (dcop) calls. Again 
the Sidebar just gets the file-list and hands it on to the application.

Another example: Kmail would supply its name, the context sidebar looks in its 
DB and finds for kmail, e.g. kaddressbook which has registered a 
functionality to be displayed as add to addressbook including the necessary 
calls. Kmail send the header-information instead of a file-list, so the 
sidebar can pass on that information to kaddressbook. Another module 
registred for kmail takes the header-information and asks kaddressbook 
whether there are any entries for that name/email-address, if so, it displays 
the returned data on the sidebar.

Is this really that complex? The sidebar just needs a DB where applications 
can register their functionality (name to be displayed), what applications 
they can be used for (konqueror/file-lists), what calls to make in order to 
make it work.
This way konqueror would be registered to supply information-type file-list. 
k3b would be registered to be able to handle file-list for application 
konqueror with the dcop-call. If K3b changes its way to handle the file-list, 
a new version of it will automatically register that new dcop-call with the 
sidebar, so there is no need to worry about applications changing the way 
they handle things, because they tell us.

I hope tha last bit was not too confusing!

> walk out your door and see how many people are on the street. every one of
> those people can benefit, or suffer, from our work. you can test this stuff
> out on anyone. they don't have to be KDE fans =) and testing will tell
> whether or not this is something worth pouring time into.

A windows XP like Copy to.. in konqueror is definitively worth it for all 
people never becoming advanced users.

Sven
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]