[Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions

[Michael Meeks]

Hi Christophe,

On Wed, 2011-06-08 at 00:18 +0200, Christoph Noack wrote:
> Let's add some more issues ... and thoughts :-)

	Nice input indeed :-) thanks.

> 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 :-)

	Heh - sure; so - if we have a -very- long running task, the progress
bar will update in small, smooth increments - still at 2 fps - but
you'll see it inching along like a snail. So that is no problem.

	If it takes four seconds we get perhaps the worst case: for the first
1/2 second we'll not see anything - then we get 12%, then 25% then 37.5%
then 50% and so on over the remaining 3.5 seconds. Personally I think
that is 'smooth enough' amusingly the reason it has to be a little
chunky like that is that the 'Experience' already got to work on
progress bars themselves: adding expensive to render gradients etc. to
the theme ;-)

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

	Agreed; in this case though being three-times slower and taking 12
seconds not four is rather sad for breaking the work-flow :-)

> Thus, if we know (and its possible), we should simply avoid the progress
> indicator for such fast operations.

	Sure - so this should be quite easy; after our first half-second, we
can judge the percentage completeness, if it is >50% we can not show it
[ though we would need to un-conditionally if it is not complete another
second later I guess ].

> @Michael: and of course we need lots of configuration options ;-)))

	:-)

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

	Interesting.

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

	Wow - so; it would be great to shrink that progress bar - that would
simultaneously make it much faster to render; mine is perhaps 1600
pixels wide so with a gradient so: perhaps this is the key fix.

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

	Yes ! :-) it is a win-win I think.

> For those who want to dig a bit deeper into the "beauty and utility of
> progress indicators",

	Thanks for the helpful input; good stuff. Markus - do you have enough
to go on ? and/or are you excited :-)

	ATB,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot