Re: [libreoffice-design] Welcome graphics for the Startcenter in 4.2

Hi Michel,
Sorry for taking so long to respond -- I had a really busy week.

2013/12/6 Michel Renon <michel.renon@free.fr>

> Hi Mirek,
>
>
> Le 27/10/2013 02:04, Mirek M. a écrit :
>
>  Hi Michel,
> > This is a meritocracy -- if you're not happy with something, you're
> > welcome to swoop in and change it. :) (Of course, the community also has
> > to accept those changes.)
>
> As Cor Nouws already said, it's always more difficult to do something and
> then modify it again and again than taking time to design it correctly the
> first time.
> I don't even talk about users getting upset by regular changes.


Agreed on going for the best design before development.

> > If you'd like to do user studies, please be my guest. Right now, designs
> > are based on heuristics [1],
>
> Too much abstract.

They might seem abstract at a cursory glance, but they're really quite
well-defined. They seem to have been devised by Alex Faaborg and have been
used to tag FireFox UX bugs.
BTW, if you have some time, I recommend his I/O presentations [1][2].

>  guidelines [2],
> >
>
> It would be ok, but here is only one (unimplemented ?) widget...

We refer to the latest Gnome guidelines when we don't have guidelines of
our own.
We should expand the guidelines when we hit on topics that the Gnome HIG
does not cover or when we have important reasons to diverge from their
guidelines and create our own.

>  and discussions,
> >
>
> That's the problem in the design team : too much unstructured discussions !
> You should spend your time on making prototypes and user testing in a
> scientific way.

Please guide the way. :)

>  but of
> > course it'd be great if they were validated by other means as well.
Till today, the validation is done only with "I like", "I don't like", "I'd
> prefer" from the design lead/team.


I feel this relates to your earlier message, so I'll post a snippet:

" Then I made a proposal about entrance animations for Impress. You can see
that I followed the process I was talking in my blog
https://wiki.documentfoundation.org/ImpressAnimationEntrance but that
proposal was refused by the design lead without any valid/scientific
arguments :http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-May/002012.html";

So, first and foremost, where does it say that I'm the design lead? I don't
recall being elected or appointed as one, nor do I recall calling myself
that.
Secondly, "I would rather opt for redesigning the current custom animation
panel than adding a new panel, especially as the task pane is overpopulated
as is." is not a rejection, it's simply me stating my opinion. Please don't
get discouraged so quickly. :)


> Creating a validation process means having a global vision, and precise
> goals with metrics (goals that can be measured ; ex: nb of clicks to
> perform a specific action, or mouse move distance).


The measurable goals you listed can have adverse affects on the UX -- they
put too much focus onto one specific UX problem without considering the
multitude of others. If we take number of clicks as an example, with the
least clicks being the most desirable, and have that as our goal, we could
easily end up with an unusable setup that could suffer from:
* Not enough space given to the document because the we put as many buttons
up front as we could
* Incomprehensible buttons because we shrank the icon size to fit as many
as we could
* Hard-to-target buttons because they've been made too small
* Being too hard to process because of the sheer volume of commands
presented at once
etc.

The principles we have take the broader situation into consideration.
For example, rather than number of clicks, the more broadly-defined
ux-efficiency principle allows for solutions like keyboard shortcuts,
contextual buttons, touch gestures, voice commands, etc., and the other
principles ensure that other important UX aspects aren't abandoned just to
support this principle.

As for the global vision, I wonder what exactly you'd imagine -- please
elaborate.

My take on the issue is that it'd be good to define what the purpose of
each module is and then base our design decisions on that purpose as well
as our principles and guidelines.
For example, if we say Writer is a tool for producing professional-looking
documents intended to be viewed page-by-page, then we should seriously
consider losing Web view (which goes against the page-by-page part) and
FontWork (which, ask any typographer, goes against the
"profesional-looking" part) -- or rather, spinning them off as extensions.
Extensions, in general, are an excellent way to provide features that are
not in the scope of the project, and they've been working excellently for
browsers.
(BTW, losing the FontWork feature wouldn't mean losing rendering of
FontWork/WordArt, but rather just leaving FontWork creation and editing up
to an extension. Whatever filetypes LibreOffice chooses to support should
be rendered as precisely as possible.)
If we say Writer is a tool for editing a range of file formats with full
support of all aspects of the ODF and Microsoft Office formats and with MS
Office feature parity, we'll probably end up forever catching up to what
Microsoft Office does.


>  (I don't have the time and energy to invest in user studies or user
> > testing right now, which is why they aren't being done. It'd be great if
> > you could help there.)
>
> The color picker experience was very interesting :
> - in mailing list or in chat, design team spent endless hours trying to
> imagine/guess what would be better, based on only one screenshot
> - in few hours, I made some html prototypes that allowed to reveal
> immediately some important question (live preview or not ?)
>
> And Jacob Nielsen showed that with just 5 users, you find nearly 80% of UX
> problems.
> (http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)
>
> So I repeat : less discussions, more prototypes & user testing.

You're clearly passionate about user testing and have some experience with
it, so please go for it.
I'd love to have someone on the team who does user testing -- if you can do
it, I'm sure the team will listen to the results you have to present.

> > I understand you're not happy with the Start Center, and it would've
> > been ideal if you could have chimed in after the inital call for
> > designs,
>
> When was it done ?
> I searched both mailing lists (design and ux-advise) and found nothing
> about preparation of Gsoc. It seems that all subjects related to design
> were proposed without any preparation in the mailing lists.
>
> The whiteboard for StartCenter was created on 24/07/2013, when GSoc was
> half time.
> And the first official mail was created by Krisztian Pinter also on
> 24/07/2013.

That's what the official call for designs was.

> ==> Design team should already work on subjects and prototypes for
> Gsoc'14. And same idea for LO4.4 (it's already too late to make proposals
> for LO4.3).

:) Funny, that was the idea with the color picker.
The problem is, there are too many variables here:
1) Will it even be picked up? Should we aim for a broad redesign or rather
a slow evolution through EasyHacks?
2) What can the developer do? What does he want to work on? The scope of
the project is set by the mentor and the developer, not by the designer.
3) Will we have related new features by the time GSoC rolls around? (The
new sidebar could lead to various changes. For color picking, themes could
completely change the way colors are managed.)
4) What UI components will we have at our disposal? Could a new VCL widget
be part of the scope?
5) Should designs count on touch support?
etc.

The template manager fell apart on not having a well-defined scope. There
were several assumptions about the initial design, such as being able to
limit the hierarchy to two levels (significantly simplifying folder
management), to use single-click-to-launch by default (as is the new Gnome
standard, and is quickly becoming standard on other platforms as well), and
to have a split button widget. It seemed as though the initial design
proposal was accepted by the developers, but at the last minute it turned
out that these things couldn't be done, which meant significant changes to
the whole design. In retrospect, the biggest mistake made, IMHO, was a lack
of communication.

Just read my advise for planning :
> http://www.mr-consultant.net/blog/2013/04/thoughts-about-
> libre-office-design-process-part-7-schedule/
>
>
>
>  but now you can still chime in with suggestions for
> > improvement, user research, user testing, or propose patches.
> Even if the design team creates a professional proposal based on user
> testing, it would be dependent on dev kindness to implement it.
> It looks more politically/diplomatic than meritocracy : it's much easier
> to get your proposal implemented if you're friend with one dev.

If your proposal has merit, there's a chance a dev will take notice. :)
It works for elementary OS, it can work here.

You also have the option of paying someone to develop it. (Note that not
everything that's developed for LibO gets accepted, but most of it does.)

It's not an offense against devs or design team : it's just the only human
> way of doing when there is no official rule.
> So, as I said to Charles, it's better for me to stop making proposals for
> LibreOffice for now.

I'd love for you to do user testing, if you're into that sort of thing.
We'll find some way to get things implemented. :)
UX hackfests could be productive --  BTW, there's one coming up this
February, right after FOSDEM. [3]

> BTW, few days ago, I met some people who might be interested by
> LibreOffice UX. I hope we can work together and maybe contribute.

Excellent! We can always use more contributors.

> Regards,
>
> Michel

[1] http://www.youtube.com/watch?v=iJDoxOTyMdk
[2] http://www.youtube.com/watch?v=z2exxj4COhU
[3] https://wiki.documentfoundation.org/Hackfest/FOSDEM2014

-- 
To unsubscribe e-mail to: design+unsubscribe@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