Improve discoverability of the "Big preview" action

[junrrein]

Right now, the button that allows the user to see a big preview of the page is hidden until the mouse enters the page area.

While this is kind of discoverable (since sooner or later the user has to move the mouse cursor over the pages in order to select them) it could be better, and it has the issue that it can't be activated at all on a touch screen.

The alternatives I thought about until now are:

1. Show the button at all times.

   I don't like this one because then pages always get partially obscured behind the button.

2. Show the button in the bottom bar.

   I don't like this one because it doesn't fit with the two groups of actions that currently reside there. Those groups being "actions to modify/do something to pages" and "actions to change the selection of pages". Where would the "Big preview" button be placed among these?

   Having the button in the bottom bar will also be awkward. If we move it there, then the action would change to "Big preview of the selected page", which would make it the only button that works when there is exactly only one page selected, and it would make it necessary to cancel any selection previously made, losing it in the process.

I can't think of a better alternative. I'm open to suggestions.

[amivaleo]

I'm actually thinking that the main content in slicer is basically a list of pages.

There are other applications that do show lists as main content. Many of them indeed: media players, ebook/pdf/whatever readers and so on.

I'd say that in most (if not all) of them, the main interaction is to click or double click on them, and then something happen. I'd say that most of the cases, the clicked/double-clicked item is somewhat opened/read/played.

Based on this idea, I believe that the user might be prone to try to click and double-click on a page in Slicer so to discover what happens. I do understand that this might not be so evident for the case of Slicer, since its scope is definetly less common that playing videos/opening folders/reading documents. And yet I think that the very similar way of showing items in a list, just like many other known applications, might lead the user to at least try to test the effects of double-click.

Some may argue about that it is surely not the case for every user. I do agree. I feel tempted to answer that some users might be so unaccostumed to any UI that they basically need to start using a pc with the help of another user. I'm basically thinking at my granny, who would have troubles also in opening Settings in gnome.

In the end, my point here is that maybe we could try to follow the same UX of other apps that show lists. What I can see in nautilus, for example, is that I need to double-click on a folder to explore it, even if I use a touch device.

IF (and this is already a big "if") we consider to go for letting the preview-window popup after double-clicking, I wonder how to instruct the user about this feature the first time he opens Slicer.

Remember: we may say that nautilus has been using hard-to-discover actions since it's very birth. And yet users are so accostumed to that that they somewhat expect a file manager to work with double-clicks, right-click-menu, etc. Unfortunately, a pdf editor like Slicer is definitely a less common application than a file manager, and thus it can't rely on this "expected-UX" approach.

One think I'd like to remember in order to make the similarity between Slicer and other list-showing-applications is: Julian, have you had any progress in trying to switch to the current UI for the page list so that it looks like other lists? I'm referring to the fact that the selction box that contains the thumbnail of a page in Slicer still fills the entire vertical space. This:

Switching to the UI used in gnome-music / nautilus / etc for showing the grid of items, might help the user to think that double-clicks actually do something.

[junrrein]

Thanks a lot for taking the time to think about this.

I pretty much agree with everything you laid out in the first half of your comment (sorry for the bad recap):

• Slicer is a "list of things" application, as are many others.
• When a user gets in front of a "list of things", there are some learned patterns of interaction they lean on (clicking and/or double clicking on items makes stuff happen).
• Not every user has already learned or these patterns of interaction or has them ingrained in their workflow.

And since I still want to go with double-click to popup the preview window,

• We should find a way to instruct the user in the basic patterns of interaction with the application: showing the big preview, selecting pages, and doing something with pages.

Something extra that is confusing about Slicer is the design decision I've made about what gets saved when using the Save function: some users expect that selected pages get saved, while actually everything that is currently shown is going to get saved.

With all of this into account, the first solution that comes to mind is: how about a guided tour of the app's features the first time a document gets ever opened? Something similar to Glade's "interactive introduction". I don't know how it's called in English, but you can find it in Glade's appmenu.

If we go with this approach, the guided tour shouldn't be as thorough as Glade's. About 4 or 5 indications should suffice. What is your opinion of this approach?

Going back to the "Big preview" action, even if we go with double click on page to activate it, I don't think the button should be removed. I don't want any action in the app to be something hidden from sight.

Another approach someone could suggest is having a menu popup on right-clicking a page, where some actions could be present. But I don't like this approach, since combining right-clicking with a selection opens another can of worms:

• What happens if many pages are selected, and I right click on one of them? Should only the actions that can be applied to the whole group be shown?
• What happens if many pages are selected, and I right click on one that's not among them? Should the selection be lost and be applied on this other page? (This is what Nautilus does).

Regardless, I'd prefer not having secondary menus on right-click if I can afford it.

Julian, have you had any progress in (...)

I completely forgot about that, sorry. I've filed #180 so it doesn't happen again.

[amivaleo]

a guided tour [...] What is your opinion of this approach?

I'm somewhat neutral.

I'd like all applications to have some sort of short guide but in reality almost none has it. Glade is the only example that comes in my mind.

So I wonder: is it because a guided tour has to be avoided if possible (maybe because UI is expected to be soooo simple that a guided tour shouldn't be used?) or because devs tend to forget/ignore it?

That said, I'm thinking that Slicer... is not that short in features, you know? :) If you want explain all of them, it'd require a lot of steps. Think a bit about that, maybe I'm just pessimistic.

An alternative: an "Help" item in the hamburger-menu that pops-up a written guide. You can find that in many applications.

And yet another alternative, which doesn't exclude either the tour or the help is a "hint" message that pops up as an in-app notifications. It could show random hints when Slicer is opened or when no file is loaded (<- take in mind that right now these two states coincide, but this is open https://github.com/junrrein/pdfslicer/issues/127 ). It is clear that this feature would require a chech-box in the hamburger-menu to let the user deactivate/activate these messages.

I don't think the button should be removed

You don't have to. It can stay there.

I'd prefer not having secondary menus on right-click

I didn't consider that chance because I couldn't even find what to put in that menu expect >maybe< for this show-preview-window action. But well, a menu with a single item is bad design for my tastes. 😄

I've filed https://github.com/junrrein/pdfslicer/issues/180 so it doesn't happen again.

💪️