[Libreoffice] [UX] Progress bars - convey this make take some time, dunno how long

2010-11-17 Thread Thorsten Behrens 
Hi,

chatting with some folks yesterday at the OOo congress for business
and administration, and two users approached me with a problem most
prevalent when saving to network volumes:

LibO save progress bars are basically driven by the xml export code
(when saving to odf, of course), but there's some non-trivial
postprocessing happening inside
sfx2/source/doc/objstor.cxx:SaveTo_Impl(), some of which is bound to
IO. The observed behaviour thusly, when saving to a slowish network
volume, is that the save progress bar is stuck at 100% (because all
xml content is written), but the apps are still unresponsive
(sometimes for a minute or so).

Changing SaveTo_Impl() to use async IO is prolly out of scope for
3.3, so another workaround would be to keep the progress bar from
reaching 100% before all work is finished - see attached patches 
for a sketchy attempt. Problem here: the progress bar will not move
either way, it's just not stuck at 100%, but at 90% now.

Any UX insight on how to best get this across? 

Cheers,

-- Thorsten
diff --git a/sc/source/filter/xml/xmlexprt.cxx b/sc/source/filter/xml/xmlexprt.cxx
index e160861..102068a 100644
--- a/sc/source/filter/xml/xmlexprt.cxx
+++ b/sc/source/filter/xml/xmlexprt.cxx
@@ -730,7 +730,8 @@ void ScXMLExport::CollectSharedData(sal_Int32 nTableCount, sal_Int32 nShapesCo
 }
 }
 sal_Int32 nRef(nCellCount + (2 * nTableCount) + (2 * nShapesCount));
-GetProgressBarHelper()-SetReference(nRef);
+// leave ~10% for zip swappage
+GetProgressBarHelper()-SetReference(nRef*10/9);
 GetProgressBarHelper()-SetValue(0);
 }
 
diff --git a/xmloff/source/draw/sdxmlexp.cxx b/xmloff/source/draw/sdxmlexp.cxx
index 82d6078..5868fab 100644
--- a/xmloff/source/draw/sdxmlexp.cxx
+++ b/xmloff/source/draw/sdxmlexp.cxx
@@ -620,8 +620,9 @@ void SAL_CALL SdXMLExport::setSourceDocument( const Reference lang::XComponent
 }
 }
 
-// #82003# init progress bar
-GetProgressBarHelper()-SetReference(mnObjectCount);
+// #82003# init progress bar - leave ~10% of progress for
+// final zip swappage
+GetProgressBarHelper()-SetReference(std::max(mnObjectCount*10/9,sal_uInt32(1)));
 }
 
 // add namespaces
diff --git a/sw/source/filter/xml/xmlexp.cxx b/sw/source/filter/xml/xmlexp.cxx
index ba0bde7..117fd28 100644
--- a/sw/source/filter/xml/xmlexp.cxx
+++ b/sw/source/filter/xml/xmlexp.cxx
@@ -325,7 +325,8 @@ sal_uInt32 SwXMLExport::exportDoc( enum XMLTokenEnum eClass )
 nRef *= 2; // for the above styles, xmloff will increment by 2!
 // #i93174#: count all paragraphs for the progress bar
 nRef += aDocStat.nAllPara; // 1: only content, no autostyle
-pProgress-SetReference( nRef );
+// leave ~10% for zip swappage
+pProgress-SetReference( nRef*10/9 );
 pProgress-SetValue( 0 );
 }
 }


pgpl0367UBNj8.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [UX] Progress bars - convey this make take some time, dunno how long

2010-11-17 Thread Christoph Noack 
Hi Thorsten!

Progress bar issue summary: Cannot be solved easily :-) But should it be
solved?

Am Mittwoch, den 17.11.2010, 15:47 +0100 schrieb Thorsten Behrens:
 Hi,
 
 chatting with some folks yesterday at the OOo congress for business
 and administration, and two users approached me with a problem most
 prevalent when saving to network volumes:

Okay.

 LibO save progress bars [...] stuck at 100% (because all
 xml content is written), but the apps are still unresponsive
 (sometimes for a minute or so).

Not that good ...

 Changing SaveTo_Impl() to use async IO is prolly out of scope for
 3.3, so another workaround would be to keep the progress bar from
 reaching 100% before all work is finished - see attached patches 
 for a sketchy attempt. Problem here: the progress bar will not move
 either way, it's just not stuck at 100%, but at 90% now.

QUESTIONS

Okay, so we just move the problem. To better understand the issue...

  * The patch just changes the progress bar behavior, but the time
to be waited is the same?

  * The progress bar is the only information - as far as I know,
there is no percentage completed (on any platform), or?


ISSUES

Two main problems: Users don't know ...
 1. ... how long it will take (the idea of progress bars is to
provide something which enables people to anticipate the
duration of the task and to get some rough information on the
percentage completed)
 2. ... if LibO is still running and will (finally) complete the
task (no real lockup).

Item 1 cannot be solved - the progress bars (better: the task) will get
stuck, no way to change that (easily).

Item 2 is only partly addressed - only few platforms bring spinning
progress bars that visualize some activity (Apple, Windows
Vista, ...) if progress bars get stuck for a short time. Although this
is just psychological magic, it works :-)


IMPACT

So there is no solution that can be addressed with a progress bar ...
but is this a real problem at the moment? How often might that occur to
people who don't know that LibO will finally finish their request? So
how much negative impact does this issue have - in comparison to the
short-term solution?

From my point-of-view, working on a real improvement would be better.
But if there is none within the next few months, and quite some users
experience this, then ...


ALTERNATIVE

If (and only for that reason) the save/load process gets stuck for
(e.g.) min. 5 seconds, and there is no way of availability-checking of
the network connection in advance, then we might simply bring up a
message box that says something like File XYZ is being saved which
requires some time. Please wait ... (not final, of course).

++
| LibreOffice Writer |
++
||
||
||
|   ++   |
|   | Saving |   |
|   ++   |
|   ||   |
|   |  File Bad-UX-Hack.odt is |   |
|   |  being saved which requires|   |
|   |  some time. Please wait ...|   |
|   ||   |
|   |   [ Cancel ]   |   |
|   ++   |
||
||
||
++
| Saving ### |
++


A bad and (from UX point-of-view) hacky solution, but it should work
with the given tools we do have (without hacking the status bar, ...).
But, another dialog to be translated. Cancel is optional - but having
such functionality is good manner. 

That might be an interim (!) solution.

 Any UX insight on how to best get this across? 

Might that work?

Cheers,
Christoph

PS: By the way, well tagged message :-)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice