Hi all!
Let's add some more issues ... and thoughts :-)
Am Dienstag, den 07.06.2011, 15:02 +0100 schrieb Michael Meeks:
> Hi Cor,
>
> On Mon, 2011-06-06 at 20:41 +0200, Cor Nouws wrote:
> > >> So, I wonder if the UX guys don't mind us never updating a progress bar
> > >> more than twice per second (say) [1] we could do this for all progress
> > >> bars in one place.
> >
> > Would really like to have an impression how that looks like. In a world
> > where people and software go more and more about eye-candidness ..
True. Of course, there is some magic on some platforms to let the
progress indicators appear "continuously updated", but the most sane
solution is to really provide smooth data to them. As Cor pointed out,
this is for the "experience" part in UX ... everything else behaves
80's :-)
Moreover, in some rare cases the real performance (efficiency) of the
system is less important than the "perceived progress" - a task may take
longer, but showing a good progress indicator makes it feel quicker.
(There is some research data out there, but I skip it for the moment.)
> Oh; hmm, well - it will mean that if you are doing a fairly fast
> operation, you are likely to see only two frames per second of the
> scroll-bar, so perhaps you see only 15%, and 75% and then it disappears.
And here might start the difference from what is usually proposed from
an UX point-of-view. Usually it is requested to show a progress
indicator (here: progress bar) if the system requires more than one
second to complete the request (Gnome HIG states this a bit different,
[1]).
Thus, if we know (and its possible), we should simply avoid the progress
indicator for such fast operations.
> Perhaps more interestingly, if it is a sub 500ms operation, perhaps you
> never see the scroll-bar at all (and no associated UI flash-bang around
> accommodating it) - though perhaps we do that now.
True, but you also stated "perhaps you never see" ... so there is still
the chance that the UI "flash-bangs". So my question ...
Is that possible (technically):
* If an operation will take less than (tbd) ms to be completed,
then no progress bar indication will be shown.
* If an operation will take equal or more than (tbd) ms to be
completed, then a progress bar will be shown. In this case, the
progress bar will be drawn "smoothly" (pixel wise).
* Note: (tbd) refers to the same value, e.g. 500. The given times
should consider the system performance LibO actually runs on.
@Michael: and of course we need lots of configuration options ;-)))
By the way, the more I think about it ... in MS Office 2007, the
progress bar behavior is a bit strange. To me (again, unable to check
now) it seems that a progress bar is only shown in the status bar if
some time (500ms?) already passed for a certain operation - it seems
they start any kind of operation and then check if there is a need to
show a progress bar. If yes, they do so and start from 0% ... (Later on,
they use progress dialogs, but this is another story.)
> From a user-experience view, things that previously were slow - spend
> their time rendering pixel-by-pixel increments in the scroll-bar at high
> frequency now get substantially faster. Of course if something is
> -really- slow, then we'll still get that pixel-by-pixel look - just
> updated only at 2 fps.
By the way, another question. One of the things that might (visually)
drive people nuts is the fact, that we (almost) use the whole width of
the status bar to show the progress bar ... on large screens, this leads
to 50cm progressbar flashing. Would it be possible to adapt the progress
bar to be (let's say) 200px (if space permits), or smaller (if the LibO
window size isn't adequate). Visually, this would be an improvement ...
[...]
For those who want to dig a bit deeper into the "beauty and utility of
progress indicators", here is the "Status quo" (still valid) of (the
different) progress indicators (2007):
http://specs.openoffice.org/ui_in_general/progress/ProgressIndicators.odp
Cheers,
Christoph
[1]
http://developer.gnome.org/hig-book/2.91/feedback-response-times.html.en
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
