Bug 401329 - Order of Next and Previous buttons while searching in Okular should be reversed
Summary: Order of Next and Previous buttons while searching in Okular should be reversed
Status: RESOLVED INTENTIONAL
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.5.3
Platform: Neon Linux
: NOR wishlist
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-23 13:06 UTC by Thiago Sueto
Modified: 2020-09-07 10:53 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Sueto 2018-11-23 13:06:46 UTC
SUMMARY
As of version 1.5.3, when using Find..., the following buttons appear: Close,  the Find: text field, Next, Previous, Options. Find..., Next and Previous also appear on the Edit menubar.
From an usability POV, Next being immediately after Find makes sense since it is the most used and it is generally used first, having a shorter path to navigate through mouse and keyboard. However, this does not follow a left->right and top->down reading convention.
Maybe the Previous button should come before Next, as occurs in other PDF readers such as Evince and Adobe Acrobat Reader.

Linux/KDE Plasma: KDE Neon User Edition 5.14
KDE Plasma Version: 5.14.3
KDE Frameworks Version: 5.52
Qt Version: 5.11.2
Comment 1 Laura David Hurka 2018-11-24 14:19:27 UTC
This layout is the same as in most other KDE applications, and I think it's fine.

I personally can't imagine whether another order is easier to understand. A simple test might be invoking okular with "okular -reverse". (This changes the order of everything.)
Comment 2 Nate Graham 2018-11-26 22:16:18 UTC
Not all KDE apps use this layout; Konsole for example has Previous before Next. Most 3rd-party software uses previous/next too. Putting previous before next on the toolbar does make a certain amount of sense. But then the toolbars would be inconsistent with the ordering in the menu, which generally goes:

Find...
Find Next
Find Previous

...Which I think does make sense.

Hmm.
Comment 3 Albert Astals Cid 2018-11-26 22:28:52 UTC
The problem with this, is there's *literally* one person that has complained about the button ordering in 13 years. Assuming we have more than one user, i'd have to guess that "in general" people seem to like the current layout and that changing it wouldn't be a wise idea.
Comment 4 Nate Graham 2018-11-26 22:35:55 UTC
The number of people who have complained is not always a valid metric. The real question is whether or not the proposal is genuinely better; sometimes all it takes is one person to alert you to that.

Consistency with the world of 3rd-party apps as well as the intuitive-ness of a left-to-right arrangement are compelling arguments for me, but I don't like how that would leave the toolbar inconsistent with the ordering in the menu. If that's not a concern, I would support changing the toolbar order.

That said, obviously this is all pretty low-priority stuff. :)
Comment 5 Laura David Hurka 2018-11-27 01:09:11 UTC
(In reply to Nate Graham from comment #2)
> Not all KDE apps use this layout; Konsole for example has Previous before
> Next.

Not really, the buttons change when you deselect "Search Backwards". Konversation does it similarly. ("bottom->up reading convention")

To understand what's more intuitive, we should ask someone who doesn't now really anything about find bars and not much about computers, for other people there won't be a difference. Maybe the answer will be: "I always read PDFs top->down, so the first offered option should be 'Search Top-Down', no matter which other options exist.".
Comment 6 Nate Graham 2018-11-28 20:50:54 UTC
(In reply to David Hurka from comment #5)
> Maybe the answer will be: "I always read
> PDFs top->down, so the first offered option should be 'Search Top-Down', no
> matter which other options exist.".
That makes a lot of sense, actually.
Comment 7 Thiago Sueto 2020-09-07 10:50:30 UTC
Hello, after watching the Akademy Consistency talk and seeing this bug report in retrospect I think it is fine the way it is.
Comment 8 Nate Graham 2020-09-07 10:53:10 UTC
:)