Solving the issue with pulldown / -up menus

[Sefriol]

Sailfish has been known for it’s unique UX ever since the introduction of swipe in MeeGo Harmattan. Sailfish added on top of it multiple new ideas which could be summarized with 3 major key points:

1. Most, if not all operations could be done one handed (Which Marc Dillon loved to emphasize )
2. Allowing imprecise UI interactions (i.e. one action/element per UI “row”)
3. Allowing operation of the phone without even looking at it (Combination of 1. and 2. + Pulldown/up menu and haptics)

When community usually picks up their pitchforks, it’s usually labeled UI becoming more “Android-like”, but I would argue that it’s more about UI changes conflicting with those 3 major ideas mentioned before.
I have for some time thought why this is actually happening and came to a conclusion long before, but it needed some time to materialize it into proper words.

Problem usually is that many applications need multiple interactable actions to use basic features. Email being a prime example. You can forward, respond, delete etc. a specific email and you need some way of doing these actions. Previously this was done using a pulldown / -up menu and recently sailfish has moved away from those in favor of buttons.

This is kind of okey, but it brings another problem: too many ways of interacting with an application can cause confusion between users and the developers on how to properly interact and implement the UI. With the current pace pulldown and -up menus will cease to exist in Sailfish, since they are much harder to use properly. Especially in listviews, accessing a pulldown / -up menu is a pain since you have to scroll to very top or bottom before they activate. Or when there is another touch element conflicting with the scroll gesture (map and email). Sometimes it’s possible to access the pulldown menu within the title element, but after the original Jolla 1 and Xperia X lineup, it has become harder and harder to reach to the top of the screen with one hand.

I think this is an important issue to solve. Rather than complaining about the current design decisions (which I can understand because of the underlying problems), I would like to discuss about possible solutions to the root problem. More and more Sailfish replaces UI interactions with buttons, more and more the 3 principles mentioned above suffer. Buttons take space and it’s more common than not to even stack multiple of them into single “row” (email-view as an example). More interactions you have in a single row, more precise touch input you need.

I think solving the accessibility of pulldown menus is the key problem here. You should have easier access to them. One solution I noticed some time ago (unfortunately I do not remember who’s idea it was) was an introduction of 1 new, system wide, gesture. Here I call it either “Treeshaking” or “Groundshaking”. In principle this would be a quick 3 action scroll, which would activate either pulldown or pullup menu:

Pulldown Menu - Treeshaking (First 2 actions in quick succession):

1. Scroll down
2. Scroll up (After user starts the next action pulldown activates)
3. Scroll down (You can interact with the pulldown menu)

Pullup Menu - Groundshaking (First 2 actions in quick succession):

1. Scroll up
2. Scroll down (After user starts the next action pullup activates)
3. Scroll up (You can interact with the pullup menu)

This would work any time there is a menu available. That way, regardless of a touch element (list, map etc) you would have access to the menu.
This is probably not the only way of solving the issue and when discussing it with @jpetrell at the Sailfish 10-year event in Helsinki, he had some other ideas as well. I still think this is a discussion worth to be had. Maybe I bring this up in upcoming community IRC events, but it would be nice to maybe discuss it further first.

[Sefriol]

Maybe discussion could also be expanded upon how gestures are defined within the OS and how they could be implemented. I think it could be something that community would love to help with.

[nthn]

Nice, I suggested exactly the same feature in a topic about difficult to access pulley menus on TJC many years ago. I still think and therefore agree that it’s an extremely simple movement, and it would fit the rest of the UI perfectly.

The only thing it doesn’t solve, however, is that you still need to remember that there is a pulley menu, because pulley menus are not indicated at all if you’re in the middle or at the opposite end of a page. Perhaps, for that purpose, the pulley menu indicator could always show up, but that could look ugly and take up too much screen space.

[Sefriol]

The only thing it doesn’t solve, however, is that you still need to remember that there is a pulley menu, because pulley menus are not indicated at all if you’re in the middle or at the opposite end of a page. Perhaps, for that purpose, the pulley menu indicator could always show up, but that could look ugly and take up too much screen space.

Yes, this is a second aspect of the problem. I think couple of pixels flat line at the top/bottom of the screen would not be too invasive. There could be an option in the settings to turn it off user wants. This combined with the proper use of built in tutorial components, I think we would be set.

[euomeu]

When i want to close any app (swipe from side) the animation sow me a transparency of the desktop, if the gesture is short the app doesn’t close. a short swipe from side can remember me if there are a pulley menu and hold a finger for a moment confirm that gesture, at these moment the transparency may disappear, and the pulley menu indicator show up, at these time i have two options, swipe up and down across the pulley menu, or swipe to the middle of the screen these action give me the focus, for example in one mail from list, then i can swipe up an down moving the focus from the different mails from list, if i swipe back to the same side, the pulley menu now is about the focus for example answer, resend or delete that focused mail. These gesture mode should work in Android side too and we can forget the go back button, a short swipe from side may be sufficient and you can get the control of the focus for example from a whattsap message an copy it without need of touch whit your finger. Sorry for my English I hope you understand me.

[Sefriol]

Swipe from the side could be another option as well to activate pulldown menus. This is something Joona was talking about in the Sailfish 10 year meeting. I think both ideas would require testing to check out which option conflicts with the current design the least.

[Andal_GER]

why not a double tap on the screen to activate and show a pull up/down menu?
After reading that I tried in many apps including the browser while writing here. the worst action a double tap created was closing the keyboard…

tap tap to let the menu/s appear, using it, done.

tap tap to let the menu/s appear, doing nothing, tap tap to let it disappear.

After thinking and experimenting the best option. ai would not want to miss the actions already existing by swiping from one of the 4 edges…

[Sefriol]

Tapping on a screen is not usually the best option, since touch area has to wait for double tapping input for all touch controls. That could substantially hamper the user experience. I am not sure how well it could interact with other touch elements either.

I would assume that that’s the reason why it’s only used to wake the phone .

[nthn]

The problem is also that most areas in the UI have large buttons, which would be in the way if you had to open the pulley menu by double tapping. Even the gallery would be unusable if you had to open the pulley menu with a double tap. On a picture, it could work, but there’s no pulley menu there in the first place. In the overview, it couldn’t work…

[akikyo]

Something like that would be nice. Being in app, sliding. No matter of Y position. Respect for left, right side. Reaching % X of screen allows to enable slide top/down menu. Otherwise act as nowadays. Btw, i did skecht in Imageworks - nice app.

[poetaster]

A bit of a brain dump … I’m going through a farily lengthy process of reworking and adding additional interface modalities to tidings, the rss reader. And, as it happens, Imageworks Where the former is concerned two things were apparent:

1. Not everyone likes to use swipe the same way. So I’m adding two experimental interfaces to tidings. One SlideshowView based, one using Dialog for swiping. Perhaps some experiments here can be usefull…
2. It’s often a question of context how and when menu entries or buttons need to appear. In tidings, I’m removing unneeded Pullup/down menus which makes Pullup (for next entry when in an Item view) usable for Items that are not ‘too long’. As it is now, Pullup wasn’t easily usable since it had two entries.

I’m also going to implement some ‘long press’ actions which I think are underutilized. I believe ™ that is an unconscious convention by now that can be helpful. Sometimes a Swipe Left on Item (Detail view) is a good answer. The new release should be out this week.

I personally don’t like the newest version of the mail app since it doesn’t really utilize the Pullup/downs at all. The Swipe Left action gets you Meta info. hmmm. Why not Attachments? As it is, I get HTML by default (uhg), can’t access a list of attachments without a button and KNOW that the additional pully menus could be productive. The current buttons for reply/delete/forward don’t bother me that much, but I’d prefer to have delete in pullup, and the attachments in the swipe or pulldown menus. That would let me do most things I can do with one hand, well, in one hand. Forward and reply require a second hand, so it’s a moot point. Buttons are ok. But for just flicking through views, the pulleys should be there, imho.

Since Imageworks was mentioned, one of the things I liked about Tobias original design and which I’m trying to be careful not to screw up, is a fairly judicious use of minimal icons as buttons. But this is the kind of app where the number of options for any given operation can’t be normalized. The context never really allows OR calls for pully/swipe gestures. But more or less anything list based can take advantage of them… end dump.

[poetaster]

So, version 1.2 of Tidings is in the queue.

In the ‘traditional’, aka default, view of an Item, if you flick up and left (don’t need to exagerate) you get a fairly quick, simple forward. Not always with the click affirmation But always with visual cue.

On the other hand, one can enable the experimental (slideshow) view to see how that feels. The downside (from my vantage) ist that it’s a carousel. So you can’t return to the list view without using the left top corner area (probably your second hand).

While working on variations, what occurred to me is, I like being able to go back to list view and don’t just want to flick through details (ie. I want to skip stuff). Among other things.

One other thing that occured to me is that the scrolling (whether in list of item view) has an accelerated form. Filck fast and you get an extra double arrow. Hit one of those and you jump to the top/bottom. This makes the use of Pulldown/Pushup more feasible. So, another lesson is that context + gesture modification can also have an impact on utility of some screen elements.

[attah]

Instead of cluttering the community meeting thread i’ll throw my two cents in here.

Potentially controversial opinion: I don’t think this should be “solved”.

Pulley menus should be reserved for global actions for which you have absolutely no use of being 100s of items down a list. And from what i can tell - for the most part it is. Putting an action that needs (or even can make use of) scroll context in a pulley menu is simply wrong.

[Fellfrosch]

@attah

I don’t think this should be “solved”

Well I think it has to be solved. Here are some examples which simply don’t work well:

In Mail and Gallery there is mark multiple items in the pulley menu. Why do I have to scroll to the top before I can marke different Items.

In nearly all Jolla apps there is search in the pulley menu. Do I really have to scroll all the way to the top of every list just to be able to search?

That’s just the native jolla apps. We have such “global” functions as well in other apps like image organizer, file case an many more. Why should one always scroll to the top of a sometimes VERY long list to be able to do some “global” actions.

If I want to select multiple files I’m usually exactly at the position of the list where the files are located. Then I should scroll to the top to choose multiselect and then scroll back to that files i want to select? This is cumbersome and I’m so tired of this.

So I disagree. There has to be a solution. Whatever it is. But to have an all over satisfying UX there has to be something done.

[attah]

@Fellfrosch

In Mail and Gallery there is mark multiple items in the pulley menu. Why do I have to scroll to the top before I can marke different Items.

If you actually try to use it, you will see that it moves to a new page (which then by definition is scrolled up) too before going into that mode. So even if you could trigger it from anywhere, you’d still lose your context.

But let’s assume the multi-select view is merged into the normal one. Why can’t entering select mode be on long-press on any/all items?

This is an example of not solving “access to the pulley menu”, but the real specific problem.

@Fellfrosch

In nearly all Jolla apps there is search in the pulley menu. Do I really have to scroll all the way to the top of every list just to be able to search?

There is quick-scroll. Search does not need to preserve your scroll context - heck it even shouldn’t.

[nephros]

I believe the real solution to the “long list = long way to the top” problem is to have the list scroll independently from the main Flickable (which has the pulley).

That way the pulley is always accessible (albeit only when pulling on the PageHeader.

So

Page{
  SilicaFlickable {
      PageHeader { id: header }
      PullDownMenu {}
      ListView {
          anchors.top: header.bottom
          ...
      }
...

[Sefriol]

Since someone woke me (and my thread) from dead I share my two cents:

Two things made Sailfish elegant: Being able to use device one-handed and imprecision of gestures/actions allowed you to do very little mistakes when operating the phone.

These are the values that Sailfish should still try to focus on. It made it unique.

I hate how precise android and iphone gestures are. There are multiple points in the screen where swiping from very specific point does different things. Sailfish used to have very clear rule on this: each “row” of the screen should only include one action. i.e. no tabs, no multiple buttons or inputs in the same row. This has its disadvantages, but it made everything very clear and simple to use.

Back to the recent suggestions:

Two-finger swipe conflicts with the first point: it is not one-handable. EDIT: Also, would not work if you wanted to do a pulldown menu in a map-page.

Separating the flickable and scroll area from each other conflicts with the second point: it is either not simple, requires precise control or puts multiple control elements on the same row.

Why I proposed the “wiggle” gesture was simple: it works for both directions, you can do it one-handed and even without looking the phone. It is a “complex” gesture, but it does not require precise, location specific position of your finger. But is it practical to implement? I have no idea.

[Fellfrosch]

I agree with you on most points. Unfortunately as well on the two finger conflict with map applications.

In theory, I agree with you as well on the one-handed actions. But having bigger and bigger screen sizes makes it already impossible for me to use my phone (at the moment a Xperia 10 III) one-handed, without the fear to drop it. I don’t have small hands. And I don’t think there are many smaller phones on the market.

At the moment I tend to @nephros solution. It seems to be an easy solution and some apps already do it like that, so it isn’t disruptive.

But I would as well accept your “wiggle” solution. I just want some solution. ANd for me it is nota solution, to always scroll to the top, no matter if there is a fast scroll or not.

[iolala]

While I like your original suggestion, the idea of always having the pulley menu indicator visible is very bad because it would confuse users.

When the user sees the pulley menu indicator, they know to pull down (or up, in the case of bottom pulleys) to access the indicator.

If you show the pulley menu indicator in the middle of a list, the user will pull down and the pulley menu will not appear.
That would be very VERY bad for the user experience of Sailfish.

There are many user interface improvements badly needed in Sailfish, many of them already suggested on this forum (including by me), but there is no interest to implement such improvements probably because there are no resources inside Jolla for such changes, since there are bigger, more fundamental issues which Jolla is and will be struggling with for the forseable future.