ubuntu-phone team mailing list archive

[Josh Leverette <coder543@xxxxxxxxx>]

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 <spencers1993@xxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sincerely,
    Josh