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