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

List:       kde-devel
Subject:    Re: RFC: WorKflow mockup / prototype
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2006-06-06 0:13:57
Message-ID: 13ed09c00606051713v757e0751t9c2a637cf5303b49 () mail ! gmail ! com
[Download RAW message or body]

Hi Thomas,

I'd like to second Vivek's comments.  This is something I probably
whine on about quite a bit but I have seen several KDE applications
fail to do their job because the developer focused on creating a
highly flexible application over creating something which "just works"
for the most common tasks.  There is nothing wrong with creating a
flexible piece of software, it seems to be a core part of the "KDE
philosophy", but it can get taken to far and prioritised over more
important goals.

One review technique I find quite useful is to write down the most
common use cases I can think of, then for each case, start the app
(with DEFAULT settings and layout) and write down the sequence of
steps need to get the result.  It then becomes more obvious if too
much work is required to accomplish something or if too much technical
knowledge is expected of the user or if the program is prompting the
user for information which it could accurately guess itself.

> Yeah, I was thinking about a Most Frequently Used list of commands.

Careful selection of the commands which are most readily accessible in
the UI is, IMO, more important.

Regards,
Robert.

On 06/06/06, Thomas Kadauke <tkadauke@gmx.de> wrote:
> Hey Vivek,
>
> Am Tuesday 06 June 2006 00:28 schrieb Vivek Rai:
> > Just as a note of caution, and something to consider while doing the
> > UI design, I have seen some projects on KDE that are really great on
> > functionality and flexiblity, but become too complex for a non-techie,
> > newbie user, whom they were built for in the first place.
>
> True, but I want this program to be useful for myself, too. So the idea is to
> have simple and common things done almost automatically, and to have advanced
> stuff easily accessible :)
>
> > So, you have to keep in mind all the time that:
> > 1) A techie developer is NOT the intended audience for this
> > application. Someone who CAN use the command line for such tasks, will
> > always do so, and NOT use a GUI tool.
>
> I don't think that's entirely true. See, WorKflow is not just a "graphical
> bash". It's about common tasks on a *desktop* system. I already brought the
> example of automatic image rescaling, which can also be done on the command
> line (but honestly, I don't really feel like going through the ImageMagick
> man pages for that). Another example which involves desktop software would be
> to have KMail pop up a message if you get an email from a specific person and
> open a reply window on request. Ok, this can be done in a bash script using
> dcop, but that's even more complicated than the pure command line. And I --
> as someone who could write such a script in a few hours -- wouldn't do it
> ever. This is just too much work. However, WorKflow will actually make it
> possible to do this in a matter of seconds.
>
> > 2) This tool will be most useful for a very newbie user, so you have
> > to keep the GUI as simple and easy as possible.
>
> That's true. And this is why I'm asking for comments :)
>
> > So, I think you will have to assist such a user with building some of
> > the frequently anticipated commands.
>
> Yeah, I was thinking about a Most Frequently Used list of commands.
>
> > E.g. 1.
> > I am assuming that you do not expect the user to type in "find
> > <some_directory> -name "*.png" as the input, but have some sort of a
> > GUI which builds such a command graphically
> >
> > like the UI to build the "find" command would probably be asking
> > questions for the most frequently used options
> > what Directory? (file open dialog)
> > --> CheckBox Search Sub Folders?
> > --> filename is like dropdown with (*.*, All Files, and various
> > frequently used file extensions, with the ability for the user to put
> > in any new filename pattern as well)
>
> Thanks for these suggestions. They're added to my TODO. However, in this
> specific case, I would rather have a mimetype dropdown or something similar,
> because this is much more powerful than just filename extensions.
>
> > --> some way to open a separate window to pick up other "advanced"
> > options, (mtime, size etc).. (ie, keep advanced things hidden from the
> > main windows, and avoid clutter)
>
> I don't know about this, because I hate advanced windows :) But since the
> command library is extensible by plugins (yes, already), third-party
> developers can of course choose to bring in modal popup windows for advanced
> options.
>
> > E.g. 2
> >
> > You dont expect user to type even simple commands like cat, sort,
> > dict, etc, rather you have these configured as "predefined" command
> > descriptions __i18n("Read the text inside the file") __i18n("Sort
> > alphabetically"), __i18n("Only look for words defined in the
> > dictionary")
>
> Sure. The goal is to hide all implementation stuff. That is, unless a user
> specifically wants to call a command line application, she won't know which
> command line application is used, if at all.
>
> > It would be good to have a flexible configuration for such
> > "predefined" commands, (and maybe even store any package dependencies
> > here), so that people can easily add to it and extend it.
>
> See above.
>
> > Also, How about also representing the steps visually, (e.g. a crude
> > kind of data flow diagram with blocks of actions joined by arrows
> > etc?) ... this can be vertical, if you think most actions would
> > involve too many steps..
>
> Yeah, that's what is shown in the screenshot. Only the arrows are missing, but
> I'm working on that.
>
> >  _______________              ________________           _____
> >
> > |  get filenames  | -------> | filter valid words| ----> | sort |
> >
> > Allow user to enter an "action" visually, example, if you want to add
> > another step between filter valid words and sort above, it the most
> > intuitive UI would perhaps be be via a menu that appears when u
> > right-click on the arrow between them.
>
> Right now, it's already possible to add actions using drag'n'drop. The
> position where the action will be inserted is shown by a cursor. Also, the
> cursor can be controlled by the arrow keys. Commands can be selected and
> removed using the mouse or the keyboard, much like in a text editor. Finally,
> full undo/redo support is already in (for most things, that is).
>
> If you want to check it out, it's in SVN at /trunk/playground/utils/workflow.
>
> > To change any such step, I would think the most intuitive way would
> > be, that if you select th corresponding box, the window should show
> > the details of that step, for you to modify.
>
> Right now, the plan is that the commands show their GUI by default, but can be
> collapsed to save some space.
>
> > Just my (hopefully constructive) thoughts on this,
>
> Thanks a lot for your thoughts, they were indeed helpful.
>
> --Thomas
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]