[Libreoffice-qa] [libreoffice-design] Future libreoffice.org web page: design request
christoph at dogmatux.com
Fri Sep 16 14:54:07 PDT 2011
after my rather lengthly explanation yesterday, here is an structural
example (based on See's design) of how it could look like:
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
> * [ --- ] a step not worked on yet after [ ... ]; step number
> cannot be calculated, but the action is known
> [ *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
> 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
> 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  as a
> * [ 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
> 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 ;-)
More information about the Libreoffice-qa