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

[Christoph Noack]

Hi all,

after my rather lengthly explanation yesterday, here is an structural
example (based on See's design) of how it could look like:
https://picasaweb.google.com/lh/photo/PLZvWTs1NiL_w3auPyfUjA?feat=directlink

Cheers,
Christoph

Am Freitag, den 16.09.2011, 00:40 +0200 schrieb Christoph Noack:
> 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