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.