Gestures

sdlzhd

@bonetone The current design is really convenient when closing a large number of tabs. But the phone screen is too big now , so it’s difficult to close the tab by one hand. We better find one that is easy to operate with one hand.

BoneTone

I've been thinking about the gestures in Vivaldi Android, and how to expand them to include popular feature requests. Here is what I've come up with, and the reasoning behind the design. Please like this post if you think the gestures should be expanded using a design like this, and comment with any feedback you may have.

There are 5 new actions added with this design change. They are:

History back
History forward
Open new tab
Close active tab
Create bookmark with active page

In deciding what gestures should be used for each action the are several considerations to take into account. Android has operating system level gestures already, and I've read that version 10 will be expanding these. It is important to not collide with these gestures as that would both confuse users, and possibly break functionality. Vivaldi also has gestures already; where possible new gestures should adhere to the design paradigm for these gestures to remain consistent - increasing discoverability & ease of use, and incorporating deliberate decisions on factors that may not be immediately evident. Lastly, Vivaldi Android is used on devices with little screen real estate. While large tablets may be able to take advantage of more gestures, the entire set of gestures should be designed with the limitations of these minimal devices in mind. Vivaldi is not going to maintain separate browsers for tablets and phones, at least not in the foreseeable future.

Before assigning new gestures to the chosen actions, let's take a look at the existing gestures in the operating system and browser itself. Starting with the OS, Android gestures are mostly global, meaning they work in every context - on every screen of every app, possibly even the lock screen if configured that way.

Drag down from top of screen - commonly open notifications
Drag up from bottom of screen - commonly used in the home screen context to open the apps list/drawer. This is the only non-global Android gesture listed in this post.

The following gestures are available currently using add-ons from manufacturers, but some if not all may become standard in Android in version 10.

Drag in from right or left edge:
- Straight in and lift
- Straight in and hold
- Diagonally upwards and lift
- Diagonally upwards and hold
- Diagonally downwards and lift
- Diagonally upwards and hold

That's 12 different gestures: 6 from each side edge, 3 with a lift before stopping the drag, 3 stopping and holding until the action is invoked - the groups of 3 being differentiated by direction of swipe. The area along the edge from which the gesture begins is configurable as is the length of that area.

The last Android global gesture I want to mention currently exists in Android 9 (and perhaps earlier versions, I can't recall). The Edge Panel is invoked with a swipe gesture from a side edge. Which side is configurable as is the position & length along the edge from which the gesture begins. There may be more gestures as part of the Android operating system, please let me know if I missed any.

When the 15 edge gestures above are combined, dragging in from the edge is pretty much saturated. The side that has the Edge Panel has two areas that invoke different actions depending on where the gesture begins, the OS doesn't let them overlap.

It would be a bit cluttered and also a technical challenge for Vivaldi to insert itself into the mix with gestures that drag in from the side edges. Similarly, dragging down from the top is for notifications, something that is very important for users to always be able to access. Additionally, Vivaldi already has downward gestures that are discussed next. So gestures that drag in from an edge are not an option for the design of Vivaldi Android.

Vivaldi Android has at least 2 existing gestures. They both drag downwards from the top toolbar. Where you begin the gesture determines the action invoked.

Drag down from address bar - opens the speed dial.
Drag down from the Vivaldi icon - opens the menu.

Using this paradigm, we can add 3 gesture by dragging upwards from the bottom toolbar. More than 3 gestures would be crowded. The 3 gestures are:

Drag up from tabs icon
Drag up from bookmarks icon
Drag up from the middle of the toolbar

Intuitively, the first gesture, drag up from the tab icon, would create a new tab and open it. This is a much faster and easily discoverable way, once gestures are known, to open a new tab rather than clicking the tab icon then clicking the plus icon. Especially considering that there may need to be more actions if the user previously had tabs open to the cloud, or history - first the user needs to switch back to the local tabs list. Instead of 3 clicks through a changing UI, the user simply swipes up from the tab icon.

The second gesture, drag up from bookmarks icon, lends itself elegantly to creating a new bookmark (or edit the existing one). Again, once the gestures feature is known, this is an easily discoverable gesture for a commonly used feature. When browsing the web, the toolbars disappear. To create a new bookmark the user needs to bring them back by scrolling down. After doing so their thumb or finger is near the bottom, not the top of the screen where the Vivaldi icon is to open the menu where the star is to currently create a new bookmark (or edit an existing one).

The final gesture that involves swiping up from the bottom toolbar is defined by swiping up from the center of the bottom toolbar. This is where the Speed Dial icon is. Currently opening the Speed Dial is assigned to the swipe down from address bar gesture. If we were to leave that as is, then the new action assigned to this gesture should be "close the active tab" as this is a highly requested feature - one that people want to use a gesture to do.

However, a more elegant design might be to move the Speed Dial action to this gesture, swipe up from the Speed Dial, and assign closing the active tab to the swipe down from address bar gesture. It's this bit of design that I think would benefit from discussion among a larger group within the development team (product management and quality assurance included), as well as feedback from the community.

The last two new gestures included in this design change suggestion/feature request are for the actions History Back & History Forward. As was detailed at the beginning of this post, Android itself has a pretty strong grip on swipes in from the edges. To avoid colliding with those, these gestures should begin in the middle of the screen and swipe off of the edge. Swipe from middle of screen and off the left edge for back, and off the right edge for forward. Middle of the screen can be defined as a box that makes sense, perhaps 25% in from every edge, that detail needs to be investigated.

The important thing to note here is that swiping left & right is currently used to scroll the page horizontally when it is larger than the screen. These movements will sometimes be small, repositioning the page just a little bit to align the page as the user desires. So the gesture when scrolling then begins & ends on the screen. The paradigm here maintains that scrolling pages must always begin & end on the screen. To scroll a lot the user will likely flick. Though scrolling large amounts horizontally is an uncommon scenario, flicking is what people often do when having to scroll ridiculously long lists vertically. So the thumb or finger comes off the screen before the edge. Vivaldi Android users will just have to be educated about this requirement for the History & scrolling gestures. Easily done with the feature announcement & on the help pages.

So I think that this not only expands the gestures feature in a natural way, maintaining the paradigm already created by Vivaldi Android, but does so while implementing some popular feature requests. The design avoids colliding with the gestures in the operating system, uses intuitive movements or visual cues for the associated actions, is easily discovered, and doesn't overload the interface or user with too many similar gestures. It is possible that in the future more gestures could be added, using diagonal swipes or right angle turns for L shaped swipes. For the time being however, I think it is best to start with this set of core functions - it covers high frequency user actions without making any individual gesture more complex than a straight swipe from points A to B. The gestures feature is kept simple, but fairly complete with the addition of these 5 new gestures & invoked actions.

I hope Vivaldi finds this idea useful, and the community can help determine what to do about the Speed Dial & Close Tab gestures. It's not ideal to change an already assigned gesture, but we're still in beta so it's not as bad as a user base trained for years having their muscle memory broken. If it makes more sense to move the Speed Dial gesture and replace it with Close Tab, there will be minimal pain to the existing user base.

Thanks for reading,
BoneTone

sirien.neiris

I have to say I do not like the idea of hard defined gestures nor I like the idea of (general, user adjustable) gestures which are tight to (1) some specific place on the screen (ie bottom left corner) or (2) to some specific place in the app (ie URL bar). The first feels like something which should be left to system (Android) UI and the second as something which should be tight to some specific function (like showing speed dial, as you suggested).

On desktop you can perform the gesture anywhere on the screen you want (that is kinda important part of the feature) and I do not see why it can't work the same on Mobile. You could even have the same gestures with the ~same UI - in fact that could be even synced.

Of course single finger gestures would have to be more complex than simple one direction drag (only "up" or only "left" etc - in fact "up-down" or "down-up" could be also problematic), but that is not such a problem. With two finger gestures I see no problem whatsoever.

For example I use "down-right" to close the tab and "right-left" to open new tab. I'm very used to this - I've been using it since the old Opera - and I would very much like to use the same in Mobile UI.

EDIT, ADD: ok, two finger gestures are probably not a good idea since they couldn't be performed single-handedly.

BoneTone

@sirien-neiris

Vivaldi already has gestures tied to specific locations on the top toolbar. That's why 3 of the new gestures are tied to a specific location on the bottom toolbar, it is keeping with the paradigm already defined by Vivaldi.

I included the other 2 (History Back & Forward) because if the requests for them that I've read. Having them work the same way as the others, pulling in from a specific location, isn't practical due to collisions with the system defined gestures or crowding the space on the toolbars. Any more than 3 and it will become mor difficult to use, requiring extra attention to the precision of where you start on devices that are known for their lack of precision.

So those two can start almost anywhere. They just have to start somewhere in the middle of the screen. How big the margins should be away from the edge would probably be best answered by a usability study - whether that's a formal study done bringing real world users into the lab to conduct, or a less formal study with internal employees trying out several options is something only Vivaldi could address.

But for those two, as long as you're inside the margins, you just swipe all the way to the edge and that should be both easy to do and sufficient to distinguish it from horizontal scrolling.

I do agree that the "open speed dial" action makes the most sense if it starts from the speed dial button in the UI. But I don't know Vivaldi's feelings on changing that action from its current gesture.

LonM

@bonetone This request looks like its related to this one for gestures - is this a different request or are you providing details of how you would like gestures implemented?

sirien.neiris

@bonetone funny, I didn't know about these "gestures" which are already in place. But the thing is that these are (feel more like...) not as much "gestures" in the sense gestures work in desktop as they are (...feel more like...) simple "swipe functionality expansion" of buttons from which you initiate them. You swipe from nav-URL, you get speed dial. You swipe from V button, it's like pressing it. Swiping from tabs button could open a new tab and so on and that would be probably even kind-of intuitive (once you actually learn that such "gestures" exist...), but I'm not sure how much is it a "gesture" in the same sense as "gestures" on desktop - nor I'm much sure how much useful would be to have there anything more complex than a simple swipe (like "down-left from V button"...)

Basically, all I'm trying to say is, that as a user I feel quite a difference between "swipe-command", which to me is just an alternative to "tap-command", and "gesture". Having gestures in Mobile would be great, though.

BoneTone

@LonM said in New Gestures Design: History Back & Forward, Close Tab, New Tab, Bookmark:

@bonetone This request looks like its related to this one for gestures - is this a different request or are you providing details of how you would like gestures implemented?

Yeah I wasn't sure if I should post in there, or make a new one since this is about a specific set of actions many of which have other threads like the swipe to close, double click to close, long press for new tab (a gesture I considered but it didn't stick with the paradigm of swiping from the toolbar icon). So because it is suggesting a specific group of actions and their specific gestures, rather than place this in another thread and maybe give pointers in a few others I had read or posted in, I created a new one.

If you think this belongs in that thread that's fine. It's half a dozen of one, six of another to me. If so, I assume you can merge one thread into another? If you want to merge them but don't have the tools and need me to post this info over there, just let me know. Whichever way works for me.

BoneTone

@sirien-neiris said in New Gestures Design: History Back & Forward, Close Tab, New Tab, Bookmark:

Swiping from tabs button could open a new tab and so on and that would be probably even kind-of intuitive (once you actually learn that such "gestures" exist...),

That's one of the "swipe-actions" included in the OP.

Swipe-actions, gestures, whatever we want to call them, I think that the OP outlines a useful & intuitive expansion of them that at the same time provides functionality that has been requested in other threads.

The one (or two depending on how you count) that I'm not certain what the best way to go about it is the Speed Dial. If implementing this from scratch, I would swipe up from the Speed Dial to launch it. That has been assigned to the address bar already. However, since it's still in beta, I wouldn't feel as bad about breaking the old flow to correct it as I would if the browser was years old with users having been trained on it and built muscle memory. I think that should be moved and replaced with close tab.

Edit: Also, I know the OP is long, so I just wanted to repeat a part that's relevant to your comments. I think this is a good starting place for gestures, something they could probably even include in the official release as it shouldn't be too much work. Especially if it's just the 3 toolbar actions & not the History ones. But I had pointed out that in the future more actions could be added with more complex gestures, having right-angle turns to make an L swipe for example. But that's too much to ask at the moment.

sirien.neiris

@bonetone I generally agree, but I do see a distinction here which you seem to not recognize. For me, "swipe-action" and "gesture" are really two separate things and should be treated differently. I'll try to explain:

Swipe action:

Part of "standard UI" - swipe action over given element does one specific thing (or one of given set of things) - like "clicking" or "taping" on a button, it just does what the button does.
- as such it "comes" with the new installation and works right away
It's tied to the given element (button, bar...) and can be activated only from this element
Is simple (preferably just a single one direction swipe), so it is easy to execute and easy to find by trial-error learning approach

Gesture:

Part of personalized UI (or fully adjustable UI) - specific gesture can be assigned to anything what specific user prefers
- as such it must be set up (or synced or learned, if you use "default") by the user before it can be used
Is executable "anywhere" (...with reasonable limitations, like "anywhere over the page space, outside of other control elements")
might be as complex as user wishes it to be in both number of moves and their directions

I really believe these two things should be treated separately, since they fill a different function and (some, many?) users will treat them differently. Both of these are useful, though, it's just they fill a different purpose.

Regarding swipe-actions: I do think that using swipe-actions everywhere is a good idea, because it allows to get more options from less UI elements, keeping the app simple and streamlined. Their usage is tight to the UI itself, though.

For example I would much appreciate to have just one "GENERAL TABS" button in the center of the bottom bar. This buttom could have following functions:

TAP: shows tab overview
swipe-UP: shows speed dials
swipe-RIGHT (=from center of bottom bar, to right) - goes to next tab
swipe-LEFT (=...) - goes to the previous tab
then:
swiping from left side of the bottom bar (left from TABS button) to right = forward
swiping from right side of the bottom bar to left = backwards

...this way you can have way less buttons in the bottom bar with way more actions which can be triggered from this bar. But it is closely tight to how the bottom bar is being organized.

(Of course it would be great to have the option to personalize ALL of this, but... I'd suggest to stay down on the ground )

esti3u

This post is deleted!