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


Hi Sebastian, *,

Sebastian Spaeth schrieb:
On Thu, 9 Dec 2010 22:59:37 +0100, Friedrich Strohmaier 
<damokles4-listen@bits-fritz.de> wrote:

What You as an individual do use or don't *must not* be a criterium
for UI and feature changes. Even and especially not because You are
a software developer!

Hi Friedrich,

this thread already became bigger than I ever intended, and I heard
that the state of the statusbar is a regular flamefest. I don't want
to awake any flames or add more fuel.

I guess this is not limited on the status bar but on UI/feature
questions in general.. And I'm glad to see this topic beeing one of
high interest and not going down in a flame.

over users shoulders. And be assured: *Every* bloddy feature you hid
anywhere in the UI has a user(base) using it. That's more valid for
the "one click available" as in the status bar.

My following statements are not intended to express bad estimation of
your good ideas.. :o))

All I am going to add is: "which user prefers single-clicks for some
status bar items and double-clicks on others, while some are not
clickable at all?".

One who has been told / has learned to do so and doesn't bother on any
theory of userfriendly UI :o))..

"Which user wants to launch dialogs when clicking
on apparently empty areas in the statusbar?"

see above..

and finally "which user wants 2 separators between icon areas that are
really empty?"

One who has learned to (double-)click the fourth area will be confused
what to do now.

"which user wants exclamation marks for default situations rather than
suitably subtle icons that show modified doc status?" :-)

Again: see above. ("You told me to click the exclamation mark - where
should I click now?").

Some things can be universally be improved, other should remain
customizable. I do know that there is a reason and a proponent behind
all those items.

The reason and proponent is the less important thing. The more important
is to change/disturb a step by step learned workflow. Changes of this
kind need very good reasons - valid for the user - and many things
accompanying to support the change.

You laugh about the examples above? I don't. That's bitter truth out
there.

The only proper way to have a "Sebastian Spaeth" UI of LibreOffice I
see:
Convince your developer collegues to build an UI framework which
allows such changes without affecting other users. :o))

Ohh, but there is much of that possible already. I was able to make
myself much happier with a few lines of editing of the statusbar.xml
definition.

That are good news! Is it a big deal to make all that already possible
available in a framework to be fed from outside? Thinking of skins and
configuration sets?

I am not sure what the right approach to finding good UI is. I
therefore defer those designs to others. I only know when something
bothers me so much that I really want it changed :).

I'm in very favor of that - as long as I have the possibility to stick
with the old behaviour for my clients - and for myself. :o))
For this reason I'm advocating a separate UI-feature framework over and
over again.

In short words: Changing UI has wide reaching consequences and this has
to be reflected by the features of the Software. How to oversee this?
Very simple: trust people who are nearby and tell You. :o))

What I want to say: All from the software developer on the one side to
the user at the other and all between should get happy with our product!
As shown in the past, UI/feature changes released without participation
of the affected (users|supporters) don't fit that need.
LibreOffice will grow best, if we achive it. And yes: we can! (tm) :o))

Stopping now spreading enthusiastic wordloads. :o))
-- 
Friedrich
Libreoffice-Box http://libreofficebox.org/
LibreOffice and more on CD/DVD images
(german version already started)




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.