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


[Warning: this is a long mail]

Hi all,

thanks for your feedback. Let me put something first: I really appreciate the 
work done here.

I think most of you got the point I wanted to make. Basically my concern is a 
lasting success of LibreOffice. To achieve this we need a functioning UX team. 
So again: thank you for all the work done. I want to help you not getting 
frustrated.

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.

Am Dienstag, 1. Mai 2012, 10:51:03 schrieb Mattias Põldaru:
I would propose a way to reduce the noise in the list. This...

We need some code of conduct and a lot self discipline to get the ammount of 
white noise down - or a tool. I do not have a solution for that, perhaps we 
can start a seperate discussion about this? But there is more to this topic, 
than tooling ad self discipline - read on for detailed thoughts.

Am Dienstag, 1. Mai 2012, 10:05:57 schrieb Stefan Knorr:
So, you blame the people actively trying to work here for actively trying
to work here?

No surely not - I highly appreaciate this.

This list might get 50 messages per week on good weeks, it's near dead on
bad weeks. Our mail volume doesn't even come close to that of the developer
list (80 messages _per day_ on a good week, maybe 20 _per day_ on a bad
week).

My criticism is not about the ammount of mails, but about the (personally 
felt) ration of white noise. 

By the nature of this list, yes, the noise ratio is higher than e. g. on
the developer list (developers push patches that will likely get applied;
designers do mockups/etc. that might not lead to anything or even be
completely wrong-headed).
You're free not to read everything, btw.

I do not accespt that the ration of white noise is higher due to the nature of 
the list or type of work we do. I rather think it is higher, because we 
haven't yet professionalied the way we work. See how the thread I was using as 
an example turned from felt white noise into something useful, just because 
fundamental information was suddenly given? Seeing that things like this 
happen lead to the situation that I feel most mails are actually noise. This 
again makes it extremely hard for someone interested but with limited time to 
spot the non-noise topics.

Am Dienstag, 1. Mai 2012, 09:36:06 schrieb Andrew Pullins:
One thing I see as a problem is that some people seem to only work on one
thing. They seem not even to notice that we that we are trying to get
things done and need every one to participate. even if they know comment on
the proposals.

This is actually the reason why we need to settle the fundations. Do you see 
that all developers are working / coding on the same topic? No, because this 
would be highly unproductive. We shouldn't do that either. And again, if we 
didn't, the ammount of mails would be reduced.

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

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.

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. 

Am Dienstag, 1. Mai 2012, 09:36:06 schrieb Andrew Pullins:
Björn I have not seen you on this list in months and come only with
criticism on how we are trying to run things, without finding out if any of
what you say is true. [...] Yes there are things we could do better but we 
are just now starting to work on our work flow and how things are done
here.

Yes, my time is extremely limited - and the speed I can work in accordingly. I 
can be kind of a mentor for the outlined appraoch - but you will have to do it 
all by yourself. And for this you need to be interested in this kind of 
approach in UX work for LibreOffice. To my experience it is the only way that 
works, but you might want or need to experience this to be true or false 
yourself. 

In any case you should face the facts. LibreOffice is one of the largest Free 
Software Projects. It plays an important role in the Free software ecosystem, 
and there are a lot of players involved with strong interests. You shouldn't 
be too naive if you want to achieve anything lasting here. 

Cheers,
Björn

P.S.: 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.

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.

With proper requirements, we can convince developers (we can argue why users 
want a certain solution vs. we think it is the best solution) and we can work 
efficiently (hence involving experienced people). <dream>And perhaps we can 
someday even set our own topics on the agenda of some developers.... </dream>






-- 
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

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

Context


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.