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

List:       kde-usability
Subject:    Re: list of usability-related aKademy discussion
From:       Segedunum <segedunum () actuaria ! co ! uk>
Date:       2004-07-30 20:48:50
Message-ID: 200407302149.17026.segedunum () actuaria ! co ! uk
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 28 Jul 2004 18:41:35, Aaron J. Seigo wrote:
> in return, those of us on this list need to be ready for some constructive
> criticisms of how things proceed here.

Well, I get the impression that there are, or were, good people on this list 
who have been put off by various things. We need to get them back or 
encourage them to speak up.

> as an FYI, i'll be talking to some professional usability ppl @ aKademy as 
> well. so it won't all be developers, it will also be building bridges
> between traditional usability groups and open source .... 

I'm assuming this will not just be people who have been involved with KDE, but 
people further afield. This event looks to be reaching further outside KDE 
than ever.

> this unfortunately ignores the reality that our desktops are amazingly 
> intricate and that not all people think of things in the same way. put those 
> two things together and a search can make things much easier to find.

*In general*, you shouldn't need to use a search in a control centre to use it 
- - and I think that's what we have now unfortunately. Most of that is down to 
the organisation of the modules, not the layout, though. However, a fast 
unobtrusive, and simple, search mechanism that would instantly bring up 
*actions* (that we have the basis of now) never goes amiss. On the other 
hand, if we focus on top level tasks on the left, and then provide an 
organised and obvious way of doing things on the right, would a search be 
necessary? If the user wanted to know how to do something that wasn't covered 
by the top level links, then possibly.

I can't help feeling that it is organisational clean ups, a little bit of 
simplification, and some user feedback that KControl needs, not a wholesale 
change in direction. I think once the structure gets a bit more nailed down 
(use cases - what do people actually need to do?), then we can look at really 
improving stuff like context specific help and looking at how we manage the 
space. The single pane idea is good, but the disadvantage is that you often 
have no space where you need it and loads where you don't. However, it's 
something we can face as we shouldn't lose what KControl has going for it.

> smooth zooming icons.

Nice. The current zooming icons aren't as bad as everyone says, as they 
provide some nice user feedback. Maybe we can use them more where 
appropriate.

> ripping out the hard-coded main panel so there is just the "child
> panel" (which just becomes "desktop panel")

That seems like quite a good idea.

> yes, that is the key. not another bobble that's cute but useless (MacOS X
> has SOOOOO much of that drek it's sad), but something USEful and efficient.

The Gnome Dashboard idea looks quite good. I've often got a reply from a 
person and wondered what the history of our conversations were, or more 
importantly, support calls related to e-mail correspondence from people that 
I needed to dredge up. However, I have yet to be convinced that they have the 
infrastructure to pull this off in the desktop as a whole. I think KDE 
certainly has.

On Thu, 29 Jul 2004 03:38:42, Datschge wrote:
> With regard to this we should keep the suggestion of the last usability
> report in mind: "offer more than one way to solve a specific task" (or
> something along that line) since there is never one "true way" to handle a
> specific task.

Very true, but there is always one or two ways that most people complete a 
task, and then you make things customisable beyond there. You have to do 
these one or two ways well (Unix philosophy), and then add behind them 
without impacting peoples' ability to get those one or two things done 
quickly and easily.

You have to focus how you present that to a user so they are not caught in 
two, three or four minds. Giving people six or seven options straight off the 
bat is not good, as no one will get anything done. However, if you can give 
them one or two solid and dependable ways to get something done, and then 
provide more methods behind that, and the ability to customise, you've got 
something.

> Regarding the sidebar I'd love to move global features like bookmarks, 
> history lists, folder tree, services etc. to the universal sidebar if 
> activated and allow it to affect the currently active konqueror 
> window, removing the redundant sidebar in every single konqueror 
> window (one could say similarly to what can be done using the 
> "global" mac alike menu applet).

With a re-worked Konqueror able to flexibly provide access to these things, 
then I'd say that is a pretty good idea. This might tie in with something 
like the Karamba stuff. However, remember the crucial guideline. Focus on 
what people readily do (difficult I know), get those one or two things right, 
don't 'clutter' things by default, and allow people to customise and do what 
they want as far as they want to go beyond that.

> There is something else which might be worth to think about: in the 
> past KDE versions there always have been a separate sidebar tab for 
> both "home folder" and "root folder".

Well, this might sound controversial, but what is a root folder, and more 
importantly, how would my users use it (I know I know what it is used for)? 
How would they know to use it, and more importantly, where would they go and 
what would they do? Think of this, especially considering that you need root 
access most of the time to be able to do things with the root filesystem. KDE 
and Konqueror haven't been terribly usable on that front, even for advanced 
users.

> I think it might be a good idea to combine both and make it a global option
> whether the user's starting folder should be root or home, then show only
> the respective tab as well as, in case of home as starting folder, show
> file:/ URLs based on ~ (e.g. file:/~/Desktop/ instead
> file:/home/myname/Desktop/)

Possibly, yes. However, remember that everyone browses their Home directory, 
so do that well first. 

> The reasoning being that in many cases users aren't even allowed to 
> play around outside their home folder so indicating the computer's 
> content elsewhere is unneeded and possibly even unwanted.

Well I don't know about not being allowed, but the main focus of any user is 
to use their home directory, copy to and from floppies and CDs, and to and 
from network locations. Most of the navigation around the root filesystem can 
be handled transparently and intuitively through recognisable devices and 
locations (network etc.) - and frequently is through stuff like KIO. The root 
filesystem isn't needed most of the time by most users - but it should still 
be there. Let's try and use the good technology KDE has, because it makes 
things more usable.

On Wed, 28 Jul 2004 23:29:26, Jamethiel Knorth wrote:
> First, I disagree with having NO searching. I had a different idea for 
> searching in the control panel which COULD be really cool. It could also 
> suck horribly, I don't know.

Well, given that the functions of the Control Centre should be re-worked so 
that people can get to things easily, any search would have to respond to 
intuitive keywords beyond what is capable with any revised structure. This 
probably means indexing the control centre modules.

> When a search is done, the results are returned as just lists of options,
> with an explanation beneath each option.

That's very good from a usability point of view, because it tells a user what 
they can do, rather than just a vague link of how to get there. It reflects 
actions.

> That is, programs setup to use it would tell it when they opened/saved a
> file, and that would be recorded, and then this central system would be able
> to tell what files were recently used by a certain program, what files of a
> certain type were recently used, or even what files of a certain are
> frequently used and were recently used by a certain program.

This would have to be done in concert with lower level components, filesystems 
and standards to be successful. The approach that WinFS and Gnome Storage are 
going for is a route to bad implementations, because the desktop has to do 
more work than it should. It will also be terribly slow. Hans Reiser has this 
one spot on.

> A good OSD system which can be accessed by the notification 
> system would likely be very useful for those with some disabilities (the 
> deaf probably get very little from the noises). For example, the potential 
> should be there to include a visual pulse of some sort regarding an error 
> message.

Accessibility framework, Qt 4, will allow more accessibility things to be 
done. Beyond that, I'm sure accessibility additions in KDE will really take 
off.

Cheers,

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBCrQ453OaWc7M8G0RAmEyAJ9QX0Ki+GQy7R9xF6y/E7vpqHLikgCfcnUu
BPXRJOv47pmW+pTntmW2npE=
=rvSQ
-----END 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]