Think, don't just do - WAS: Impress remote

Hi all,

I like to step into the Impress Remote discussion - not presenting a mock-up,
but trying to get you guys to reflect a little bit about they way you are
working.

In the past I (and many other experienced design and usability people) more or
less left this group / mailing list. This is definitely not due to a lack of
interest - I still read a lot of the stuff written here.

I think the thread about creating an impress remote UI at least for me is a
prototype to illustrate what is going wrong here at the moment.

Let me tell you a little bit about my background: Personally I have spent more
than 10 years now working on the usability for free software projects (and
almost 15 years of professional consulting in UX, including running small
companies offering UX services). Next to LibreOffice I have worked for
Wikipedia or KDE just to name some you might know. I have also co-initiated
OpenUsability.org and was in the jury of free-software awards.

I am not writing this to show off - I am writing this in the hope you might be
interested in the experience I gained over the past years and you might accept
my following criticism to be constructive - and not as trolling or ranting
around.

So what do I actually want to say?

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)

Working this way will never work out. I predict a great amount of frustration
for a lot of people and lasting harm to the standing of UX within the
LibreOffice community.

UX is a service discipline to the coders. If we do this service well enough,
we might be able to set our own topics on the agenda - but to my experience
this will take a (very) long time of providing excellent service first.

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.

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.

The impress remote thread shows that we do a lot of work without even
reassuring that our work is welcome - or evaluating the criteria for a good
solution.

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.

To sum it up, please:
- think before you start working on a topic
- think before you send a mail to a mailing list

Hope this mail is fruitful - LibreOffice as a project is too important for the
Free Software ecosystem, and we really need the energy you guys show. Simply
do not waste it to create tons of frustration.

Thanks for reading.
Björn

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

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi Björn,

2012/4/30 Björn Balazs <[hidden email]>

> 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. <[hidden email]>

> Hi Muthu,
>
 I'm from the LibreOffice Design team.
2012/4/26 Muthu Subramanian K <[hidden email]>

> 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. <[hidden email]>

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
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 [hidden email]
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

Thank you Björn, I read it twice and it got me thinking about my recent
less useful e-mails to the list.


30.04.2012 22:45, Björn Balazs kirjutas:
> 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.
I would propose a way to reduce the noise in the list. This is partially
inspired by the way how Drupal issues queue works (also similar to
Launchpad) with additions from Debian mailing list commands.
Unfortunately I am unable to implement this myself.

There would be a central website with threads/topics/issues and comments
(possibly Drupal) with mailing list integration.

Every e-mail or thread which is started is by default sent to everybody,
unless "Important" is unticked in web form or "not important" is added
to the first line of the e-mail.

If any thread seems important or interesting you could click "Follow" in
web thread or reply with a single-line e-mail reading "follow".
Obviously nobody else is notified of this. Unfollow is possible as well.

Every reply or comment to the thread is by default visible only on web
and only the people who are "following" the thread are e-mailed (or
notified on the web). By commenting on a thread you are automatically
following it.

If someone is sure that the comment is important to everybody, one could
add "important" to the first line of the reply email or tick a checkbox
labeled "Important". And everybody would get the mail.

For everybody who like the old way for themselves, they could be
"Autofollowing everything".


Unfortunately this kind of kills the point of mailing list, it becomes
"Thread announcements list" instead, this is what Daily digest is for,
and it may suit it even better. But on the other hand it really shines
only on the web representation of discussions, making it easy to jump in
by non-members to search and comment on threads they find useful.


Best regards
Mattias

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi Björn,

> In the past I (and many other experienced design and usability people)
more or
> less left this group / mailing list. This is definitely not due to a lack
of
> interest - I still read a lot of the stuff written here.

Sure, it's a huge problem that we don't have any UX professional as a
regular contributor currently. But is it not a tad unfair to blame the
people that are actively working on things here for that not being the case?
I'm sure if there was no one posting here at all, the UX professionals
wouldn't come in droves either.


> I am not writing this to show off - I am writing this in the hope you
might be
> interested in the experience I gained over the past years and you might
accept
> my following criticism to be constructive - and not as trolling or ranting
> around.

It's probably best to lead by example not by criticising... no?


> - nobody from the design team even talked to the GSOC student or the
mentor

I believe this criticism is unfair, in particular to Mirek. (Who posted his
conversation in this thread; he's talked to relevant developers on other
topics as well.)


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


> UX is a service discipline to the coders. If we do this service well
enough,
> we might be able to set our own topics on the agenda - but to my
experience
> this will take a (very) long time of providing excellent service first.

We're trying to go into this direction. Meanwhile, there's still ux-advise
for very focused UX advice. If would like to help out there: would love
that.


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

So, you blame the people actively trying to work here for actively trying
to work here?
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).
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.


Regards,
Astron.

PS: On the topic of surveys... I'd be very much interested in a survey on
the placement of the Add/Remove buttons on my conditional formatting
proposal. I imagine having ~three participant groups, and each group gets a
more-or-less functional HTML mockup with differently positioned Add/Remove
buttons. Would that be something that we could do together?

--
Unsubscribe instructions: E-mail to [hidden email]
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

Björn, Mattias

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. Mirek has taken the time to get the devs view on
things. 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.

Mattias that sounds way too complicated for this list and may kill it. Like
Astron said we do not get all that many emails each week.

> ...This list might get 50 messages per week on good weeks, it's near
>dead on bad weeks.

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.

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.

The only solution is for people to stop getting the thread on tangents and
post their questions in their own  thread. Even if it's even slightly
related to the current thread.

--
Unsubscribe instructions: E-mail to [hidden email]
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

2012/5/1 Stefan Knorr (Astron) <[hidden email]>

Frankly, I really appreciate Björn's feedback -- it's this kind of feedback
that makes us rethink our work processes and it makes the chances of
anything we design getting implemented much higher.

Not everyone can afford the time to contribute, and when you feel like the
team's processes are completely misguided, you don't even feel like
contributing.

That said, I believe I've done all I could to get the relevant developers
involved, whether they do is their decision. Right now, we can't afford to
wait with the GSoC whiteboards -- we have 3 weeks to produce a design for
four whiteboards, and that's the minimum time that our idea workflow allows.

>
>  > - nobody from the design team even talked to the GSOC student or the
> mentor
>
> I believe this criticism is unfair, in particular to Mirek. (Who posted his
> conversation in this thread; he's talked to relevant developers on other
> topics as well.)


Yeah, but I posted the conversation afterwards, so it's understandable that
Björn would think that nobody contacted the mentor or the student.

The goals should be part of the Scope as well. The Scope is basically the
definition of what traits the design should have.
Goals are further cleared up by the Personas (the kinds of users the design
is intended for).

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi Astron,

Stefan Knorr (Astron) wrote (01-05-12 10:05)

> So, you blame the people actively trying to work here for actively trying
> to work here?

I would rather understand  Björn's mail as an support to be critical
about the way the work is going on, and with good pointers, from an
experienced person, for possible improvements, beneficial for ourselves
and the work.

Depending on the circumstance, something like that could be worth more
then a dozen designs ;-)

Regards,

--
  - Cor
  - http://nl.libreoffice.org


--
Unsubscribe instructions: E-mail to [hidden email]
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

[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:
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 [hidden email]
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

Hi Björn,

2012/5/2 Björn Balazs <[hidden email]>

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.

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:
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 [hidden email]
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

Hello Mirek, Björn,

from Björns mail:
I absolutely agree with Mirek. Your offers have always seemed
relatively vague to me. I would find it very interesting to know how
to best work with what you have to offer.


> To be honest, I don't have a very positive experience with user research.

Hooey... out of genuine curiosity: where/how have you collected your
experiences?


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

To some (largeish) degree that's probably true in LibO... but user
research might at least _help_ with priorisation of problem points. As
in, you or I or [design team member] are not the (only) people whose
problems we are/we should be trying to solve.


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

Seconded.


>> Foget the revolution - find ways to step-by-step transform LibreOffice.

:) This point has been made quite a number of times before. So yes, we
are covered.


Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
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

> I absolutely agree with Mirek. Your offers have always seemed
> relatively vague to me. I would find it very interesting to know how
> to best work with what you have to offer.

It's late already... excuse my awful wording.


Also, Björn, I am sorry for seeming so harsh in my first reply to this thread.

Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
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

2012/5/3 Stefan Knorr (Astron) <[hidden email]>

>
>  > To be honest, I don't have a very positive experience with user
> research.
>
> Hooey... out of genuine curiosity: where/how have you collected your
> experiences?


Some firsthand experience from a few school projects, plus observation
based on Mozilla's and Canonical's (and perhaps some other companies' that
I can't recall right now) user tests.

So not much experience at all.


I didn't mean to say that user research is useless -- far from it. In a lot
of cases, it's genuinely helpful.
I just meant that, right now, if you look at the topics we've covered with
our whiteboards (color handling, Template manager, the Options dialog,
...), the faults there are obvious and the designs that we create turn out
miles different from our previous implementation, so IMHO any user testing
we'd have done there would have been a lot of effort wasted for very little
(if anything) gained.

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi all,

thanks for your feedback. And no excuses needed for anything that is beeing
said. I assume everyone (including me) has only the best in mind, so do not
take anything personal...

I will try to address the major points.

1. Made bad experiences with User Research

Anyone who is working in UX and does not believe in the power of working with
users should actually question him / herself wether (s)he is doing the right
job. Funnily enough, there was a great dilbert about this issue just a few
days ago:

http://dilbert.com/strips/2012-05-07/

If we do not go out of the house and work with real users (think of cultuural,
social and many other factors influencing UX) we automatically do imply we are
the users. But we are not. We are users, but not the users. Any UX process
that does not take this into account will only accidently produce good
results.

If anyone has made bad experiences with that, then do should not resign.
Instead work harder on making this work. It is a difficult topic. At least I
never said anything different.

I am not saying anything about the arguement, that we cannot do it any worse
than it is, even without asking the users. If I have to say anything about
this it would propbaly turm out to be personnal... So we agree on this never
beeing said, ok?


2. If you want to help use our structures.

I will not use the structures you set up, because I think they are
fundamentally wrong (disclaimer: as far as I could follow them, seeing there
have been tons of mails about this topic that I did not read all - correct me
if anything I say is wrong).

You propose a waterfallish modell with a closed design phase at the beginning.
All I have learned in software development is: This does not work out.

Not all designers should work on every topic. We have to build small teams and
apply best principles of agile software development.

You are isolating topics. The personas for Impress remote are different from
those I saw at some other place. This will never lead to a consistent user
experience across LibreOffice. This might lead to some isolated really cool
solutions, but the user will never feel this is one applications suite.

So, sorry, but I am not willing to invest my valuable time into these
structures.


3. Vague offers of help
You said my proposals are very vague. I partially agree with this.

I did make a very concrete suggestion to help you solve the "bold, italic,..."
icon discussion, by showing you a way how to solve this problem with users,
taking different languages and cultural backgrounds into account. But there
was no reaction to this. This offer still stands and could be a extremely
concrete starting point.

My following suggestions were indeed vague, because I felt it would be a waste
of time to offer something concrete again, if there is no interest. As I said
- my time is strongly limited.

So, still staying vague, I can help to build up the artifacts (vision,
personas, scenarios,...) that can help us to create a consistent UX within the
LibreOffice suite, help to validate these artifacts with real users, create
solutions together with developers and again validating them with users - just
to name some things we need to work on.

But be aware, this will shift the focus in this list from designing (which I
still see as a craftmenship) to research and understanding. I strongly
believe: if we understand, finding the solutions is easy. This is why the work
we need to do is research.

So if there is anyone interested in this resaerch based approach on
LibreOffice design, give me a sign and we will find a way to start working.

Cheers,
Björn


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

--
Unsubscribe instructions: E-mail to [hidden email]
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

2012/5/8 Björn Balazs <[hidden email]>

:D good one

>
> If we do not go out of the house and work with real users (think of
> cultuural,
> social and many other factors influencing UX) we automatically do imply we
> are
> the users. But we are not. We are users, but not the users. Any UX process
> that does not take this into account will only accidently produce good
> results.


I feel like I phrased what I meant to say badly -- looking back, I do feel
stupid for what I said.

What I meant to say is that I'm not sure testing our current UI for the
things we're working on now would be worth the effort. We plan to
restructure some things in a major way to target the major problems that
are blatant (just look at the template dialog or the color picker or the
settings dialog). With the GSoC projects, we're also under a deadline of 3
weeks, and I doubt we could set up a good design workflow that takes user
testing in mind, then follow it, and still make it on time. On the other
hand, I certainly believe we will need to do user testing once we produce
those designs.

I can see how analysis of our current UI could be useful, though, and I'd
like to incorporate it into our workflow. It would also be helpful to test
the designs of our competitors. If you have tips on how to incorporate it
into our workflow, especially in such a way that any volunteer could do it,
please voice them in a reply.

2. If you want to help use our structures.
Not sure what you mean by "closed design phase". Everyone is welcome to
contribute.


> All I have learned in software development is: This does not work out.
>
> Not all designers should work on every topic. We have to build small teams
> and
> apply best principles of agile software development.


That sounds great, down the road. Right now, though, I don't really think
we have enough people involved to be able to form small teams. I'd also
like to get some basic design principles, maybe a small HIG, approved so
that we'd have something to guide our designs.

>
> You are isolating topics. The personas for Impress remote are different
> from
> those I saw at some other place. This will never lead to a consistent user
> experience across LibreOffice. This might lead to some isolated really cool
> solutions, but the user will never feel this is one applications suite.
>

As I said, I believe we need some guiding principles.
I also agree that our personas right now are basically worthless given
their quality. Please feel free to improve upon them.
I'm not exactly sure what you mean by isolating topics. I feel we have to
work on one topic at a time, though of course we have to take the whole of
LibreOffice into consideration, and some topics are interconnected. For
example, the design of the file manager for Android will depend in part on
the design of our Template dialog, as is clearly stated in the whiteboard's
scope.

>
> So, sorry, but I am not willing to invest my valuable time into these
> structures.
>

Could you offer some tips for creating a better structure, though?

I completely agree with user testing icons. I think it'd be great.
That said, I hoped an experienced icon designer would come in and help with
the project -- and some experienced designers did show interest at first,
but, unfortunately, were never heard from again. The submitted icons used
varying line widths, some used rounded corners, some used sharp corners,
all were different widths and heights and used differing amounts of detail,
and since I personally have never designed an icon set, I'm not sure how to
best coordinate development to end up with a consistent-looking set. So I
personally gave up on the project, at least for now (I might come back to
it later). If anyone wants to take control of it, he/she is welcome to do
so.

Sounds great.

>
> But be aware, this will shift the focus in this list from designing (which
> I
> still see as a craftmenship) to research and understanding. I strongly
> believe: if we understand, finding the solutions is easy. This is why the
> work
> we need to do is research.
>

I agree.

>
> So if there is anyone interested in this resaerch based approach on
> LibreOffice design, give me a sign and we will find a way to start working.


Definitely interested. How do you suggest we start?

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi all,

just a short additional note - a more detailed answer will follow in the next
days:

Please do not mix up user testing user research.

RESEARCH is about understanding (and creating artifacts accordingly) who the
users are, what they (want to) use the product for, what goals they want to
reach, what criteria apply to a successfull interaction, what prior experience
they have, where they will use the tool,.... This can perfectly be done in
distributed teams using web tools. We can reach users all over the world. Past
experience in Libre Office has shown that it is easy to get feedback from more
than 10000 actual users within days. And these were just first tries...

TESTING is about presenting users with possible solutions, and watching how
they solve given tasks. This usually is extremely difficult to do with
voluntary development teams, as you would need test rooms, local, but still
representative - perhaps even paid - participants etc. There might be some
room for this on fairs or similar events, but I would rather not be too
enthusiastic about testing. In my experience the value of testing is over
estimated. Most user tests actually do post-hoc research. And the other way
around, I found that tests following projects that did decent research did not
reveal any significant new insights.

Summing it up: Lets do extensive user research - both because in Free Software
we simply will never be in the situation to do extensive testing and because
it is the more sustainable anyhow.

As a sidenote: icons are something that can actually be user tested easily via
the web, here research rather does not help that much in contrast. These
different ways that are appropriate to reach our goals are part of the
experience I would like to share with this group. This also is one of the
reasons I do not think we need a standard workflow the way it is defined at
the moment, but standard artefacts (see above), that need to be used in smart
ways to reach the different goals we have.

Cheers,
Björn


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

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi Bjorn,

2012/5/9 Björn Balazs <[hidden email]>

> Hi all,
>
> just a short additional note - a more detailed answer will follow in the
> next
> days:
>
> Please do not mix up user testing user research.
>

:D funny, I was convinced this whole time that you were talking about user
testing
oh well...

What tools do you suggest to use?
Should every project we work on be preceded by a survey on the topic?

TESTING is about presenting users with possible solutions, and watching how
I'd still like to do user testing if we could. I'm not sure if we'd need
special test rooms with local participants. Actually, I think just seeing
how people use the software would help, and that could be done simply by
people videotaping their friends/relatives according to some directions we
give them and putting the videos up on YouTube. It wouldn't be the most
professional thing to do, but it would undoubtedly help us understand our
users more, more than surveys or usage tracking extensions. It might be
especially interesting to watch how users coming from Office or iWork work
with our UI. (I guess that still falls under the umbrella of user research,
though.)




> This also is one of the
> reasons I do not think we need a standard workflow the way it is defined at
> the moment, but standard artefacts (see above), that need to be used in
> smart
> ways to reach the different goals we have.


I agree that we need some standard artefacts, but I disagree we should let
go of our workflow. While it isn't perfect by any measure, it seems to be a
step in the right direction. I've been subscribed to this list for about
two years now, maybe longer, and I've been sorely missing a standard way of
working. It seemed that developers weren't really interested in the design
team, whiteboards were a mess of unfinished ideas that could never be
carried out to completion, any sort of UI work was fruitless, and we
weren't really collaborating -- everyone (including me) was doing his/her
own thing.
I'm afraid that if we didn't have any sort of defined workflow, we'd revert
back to the chaos that came before, even with the various artefacts
defined. If you have a suggestion for a better workflow, please do voice
your opinion.

--
Unsubscribe instructions: E-mail to [hidden email]
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

On 05/09/2012 07:14 AM, Mirek M. wrote: It probably depends on the project. Some should be discussed on the list
before asking user opinions. This partly to avoid survey fatigue and
partly to allow us to think through the ideas before asking for user
opinions.

Other ideas may be generated by asking the users what they think should
be done. IMHO, the basic problem with user testing is that most users do not use
any software package at optimum efficiency. They have a method that
works well for their needs that is not the fastest or "easiest" method
available.

--
Jay Lozier
[hidden email]


--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi all,

trying to find some answers to the raised questions:

# Structure (of artifacts)

In my experience we will need to set-up at least the following artifacts (in
whichever way we are going to produce them in the end):

1. Vision:

Here are two examples of visions:

"I believe that this nation should commit itself to achieving the goal, before
this decade is out, of landing a man on the moon and returning him safely to
the Earth." (John F. Kennedy, May 25, 1961)

"The iPod will be a portable digital music player that will hold 5000 songs.
It will have a battery life measured in days, not hours. You will navigate the
thousands of songs with a single finger. You will sync all your music from
your computer to the iPod in minutes automatically, so you can have all your
music in your pocket." (said to be formulated by Steve Jobs end of the 1990ies
- might be an urban myth though...)

To sum it up
- The vision gives a clear goal (benefit) that helps to unify all people
involved into making it become real
- It is commonly understandable and does not provide technical solutions
- leaves enough room for creativity
- helps to provide criteria so that different people in similar situations
will likely come to the similar decission
- is short and hence present to everyone involved into the process

-> We would have to involve all LibreOffice people to find this vision. This
cannot be tested or validated with users. It provides the frame we want to
achieve.


2. Personas:

Personas help us to understand and focus on certains users. Personas can be
validated and quality assured by the users. Hope creating and working with
personas is known to people on this list.


3. Situationas

Situationas are the situation / setting equivalent to Personas. They help us
to understand in which situations / environments our product is beeing used.
These can again be validated and quality assured by the users.


4. Goals / Core Usability Goals

When we place a Personas into a Situationa, we can understand the goals a
person has in this situation. Yes, this gives a matirx that can be large. But
again, we can validate and quality assure these with the users. From these
goal we can derive the actual usability goals (e.g. learnability, Error prone,
don't feel stupid,...) that can help us to design and later on meassure the
success of our designs in usability tests.


5. Features / Szenarios

On this basis we can derive the actually needed features by creating szenarios
of the usage. Again this can be tested with the users by using imagination
techniques. These can also lead to wireframes or other mock-ups of the
intended solution, so this is actually the bridge to design...


# Do we need to do user research for every project?

No. If we have these foundations we can build upon, we only need to do user
research if we encounter any gaps. Usually the above mentioned artifacts
should be created rather independently to current project. But staying real -
it makes most sense to only create the artifacts that are currently needed.
This way all the artifacts are created over time.

So instead of a workflow for every project, I propose to rather create sets of
artifacts that every project would have to refer to, to reason the created
solutions - but every project needs a maximum of freedom how to solve the
problem. People are very different how they work. The task might be very
different and needs different approaches...


# Tool?

With OpenUsabilily, KDE and other free software products, we are working on a
tool, that helps us to actually do these things. This tool (User Weave) will
be published under an aGPL soonish. My company wil then sponsor the hosting of
this tool, so we can easily use it for our purposes, without having to deal
with technical issues... So I would be happy if we would use and improve this
tool for our needs. What do you think?


# Start?

We need to start at the beginning. Let's start to work on a common vision for
LibreOffice. We will need a small team that conducts a couple of surveys in
order to get feedback from the community - it would be perfect if we would
finish this process in time for the LibreOffice Conference - just to give you
an idea about the length of such a process...

Paralle we could use user-surverys (such as the proposed work on the iconset)
to gather information about our users in order to create first sets of
personas.


Ok, so much for today. I am curious for your thoughts on this....

Cheers,
Björn

Am Mittwoch, 9. Mai 2012, 11:58:42 schrieb Jay Lozier: --
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

--
Unsubscribe instructions: E-mail to [hidden email]
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

Hi Björn,

2012/5/14 Björn Balazs <[hidden email]>

Of course. How would you propose we do this? On the IRC? Across mailing
lists? How would we agree on a common vision? I believe we should agree on
something unanimously...

My vision would probably be to make LibreOffice popular not as an
alternative to MS Office, but on its own right, as a set of simple and
straightforward tools that each do their one job as well as possible (i.e.
Writer helps you produce great-looking documents, Impress helps you
supplement a great speech, Calc helps you interpret your data, etc.).

> # Do we need to do user research for every project?
>
> No. If we have these foundations we can build upon, we only need to do user
> research if we encounter any gaps. Usually the above mentioned artifacts
> should be created rather independently to current project. But staying
> real -
> it makes most sense to only create the artifacts that are currently needed.
> This way all the artifacts are created over time.
>

> So instead of a workflow for every project, I propose to rather create
> sets of
> artifacts that every project would have to refer to, to reason the created
> solutions - but every project needs a maximum of freedom how to solve the
> problem. People are very different how they work. The task might be very
> different and needs different approaches...
>

I'd be open to having a centralized page for personas and situationas.
However, I still believe having a workflow for each topic is key to getting
work done.

Possibly. I'd need to know more about the tool to determine whether it
would be useful.

Could you propose the questions these surveys would ask?

>
> Paralle we could use user-surverys (such as the proposed work on the
> iconset)
> to gather information about our users in order to create first sets of
> personas.
>

Again, how would these surveys look? What would you ask?

>
> Ok, so much for today. I am curious for your thoughts on this....
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
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