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

Hi Björn,

2012/4/30 Björn Balazs <b@lazs.de>

> 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
> name
> some)

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. <mazelm@gmail.com>

> 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
> https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote 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 <sumuthu@suse.com>

> 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. <mazelm@gmail.com>

> It's on the design mailing list already [1]. If you don't want to receive
> e-mails from the list, subscribe to
> design+subscribe-nomail@documentfoundation.org 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. :)
>
> [1] http://nabble.documentfoundation.org/Impress-remote-td3940884.html
> [2] https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote

The inital scope of the project was based on the GSoC ideas page:
http://wiki.documentfoundation.org/Development/Gsoc/Ideas#Use_your_SmartPhone_to_remote-control_slideshow.
Muthu didn't make any edits to it, so I assumed he approved of it when
he
replied.

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
> interest
> their employers or that tickle them personally. They simply won't work to
> make
> our visions come true (at least not until they gained trust in us as
> persons).
>
> So on every topic - the first thing we always have to do is to understand
> why
> 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
> first
> that allow us to evaluate the solutions we create - and make sure the
> coders
> 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
> the
> criteria. In this judgment we have to take coding effort (and other
> relevant
> aspects) into account and together with the coders agree on the final
> solution.

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

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,
> we
> 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
> and
> experience.

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

Thanks. :)



[1]
http://nabble.documentfoundation.org/Fwd-GSoC-LibreOffice-Templates-Dialog-tt3941992.html
[2]
http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-April/001017.html
[3] 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