Bug 157207 - Auto-size the "Search Results" dialog (after a find & replace across multiple sheets) to avoid scrolling
Summary: Auto-size the "Search Results" dialog (after a find & replace across multiple...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Find&Replace-Dialog
  Show dependency treegraph
 
Reported: 2023-09-12 14:43 UTC by Jeff Fortin Tam
Modified: 2024-03-11 15:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the current vs proposed sizing behavior (264.49 KB, image/png)
2023-09-12 14:54 UTC, Jeff Fortin Tam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Fortin Tam 2023-09-12 14:43:17 UTC
Description:
The "Search Results" dialog should autosize to a more useful width/height whenever possible.

Steps to Reproduce:
1. Run Calc on a high resolution screen
2. Do a "Find and Replace" search query or replacement

Actual Results:
The dialog shown in the 1st screenshot takes only a tiny portion of my screen, as if we were still in the 640x480 / 800x600 era, and creates lots of scrolling in that tiny window.

Expected Results:
Auto-size that dialog to a more reasonable size:
* Autosize its height (up to maybe 70-80% of the screen's height?) if there are more than a handful of results
* Autosize its width (up to maybe 50-80% of the screen's width?) if the results's strings are long enough


Reproducible: Always


User Profile Reset: No

Additional Info:
See https://fortintam.com/blog/dont-make-me-scroll/ for further reference / examples.
Comment 1 Jeff Fortin Tam 2023-09-12 14:54:53 UTC
Created attachment 189523 [details]
Screenshot showing the current vs proposed sizing behavior
Comment 2 Stéphane Guillou (stragu) 2023-09-27 18:34:55 UTC
Thanks Jeff.
Design/UX team, what do you think?
In my opinion, instead of showing everything, I think we could use ellipses before and after some context around the searched string. See bug 157227 comment 4.
In any case, we need to make sure the dialog doesn't get too big for small displays.
Comment 3 ady 2023-09-28 01:22:21 UTC
(In reply to Stéphane Guillou (stragu) from comment #2)
> Thanks Jeff.
> Design/UX team, what do you think?
> In my opinion, instead of showing everything, I think we could use ellipses
> before and after some context around the searched string. See bug 157227
> comment 4.
> In any case, we need to make sure the dialog doesn't get too big for small
> displays.

Emphasizing the text that is explicitly being search might be helpful in some case, but hiding other text with ellipses? Hmm.

If the result is there, then it is evident that the searched text was found. The way users can identify the specific result/row/line that is being searched, from all the other results, is by the context of each result. LO should not try to be smarter than the user.

Let the user easily identify the specific location that is being searched. Some kind of formatting to the searched-for text might be useful in _some_ cases (not necessarily in each-and-every case). Hiding context is not a good UX in the resulting window IMHO.
Comment 4 Heiko Tietze 2023-09-29 11:01:25 UTC
Let's allow resizing of this dialog - and discuss what is shown in bug 157227.
Comment 5 Heiko Tietze 2023-09-29 11:06:33 UTC
Wait a second, the search results dialog is resizable. Checked with 

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 847f899cb3f9607b55fd5989b2043a0b513dec22
CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_DE); UI: en-US
Calc: threaded

and 

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b45ab5256c9768914bcad854ce32b06caa0539b8
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

Jeff, please double check.
Comment 6 Heiko Tietze 2023-11-29 13:18:30 UTC
(In reply to Heiko Tietze from comment #5)
> Jeff, please double check.
Comment 7 Heiko Tietze 2024-02-21 15:17:06 UTC
No reply, closing for now. Please reopen if needed.
Comment 8 Jeff Fortin Tam 2024-02-21 16:50:21 UTC
Hi, sorry for the delay, as I have now tested with LibreOffice 24.2 just to be sure…

My suggestion still stands: I was not requesting for the dialog to be resizable (as it already is), I was suggesting for it to be auto-sized to the appropriate size (whenever possible / whenever space is sufficient) to avoid the user having to resize by themselves. 
I still believe that having the user manually resize that dialog is superfluous work that the machine should take care of.

In addition to the article I had linked to in the description above,
see also this additional article: https://zachholman.com/posts/shit-work/
Comment 9 V Stuart Foote 2024-02-27 12:55:42 UTC
+1 to OPs original request to use more of the display.

The query results are held in a pop-out frame, and it can be resized, but it would be better UX to make the results pop-out larger to expose more of the results.

So we could either use the current LO app frame extent for v-height, or we could use the display height reported by system. So long as all LO controls remain visible and actionable, would think using height of the current LO app frame is probably safer.

Its not "shit work" but increasing count of visible results without scrolling has merit--advantageous for folks on a 4K or 5K display.
Comment 10 Heiko Tietze 2024-03-08 09:48:16 UTC
We discussed the topic in the design meeting.

Besides the suggestions we may also consider text wrapping, however that would be is detrimental for reading. Ellipsis at start and end to bring the search term into the view is also an option but fails in case of multiple results and includes a lot of coding work. Ellipsis at the end blocks reading the text if the length exceed the maximum dialog width (small screen, huge text). We recommend a simple solution and make the dialog wider in case of long text results but only up to a reasonable width (eg. 600px).
Comment 11 Jeff Fortin Tam 2024-03-08 16:11:47 UTC
Just for the sake of clarity: what I've been talking about here is simply setting the window's default sizes, it's mostly a suggestion for the window manager, not a hard requirement; if it somehow exceeds the screen's sizes, the WM (at least reasonable ones like Mutter) just constrain it when needed.

Out of curiosity, why would you limit yourself to 600px if the screen has plenty of available space (which is something that can be measured automatically) vs the space you might need to show the data (which can also be measured programmatically)? I mean, nobody is running 640x480px screens for office work anymore, especially for spreadsheets work.

Or is that not about the screen size, but rather about not obscuring the spreadsheet's contents?
Comment 12 V Stuart Foote 2024-03-08 16:34:59 UTC
Would add, the issue is more the vertical height (and hence to avoid/reduce scrolling). Fixing a horizontal width at 600px doesn't really make sense considering normal extent of data in calc cells being rendered.

Since it is a pop-up it can be minimized/closed allowing view of the sheet canvas and controls. So results can easily be sized to size of the current LO app frame, or alternatively/toggled to the full display size reported available by os/DE.

Obviously we need to set some starting extent for the search results--it is just that currently they are set too small, even for our minimum 1024px x 768px supported display spec.
Comment 13 Heiko Tietze 2024-03-11 15:24:50 UTC
(In reply to Jeff Fortin Tam from comment #11)
> Out of curiosity, why would you limit yourself to 600px...
It's not good design if your dialog has a height of 200px but is 10 times wide. And reading such a text is also not fun. My screen is 3440x1440 but each individual window is about 4:3 or a little bit wider. And I guess most wide-screen user appreciate to have to windows next to each other rather than one ultra large.