Why do you need a back button at all in the email app? I can actually think of a number of effective implementations that don't require a back button -- not even to return from viewing an email. However, if an app is making such extensive use of the back button, there's nothing stopping the developer from putting their own alternate implementation in.
One reasonable option which requires no tabs. Option A: Using expansion<http://design.ubuntu.com/apps/building-blocks/expansion>, users could quickly inspect various emails, marking them as read in the process. If the user wishes to see the email in the full context of the thread (and not just the unread emails in this thread), they can tap an "open" button that dynamically generates a new tab for this email thread and lets the user scroll through it all and reply accordingly. If, for some reason, we're unable to show complex (HTML) emails in the expansion context, then tapping the "open" button would also allow for a 'correct' visualization of the email's contents, beyond mere text. Closing the tab would be as simple as hitting an 'X' in the top right hand corner of the email view. The user could then open several full email chains and switch rapidly through them using the native Ubuntu touch tab system, allowing for unprecedented productivity with a mobile email app. On tablets, they could take the iPad/Android approach of having the list of emails on the left, and the full message body/thread context on the right, with an open button to allow similar functionality on the phone version, but it doesn't scale perfectly to tablets. This design took me all of five minutes to come up with, so it could definitely use some refinement, but the phone-size version of it seems like a perfectly valid option with no need for a back button. Option B: Rather than having an "X" and allowing all emails to persist as long as the user wants, there could be a dedicated "viewer" tab showing the most recently opened email and its context only. This is admittedly less complex, and probably more scalable between phone/tablet/desktop. Option C: We could make use of the above mentioned expansion, and then follow the "open" button up with a dialog<http://design.ubuntu.com/apps/building-blocks/dialog>context containing the full thread context and HTML rendering of the email. Once the user is ready to move on, they could hit reply or simply exit the dialog. Hitting reply could either move to a different dialog context focused on responding, or (better), it could open a new Ubuntu touch tab for composition and exit the dialog. The back button is a crutch in most designs, since there is usually an elegant way to avoid it. Sometimes, the back button is necessary, and that's what it is there for. If the back button is extremely pervasive inside of and necessary to an app, then a persistent toolbar (one that doesn't need to be swiped up) could be used while not at the top of the page stack. *So can we please drop this subject?* Until the day that Ubuntu touch is overrun with back button UIs, the only thing this discussion is getting is old. *75 emails about a back button is just crazy.* Especially when the back button is not going to be used like the one in Android is. On Mon, Jun 24, 2013 at 4:45 PM, Michael Spencer <spencers1...@gmail.com>wrote: > On 06/24/2013 03:47 PM, Zisu Andrei wrote: > > Too many places, variations and bla. I urge the design team to find > > only ONE size fits all, as long as it adresses Android's ugliness. > > > > That's the biggest difference between iOS and Android: consistency, > > you only have one "paradigm" that you use to get back in the app, and > > one home button you use to get back to the screen. > > I quite agree that ideally there should only be one way to go back. > However, having the back button in the toolbar is my opinion is really > cumbersome. I've been tinkering around with ideas for the email app, and > already I'm tired of having to swipe up the toolbar, click the back > button, swipe up the toolbar, and then click the back button just to get > to the top level. > > I would definitely recommend having a back method that requires only one > click/tap/swipe to operate. Concidering how the title of the page is > displayed in the header, I think that would be a good place to put it. > However, that would require a different place for the back button in > fullscreen mode. > > In my opinion, I'd rather have the back button in the header for regular > mode, and placing it somewhere else for fullscreen mode, even though > this would result in two methods, because they would be two standardized > methods that always work in their corresponding modes, and would be a > lot easier to use and more obvious than putting the back button in the > toolbar and requiring to open that just to go back. > > -- > Michael Spencer - ibeliever.github.io > > Trust in the Lord with all thine heart; and lean not unto thine own > understanding. In all thy ways acknowledge him, and he shall direct thy > paths. > - Proverbs 3:5-6 > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- Sincerely, Josh
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
