Good evening Loic!
18 minutes to go before tomorrow gets today ;-)
Am Mittwoch, den 14.09.2011, 12:57 +0200 schrieb Loic Dachary:
On 09/14/2011 01:01 AM, Christoph Noack wrote:
Hi Loic, hi all!
I've refined the interaction design a bit and uploaded it to the wiki -
[...]
I noticed the "next" button and the fact that each step would be
displayed on its own.
I assume that the user would be able to click on a previous step to
amend its choice. Is that right ?
Yep, otherwise the progress indicator on the left side isn't that much
needed ... the "Next" approach helps to slice the required information
in reasonable chunks being (hopefully) more understandable, and it
ensures a constant screen height. Of course, there are other
solutions ... but not knowing exactly the workflow and the questions, I
assumed this to work best.
If it is the case, let say (s)he changes the component. How would
(s)he be notified that a new subcomponent must be chosen ?
In the case of a single page displaying all the information, I though
there would be an error message + red border around the missing field.
With a multipage display I can't picture how it would work
Okay, there are some assumptions on my side, so let's go through some
use cases. I lack the time to do the example graphics, so I hope some
descriptions are sufficient to understand it. I hope something like that
can be done technically ...
The problem:
* We have procedure of several steps,
* the procedure might be tree like instead of linear,
* (future) steps may be added when working with the wizard
* (future) steps may also be removed when working with the wizard,
* the user might choose to go back and to change options,
* selected steps need to be checked for consistency/correctness,
* assumption: the user can only continue to the next step, if the
current step (and the steps before) are valid.
So, we need to introduce some states for each step (the stuff in the
squared brackets will be used for further description):
* not available
* [ 1 ] a step with number 1 not worked on yet
* [ <1> ] a step with number 1 already currently being worked on
* [ *1* ] a step with number 1 already finished
* [<*1*>] a step with number 1 already finished (before),
currently being worked on (because user visits it again)
* [ ... ] a placeholder for one or more steps not worked on yet
and not known yet (because we have to implement the tree like
procedure)
* [ --- ] a step not worked on yet after [ ... ]; step number
cannot be calculated, but the action is known
Example:
[ *1* ] Preparation
[ *2* ] Component
[ <3> ] Sub-Component
[ 4 ] Version
[ ... ]
[ --- ] Description
[ --- ] Submit
[ --- ] Attachment
It might look overly complex, but I'm sure you know such indications
from websites and other software. Let's dig into it ... the use cases
(each of the cases starts with the conditions in the example above).
Current: The user works on step 3, he successfully completed steps 1 and
2. The next step 4 requires to chose the LibO version - but this may
have impact on <insert_reason_here>, so we may need additional step(s)
[...]. Therefore, we skip the numbers for Description, Submit and
Attachment.
Go back: User goes back to step 2 but doesn't change anything.
* [ *1* ] Preparation
* [<*2*>] Component
* [ 3 ] Sub-Component
* [ 4 ] Version
* [ ... ]
* [ --- ] Description
* [ --- ] Submit
* [ --- ] Attachment
Note: If the user changes the component in step 2, then (in our
constructed case) all future steps are dependent and get set to "not
worked on yet".
Go forward: The user choses to have a look at one of the steps not yet
done. Here we have two alternatives (technical constraints will decide
here):
1. We don't offer to go there (inactive button)
2. We show the BSA page, but the whole page content is inactive
Add steps: The user selects the sub-component in step 3 and confirms.
Now we are sure that we need two additional steps - the workflow is
linear now. So we can add step 5 and 6, and the remaining steps can get
numbers as well:
* [ *1* ] Preparation
* [ *2* ] Component
* [ *3* ] Sub-Component
* [ <4> ] Version
* [ 5 ] Whateveroption
* [ 6 ] Evenanotherwhateveroption
* [ 7 ] Description
* [ 8 ] Submit
* [ 9 ] Attachment
Note: This behavior is similar for removing steps.
Note: The bullet points show the most simple linear use case we will
implement now, I assume.
I hope that explains most of the behavior - I hope some of the basic
ideas came through (and hopefully I did not make too many mistakes).
Let's see how to transform that into visual feedback ... using [1] as a
reference.
* [ 1 ] shown small number in small circle, semi-transparent
* [ <1> ] show large number in large circle, non-transparent
* [ *1* ] show small number in small circle, non-transparent
* [<*1*>] show large number in large circle, non-transparent
* [ ... ] placeholder like small circle, semi-transparent, no
description, no number
* [ --- ] show small number in small circle, semi-transparent, no
number
[1]
http://wiki.documentfoundation.org/cgi_img_auth.php/d/dd/BSAsee1.jpeg
Did anybody survive that description? ;-)
* I've tried to follow your current workflow, added snippets
provided by Michael and Rainer ... and considered "getting help"
and "joining a user survey". However, the essential part "bug
report" would also work "stand-alone".
* The structure contains a lot of "Full Description" elements -
added for scalability reasons, if the normal field size is too
small. So, they can be removed if not needed.
I'm not sure what you're referring to. Are there the "Read on..." links ?
Sorry, I haven't been clear enough. I've used some list fields that show
the information like tables (two columns). Rationale:
* The doesn't need to open a drop-down and is able to correct a
wrong selection more easily
* The user sees (a part of the) description right from the start
(e.g. what Chart means) - no need to "select, check description,
open drop-down again, select, check description, open ..." until
he finds the item that fits best
But, the table does only provide space for (approx. ???) 30 characters,
so we need a full description. That is the reason for adding the full
description below each field. Mabey we need it, maybe not.
* Personally, I think the structure is just a contain to add the
real workflow like the one by Michael. I don't know what's
currently planned, but it would provide more guidance (asking
for crashes, rendering fidelity ...).
I suppose the bug report will eventually be a tree of decisions. Because of that
it won't be possible to display all the steps in advance on the leftmost menu. But
for now it is and changing later should not be too much of a problem.
Should be covered in my example above.
* I've left some placeholders due to missing time and missing
knowledge, here it would be great if the others could jump in to
help us finalize the work.
* I might have missed some (or many) details, since I've tried to
avoid reading further mails this evening ... aehm ... night :-)
* And, grr, already found some caption mistakes after
uploading ... but that doesn't affect the concept.
Feedback appreciated ... :-)
There are two technical issues that impact the user experience.
a) the fact that the bug assistant cannot register a new user (this
has been covered extensively already and there is nothing to add, I
think)
Okay, but I had hoped this is considered already ... that's the reason
for asking the user to come back once the registration is finished (see
the preparation step of the BSA).
b) the fact that bugzilla only allows for an attachment once the bug
is created. It means that no attachment can be required to the user
*before* the bug is submitted. Of course, the bug assistant could hide
this from the user. For instance the bug could be submitted just
before the first attachment is required from him. However, since the
goal of the bug submission assistant is to reduce the number of bugs
that are poorly described, this should be done only after there is
enough information in the bug report, so that even if the user gives
up before attaching the document the created bug report is useable.
It is possible to workaround this limitation (attachments). However
that implies the creation and maintainance of a server side temporary
cache for attachments. This is not complex, but it adds a new layer to
the bug submission assistant. It currently is client side only and
there are no server side part. I'm happy to implement it if you think
it's worth the trouble but I wanted to let you know what it entails,
technically.
I've stumbled across the "no whiteboards entry" and "no attachments"
when submitting the bug for the first time as well ... of course it is
possible to work around that and to ask the user afterwards for one or
more attachments. The only thing is, that we have to clearly communicate
that in advance. So let's try to guide the user accordingly ... if it
doesn't work, then "we" might rethink the server cache stuff.
[...]
I'm expecting proposals from a web designer [...]
The work you've done with
http://wiki.documentfoundation.org/File:BSAinteraction.png makes it a
lot easier for them to understand what's going on. Much easier than
playing with the live example.
Hehe, thanks for the feedback ... indeed, that's the intention. Such
mockups make it usually easier to "connect" and to discuss with peoples
from different domains. And it helps me to understand the workflow ...
[...]
40 minutes past midnight ;-)
Cheers,
Christoph
