[Opinion] Terrible UX for new top menu

asked 2018-11-05 03:58:56 +0300

dgolcher
281 ●3 ●4 ●4

updated 2019-12-25 17:32:56 +0300

rozgwi
4618 ●49 ●77 ●79

I am well aware this is just my opinion and there is no right or wrong here...

I have been swiping down to close my apps since meego I believe and paid all import taxes to get a Jolla into Costa Rica since day one, using Sailfish and nothing else since it became available.

Fast forward 3.0.0.5 it has been so frustrating with the new menu, yes it looks lovely... but when on an app the most important actions must be contextual to the app be it native or android.

Since installing 3.0.0.5 I have been able con conscientiously swipe down on the borders to close the app twice, just twice... making me have to frustratingly double swipe afterwards to close the menu and the app.

Since the menu is a device menu and no a contextual menu pertaining to the app being used or about to be closed it is my opinion that the centre bulk of the down swiping are should have remained focusing on quick closing the app and the device menu assigned to the sides in a minimal way.

If you are using an app and you need some device menu you conscientiously would go to a more selective gesture to select that option, closing an app is directly related to the app usage and experience and should be as it was before center and the bulk or the gesture area.

Making a decontextualized device menu the prominent down gesture on an app makes NO sense for a user experience. Just my opinion, I love the menu I HATE the placing of its gesture.

Dunno if other people feel the same way. Cheers from Costa Rica, Daniel

edit retag flag offensive close delete

Comments

Yeah I mean we will get used to it but I'm afraid it's too complicated to new users, as nothing suggests that the top menu/closing swipe works that way (if tutorial for that was already done by someone else). Could one swipe gesture (from upper edge to down) somehow be combined to serve both these? First it would close app but swiping further it would turn into this new menu? That would graphically explain the function all the time and user could "cancel" the menu and select app close by swiping back a bit.

goldenm ( 2018-11-05 07:43:19 +0300 )edit

3

In BB OS10 you have to swipe down with two fingers to get the top menu if you use an app. From homescreen it's just a one finger swipe.

dirksche ( 2018-11-05 08:03:36 +0300 )edit

I feel the same way, in that swiping down from the center is more common than from the sides. I have found myself swiping from left / right more tho, so my task switcher looks alot more crowded !

tortoisedoc ( 2018-11-05 10:14:44 +0300 )edit

4

I've been screaming for stuff like that since forever. (havent installed sfos3 yet though) We need a separate gesture for closing apps. (suggested LtoR swipe) Adding close to an already used gesture complicates things, annoys people that are used to it and requires more precision in using the device which is wrong.

ApB ( 2018-11-05 11:20:47 +0300 )edit

5

My experience is the opposite: I don't have any trouble closing apps but always forget about the top menu and go to events view instead. For me swiping closer to an edge is natural when using the phone one-handed.

Aldrog ( 2018-11-05 11:38:24 +0300 )edit

20

answered 2018-11-09 22:14:09 +0300

DrYak

9624 ●93 ●134 ●128

http://www.sympato.ch/

I would vote for making the "top" swipe configurable :

current: ⅓ close + ⅓ topmenu + ⅓ close
classic: 100% close when in-app.

My opinion : the top menu is actually a cool features, it mostly solves what previously required hacks as Patch: Quick settings on power menu (it brings the settings accessible on power-button, on top swipe from app view, etc).

But in-app isn't necessarily useful. I use a lot of different native apps. I find my self often launching something, using it and closing it. Much more frequently than I find myself fumbling with connection settings.

Also, from workflow point of view: if I need access to quick settings while I'm midway through using some other apps, it's usually to fix a problem (broken connection, wrong Wifi, wrong roaming, etc.) Thus I am first going to diagnose the problem. Sailfish doen't have a top status bar (or $DEITY forbids, an awful ugly notch to put status next to the webcams), but Sailfish has its wonderful "peak" gesture, so I'd very likely be sliding my finger halfway side wise to check the status. If I notice something requiring attention/settings, I'm more likely to finish pulling my fingers all the way to switch to the tile display and pull the menu from there. I have little situations were I need to jump to quick settings straight from the app.

Also, I'm a former Palm/HP webOS user and used to simple closing gesture.

But I understand Jolla's logic :

former Android users are used to an always accessible top menu. that can make things easier to transition.
some people tend to lock everything down (only turn Bluetooth / Wifi / GPS / etc. on strictly when needed), to them, it makes sense to have a quick access to turning on something right before using it (i.e.: activate Bluetooth right before sharing a picture from the Gallery app) having top menu accessible within apps is useful to them.

Also several gestures are configurable in Sailfish (Quick Events access, Quick access to Camera, Flip to silence), configuring if top menu is available in-apps or if it's close only makes sense in my opinion.

edit flag offensive delete publish link

Comments

I'm really interested in having the option, because in the contrary I don't like the quick close and often do close apps mistakenly. There can be a combo to choose between (1) top menu, (2) close, and (3) both. (I mean one more choice than what you suggested.)

After all, you mentioned "Android users are used to an always accessible top menu"; part of it, I guess, is due to notifications there the same as many of Jolla users, including me, used to always accessible bottom swipe for events.

AliN ( 2018-11-16 17:34:50 +0300 )edit

8

answered 2018-11-14 09:48:27 +0300

Joona Petrell
1383 ●12 ●21 ●20

http://www.joona.net/

when on an app the most important actions must be contextual to the app be it native or android

Swiping global platform panels in from edges is quite pervasive behavior in mobile operating systems. Actions happening inside the app belong to app, edges belong to the system UI / OS. Remember for many people Sailfish OS device is not the only device they use at work, home, etc.

For old users new close gesture takes a bit of learning, which I know is frustrating, sorry. But it will get better once you have used the new gesture more. But it was bad that the close app gesture wasn't available by default (since in new users really struggled if the whole top edge was reserved for closing as they expected system panel to slide in) and it was bad that accessing common device settings required you to minimize the app and scroll to Events.

edit flag offensive delete publish link

Comments

3

@Joona Petrell:
Thank you very much for your statement. You are certainly right that it's necessary to cater to users coming from other OSs. But in the process it's also important to not forget about the existing user base and, above all, consistency. Also, offering configuration options would help. Like with the close swipe: It need not be enabled by default but the possibility to disable the top menu for open apps would be great.
Has the UX team seen and considered the ideas proposed for gestures here on TJC? The top menu is a great feature but it definitely needs some improvement independently of the fact that users will have to get used to the new gestures.

rozgwi ( 2018-11-14 10:28:17 +0300 )edit

3

Actions happening inside the app belong to app, edges belong to the system UI / OS.

You're contradicting yourself. Closing an app is a function of the OS, not of the app. (Actually it's one of the core functions of any OS, much more so than activating Wifi or changing the walllaper.)

accessing common device settings required you to minimize the app and scroll to Events.

That's exactly one swipe more than with the new SF3 style. Is that worth the confusion?

Also, changing any of these settings doesn't happen as often as closing an app.

In reality, what youre saying is that new users who are used to Android are worth more than existing users who are used to Sailfish. So are we gonna change everything now that makes SF more easy to use than Android?

ossi1967 ( 2018-11-14 13:03:33 +0300 )edit

1

That's exactly one swipe more than with the new SF3 style. Is that worth the confusion?

Say you are in an app and need to enable some hardware function. In Sailfish 2 that was quite cumbersome: Minimize app. Scroll to Events. Drag down to open Events pulley. Toggle the setting. Collapse pulley. Swipe to App Grid or Home. Maximise the app to continue what you were doing.

Has the UX team seen and considered the ideas proposed for gestures here on TJC?

TJC comments are actively followed and discussed yes. Sailfish 3 is evolving thing. Thanks for the opinionated comments coming, they are the most valuable kind of feedback when we weigh the next steps.

Joona Petrell ( 2018-11-14 14:29:51 +0300 )edit

3

@Joona Petrell I understand that you want to say it was more cumbersome than it is in SF3. (And my answer remains: That was OK, because the functionality isn't used as often.) What I don't appreciate is when you try to blow it out of proportion by describing steps that either weren't there or are the same in SF3.

Like: I never minimized the app - I just swiped to events view. (Yes the app got minimized in the background, but it's not something I did.) Yes, I dragged down the menu - but I need to do this now, too. Yes, I toggled the settings - that's the point, isn't it? You need to do this now, too. No, I didn't collapse the pulley, I went straight back to the home screen. (You need to collapse the menu now, thats new!)

ossi1967 ( 2018-11-14 15:08:58 +0300 )edit

If you didn't use left swipe for events screen (which I personally find confusing), in SFOS 2 it was swipe to multitask launcher screen from app, pull left and pull down to access the toggles. This was so unintuitive and ugly that I actually disabled the whole top menu because of it, and used settings instead (not optimal either but wasn't so odd).

Some kind of compromise would have been to access the top menu by pulling down on both carousel screens instead of just events and leaving top swipe for app closing. But that would not let you close the screen directly from the app without the physical power button, or change the brightness to your liking while reading if automatic does not cut it, or lock to landscape if you are reading in the bed.

Manatus ( 2018-11-14 18:13:28 +0300 )edit

6

answered 2018-11-09 17:41:20 +0300

roland684
421 ●12 ●20 ●21

Agreed. It is out of context in the app and an annoying change. it should be (remain) an action for the home screen.

It could make sense when you start swiping the app to the left/right and when (while swiping) you see the home screen, change the swipe direction to downward.

Same is true for swiping up the apps menu, but that is not conflicting with any swipe action in app context.

edit flag offensive delete publish link

4

answered 2018-11-14 08:39:48 +0300

Nova
598 ●9 ●18 ●29

I also like the new top menu, but UX and UI goes together. The new top menu does not look (visually) like the rest of Sailfish UI: No transparency effect on background, no "glow" buttons for options, no "glow" dot on sliders for e.g. Brightness. This makes the new top menu feel a bit out of place...

Also see my suggestion for calling up the top menu versus closing an open app: https://together.jolla.com/question/191932/suggestions-for-the-sfos3-new-top-menu/?answer=193151#post-id-193151

edit flag offensive delete publish link

Comments

2

Also my opinion. Maybe make it a lil transparent like before so that the ambience is shinig through

Dreej ( 2018-11-14 15:00:14 +0300 )edit

1

The dialog, top menu, etc. backgrounds will gain blur, which I think makes them feel more at home with Sailfish OS style. There is no glass effect on the backgrounds so there is no glass glow on UI components like the sliders either. Settings toggles are more than just simple switches so it makes sense they look different to normal switches.

Joona Petrell ( 2018-11-14 20:01:10 +0300 )edit

3

answered 2018-11-14 09:49:46 +0300

Kopekenscheich

758 ●6 ●19 ●26

updated 2018-11-14 09:51:58 +0300

Being new to Sailfish, I just love the look&feel of it. But then, I do not know it any different. (Former iOS user, hate Android.)

edit flag offensive delete publish link

2

answered 2018-11-16 16:35:00 +0300

fanda
41 ●1 ●1 ●7

I can realize that there are situation when user must operate on device using one hand only, so one handed UI is valid requirement also for me, but this doesn't mean that more fingers gestures will not be supported. My wife, for example, is not able to pull down from top device edge with one hand easily and this gesture is not handy event for me with much more bigger palm and I'm using second hand almost every time. My proposal is to keep UI one handed but also to support more complex alternative gestures too make UIX nicer. For example, even if settings pull-down will be implemented as two fingers gesture, UI will be still single handed, since settings can be accessed old way, swipe right + pull down and this way is IMO much easier one-hand gesture that try to reach device top edge by my thumb.

edit flag offensive delete publish link

0

answered 2018-11-14 10:12:53 +0300

fanda
41 ●1 ●1 ●7

What about two finger swipe for settings and keep one finger for app close. I also really miss previous app-close gesture. Two fingers setting pull down was used in BlackBerry BB10 and worked very well.

edit flag offensive delete publish link

Comments

6

Requires two hands to operate. UI must remain single hand.

ApB ( 2018-11-14 13:30:06 +0300 )edit

[Opinion] Terrible UX for new top menu

Comments

7 Answers

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

[Opinion] Terrible UX for new top menu

Comments

7 Answers

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions