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


Hi Astron, Mirek,

Thanks for your remarks and ideas. I have to admit that Mirek's idea
looks nice to me as it means less work ;)

I would just raise another question. Is it a good thing to have the
color of the info bar configurable in the Appearance options page? I
already have that implemented, but there is a tiny problem still to be
fixed: the info bar is not repainted when changing the color in the
options.

--
Cedric

On Fri, 2012-10-12 at 12:26 +0200, Mirek M. wrote:
Hi Astron, Cedric, everyone,

On Thu, Oct 11, 2012 at 3:33 PM, Stefan Knorr <heinzlesspam@gmail.com>
wrote:
        Hello all,
        
        the following is just an idea of mine (yes, the discussion is
        ~over, I
        know):
        In general, I agree with Mirek's stance of "don't overuse the
        info
        bars." Still, to cover some more possible cases:
        How about overlaying all infobars on top of each other, but
        push every
        subsequent infobar ~2 pixels down and make it a bit darker (or
        lighter).
        This way, you should easily be able to fit a few bars in the
        average
        window without it looking too ugly. If there are any more than
        three
        bars, you could show a counter, something like (4) or so.
        To see all bars, one could go either of two ways:
        
        * Create a hover effect where when the mouse hovers over the
        bars, they
        all automatically expand (might not be a good idea, given how
        we killed
        two hover features since two 3.6.0 already) 


I would oppose this on the basis of ux-error-prevention. Moving
targets are rarely good.
Also, since the bars would expand anyway, it wouldn't really solve the
problem of having too many infobars in one window.
        
        * Let the user scroll through the info bars with the mouse
        wheel/touch
        scrolling


I would oppose this as well: not everyone can scroll. (I've seen
various touchpads where scrolling is pretty hard, and touchpad
scrolling itself is not very discoverable.)
Also, that the user should scroll would be undiscoverable itself.
        
        Additionally, we might indeed want to use colour to
        discriminate between
        different types of notifications. "Your document is
        unreadable" and
        "Printing ..." should definitely have different importances.
        Likewise,
        we could push more grave notifications above less grave ones.


Here I can only speak for my proposal, but infobars are not
notifications per se.
They're more like problem-solvers. They're there not to just inform
you that there's a problem, they're there to help you fix it, either
by offering a remedy right away (but, as the remedy has some
side-effects, it needs to ask the user first, as per ux-control) or at
least by giving you the necessary info to fix it.


Thus "Printing..." should never be an infobar, it should be shown in
the status bar or, preferably, handled by the OS itself.


There should be no "grave" and "non-grave" infobars. Each one should
be there in case of a problem. In case of a serious problem, where the
user is unable to work with the document or when editing would lead to
data loss, a modal dialog should be used instead.


Thus "Your document is unreadable" should not be an infobar either.
        
        Lastly, for notifications the user really needs to see, we
        could think
        about an elevation scheme when there are too many bars
        already, i.e. the
        normally non-modal alert would become a normal modal window.
        (Of course,
        this somewhat bears the question if there really should ever
        be a
        modeless notification that users have to answer.)


As said above: the infobar is for problems that don't prevent the user
from editing the document without data loss, yet for which an
automated solution could cause harm to the user, his data, or would
counter what the user is trying to do.
Infobars can be safely ignored or dismissed, but acting on them should
improve the UX.


Anyway, I stand by my previous post.
_______________________________________________
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise



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.