[Okular-devel] Consistency in user interface

[Albert Astals Cid]

El Monday 29 February 2016, a les 09:13:10, Jonathan Schultz va escriure:
> > They operate differently because they do different things, after drawing
> > the rectange there's nothing else you want to do so the menu is triggered
> > immediately.
> 
> I differ with this interpretation in several ways:
> 
> 1. On what basis do we know 'there is nothing else you want to do'? Some
> useful examples of things you might want do do include adjusting the
> boundaries of the selected area, 

This feature doesn't exist

> making a compound selection (eg by
> selecting another area while holding the control key

This feature doesn't exist

> ), displaying properties of the selected area
This feature doesn't exist

> just to name a few. The fact that none
> of these have been written yet is not a good reason to preclude them.

Yes it is, why make you take an extra step to do the only thing you can do in 
spirit of adding features that may never exist?

> Moreover, my current project (more on this below) will need some of
> these functions (at the least adjustment of the selection boundaries),
> and I believe that such a change would be an improvement of Okular as well.

If there are new features that make sense adding an additional step in between 
selecting the area and showing the menu, it may make sense to add such step.

> 
> 2. It means that Okular is unlike just about every other GUI program
> ever written. I tried to find a reference to UI standards in the KDE
> Usability standards, and it is a bit unclear, but I think that the
> 'correct' (ie standard) way is implicit in the description of context
> menus: https://techbase.kde.org/Projects/Usability/HIG/ContextMenu

*every other GUI program ever written* is a very strong statement, you may 
want to reconsider it ;)

> 3. The same logic of 'there is nothing else you want to do' would also
> apply to text selections, yet Okular uses a more standard approach with
> those. In this sense Okular's behaviour is clearly inconsistent.

As i said, there's a well known pattern for text selection out there, so we 
follow it. And it fact it *does* copy the text, you can just middle click 
somewhere and it will paste it.

> 
>   On the table selection mode, you need to "draw" the table in
> 
> > multiple strokes, so you need a way to get out of it (i.e. escape).
> 
> 4. I don't have such a big problem with this aspect (ie it is less
> disruptive to my personal project). However in the context of this
> discussion I would point out that the first time I saw table selection
> mode I thought that Okular had hung, because it stopped responding to
> mouse presses outside the selected area. Yes, there was a message
> telling me that I had to press escape, but that was not immediately
> obvious as it blended a bit too easily with the contents of my document.
> I do feel that a more friendly and intuitive approach would let the user
> get out of the table 'drawing' mode via right-clicking.

Patches and ideas to improve the code are always welcome.

> 
>   The text
> 
> > selection mode works like other text selection modes.
> 
> Exactly - this is why I suggested that the same behaviour should guide
> the other modes.

But the other modes are not "well known patterns" out there. 

> The whole reason I am getting involved in this discussion is that I am
> working on code that does offer the user other things to do (ie
> 'tagging' the region with various codes) with a rectangular selection.
> If I have to modify the behaviour of Okular to do this, then I will just
> go down that path. However, given that the Okular UI seems to me to have
> clear room for improvement here, I thought I would like to raise this as
> a topic for discussion.

As I said, if there's a need to change how the modes behave because new 
features are added, sure let's change them. And if there's ways to make some 
of the modes less confusing, let's do that too.

Cheers,
  Albert

> 
> > I find they are quite consistent in how you want to use them.
> > 
> > Cheers,
> > 
> >    Albert
> 
> Best,
> Jonathan
> 
> >> I would like to suggest that the operation be standardised around the
> >> current behaviour in text selection mode, as this is standard GUI
> >> behaviour. In addition to eliminating the current inconsistency, this
> >> would permit a wider range of context-dependent options to be made
> >> available via right-click. We could also (eventually) do more fancy
> >> things like allow compound selections, even of different kinds and get
> >> rid of the zoom tool entirely, by making 'zoom to selection' and 'zoom
> >> out' as right-click options, depending on whether or not there is an
> >> active selection. None of this seems very difficult to do at all - the
> >> code is all in ui/pageview.cpp and it would simply be a question of
> >> rearranging the functions that handle mouse button presses and releases.
> >> 
> >> FYI the reason why I am interested in this is that I am working on using
> >> Okular as the basis for a mark-up/tagging tool for qualitative research,
> >> as a part of which I need to extend the range of functions that can be
> >> applied to selections. See a brief discussion here:
> >> https://mail.kde.org/pipermail/okular-devel/2015-November/021920.html
> >> and the code itself here: https://github.com/jschultz/okular-tagging
> >> 
> >> Cheers,
> >> Jonathan
> >> 
> >> 
> >> _______________________________________________
> >> Okular-devel mailing list
> >> Okular-devel at kde.org
> >> https://mail.kde.org/mailman/listinfo/okular-devel
> 
> _______________________________________________
> Okular-devel mailing list
> Okular-devel at kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel