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

List:       kde-usability
Subject:    Re: list of usability-related aKademy discussion
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-07-29 3:29:26
Message-ID: BAY7-F24dif9PS7RPMe0001967e () hotmail ! com
[Download RAW message or body]

This email spawned new ideas in my mind, so I'll spill them here in case 
people are interested.

>From: Segedunum <segedunum@actuaria.co.uk>
>Date: Wed, 28 Jul 2004 23:18:31 +0100
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mon, 26 Jul 2004 17:23:46, Aaron J. Seigo wrote:
> > yes, just let me know what to take with me and what you'd like to have
> > discussed/presented and i'll do my best =)

[much snipping]

>There should be *no* search function to search the control centre itself - 
>if
>you need to search a control centre you've failed. There's also the 
>sizeable
>usability connotations of presenting the results of that search, *and*
>keeping the control centre structure sane and infront of the user.

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.

Consider it this way:

There are, as far as search is concerned, only a list option which can be 
changed. Search does not know about KCMs. Search has an index of information 
files (What's This? help size) and keywords for each option which it uses to 
find things. When a search is done, the results are returned as just lists 
of options, with an explanation beneath each option.

So, a search for "Monitor" might return:


X Resultion: [ 1024x768 | v ]

Sets the resolution of your monitor in pixels. (Imagine better help here)

         -----------------------------

X Refresh Rate: [ 75 hz | v ]

Sets the refresh rate of your monitor. Adjusting this may help reduce any 
flicker.



Of course, this would need well-written information for it to work, but it 
could be great if it did work. It would also give easy access to ALL 
options, rather than only those which could be properly organized into the 
control center.

Well, not sure if that's a good idea, but I thought I'd mention it.

[much snipping]

>What is required is a customisable Konqueror, that can change its icons,
>toolbars, menus and configuration menus based on defined views and 
>protocols.
>If you change protocol mid-stream, the look and feel will change. Many of 
>the
>common views should ship with KDE by default, and allow people to create
>customised views for themselves. We would have file browsing, web browsing,
>FTP browsing, network browsing... Not too many, just enough to get the 
>really
>common tasks that people do done and allow people to build infinitely on 
>top
>of them.

It might help in general if toolbars were configurable according to protocol 
as well as KPart. That would allow Konqueror to give different options when 
at an FTP site than when browsing locally. As best I can see, that doesn't 
exist yet.

Also, a major dialog in need of improvement is the toolbar editing dialog. 
It is very bad, but I really don't know how to fix it. I've done a little 
work, but am mostly busy with other things at the moment so I've never 
gotten far.

[much snipping]

> > b) new default kicker layout for KDE4?
>
>I think so, hopefully having identified the common tasks that people 
>actually
>do - i.e. not just the developers. I believe some people call them use
>cases :).

Talking about common tasks and use cases got me thinking about trying to 
make a better task-oriented desktop interface. Something that would help 
with that is a better "Recent" system. Currently, it seems that every 
program tracks what it used recently, and that's about it.

I think this could be improved, vastly, if there were a system for tracking 
"Recent" activities for everything at once. 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.

There are two major risks that exist in moving to such a centralized system:

1) Data Durability: I know several people who have had their registry wiped 
out in MS-WindowsXP. They basically have to reset everything they have, 
because everything goes down in one fell swoop. However, the list of 
recently accessed information isn't as important, so this is only a minor 
concern.

2) Confusion: If the system appears to track files for all programs and has 
a "Recent Documents" list, people will get confused when things they write 
in OpenOffice.org don't show up. Although this is a problem, because 
third-party apps will always exist, I don't think it outweighs having the 
system there.

I'm sure there are other problems, but I don't see them right off.

If something like a general protocol is being suggested, a big get-together 
like aKademy seems like the place to mention it, as many of the people there 
will be writing applications which will need to read from it and write to 
it, and they will probably want some input on what capabilities it has and 
how the API is designed.

>4. Desktop
>
> > b) something like karamba ought to be IN kdesktop if there at all
>
>I certainly think so. A good notification and information infrastructure is
>never a bad idea from a usability point of view. Unfortunately, stuff like
>Karamba is the subject of a lot of crap at the moment, so we'll have to 
>have
>a think about what people would actually use it for.

You reminded me about an issue in system notifications. I can't check now 
and haven't checked in a while, so correct me if I'm wrong here.

The current system can do lots of things (noises, logging) but it doesn't do 
OSD/Video. 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.

Also, some warnings could just display some icon in the corner. For example, 
I could have it setup so that, whenever K3B finishes burning a CD, a flaming 
CD icon appears in the upper-lefthand corner of the screen and remains there 
for thirty seconds or until I click on it. If I click on, K3B will be 
brought to the forefront.

Once again, an addition like that seems like it would be fairly large.

[much snipping]

Well, that all seemed like a ton to say, especially after how much I already 
said. I guess the biggest problem is always that there are too many ideas to 
do them all, so they need to be weeded through to find the good ones. Feel 
free to weed as much as you like, but I'm going to repeat that I think a 
good indexing and searching system is more important than anything I 
mentioned here.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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