Re: [libreoffice-design] Future libreoffice.org web page: design request

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


-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted