About redesigning incoming call experience in 3.4.0

[Eztero]

Personally, I find it more efficient to swipe vertically is much easier than swipe horizontally.
I answer the calls on loudspeaker from a pedestal that I have to cellphone and sliding vertically for answer a call it is too easy, with the android I could never answer like that, many times I had to pick up the phone to answer. now with the new interface I returned to the same problem.
I think that this is a decision that was made for a certain group of people.
Personally, I would like you to leave both interfaces and that they can be chosen from the call settings.
That way we’ll all be happy .

PD: Every new device has a learning curve, the first android went through that too, and incorporated its tutorials. To use a mac you also have to learn to use it, which is different from windows in some aspects and the same for linux, for example with kde, but that is also because the way you use it adapts to your system and it is easy to use that way. go back to the traditional because it is something that was established in the culture of the cell phone, i feel that break the sailfishos interface and your originality

[Firefox84]

Yeah on option between the old and new design would be cool, or simply a customizable way to unlock your phone. If i remember it right Blackberry had the option of creating custom gestures. So everybody could have his favourite way of unlocking the phone

[rozgwi]

@jpetrell Thank you very much Joona and the Jolla team for sharing this! Hopefully now all the negative speculation and accusations will decrease.

I’m very happy that you’re also considering making the process of design and development more open. If you ask me, this could benefit the further development as you’ll get community feedback (ignoring the cynics of course) in addition to user studies.

In any case: Keep it up!

[danielfinsler]

@Eztero

Personally, I find it more efficient to swipe vertically is much easier than swipe horizontally.

same here, plus vertical swipes are in line with other app’s gestures, like the clock. Would be nice if the user just could choose, even though a lengthy design philosophy may be the reason behind.

[Sefriol]

Personally, I have too many times loved to have direction of the swipe to dictate an action with alarm. So many times I have had to pick up the phone and think which way to swipe to get snore…

I would have liked that Sailfish uses the design elements that it has already had for a long time. Unlock screen is a prime example on how the call answer could have been made. Just add colors to actions and that’s it. (green on left / right, red on up and down).

It is not always easy for us to revisit designs after the implementation project has already been completed. We are discussing internally how we could involve you guys earlier.

Involvement is the key. Jolla has for long “discussed internally”, made changes and got a lot of backlash after the fact. Then there is a lot of “correcting” and “clarifying” to be done. Such a waste.

To be honest, the solution is really simple: use the platforms that you have been given to communicate and pitch ideas. Even if you want to go in particular direction, community can still help you to find a middle ground to satisfy both parties. Or in the best case, agree with you, but also improve your original idea.

[nephros]

@jpetrell

[…]
One resilient myth is us copying competitor UX, which is simply not true. We do want Sailfish OS to retain its unique character.
[…]
Pull-down menus are initially difficult to grasp since it is an unique concept in Sailfish OS.

So, will you be removing pulley menus from the SFOS UI? Seems to me that is the logical conclusion.

[jpetrell]

I see those email buttons as the first real UI misstep
one that betrays the philosophy of SFOS without a sufficient advantage

It was a painful compromise, as discussed in community meeting there were also technical limitations of getting the pulleys and gecko scroll areas to behave together. Note while the common case is to only have three actions there can be more like “Reply all”. Also emails are quite often long and we don’t have quick scrollbar available yet for Gecko webviews, scrolling all the way up just to reply can be painful. We should find a way to both improve platform scrollbars and how to allow accessing pulley from anywhere in the view.

SFOS does left swipes to accept and right swipes to cancel. I do feel you have left the UX philosophy which you say to want to stick to. As this screen is the only screen in which a swipe either way performs the same action.

There are some cases like dismiss gestures that work horizontally on both directions, but that is definitely a fair point of us going against the existing gesture rules here. We tried “left swipes to accept and right swipes to cancel” initially, but settled on supporting both directions to accept after user testing and due to “not always easy to figure which orientation the device is in”. In comparison in dialog flow the orientation of your device is quite clear and there is little risk of swiping in wrong direction.

I would appreciate a similar setting for the answering call dialog.
Can such an option be added into SFOS?

The diff between the old and new implementation wasn’t exactly small, not sure we can really afford to maintain multiple implementations of such a feature. Events quick access is smaller feature to maintain, but a good example how we sometimes struggle to keep it working since most of us don’t have it enabled.

You made tutorial for purpose. Tutorial include answering calls. After tutorial everything is clear so whats the problem.

One customer feedback has been that people (who e.g. don’t necessarily feel as passionately about technology as people here) don’t bother to pay attention in stand-alone tutorials. You cannot force people to learn, if you are not readily interested in the topic even if you make the Tutorial flow mandatory doesn’t mean the learnings will stick. People learn better when guided in the context i.e. when user is performing the given task and acutely need help, even better if we can detect that user is attempting something but doesn’t succeed (e.g. tries to tap an answer gesture indication instead of swiping to answer).

So, will you be removing pulley menus from the SFOS UI? Seems to me that is the logical conclusion.

No.

[ApB]

@jpetrell

One customer feedback has been that people (who e.g. don’t necessarily feel as passionately about technology as people here) don’t bother to pay attention in stand-alone tutorials. You cannot force people to learn, if you are not readily interested in the topic even if you make the Tutorial flow mandatory doesn’t mean the learnings will stick. People learn better when guided in the context i.e. when user is performing the given task and acutely need help, even better if we can detect that user is attempting something but doesn’t succeed (e.g. tries to tap an answer gesture indication instead of swiping to answer).

People learn when they want or are forced to do (payed). Lets focus on the want here and take Apple as an example. An Apple product does many things differently than ie a windows desktop. Yet people learn and adapt to it because they want to be part of it (its a status symbol, cool etc etc).
If there is value in your product -or people see value in it- people will want to use it and will adapt no matter what.

[atlochowski]

@jpetrell

One customer feedback has been that people (who e.g. don’t necessarily feel as passionately about technology as people here) don’t bother to pay attention in stand-alone tutorials. You cannot force people to learn, if you are not readily interested in the topic even if you make the Tutorial flow mandatory doesn’t mean the learnings will stick. People learn better when guided in the context i.e. when user is performing the given task and acutely need help, even better if we can detect that user is attempting something but doesn’t succeed (e.g. tries to tap an answer gesture indication instead of swiping to answer).

I’m long time SailfishOS user and the only problem with vertical swipes I had was with alarm. I had problem, which side is to turn off alarm and which is to take a nap.
Because incoming call screen had green pull down menu and red pull up menu it was diffucult to make wrong action.
I have one Sony phone with android, and incoming call screen looks almost like it was in SailfishOS. But not so good. So if you coming from Sony android phone to SailfishOS you feel familiar.
On SailfishOS it was even more intuitive because green and red color without swiping by finger on screen.
@jpetrell show me big diference between old Jolla incoming call screen and sony android incoming call screen

nothing to learn when you coming from sony’s android phone.

[Eztero]

@jpetrell

One customer feedback has been that people (who e.g. don’t necessarily feel as passionately about technology as people here) don’t bother to pay attention in stand-alone tutorials. You cannot force people to learn, if you are not readily interested in the topic even if you make the Tutorial flow mandatory doesn’t mean the learnings will stick. People learn better when guided in the context i.e. when user is performing the given task and acutely need help, even better if we can detect that user is attempting something but doesn’t succeed (e.g. tries to tap an answer gesture indication instead of swiping to answer).

It saddens me to read that, in life you never stop learning and studying.
As a comment just to contribute I think that the problem of the interface (old) to answer calls and the alarm as I read above, is that it does not respect the logic of the system well. for example, the app closes with a downward swipe, one inherently associates the gesture to close, cancel, hang up, exit. So the right thing to do would be to swipe down to stop an alarm and hang up the call.
Now when we open an application we swipe up and access the application menu and open the one we want, logically, one intrinsically associates that gesture with accessing some function or accept a thing, following that logic, the swipe up should be taken to answer a call or snooze an alarm. in this way we have a coherent interface with gestures.

If in addition to that when answering I could place an animation of a phone that hangs up when you slide down and another that gets up when you slide up, you would have had a more than intuitive and visually guided interface.

What happened before is the following, we close an application with a swipe down, but when you receive a call and want to reject it, one unconsciously performs a swipe down, that happened to me many times , and it was quite confusing for me ,for the same reason, the interface did not respect the logic, it is likely that the same thing will happen to several users and that is why many stop to look at the screen to see what decision to make because it’s confusing in the beginning.

Also emails are quite often long and we don’t have quick scrollbar available yet for Gecko webviews, scrolling all the way up just to reply can be painful. We should find a way to both improve platform scrollbars and how to allow accessing pulley from anywhere in the view.

in that case, if possible, you can enable a feature where you can double-tap the screen, hold down, and slide down to display the menu.

But ,I see it difficult to implement if the customer does not want to learn so many gestures.

[thisisme]

@jpetrell thank you for providing insight into this. I am glad that you also involve experienced users in your testing. But how can one participate in these user studies?

[DrYak]

Pull-down menus are initially difficult to grasp since it is an unique concept in Sailfish OS.

Pull-down menus were the thing I liked the most about Sailfish OS - mostly because they play nicely with Fitt’s law: no button hunting just gesture directly under the thumb.

(Maybe I also love them, because I used to experiment with similar concepts eons ago).

On the other hand, I’ve never used an Android phone (my previous phones before the Jolla were webOS based Palm and HP which are also heavily gesture oriented), so unlike most users, I don’t have the muscle memory hunting for button, so maybe yes for users used for touch buttons, pulley are completely counter-intuitive.

One issue that caused confusion was related to the answer and decline indications being far from where the user’s thumb (that performs the gesture) was located.

Performing the gesture directly under the user’s thumb was in my opinion (and in the fitt’s law) the actual best feature.

Earlier-style pulley (with the glow) were easiers to understand intuitively than the current “couple of pixel wide solid line”

And though I understand your argument against maintaining too many alternatives, I would second Firefox84:

Yeah on option between the old and new design would be cool, or simply a customizable way to unlock your phone.

Having a way to keep pulley menu as much as possible would be great for those who enjoy them.

[nthn]

@jpetrell

how to allow accessing pulley from anywhere in the view

I’ve always had the idea that a ‘record scratch’ gesture would be extremely useful for this: to access a top pulley menu when it isn’t visible, do a quick swipe down, up and down again (in one motion), where the third swipe starts pulling down the pulley menu. And, of course, the reverse gesture could be used for a bottom pulley menu: up-down-up. It’s a very easy gesture and it just feels natural. If you haven’t yet, please do consider this suggestion!

[Novacane]

+1 for this! I remember Sailorgram had a similar feature in the chat window: If you were at the bottom of the chat, you could swipe up and then down in one motion to open the pulley menu. Your idea seems even better, as it can be performed anywhere.

[danielfinsler]

plus (currently) the pulley menu keeps things like the clock, or the calendar, in line with things like calling…

[jpetrell]

@atlochowski

show me big diference between old Jolla incoming call screen and sony android incoming call screen

There are many different Android incoming call experiences. I remember answer often performed there by swiping finger away from you, which was total opposite to the old Sailfish answer gesture. It can be problematic if you use multiple devices daily (e.g. one as personal phone, other one at work) if devices reverse gesture directions (while I personally found original Sailfish OS direction more intuitive to Android).

Note that during user testing we also had the old incoming call implementation as one option users were asked to evaluate, and at the end of the testing always asked which option they preferred.

[atlochowski]

So if someone is coming from Sony or Xiaomi android phone then they will be rejecting calls instead of answer with this new incoming calls screen.

[mattipulkkinen]

I have similar experience with the muscle memory on Sailfish OS. I also had Palm Pre (best OS ever) and still use Blackberry 10 phone every day. I never have problem to remember the gestures on these phones, even if change those on the fly. But when I use my Android work phone I really struggle with the buttons because I have to find those small things the my screen.

First Sailfish versions’ pull-down menu was great because the lines were closer tho each others and pulley was easier to notice. I think Sailfish should be different from other OS’s because that way it’s easier to remember which phone you use, work or personal

[jpetrell]

So if someone is coming from Sony or Xiaomi android phone then they will be rejecting calls instead of answer with this new incoming calls screen

Well silencing not outright rejecting, but true then they will need to perform second gesture to answer.

[DrYak]

It can be problematic if you use multiple devices daily (e.g. one as personal phone, other one at work)

Okay, now I understand why I am the weird guy: I am still not using Android even nowadays.

The only time I had to use multiple phones was back when I did work in clinical medicine (as opposed to medial research, nowadays in my day job): the (military) partice I worked in still used Nokia 3310s for emergency calls. One of the perks of moving to research is not having to be constantly on call (and to endure some crap that the eemployer imposes as a work phone). I only have my private phone, and the only externally imposed upon me thing I get is that I need WhatsApp to chat with my circle of friends and a couple of bank logging-in.

I would second @mattipulkkinen:

I think Sailfish should be different from other OS’s because that way it’s easier to remember which phone you use, work or personal

I also think that having radically specific user interface (pulley based) would be better at distinguishing phone than having something that almost looks like android but not quite . But again that’s based from my time switching between HP Pre³ and Jolla 1, I have very little first-hand experience with android.