'Re: TOM'

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

List:       kde-usability
Subject:    Re: TOM
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2003-05-23 17:07:09
[Download RAW message or body]

this is true if they use a non-KMail client, TOM or not. if our biggest 
question is making sure the user can communicate to the help desk (be that a 
corporate help desk, Dell's 1-800 number, or #kde on IRC) what application 
they are using, perhaps we could accomplish that with tooltips? does one need 
this information for the help desk often enough to warrant a consistent 
intrusion in the menu? can this information be found quickly and easily from 
the mail apps window titlebar?

> > > * Run A Command...
> > > 	Why is it needed on the head level anyway?
> >
> > a) because it's a common action
>
> Common for who? Certainly not for me. When did you last use it?

i use the minicli via the keyboard shorcut, but have seen many people use Run 
A Command... both in KDE and Windows. it's often easier to walk someone to 
the minicli by saying "Open the K Menu, select Run A Command" than "Ok, now 
press Alt-F2" because:

 o unskilled users often have issues with knowing when to hold both keys down 
at the same time (i kid you not)

 o the entry is always there in the menu, Alt-F2 can be remapped (as it is on 
my system right now)

 o newer users can stumble upon a menu entry themselves, but will rarely 
stumble on Alt-F2 on their own.

> Rookies?  Care to explain how they should know what to write in the box.

they are told what to type in there, or know the URL/name of the program they 
want. i've been impressed by Windows users who aren't very technical pop up 
the Run window and type in "cmd" to get a Windows command line when asked to 
pull one up.

> > b) people are used to it being there
>
> People are used to Windows too :-)
> I rather prefere a possibility to query for the right application/command.
> Like "man -k"
<snip>
> The problem is: I still like to be able to enter an URL without html:/
> and a command like "ls -l"
>
> How about keeping the current behavior but adding an HowTo(?) button?

interesting, indeed.. =) would you care to do a mockup in Designer, or some 
such, so we could try it out and test it on various people? i think this 
could be a great step forward.. it's a minicli/kdesktop thing rather than a K 
Menu thing, of course ... 

it would also require a way to know what to display there... perhaps an 
addition to the services .desktop menus (or using what is already there 
somehow?) ... perhaps gathering some information from the web shortcuts... 
from the control panels... or perhaps a completely new set of files? hm....

> Search the web with Google - gg:
> Connect with digital camera - camera:
> Look at manual for Unix command - man:
> Browse the web - http:
> - - -
> Translate from German to English - de2en:
> (How to display this list?)

these would be well suited to be a task in a task group...

> > >  Alt-F2 is much quicker.
> >
> > sure, if you know it's there. many don't.
>
> Why don't they? 

people don't read the documentation, they forget key sequences quickly, and 
the minicli window doesn't say that you can pop it up with a key combo?

> OK, most can. But you can not describe all uses of konqueror in 1000...
> So we will have: One task -> Many applications, and Many tasks results
> in calling the same application (possibly with slightly different data)

yes, that's inherent to a task oriented environment... one more reason i'm 
hesitant to put the application name after the task name...

> > how about a more radical idea: what if when you moused over an entry and
> > it got focus it would expand and a comment would appear right IN the
> > menu? there would be some reasonable timeout to avoid this behaviour
> > triggering when the user was simply moving from one part of the menu to
> > another....
>
> You might loose your mechanical feel for where items are if the space they
> use changes - that will move items around. (This is one of the problems
> with the autohiding on unused options in Windows)

the ordering wouldn't change, and the spacial relationship would only change 
if you stop for a moment over a particular item (perhaps indicating a lack of 
confidence?) ... i don't think the problems seen in the Windows collapsing 
menus would be seen nearly as much with this approach. but maybe it will be; 
i'll try and implement it and see how it feels ....

> But still - if an application is not
> installed should the related actions be selectable?

no, TOM already checks to make sure than the application (or at least the 
corresponding .desktop file) is available.

> And if a non cvs
> application is installed, shouldn't the corresponding tasks be added?

yes, this is an oustanding issue that hasn't been addressed yet. the README 
file notes it as such, however. the vfolder menu implementations are coming 
up against similar issues as well...

> Or is the TOM static with little reason to modify?
> Should all users have the same set of tasks?

not at all... that's why there are all the "Modify..." links in the menu =) 
taskgroups and individual tasks can be hidden/shown, the application they 
point to can be changed, etc...

> Should all configuration really be in one file?

it isn't...

> Or should the task descriptions (one liner + summary) be placed in the
> .desktop files? With only a simple file pointing at them? (to keep the
> translations in a minimum number of files)

that's how it works right now... the question is whether or not that will be 
flexible enough... KRun::processDesktopExec and KService::exec may be enough 
by themselves, but that will require testing. which will require real-world 
task groups. and i'd prefer if those came from people other than me so that 
my biases aren't reflected in their creation. i'd like to have a selection of 
files that will look like what a user or sys admin might actually want to put 
together... any takers?

> The point is: there is little use in deciding on format before it is known
> what needs to go into the files.

without a format, i can't build anything. it doesn't do much good to just sit 
in design mode the whole time, code needs to be written so the concepts can 
be tested. but the format can evolve during development. again, this requires 
feedback and real-world examples....

> Using an XML file might even result in
> using more complex data than necessary.

i'm hoping to avoid XML altogether, as i believe i mention in the TASKGROUP 
file

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

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD4DBQE+zlU91rcusafx20MRAnTxAJ9i3XQT4yoAramwiCfZIrglL+NS+ACXR7/C
fpiLajCBXlj+JyJhr58ANw==
=z4mS
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 