https://bugs.documentfoundation.org/show_bug.cgi?id=159375
Bug ID: 159375
Summary: Opening Tools > Options dialog takes too long
Product: LibreOffice
Version: 24.2.0.1 rc
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: UI
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: hoss...@libreoffice.org
Description:
Opening Tools > Options takes too much time, and in recent versions, it has
grown beyond the users' expectations.
There is a general rule in some human interface guidelines that the response
time of the UI should be less than 0.1 second, and then the user will think the
action is almost instant. The response time between 0.1s and 1s is acceptable.
But having response time more than 10 seconds risks the users abandoning the
software, and this is not acceptable.
Response Times: The 3 Important Limits
https://www.nngroup.com/articles/response-times-3-important-limits/
With the latest changes in LibreOffice, 1 second response time limit is passed,
and at least debug build also fails with the 10 seconds threshold. This is
important, as LibreOffice users usually have to set many things in the Options
dialog, and having that bad latency is destructive.
I think the reason for such high latency can be the (actually nice and useful)
feature that introduced search filed in the Options dialog:
https://bugs.documentfoundation.org/show_bug.cgi?id=49895
Here I compare the time when clicking on Tools > Options and the appearance of
the dialog after a cold start (run LO, click on Tools > Options immediately):
OpenOffice.org 3.2.1
OOO320m18 (Build: 9502)
Almost instant
Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Seems to be less than 1 second
Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Seems to be around 2 seconds.
These rough measurements are office TDF release builds installed on my
computer, which is a relatively fast one.
Looking into the some HIG recommendations like the above link, I think
everything beyond 1 second is problematic. Therefore, it is needed to measure
the response time, and make sure the response time is acceptable. Having a
mouse pointer with busy icon is good, but it is not enough.
--
You are receiving this mail because:
You are the assignee for the bug.
