Hi Michael, Sébastien, all!
First, thanks Sébastien for your effort - this statement is most
important to me at the moment :-)
The "second most important statement" is, that I share some of Michael's
concerns. So please let me shed some light on the issue. And for the
developers, this might also be helpful ... and grab a coffee (or
something equally nice).
Am Dienstag, den 08.03.2011, 12:05 +0000 schrieb Michael Meeks:
Hi Sebastien,
On Tue, 2011-03-08 at 09:09 +0100, Sébastien Le Ray wrote:
this simple shadow patch has generated a long discussion on
Libreoffice-design. Some people don't like the color, some people don't
like the amount of blur, some people want no shadow at all, some people
want a "4 borders" shadow. So here is a second patchset that tries to
address the first three critics :
So - firstly, this -sounds- like an interaction disaster :-) I hope it
is not of course, but it looks like this:
We finally get a competant, enthusiastic, motivated developer -
actually fixing our horrible user interface problems: and he does some
great improvement - and our design guys apparently emit a long stream of
complaining left and right ! That, if true, is hard to excuse.
May I rephrase this a bit? We, as well, have new enthusiastic and
motivated people on the design list. And some of those guys still need
to gain some experience - otherwise they do the best they can: they
offer their / other's personal opinion on issues that pop up: "I like
red." "Joe never wanted it so." "This looks bad." "I always use this."
But personal opinions are, well, personal opinions. Usually this
personal statements don't match with usability requirements or the
overall visual language we require to serve that many users.
Since the outcome of the Design Team is usually information ("this will
work") wrapped in words (and not code), it is very hard to distinguish
who might be right. If person A says "Left" and person B says "Right",
whom to believe? This talk happens ... it happened in the OOo UX team,
it happens in all FLOSS design and usability lists. And the entry
barrier to such discussions is quite low ;-) So this is something we
(Design Team itself) has to deal with.
Thus, the more experienced team members try to explain why this or that
won't work by giving some rationale - this might appear as a noisy
discussion and takes time. In this case, we aim for guidance for less
experienced people, not for the quickest decisions (at the moment).
But also the long-term members discuss proposals (as we did for the
icons being now pretty mature). This is like patching code - it requires
some iterations to get a reasonable state. And similar to code
peer-reviews, we usually "decide" when to release something to (for
example) you.
For the current issue, there has been quite some discussion. So Nik
offered to do a mockup to support the "patching/improving" before doing
the real implementation ... this was the idea. Sébastien was (simply) a
bit faster with a first implementation.
[...]
I think we need to remember that the perfect is the
sworn enemy of the good - so lets get good across the code, before we
get perfect.
In general, I would say, please ping us in advance - if somehow
possible. As you might get comfortable with the code, it also helps us
to have some time to get settled with the issue. There is no magic stuff
like "Instant Usability" or "Ready-to-serve Design".
And if you want to work on the code before getting in touch with us,
please add a bit patience to the request ;-)
Personally, I'd like to both look at Sébastiens work, and on Nik's work
once being reade.
[...]
Personally, I would have preferred
you to move on to some other fun / high-impact win, rather than getting
bogged down in random details here ;-)
+1
So here a short takeaway:
* Please ping us in any case if you need something
* Have also in mind that some of our members are new and also need
some time to get settled --> expect personal likings, relax and
wait for a mature outcome
* If you require a decision more quickly, or if you're unsure
about the current state, then please feel free to bother us ...
* Over the time we'll get to know each other ... and you'll know
whom to trust ;-)
Oh, and this may be an excellent chance to ask you something - we are
currently in a phase of defining what we (and others, like you) need to
work with us efficiently. Thus, would it help to have a page "How to
request stuff from the Design Team?" in the wiki? There, we could
describe how things should work, what to expect, ...
Okay, I hope this helped a bit to clarify some things ... it's just two
mailing lists, but from the "deliverables" point-of-view, it is vastly
different.
Cheers,
Christoph
PS: Still, if you want to have a look how we look like ...
http://wiki.documentfoundation.org/Design/Team
--
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
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.