swipe to go back
-
@makeixo I'm curious what gestures SFOS uses? As I see it there is really only 3 easy gestures per edge: quick flick, and long drag (perpendicular to edge), and sliding along the edge (parallel to edge). Currently only the indicator edge implements a parallel action.
I missed the 'back' button when I moved from Android, but these days I find it awkward when I use an Android device that the back button does inconsistent things... sometimes it move back in an app, sometimes it closes an app, sometimes it switches apps. My point would be that I like how UT has separated the concerns the 'back' button provides. App switching is on an edge, and induvidual apps are left to determine where and what a back functionality does (many don't even need it).
A global back gesture would have the same problem, what back action should be implemented in a given situation? Is this up to Unity8 or the app in question? If it is on the app, what happens if the app doesn't implement an action?
Thinking further about my example of Morph, the 2 basic gestures on the bottom edge would work, and could be just like the new app drawer coming in the next OTA; a short flick could show the address bar and a long drag could switch to the tab view. And all functionality would be maintaned with an easier to reach 'back' action.
If I was able to (and who knows, I might learn) I would add a parallel action to the right edge, so that sliding a finger up and down the edge would simulate a scroll wheel.
-
@Giiba You swipe to the left/right to go forwards/backwards. In SFOS that is very consistent to the UI.
I never have used an Android device as daily driver, therefore I dont miss the "back" button of Android. I think I wasnt the one who has brought up Android. I neighter have liked the navigation of Android nor I think it is somehow a good example.
Nevertheless I think having the option to navigate through the OS with just one hand could be a nice feature. I personally would prefer a global gesture. If a dev doesnt hook up his app to this feature, nothing happens. I dont think thats a problem. In SFOS not every app is consistant to the UI, but most of them are because its a consistant UI gesture. -
I have no idea if its possible to implement this EMUI Back feature but I really do like it and maybe it could work on UT as well.
-
Hey guys. I do have an idea to solve this - not without some big change, but I believe a possible solution.
Left edge currently is used for the launcher and the drawer. What if we extend this to bring up the app stack too?
Usecase 1 - home = no app open:
- Launcher is open
- swipe up to 1/2 screen width -> drawer opens up
- swipe more than 1/2 screen width -> app stack opens
Usecase 2 - another app open:
- swipe 1/4 -> launcher opened
- swipe up to 1/2 screen width -> drawer opens up
- swipe more than 1/2 screen width -> stack opens
The distances will certainly need some fine tuning. But I think it should be possible to get this working.
With this change implemented, the right edge is free for a systemwide swipe to back.
Swipe maybe 1/3 (1/2?) of screen width to trigger the back action.
Maybe show a little icon/bar to give visual feedback for the user that he/she is triggering that action.
On release, trigger back. When swiping back to the edge, do nothing (=cancel back action). I think this is important to avoid unwanted back actions.Mouse could trigger that back icon/bar too. On click (or further swipe) back is triggered.
I am aware of the fact, that this would be a serious change in UI behaviour. BUT the length of this thread and the many many discussions about hardware buttons*1 do show, that this requires a solution. So it might be worth it.
1 I think mainly because of the missing back button. "Go to home" and "open recent apps" we do have sort of covered.
-
@danfro I understand your suggestion but I see further issues.
- I love my quick swipe from the right to switch between 2 apps. Where would you put that?
- The concept of "back" does not exist yet on UT. Each app implements them differently.
- This adds more complexity with the navigation.
To me, the solution would need to be implemented in the standard tookit used in UT /Lomiri. Then it will remain the app's decision how to implement the "back" function.
-
@kugiigi It certainly needs to be implemented into the standard toolkit. Otherwise it would not be systemwide.
Regarding the swipe switch between two apps. Hm, I did not think about that - because I do not use it at all.
It certainly adds some complexity. But I do see the need for a "new" back functionality. The back button is the action used most often - and is the hardest to reach.
Most people are right handed. So when using the device one handed, you have to go into the furthest corner to aim for a small button. Left handed (and using both hands) still the largest distance to reach.
-
@danfro said in swipe to go back:
The back button is the action used most often - and is the hardest to reach.
This is your personal point of view, probably shared by many.
While I may not be an example of a typical user, I have to point out that I almost did not use the back button.
Often there are swipe from the bottom or bottom bars instead, it's faster and more efficient.Except the messaging app, I don't see one requiring a frequent use of the back button.
And even for messaging, I tend to close the app frequently and open it from notifications.
So most of the time I never go back.I understand your idea but I order to find the best solution for you why don't you explain your use cases.
Because the answer you're looking may be within the app(s) you're using instead of an overkill imposed system wide solution. -
@AppLee
To be honest, I don't know how one can use UT without back buttons.Teleports, FluffyChat, Axolotl: leaving a chat I do Idontknowhowmanytimesaday => back button.
Dekko after reading an email going back to the list => back button
Closing Pages e.g. settings, new events, new contacts in most apps => back/down button
OpenStore leaving an app's page => close (back) button
Gallery leaving view of image to return to list page => back button
Music app return to lists from artist/song/album view => back button
Logviewer, returning from log to list => back button
returning to list from every system settings subpage and subsubpage => back button
...
That is the usecase I am thinking of.Name me apps (exept of Palitan) that feature a bottom bar that covers those actions. Name one single app (with more than one page) that works without a back button somewhere.
I do agree, that this CAN be solved appwise. But the back button is build into the toolkit. No coding required except implementing a header. There you go. If this is left to app developers, we will likely end up with 100 different implementations.
So if you don't see the need for a improved back solution, you are lucky. But I guess, you are amongst a few people that think so.
I wish I had a better idea for this. Maybe we can facilitate a dedicated area at the bottom for that. Say bottom right corner swipes trigger that action. Whatever app developers have coded into the back action, will happen there too. Sounds easier that it is I guess. Ok, getting desperate. sight I am lost for ideas. But I do still suffer from back-ness.
-
@danfro iOS doesn't have the "back" functionality right? How does it tackle this?
I think they implemented the "reachability" feature (or whatever it was called
) for those who really want to use one-handed? -
@danfro said in swipe to go back:
Name me apps (exept of Palitan) that feature a bottom bar that covers those actions. Name one single app (with more than one page) that works without a back button somewhere.
Domoticz, made by fabulous AppLee
I kept the back button for not frequently used features : settings, logs and advanced controlTeleports, FluffyChat, Messaging or Axolotl, I enter the chat using notifications and I don't need to leave as I close frequently those apps.
Gallery : why would you leave the picture view ; just close the app and open it up when you need it again. Because when I watch pictures, I slide them.
BTW this is the right example, I use more frequently the share button than the back button.
So which should we choose for a system wide share mecanism ?The system provides a back button in the header of the page, as a developer you can keep it, remove it, modify it. The system provides also swipe from the bottom so a developer can add a custom menu/settings/easy access to the users.
Nothing else needs to be done IMHO system wide.I understand your need for this.
But imposing a solution to everyone has to be carefully thought about.
If you consider the decision to remove the scopes it was long discussed and there are still some grudge hold... But people are moving on as it's become a reality and alternatives are made so they can have some convenience they would have lost (I'm talking about launcher modular)I'm satisfied with the features provided byt the OS. I think the best course of action is to keep the changes as minimal as possible. But it doesn't mean you're wrong and that apps cannot implement better solutions adapted to their specific use case.
To use the Gallery app example, I think using the bottom edge to display picture informations, and the different buttons would be a good idea...
And you can also use a long swipe to go back.I said my part, I won't argue more, but you're entitled to your opinion and I respect that.
Maybe a poll can be done if other back your ideas. -
@AppLee said in swipe to go back:
Maybe a poll can be done if other back your ideas.
When OTA 12 is released we will get an unofficial poll, lol.
If the user base revolts there may be a problem... but I feel most people forget UI metaphors like the global back button or home screen after using the UT for a little bit. I too felt them necessary once upon a time, but now don't miss them at all.
-
@AppLee said in swipe to go back:
Maybe a poll can be done if other back your ideas
In my opinion polls can raise false expectations. Unless the community is being consulted on a concrete choice with concrete implementation plans, it might be best not to hold them.
