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


Hi Caolán, all!

Am Mittwoch, den 09.03.2011, 08:51 +0000 schrieb Caolán McNamara:
On Tue, 2011-03-08 at 15:51 -0500, Jon McCann wrote:
On Tue, 2011-03-08 at 00:02 +0100, Christoph Noack wrote:
We're deprecating with the intent of eliminating the use of
GtkStatusIcons (the notification area).  So there are things like:
https://bugs.freedesktop.org/show_bug.cgi?id=31206

The quickstarter thing that lives there isn't enabled by default
out-of-the-box anymore on a fresh install, though of we still honour the
setting if it was previously enabled. I'm not sure if we want a sort of
"if we're running under GNOME3 then forget about it" kind of thing.

If we aim for platform conformance and it would be still manageable
code-wise, the Gnome 3 specific handling would be fine. Based on a
discussion with the (Oracle) UX team some time ago, they even added some
features (the drop-down to starts the applications) because of the high
demand, although this disregards user-interface guideline rules. So,
assumption, there is at least some request for that on other platforms.

The best way would be to check how many people activate the option
afterwards (if not inherited from previous installations) and decide
whether it could be removed completely. But, without proper usage
statistics its hard to say whether to remove it completely (lacking real
user data). Otherwise, some more guessing ;-)

We're also have new guidelines for notifications (libnotify type).  Do
you use those at all?

No I don't think so, though I had wondered previously if we should run
our help warnings (like the first time autocorrection changes something
for you it tells you about it and how to disable it if you want) through
the notification area. So guidelines on if that's a really stupid idea
would be helpful :-)

You mean re-routing the "HelpAgent" messages? From what I can see,
libnotify is rather used for messages by applications currently not
having the focus (or being a daemon, service), or to communicate overall
system messages. With regard to these cases, the one notifications that
might benefit would be the "update available" message - on Windows ;-)
This might change for deeper integration with CMS.

Caolán, the autocorrection stuff is a special case (and currently also
discussed on Design). It is highly related the place of the change,
therefore an "in-place" message would be desirable here (and for some
more cases) to solve some more issues (how to revert once / for this
document / ever). I've started a page covering some of these some years
ago, by refining some behavior within MS Office (a bit outdated ow):
http://wiki.services.openoffice.org/wiki/User_Experience/DirectManipulationSnippets

http://people.gnome.org/~jclinton/libreoffice-modal-dialogs.png

Other things to note in that screenshot are:
 * the button order is incorrect for use in GNOME.  The Print button
should be at the right side.

Mind you, for the print dialog at least, a lot of these problems would
go away if/when we use the native gtk print dialog there. *cough*,
dtardon was poking at that a while ago, but I think that slipped off the
radar.

Jon, thanks for the hints. Although it doesn't make it better, some
explanation - the effort of UI changes within LibreOffice ist still very
high. So the guys at Sun/Oracle decided to use a style that works
"somehow" on all the platforms - do once, use several times. Maybe, with
a slight preference for Windows (the majority of users worked with OOo
on Windows). Any further word on that will result in Marketing
requirements :-)

For example, this UI decision causes the additional lines (usually a
replacement for group boxes, or their Gnome "spacing and indention"
equivalents). Currently, LibreOffice is a less than ideal cocktail of
different ingredients (e.g. platform specific keybindings, platform
unspecific dialog design).

So, with regard to the dialogs, we'll need a layout manager that is
capable to take care of buttons and other layout issues. And as far as I
know, the guys within this thread starting working on that quite some
time ago (and maybe will ...).

Any further comments (mac like sheets, menu and button mnemonics, ...)
may be answered by the developers. I'm unsure how this relates to our
implementation. In general, this would be helpful for all our supported
platforms.

Jon, I think your input is very helpful since it still emphasizes the
need for a proper long-term perspective for LibreOffice (target user
bases, preferred platform, ...). And I'll think about how to further
improve the situation within Gnome ...

Thanks and enjoy your day ... now I have to hurry up, or I miss my day
job duties ;-)

Cheers,
Christoph


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