Hi Michel,
Sorry for taking so long to respond -- I had a really busy week.
2013/12/6 Michel Renon michel.re...@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
