From kde-usability Fri May 23 17:07:09 2003 From: "Aaron J. Seigo" Date: Fri, 23 May 2003 17:07:09 +0000 To: kde-usability Subject: Re: TOM X-MARC-Message: https://marc.info/?l=kde-usability&m=105370985101694 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 May 2003 04:58, Roger Larsson wrote: > But suppose the user does not have KMail as default? > "Click on the Email entry" > "OK, done that" > "Now select: Tools - Address Book" > "Huh - I have no such menu" 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" > 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