[Libreoffice-ux-advise] InfoBars: problem when stacking too many of those

[Cedric Bosdonnat]

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 at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise