Re: [libreoffice-design] Think, don't just do - WAS: Impress remote

Hi Björn,

2012/5/2 Björn Balazs <b@lazs.de>

> Am Montag, 30. April 2012, 23:25:32 schrieb Mirek M.:
> > I did contact the mentors of all the GSoC projects with need for design
> > privately [1] [2], but I did make the mistake of not reposting the one
> with
> > Muthu Subramanian, the mentor for the Impress remote project, publicly.
> > Here is a copy of the conversation:
>
> Thanks for posting this. Actually this would have been one of the most
> usefull
> mails on the list, because it helps to understand if it is worth to step
> in or
> not. Because of this missing, I felt the rest of this thread was white
> noise.
> If you published these, we cold have told you that the work is done by the
> student and not the mentor, so contacting the student is almost as
> important.
> Thanks again - and great you did contact the mentor.

I did realize the work was done by the student, but I believed the mentor
was the project lead and therefore it seemed like I should contact him
instead.

> The other thing that bothers me is when they finally do join in on the
> > conversation they one get us off track, forcing us sometimes to make a
> > completely new thread just to get what we were working on done. But even
> > worse is once the second thread has been made there is no interest in it.
>
> This and your point above both have the same roots. We have not agreed on
> the
> goals we want to achieve with our designs, we have not agreed on the users
> (I
> found personas, but not how they were created or any case of them ever
> being
> used actively).

So far, personas have been done by designers without proper concensus, but
they should be done (or at least approved) by the developers in charge of
the project, since they should know more than anyone who they want to
design for.
You're right -- they haven't been used actively yet. Would you prefer it to
be required to include personas in the design proposals, detailing how the
design would help each person?

What kind of goals do you mean?
In my view, the Scope is restrictive enough to keep all design proposals on
topic, yet open enough to allow some creativity and not mandate a single
workflow.

> Most of the time design - esp. interaction design for a tool like
> LibreOffice
> - is not art - it is craftsmanship. Different craftsmen (aka designers)
> should
> come to almost the same solution, if they have the same briefing.

Thus it is not necessary to have competitions on design. Most of these
> competetions are due to lacking requirements. Simply the discussion is not
> lead about the requirements, but about derivates from it - design
> solutions.
> This is how we produce white noise, ineffective workflows and this is also
> the
> reason for people jumping into a discussion, trying to bring in something,
> others obviously have overlooked.

I don't agree. I believe the Scope itself should provide the necessary
restrictions for a good design. It is imperative that the Scope is defined
precisely and in detail, but not in a way to restrict the creativity of
designers when it doesn't need to.
There are a myriad of ways to design for a single feature -- just look at
the amounts of OS shells cropping up lately, all with a different workflow.
Interaction design is craftsmanship, yes, but good craftsmanship itself
requires artistry and out-of-the-box thinking.

Am Dienstag, 1. Mai 2012, 10:05:57 schrieb Stefan Knorr:
> > > - there was no proper analysis of requirements
> > You might be able to help us here, I guess. We're currently using the
> Scope
> > field of Whiteboards. If you want to propose a better process to go along
> > with that, please do.
> >
> > > - there was no agreement on the goals that need to be achieved (just to
> > name some)
> >
> > Hm, this is one of my own criticism of the current whiteboard workflow we
> > have. So yes, I agree.
>
> I have offered this before and I do it again now. I am willing to help you
> defining the requirements. I can help you to conduct the user research to
> find
> and validate the requirements. I can help you to deerive the needed
> artifacts,
> like personas, goals, situationas, szenarios. I can help you to work with
> them.

I would prefer if you posted a proposal of a way to include these in our
idea workflow [1] on your user page.

To be honest, I don't have a very positive experience with user research.
> From my experience, in most cases, the problems with the current design are
so blatant that designer can rely on his own experience with the software
and so painful that the designer wouldn't even think of including them in
his proposal. It's much more likely that the designer will have some
omissions in his proposal that impede usability, and it's very important to
test for those.
If you know of any open-source tools that would help us produce some simple
prototypes, please speak up.

Defining the requirements is one of the very few tasks we can actually
> do mostly for ourselves. For every solution, we need a coder to make it
> come
> real. Finding the requirements - and by this setting the future goal (not
> the
> way) LibreOffice is going to reach - is something we can - no we have to
> initiate, because nobody else will do this.

Again, what do you mean by requirements if not the scope?

If you mean establishing some design principles that will influence all of
our proposals and the way LibreOffice develops over time, something like a
HIG or a style guide, then I agree that it's something we need to work on.

> Once this is done we have to efficiently use the opportunities we get (aka
> things developers want to work on) to evolve LibreOffice into something
> great.
> Foget the revolution - find ways to step-by-step transform LibreOffice.

I agree.

[1] https://wiki.documentfoundation.org/Design/Whiteboards/IdeaWorkflow

-- 
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