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

List:       kde-usability
Subject:    Re: TOM write-up
From:       Eric Ellsworth <whalesuit () softhome ! net>
Date:       2002-06-11 0:52:11
[Download RAW message or body]

> On June 10, 2002 05:54 pm, Eric Ellsworth wrote:
> > Quick addendum to that:
> > 	{W} means I think that novices would want some kind of help (like a
> > wizard) when they click on this item.
>
> should we perhaps have a set group of these ready for re-use?
Yes, in general, I think we should try to set it up this way.

> this also begs the question of whether this information should remain in
> the TOM menu task group configs or if a corresponding .desktop file should
> be created in the $KDEHOME/share/applnk ...  right now TOM relies
> completely on .desktop files in applnk directories, as I believe it should.
> =)
>
> > 	For Office-Specific programs (which is terrible terminology, BTW), I was
>
> Business Application?
Excellent.

> > thinking of programs that an enterprise may have that few others have -
> > databases, custom software, unusual software, etc.
> that's what the "Modify these tasks" entry in each task group is for ...

Right, I was thinking of cases like apps that run in a terminal, or over 
Citrix/Terminal Server, or some other weird setup, but I guess we should 
leave that to local sysadmins - in the current design, can tasks like this be 
something that you can just dump into $KDEHOME/share/applnk dir?

> can we avoid the word "boxen" and use "remote system" or "server"? perhaps
> "Start a command line session on a remote system", only less verbose ;-)

Sorry, "boxen" was a joke...  My point is that "start a session on a server" 
is a task that no novice would understand.  They (in this case I know LOTS of 
people like this) know they "open up homer", then type pine (or choose it 
from some menu) to read email.  So to them the command line session IS email.  
If we can work this into our wizard, that's would be super cool.  In a lot of 
those cases, our wizard could even check for POP/IMAP access and inform them 
they can use KMail to read this mail....

> this could also be served well by a TOMWizard service, if it was designed
> generically enough..
That's kind of where I see it going, but perhaps we should try a few cases 
before trying to solve the general problem. Oh, wait, I guess I'm the holdup 
here....:)

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