KAssistantDialog proposal

[Jarosław Staniek]

Tim Beaulen said the following, On 2006-08-24 22:07:

> I think the clickabel steplist is an awfull idea.

Generally I agree. You mentioned other issues, so I commented below though:

> Why would someone need a clickable steplist ?
> To skip several steps (and use the default values) and set some other
> values in relevant steps?
> 
> If so, the problem is that there are too many steps.
> The solution is to reduce those steps.
> 
> Why not ask the user what he wants to configure?
> Something like a switch between a basic setup (default values) or
> advanced setup.

This is whole another topic to discuss. Quite orthogonal to our topic. I fully 
agree about hidding advanced options.

> In the advanced setup present the user with a list of maximum 5 or 6
> items that he can choose to setup individually and return to that list
> after configuring.
> If you need more, I think the design is wrong and the assistant should
> be split up in multiple assistants.
> 
> Instead of a clickabel steplist on the left, show a (non clickabel)
> context tree so the user knows where he is.

A tree? You just told about avoiding complexitiy and now proposed a tree?
Tree is not a model people can understand here. And our "people" are assistant 
users - we assumed these are often least experienced.

> Example:
> 
> First page: welcome page with the purpose and goal of the assistant/wizard.

Asking the first question here is recommended, if possible.

> Second page: ask the user if he wants to keep the default values with
> the exception of those values that need to be set. Or ask if the user
> wants to fine tune the settings.

How user can know what the values ARE? Aha, you show the values to him? So you 
need to offer the pages to him (that became available on his desire) _if_ you 
want to avoid cascading dialogs (Microsoft's way).

I am all for avoiding cascading dialogs indeed. Unfourtanely, a subpath (tree) 
that is created then becomes something like "assistant within assistant" or 
"modal dialog within assistant" in terms of logic, even is no dialog is used 
visually. Any ideas for this?
Maybe using "More>>" button showing the page's extension area fullfils our needs?

> If the user wants to tweak/fine tune the settings, give him/her a
> short list with the main topics he/she can change. Try not to give too
> many options (as it's going to be confusing for the user). 

> Also
> explain those topics in clear text, don't give five cryptic words for
> example. An assistant should help the user make his/her decisions.

This is quite obvious and has almost nothing to do with the topic.
A good addition to the HIGs.

> Now, when a user clicks on one of the options, a new page shows with
> more options to fine tune and so on. But don't create a tree that goes
> too deep here.

Above you taled about a tree. I dont liek _visible_ trees too in the assistant.

> In the mean time, give a context tree of where the user is on the left.
> If needed, it can be made clickable to go back. Clicking should not be
> available to go forward, 

Sure, because for the "steps" design boxes for upcoming steps are "grayed".

> which is ok if you only show the context
> because then you can't go forward only backwards. Going back should be
> seen as a cancel operation and should not set any values. Going back
> is a panic solution in most cases. Only clicking next should actually
> set values.

As I remember my battles with various assistants/wizards, I would agree that 
it's RISKY to allow jumping from step N to step M where ABS(N-M) > 1.
In fact such behaviour should be implemneted as a series of internal button 
clicks (next->next->next or prev->prev->prev). Jumping forward is only 
sometimes available for certain assistants. Cross-dependencies between steps 
can be really hell to debug (e.g. if page N+1 needs to be re-filled after data 
on page N has been changed, so jumping from N to N+3 is not allowed).

> After finetuning the options the user gets back to the original topics
> he can finetune. There he still has the option to finish the assistant
> and keep the defaults for the other options. Maybe the user can be
> shown visually which topics he altered and which not.

Maybe rather to show _the results_ of the selections made by the user on the 
last page? It's not always equal to the list of fields altered. It could be 
nice to support this feature somewhat in the API to get additional 
consistency, e.g.:

<Assistant page>
--
The assistant is ready to perform destroying your hard discs. You have 
selected the following actions:

<listview>
1. Destroy a surface of /dev/hdc
2. Burn /dev/hda
</listview>

Press 'Start' to begin destroying.
--
</Assistant page>


^^Note: sometimes we really replace "Finish" by other word.

> In short, what I want to say is that I have the feeling that a
> clickable steplist will eventually lead to super complex wizards with
> all the bells and whistles one can think of. Instead, these should be
> seperated in different assistants.

I see the point.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org