[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-26 18:02:42
Message-ID: BAY7-F6oV8CnfnSw5ZX0001be56 () hotmail ! com
[Download RAW message or body]

>From: "Aaron J. Seigo" <aseigo@kde.org>
>Date: Mon, 26 Jul 2004 00:09:03 -0600
>
>hi all...
>
>i'm starting to organize my aKademy schedule. the purpose of this email it
>three-fold:
>
>	1. to get an idea who else will be there to discuss these things with
>	2. to let everyone here know what i plan to work on
>	3. to get feedback from this list on #2
>
>#3 is particularly of interest to you, the reader, because it allows you to
>have a say in what happens @ aKademy w/regard to usability even if you 
>aren't
>there. basically, i'm openning myself up as your representative / 
>ambassador
>to aKademy. remember, i'm only there for 10 days, so this list needs some
>limits.
>
>enjoy.

Thank you for the opportunity to comment on this issue. I'm sure my long 
dialogue will quite bore you to death, but please persevere.

>The List
>=====
>1. kde-usability-devel
>	a) the mailing list
>	b) the associated web site
>	c) relationship and x-over between it and kde-usability
>
>2. kcontrol
>	we have several similar versions of new kcontrols floating around. most 
>are
>similar, all have subtle problems. i've discussed these things at length
>already with some developers, and aKademy is THE time to pick a directrion
>for KDE4 and actually write some code to cement that direction. i don't 
>want
>to do this via email and irc as i'm tired of typing the volume of text
>implied by such discussions; i'm looking forward to face-to-face discussion
>=)

I'm going to have to go off for a while here, because I am very interested 
in KControl and its future. Allow me to preface by reiterating that I am not 
a programmer, so however much I do on design, I'm not going to be the person 
actually writing any of this. I am glad that people are interested in my 
designs. I may end up mentioning my designs, which are contained in the 
page:

http://www.csis.gvsu.edu/~abreschm/designs/the-control-panel/index.html

and have two mock-up images of the main control center:

http://www.csis.gvsu.edu/~abreschm/designs/the-control-panel/images/control_center.1.png
http://www.csis.gvsu.edu/~abreschm/designs/the-control-panel/images/control_center.2.png


First, I think a large topic of discussion should be the integration of 
searching into the control panel. Searching is the future on the desktop, 
and KDE should try to get it done right and done first. In my main KControl 
design I has a search area which is clearly labeled and obvious. However, I 
still am not sure how it would work.

Searching in a control panel is extremely difficult to implement, because 
you want to search via contents and have an area to display the results, but 
the basic interface to the control center is an icon view which doesn't lend 
itself to changing to a results view, and the contents are not indexed.

If anyone can find a way to help with automatically indexing the contents of 
control modules, that would represent a magnificent improvement in the 
control center usability. My only idea is to have a tool parse and index the 
contents of tool-tips, labels, and what's-this helps, as those all contain 
information related to the contents of a control module. The reason it needs 
to be automated is so that it works with multiple translations relatively 
smoothly. That is, any fully translated module would be searchable.


The next thing after discussion of searching is that I think discussion of 
the organization of control modules is vital. How they are organized will 
define if the next interface is bloated or slim. I would say that the 
organizational decisions need to be made with an eye to logical divisions 
and an ever-growing set of control modules.

By logical divisions, I refer in particular to the division between the core 
system and app-only stuff. For example, Benjamin's design says that File 
Associations is not in there because it is only applicable to Konqueror. 
Where that line is drawn, the line between application and system, will 
change the entire face of the control center.

Also, is there going to be consideration for more administrative modules 
being added? Currently, KDE Kiosk appears to be adding some administrative 
controls, and there are the potential for many more. Where do these get 
placed? There is potential for a great deal of these to exist, as many as 
most other sections combined, yet they are all place into one clump in the 
current system.

Further, where does hardware stuff go? Currently, there are hardware pages 
for some things, but not according to what devices are attached to the 
system. Does hardware management need its entire own separate system, or can 
it be slid in there as well? I know most designs call for mostly just a 
keyboard/mouse module and a display module, but there are other devices 
which may have settings available.

And, going on in that vein, what about removeable devices? I had an idea, 
which I believe I posted here before but cannot find, regarding handling of 
removeable media and devices. It goes something like this: the system tracks 
such objects according to some profiling method, then decides what to do 
with them when they match. So, a special set of option would be added when a 
digital camera is added, and a separate set of options would exist for CDs 
as well. The system could track devices in a lot of ways. Digital Cameras 
might be tracked according to exact matches (same model, serial, whatever) 
so that multiple different cameras could be treated differently. Of course, 
to have it not cause trouble with the addition of a new camera, any unknown 
cameras would be treated like the already known ones. CDs could be 
recognized according to contents, external drives according to exact 
matching, so-on and so-forth.

The control center would add entries for attached devices so that the user 
could configure whatever they were using. Also, settings could be added to 
do specific things when something of a certain type was attached or 
inserted. So, if a DVD were inserted, it would start MPlayer with 'mplayer 
dvd://1' and no troubles would occur. And, if a digital camera were plugged 
in, all the images would be automatically copied to a place on the drive, 
then removed from the camera.

As you can see, the idea is still a fledgling, but I would love to see some 
developers give it wings to fly with.


Another issue regarding the control center is whether to keep it 
single-window or to allow it to be multi-window. I much prefer for it to be 
single-window, but others want multi-window. Such a decision needs to be 
made. (And, as a thought to help with some issues for those who love 
mult-window, if it is made as a single window, and option could exist to 
right-click on the icon for a module and have "open in new window" on the 
context menu.)


I would like to reiterate that the control center needs to be kept to a 
two-level system. My system is three-tiered, but in the same way as the 
current one is: Tier one is the top level groupings. Tier two is the 
modules. Tier three is the tabs. However, my design calls for no control 
modules to have tabs, but to allow the system to place control modules into 
tabs, thus allowing freer reorganization of the system. Such a thing might 
entail a lot of redesign, so it needs to be dealt with early.


Although a lot of this is dealing with the control center interface, a lot 
of attention needs to be eventually given to the KCMs themselves. I don't 
think there is nearly time for them at one event, but if there is it would 
be good to discuss some of those that need changing. And, if any do get 
attention, I would like to point at my pet favorites, the file-association 
system and my much-desired directory-association system (which doesn't exist 
and would take a lot of work).


>3. kicker
>	a) internal coding issues and general improvements. i already have a diff
>here in excess of 4k lines, and hopefully that will serve as a baseline for
>discussion and will be even larger by the time i get to aKademy =)
>	b) new default kicker layout for KDE4?
>	c) examining the state of the various kicker extensions
>
>4. kdesktop
>	a) icon layout and handling. needs a rewrite, and Qt4 forces that anyways
>	b) something like karamba ought to be IN kdesktop if there at all

Karamba definitely should be IN the desktop, not just something tacked onto 
the side like an abnormal growth. However, I am more in favor of actually 
merging a lot more into the window manager and adding a lot of power to the 
system like that.

My idea is more of a combination of Slicker (www.slicker.org), Karamba, and 
KWin. None of them really have an excuse for being separated. I would like 
to see things like allowing windows to be docked onto the side of the 
desktop and treated like drawers. The code would be a lot like 
window-shading, but would also need attention to maybe putting in vertical 
title-bars instead of only horizontal ones. And then, there is the added 
ability to dock one window onto another, which could be useful with apps 
like The GIMP.

One of the nice things about this change being done properly is that it 
allows Kicker to be emulated perfectly with a system that is actually much 
more powerful. That is, changes to the interface don't need to happen 
overnight, but they can happen whenever they need to.

Karamba comes in with not only have little applets on the desktop, but even 
going so far as allowing a person to just, on-the-fly, embed a window into 
the desktop.

Of course, that's a lot of work and changes. What I would really like to see 
there is some discussion of it. Even if the discussion were to lead to a 
decision of "No, don't do it" I would like to see the discussion happen.




And, now for other things I think are important for KDE's usability which 
you didn't mention. Again: SEARCHING. Look at

http://www.csis.gvsu.edu/~abreschm/designs/ubiquitous_searching/index.html

if you haven't yet. It's needs some updating, but the ideas are all there. 
Basically, the interface of the future is searching. So far, I have shown 
the search-bar-in-file-selector and search-bar-in-menu to seventeen people I 
know, fifteen of whom, use MS-Windows almost exclusively. 100% of them said 
it was a great idea, something that they would love to have.

The fact is, people have too much data on their computers these days. They 
just don't know how to organize it, and many of them just don't want to try 
to organize it. That may be their failing, but we can fix it with a good 
search interface and good system indexing.

Some discussion of indexing happened here, but we aren't the expert 
programmers which keep KDE running. Those people will be at aKademy, and 
they might be able to get an indexing system going while there.

Microsoft knows that searching is the future. That's why they are mixing it 
all through Longhorn and pushing MSN Search so much. We also know that it's 
the future, we just need to get it working. KDE can bring out a fully 
functional search system inside of the year, if it is made a priority. I 
think it should be made a priority, and aKademy is the place to do that.

I would love to talk about it there, but the odds of my being able to come 
aren't the highest. I might be able to, but don't expect me. I would love to 
have you bring it up since I probably won't be able to.


To point to another one of my projects which involves searching, I am trying 
to redesign the file selector. Since the file selector is one of the most 
used tools in the desktop, I do think it warrants attention at aKademy. 
Again, if I can make, I'd love to talk about it. If I can't, I'd love for 
someone else to bring it up. Some of my progress on that design is at:

http://www.csis.gvsu.edu/~abreschm/designs/file_selector/index.html

Unfortunately, that's out-of-date. I am trying to finish up the redesign, 
but having only limited access to Linux (I'm on vacation) is making that 
difficult. Inside of the next two weeks, it WILL be done. However, I can't 
put it up right now.

I won't go in depth on that; you can look at the page if you want to, but 
I've said enough here.


I know that you are already working on a lot, so don't get worried about my 
ideas. The main one I really think should be mentioned is the searching 
system. That would represent an entire shift in the direction of KDE 
development, because every application would want for a little redesign to 
work with the system. Such an issue MUST be brought up at an event like 
aKademy, and I most likely won't be able to do so. I hope you can find the 
time to bring that up as well. Thanks for your time.

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