Solving the cover-actions

asked 2015-09-05 18:43:49 +0300

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2015-09-09 21:51:23 +0300

9595 ●94 ●124 ●122

Cover actions were one of the best and most used (at least for me) features of Sailfish 1.0. The change that came in the new UI converted the gestures to buttons (and limiting them to one for official apps, but that's another story).

While I understand the need for rethinking horizontal swipes as triggers for the cover actions (it would interfere with the carousel navigation), I think that the chosen solution is worse than removing the cover actions altogether (which I'd hate to see).

I have never accidentally triggered a cover action in Sailfish 1.0, but I am constantly triggering them in 2.0.

In the upper row of the apps, the trigger is directly below one's thumb, so you need to stretch your finger out of your comfort zone
I am often triggering cover actions without wanting to (instead of opening apps) and I am quite an advanced user - imagine how confusing it will be for regular users

It is a big problem, so I am proposing either rethinking the trigger to something more useful and intuitive, or removing cover actions altogether. I for one will be removing cover actions from my apps, if this doesn't change before the final version of Sailfish 2.0 UI.

A call for other users - please provide possible solutions as comments to this post.

PS: I admit I am writing this a bit angry - I was trying to make a calendar event and needed to check an e-mail to find the details. When coming back from an e-mail, I accidentally hit the '+' action of the Calendar app and everything was lost.

edit retag flag offensive close delete

Comments

6

One possible solution (not elegant, but better than the current approach) could be using double tap. One tap would change the color of the button, as an indicator for the action, while the second one would trigger it.

nodevel ( 2015-09-05 18:47:38 +0300 )edit

16

In Sailfish OS 1 the screens are positioned vertically, in version 2 horizontally. Why not simply change the cover swipe direction from left/right to up/down?

ibins ( 2015-09-05 19:11:09 +0300 )edit

3

@ibins because the home screen is also vertically scrollable: it's now possible to open more than 9 applications. Obviously that rarely happen due to the OOM killer, but that's for another topic... :)

g7 ( 2015-09-05 19:42:21 +0300 )edit

2

@ibins I thought of that as well, but the problem is (actually, it is quite a nice feature) that now you can have more than 9 apps and then the list becomes scrollable and scrolling would interfere with that gesture. EDIT: Ouch, @g7 beat me by 1 minute :)

A solution could be that your up/down cover actions would be visible only if there are <=9 apps open.

nodevel ( 2015-09-05 19:44:01 +0300 )edit

19

@ibins: impossible, the app covers are a vertically scrollable list.

@nodevel: it took some getting used to as I probably always tapped covers at the bottom, but I'm not hitting the buttons anymore after a couple of days using it now. I do agree that it's not nice that they can be accidentally selected in the first place. I bet the buttons work superb on a tablet, but on a phone they're a bit small, yet big enough to get in the way.

My proposal would be to only allow to move between home/events(/partnerspace) with swipes from the edges, then cover actions are still possible by swiping on the covers. This is how I already do it anyway.

nthn ( 2015-09-05 19:45:30 +0300 )edit

65

answered 2015-09-05 20:25:59 +0300

AliN

6981 ●94 ●134 ●137

updated 2015-09-06 22:56:16 +0300

Predicting unwilling taps on cover actions, I had a suggestion months ago (just the same as @nthn mentioned here):

Events and partner space on edge swipes.

I believe that changing right/left swipes from the home screen to edge swipes can make using gestural cover actions possible again; i.e. on the home screen a swipe from the left edge will go to events and from the right edge will go to partner space. Edge swipes from either side inside an app will go back to home as before.

edit flag offensive delete publish link

Comments

7

Yeah, that sounds like a good solution. While I kinda understand the rational of using swipes for horizontal screen switching (tablet screen might be too big to comfortably swipe across the edge at all times) it makes no sense on a smartphone and loosing cover action because of this little convenience is a too big cost to pay!

MartinK ( 2015-09-06 02:48:08 +0300 )edit

I don't think this would work since apps could use swipes from inside the edge for something on their own (e.g. you could be scrolling around in a game).

Giacomo Di Giacomo ( 2015-09-06 09:16:17 +0300 )edit

3

@Giacomo Di Giacomo: I don't see that as an issue - edge swipes have been reserved for the OS since Sailfish OS has been released (and even before that on Harmattan) and it all worked out just fine.

And in case you really need edge swipes in your app, there is an API that you can use to take it over from the system - as long as you provide a way to exit this mode.

MartinK ( 2015-09-06 12:24:27 +0300 )edit

Yes, you are right, I got confused while reading. This could indeed work.

Giacomo Di Giacomo ( 2015-09-06 13:39:59 +0300 )edit

3

Great suggestion, solving not only covers issue, but also improves overall OS consistency. Look: now on the home screen two different gestures (edge swipe and screen swipe) do same action - rotating the carousel (Home-Events-Home). Considering Home screen as (meta)app we must reserve screen swipe for in-app action (such as covers management) and edge swipe as navigation to other (meta)apps such as Events or Partner.

kandelabra ( 2015-10-01 13:52:30 +0300 )edit

22

answered 2015-09-06 16:38:09 +0300

nodevel

9595 ●94 ●124 ●122

updated 2015-09-06 18:46:08 +0300

My proposal is creating pulley menus on the app covers. I had this idea months ago and I think it's worth a try.

Here is my patch, that enables this.

Read more about it here and read the warnings especially!

Screenshot

PS: Opened the original question, as I have not heard from chemist yet (with his reasoning about closing this).

edit flag offensive delete publish link

Comments

Can't test now, but seems to be a good idea.

malibu1106 ( 2015-09-06 16:45:14 +0300 )edit

your idea deserves its own thread, please split it out. I closed this question again.

chemist ( 2015-09-06 20:10:34 +0300 )edit

5

@chemist I will not open it again, but please provide reasoning for closing it. Did you read the last paragraph, which was there from the beginning?

My idea deserves its own thread just like any other idea in this thread. This thread is based on user experience and is focused on finding possible solutions. The thread you're referring to is completely different.

There are already 7 answers to this thread - do you think it is better to create 7 new threads just for the sake of closing this one? I don't see the reasoning behind it.

nodevel ( 2015-09-06 20:28:13 +0300 )edit

1

Seems interesting, but my problem is the inteference with vertical scrolling.

AliN ( 2015-09-06 20:45:39 +0300 )edit

1

because reasons? collector-threads on a voting platform are a bad idea in general. The possible solutions to your problem are so general that it hurts, the simplest solution is to have it like 1.0UI... as 2.0 simply uses pulls and swipes for the same action twice! So if you want to rework cover-actions do that instead of hijacking a painpoint of this ui change!

chemist ( 2015-09-06 20:59:47 +0300 )edit

18

answered 2015-09-05 20:27:23 +0300

Moth

4610 ●32 ●70 ●70

Why is "Tap and Hold" limited to 1 action (Close)?

cover action

edit flag offensive delete publish link

Comments

16

This approach is slow.

ApB ( 2015-09-05 21:01:20 +0300 )edit

7

Not necessarily slow. It's a question of implementation. How about swiping immediately after tapping the button?

Moth ( 2015-09-05 21:48:06 +0300 )edit

2

The current implementation (pre 2.0) is one move. A swipe to each direction. Tap and swipe is two. Tap and hold is one-delay-two.

The only approach i can think -even though problematic because it requires more precision by the user and might present other problems since i haven't put much thought in it- is to have the lower 1/3 part of the cover not swipeable. Swipe outside this you get the screen moving swipe in that area you get an action.

ApB ( 2015-09-05 22:19:44 +0300 )edit

1

would you mind to spilt this out in its own thread? i think it deserves some more attention than being an answer.

chemist ( 2015-09-06 20:03:20 +0300 )edit

2

What about TapAndHold, wait for vibra and then the old action? I am thinking about blind use. I can feel that I start a cover action and then do the action.

cy8aer ( 2015-09-09 11:12:41 +0300 )edit

17

answered 2015-09-06 02:17:38 +0300

zeta
973 ●8 ●14 ●15

I always liked the idea of the cover actions, but it feels it is broken since the begging. Something that I would like for a long time is a task based UI, not an application based one. This would have the benefit to remove cover action need. I will try to explain my crude idea, maybe you can help by solving the missing parts to make it useful.

So, now, when you pick up you phone to do something, you have to: * open the app drawer, find the app to open it, then navigate in the app to start your task (for example from a pulley menu to add an event or write an email) * if the app is already open, you can use a cover action as a shortcut, but this has always be inconsistent. First, the cover position on the homescreen is always changing each time you switch app (they are ordered by the last one used), needing focus to find where it went (whereas widgets are at a fixed position). Also If you are reading a mail, and come back to the homescreen the mail cover shows an extract of the mail and there is no more cover action, until you open the mail app again and get back to its main page... * if the app is already open, but have no cover action or not the one you need, you are back to opening it and navigate in the app to start your task.

One possible solution to this would be to have an "action drawer", in the same kind as the "application drawer". A list in which you could have things like : * write an email * write an sms * drive to somewhere * search for an adresse on the map * add a contact * add a new calendar entry Each app would provide a list of tasks when it is installed, and the UI would count each time you use an action to order them by the most used to limit scrolling (but without having to manually order them, or to find an order that fits everyone). It could be a text list, or an icon grid, or a mix of both.

The event view can be seen as the "phone to human" direction, this list could be viewed as the "human to phone" way.

The benefit of this is that the action would be right there without needing the app to be already opened. About the interaction count, it is not more than with covers, because to interact with a cover, you first have to go to homescreen then do the action. Here you would have to go to the "action drawer" and launch the action.

You could also thing of a "widget like" top of the list to add things like media controls, or settings controls (GPS on/off for examples).

If thought correctly, the combo events/actions views could be the first class citizen, and the applications drawer and multitasking view a second class.

Just my 2 cents. If you see ways to fit this correctly in the UI or where my reasoning fails, feel free to comment. If needed I can sketch something to illustrate.

edit flag offensive delete publish link

Comments

This is a great idea, the same idea on the events screen on the tablet which includes quick actions such as make a note, take a selfie, etc – I'm not sure if it's implemented yet.

But there's a problem. To have all actions of all installed apps you should find the desired action among tons of actions and there will be some problems:

You should find by searching texts which needs more focus;
You may have the same actions for different apps and therefore you have to choose the app at last.

AliN ( 2015-09-06 10:58:30 +0300 )edit

...at least for native OS apps your task actions could be made with a task collection in an 'action app' which forwarded all task actions into the original apps. The 'action app' could be started with the system automatically...

Why not ask some developers to implement such an app?

M.Bln. ( 2015-09-07 01:24:07 +0300 )edit

Palm/HP WebOS 2.0 had a nice feature called "Just Type". It's an advanced form of search (similar to Spotlight, etc.)

When in card view (the closest thing to Jolla's cover-view) or in App menu, you can start typing away on the keyboard and the OS would automatically do a quick search (e.g.: for contacts, browsing history, and the like - a behaviour inherited from the PalmOS ancestrors) But you would also get propositions: "write an SMS", "write an e-mail", "search it on a map", "search it in wikipedia", etc.

These were configurable and installable.

That's a bit similar to the idea of "action drawer" that you're proposing (except that, by having a keyboard, on Palm device it was automatically activated as a result of typing text, whereas your proposition is to have them appear after a gesture).

DrYak ( 2015-09-10 01:04:05 +0300 )edit

WebOS "Just Type" was best but I found swipe cover actions to be great.

Hitting the correct button, for instance on the media app (where there are two buttons, play/pause and next track) is not so cool or easy as the swipe gesture; it is a small area to hit.

Stuarty ( 2015-09-15 17:16:15 +0300 )edit

11

answered 2015-09-06 02:44:16 +0300

MartinK
18500 ●154 ●178 ●174

Just make it optional - at least I'm read to swipe outside of app covers just to get this feature back. :)

edit flag offensive delete publish link

4

answered 2015-09-07 20:16:02 +0300

M.Bln.
4289 ●76 ●117 ●113

updated 2015-10-23 22:43:15 +0300

Because in-screen-swiping is assigned to Caroussel switching why not an option to replace the new cover actions OPTIONALLY with this?...

reopen an app: double tap the cover
de-/activate an app: single tap (maybe shown via a coloured cover frame off/on, where 'on' holds for 3 or 5 sec.)
use cover actions: swipe cover AFTER app activation

So you can simply use the cover actions. It doesnt interfere with horizontal scrolling and it's intuitive cuz widely known from desktop guis.

edit flag offensive delete publish link

3

answered 2015-09-06 12:31:49 +0300

MartinK
18500 ●154 ●178 ●174

updated 2015-09-06 12:33:09 +0300

What about tap-and-swipe ?

The current area holding the two action buttons would be replaced by a single big action button. Clicking the button would lock the global horizontal swiping and show the swipable cover actions. (basically bringing the old behavior back)

So basically bringing the old behavior back with the only downside being to click on a reasonably sized button beforehand.

This could also possibly be extended to lock also vertical swipes so that vertical cover actions could be added.

(Extending the original idea proposed by @Moth. Thanks!)

edit flag offensive delete publish link

Comments

yup, it takes ca two seconds after an tap till the close button appears. in between would be enough time to start a swipe.

pawel ( 2015-09-12 16:15:37 +0300 )edit

2

answered 2015-09-06 13:28:54 +0300

shfit
3003 ●30 ●38 ●41

updated 2015-09-06 18:29:59 +0300

I like @Moth's idea, it's intuitive. It could be combined with a "reverse peek" kind of mode. What I mean by this, is that if you tap and hold a cover, it shows a full screen/zoomed in version of the app cover which allows you to view additional information of the app without actually "opening it" permanently. While in full screen/zoomed in mode, the user is shown a couple of actions like @Moth suggested, which would be activated by sliding to the action and releasing. These actions would also include standard actions like close and open. If the user just lets go of the hold without selecting a cover action, the full screen/zoom in returns to the home screen again. This would allow you to peek into the apps and/or interact with them with a "single" gesture. The interactions could also be implemented by a pulley menu instead of buttons/icons. So you would tap and hold to peek into the app/app cover and then pull to reveal a pulley menu and select your cover action from there. After selecting the action the zoomed in/full screen cover returns to the home screen.

edit flag offensive delete publish link

2

answered 2015-09-07 15:34:39 +0300

Pam
63 ●1 ●3 ●7

In SailfishOS 1.x.x the whole cover area is reserved for cover-action (left right). In SailfishOS 2.0, let only the lower 1/4 part of the cover be reserved for cover-action. Then we could have 4 cover-actions (left, right, up and down). Outside this area let us have nomal SailfishOS 2.0 swipe behavior. https://blog.jolla.com/design-insights-sailfish-os/ Pam

edit flag offensive delete publish link

Comments

1

That combines the bad aspects of the old and the new cover actions and leaves out all the good ones.

nthn ( 2015-09-07 17:32:18 +0300 )edit

Please explain.

Pam ( 2017-11-10 12:29:27 +0300 )edit

1

answered 2015-09-06 12:55:06 +0300

chemist
41469 ●392 ●542 ●615

moderator

http://talk.maemo.org/

duplicate of https://together.jolla.com/question/84391/hyc-dont-replace-cover-action-pulls-with-buttons/

edit flag offensive delete publish link

Comments

1

I disagree. Did you read the text of this question (especially the last paragraph)?

This is based on user experience (not on speculations like the thread before) and it is focused on finding alternative solutions.

nodevel ( 2015-09-06 14:29:26 +0300 )edit

2

The other thread is based on MWCB, has alreday discussion and 4 times the votes, it is a wiki already... append there. Oh and btw some version people installed from repos without a public release by jolla are also not said to be final!

chemist ( 2015-09-06 20:01:32 +0300 )edit

Solving the cover-actions

Comments

13 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

Solving the cover-actions

Comments

13 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions