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

Hi Björn,

2012/4/30 Björn Balazs <>

So far there have been 16 mails and a couple of possible solutions in this
thread and - as far as I understood -

- nobody from the design team even talked to the GSOC student or the mentor
- there was no proper analysis of requirements
- there was no agreement on the goals that need to be achieved (just to

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:

2012/4/26 Mirek M. <>

Hi Muthu,

 I'm from the LibreOffice Design team.
I see that your "Smartphone remote control for LibreOffice Impress" GSoC
project has been accepted. Would you like to work with us to produce a
design for it? How soon do you need the design?

We will be using a whiteboard on the LibreOffice wiki at to
design this. Could you take a look at the page and make sure the scope of
the project is correct, perhaps add to it if there are any development
limitations designers should be aware of?

Thanks. :)

2012/4/26 Muthu Subramanian K <>

Hi Mirek,

Thank you! Its really nice to have help being offered.
Sure, can we take this on the public mailing list then, please? I guess
more people would like to involve (?)

Thank you so much!
Muthu Subramanian

2012/4/26 Mirek M. <>

It's on the design mailing list already [1]. If you don't want to receive
e-mails from the list, subscribe to to take part in the
discussion and use Nabble to follow the discussion.

Our workflow is basically this: we take a week for submitting proposals,
then a week for analyzing the proposals, then yet another week for shaping
the final design. Each "week" begins on Saturday at 18:00 GMT with our
regular IRC chat. Designs will be posted on the whiteboard [2].

If you'd need the design faster, though, we could definitely pull some
strings and work faster. :)


The inital scope of the project was based on the GSoC ideas page:
Muthu didn't make any edits to it, so I assumed he approved of it when

For some reason, I did not think to contact the GSoC students, as I somehow
assumed that the mentors were basically the go-to people in this situation.
I see that my assumption was wrong, and I will contact the GSoC students as
soon as possible.

There is a simple reason for this: Coders work either for topics that
their employers or that tickle them personally. They simply won't work to
our visions come true (at least not until they gained trust in us as

So on every topic - the first thing we always have to do is to understand
the coders are working on a it - aka what tickles them. Next is a polite
question if they are interested in any UX support at all - and what extend
would suit them. If they want us to step in, we have to discuss criteria
that allow us to evaluate the solutions we create - and make sure the
agree with these criteria (sometimes we even need to do user research for
this). Only then we can create actual solutions and judge them by applying
criteria. In this judgment we have to take coding effort (and other
aspects) into account and together with the coders agree on the final

That is essentially what the Scope of each whiteboard defines. The Scope
for each of the four GSoC whiteboards was based on the descriptions on the
initial GSoC ideas page I already mentioned and on the discussions with the

Each whiteboard should start with the scope, and the scope should be
determined by the person who plans to implement the whiteboard. Then comes
the "idea workflow" [3] which every whiteboard goes through. The first part
of it is a call for proposals, which is basically a design brainstorm.
Coders don't need to be involved at this stage -- the designs are based on
the scope alone, and it is important that designers get some degree of
design freedom in the brainstorm session. If a coder sees a problem with
the scope, he can, of course, adjust it accordingly. The coder also doesn't
need to be involved in the first IRC chat, as it is simply a prelude to
what will happen the following week -- the proposal analysis. The coder is
encouraged to submit problems that haven't been solved by the submitted
proposals or ones with several possible solutions, their possible
solutions, and the advantages he sees to certain solutions. The final
solution to each problem will be up to the coder, unless he gives this
power away to the designer.

If we do not roughly follow this agenda, it is very likely the coders will
simply ignore whatever we do - thus we do not need to do it at all, because
everything is wasted anyhow. This will predictably lead to frustrations on
both sides - coders and UX people.

I agree, though I still believe there is value to making whiteboards
ourselves when no developer has shown interest in working with us on a
certain feature, as a good tentative design may inspire a developer to work
on a feature.

I believe the Gnome team works largely this way, and they've produced some
wonderful work.

A bit unrelated, but also important: with the current way of doing things,
are creating such an amount of white noise on the mailing list that some
people (like me) simply cannot follow the discussions anymore. Again, this
will not lead to acceptance, but to frustration and to a loss of knowledge

As our new way of doing things goes, we have one thread per topic we are
working on, which I believe is a must. Any suggestions on how to reduce

Thanks. :)


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.