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

List:       kde-usability
Subject:    Re: What is obvious?; Context sensitive sidebars.
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-03-12 18:41:43
Message-ID: 200503121141.50249.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 12 March 2005 11:28, Sven Burmeister wrote:
> For mail: When I am working in an office and get an email from a customer
> it would be very helpful,
 <snip lots of cool ideas> 

i agree that this functionality is useful. in fact, we'll have all that and 
more available to us with klink. the challenge is one of form factor. in 
fact, in IR (info retrieval) research one of the most unanswered questions, 
and on that's getting a lot of study, is the UI for these things. 

take email as the specific example:

	A) how often would such information be truly useful?
		i know that i only need that info for probably <10% of my mail at work
		and less <1% at home. those who need this closer to 100% of the time
		already use a CRMS

	B) is a sidebar the best way to present this information?
		a sidebar is "out of context", so to see this contextual information in a
		sidebar one's focus must leave the context. this isn't true in a filemanager
		or a media player, btw.

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?

with the second issue of context, how efficient is it to flip visual 
concentration away from the email to get the other information related to 
that email (e.g. the person's phone number) only to come back to the email?

here are some of the things i've observed elsewhere when it comes to 
contextual additions:

the world wide web did it with links. links are differentiated visibly and 
clicking on them will make something happen that is (hopefully =) 
contextually relevant.

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.

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 =)

> 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!

> for lets say kmail. If it was external and would simply communicate via a
> standardised method such as dcop others could take care of the extras and
> not bothering kmail developers.

kmail would still have to know to talk to it, or the sidebars would have to 
know how to talk to kmail. repeat for every app you wish to apply this too. 
either you duplicate a lot of effort, or you spend a lot of time engineering 
an intelligent component based system. neither are trivial.

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

> by the app's developers. Is it not possible to have the sidebar and the
> apllication it is attached to communicate via dcop and thereby avoiding the
> need to put it into the application itself? This way, if for examplea
> company needs some extension for kmail, it can develop it without having to
> introduce anything into kmail's code.

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.

> > creating software isn't simply throwing random first draft ideas at
> > developers who then code them and slap into CVS. or at least it shouldn't
> > be. new interface concepts should be thoroughly reviewed and considered.
> > it's a time intensive effort to create these things, and our users (which
> > includes us too =) are impacted enormously by our decisions here.
>
> That's why I try to get constructive feedback. The problem however is that
> I cannot reach those users who would benefit most from it.

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.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]