Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

Hi Björn,

2012/5/2 Björn Balazs <>

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

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
goals we want to achieve with our designs, we have not agreed on the users
found personas, but not how they were created or any case of them ever
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

Most of the time design - esp. interaction design for a tool like
- is not art - it is craftsmanship. Different craftsmen (aka designers)
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
This is how we produce white noise, ineffective workflows and this is also
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
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
and validate the requirements. I can help you to deerive the needed
like personas, goals, situationas, szenarios. I can help you to work with

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
real. Finding the requirements - and by this setting the future goal (not
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
Foget the revolution - find ways to step-by-step transform LibreOffice.

I agree.


Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.