Activity stack improvements

[GoogleCodeExporter]

This might actually be a combined bug report & feature request, since I 
consider the back button behaviour as a bug. I already posted this to the 
mailing list, but here it is for better tracking.

The problem:

- The activity flow isn't intuitive.
- It's hard to understand how to access all tracks.
- The back button hardly ever brings you back to anything.

Proposed solution:

- The app should start with the "All Tracks" list activity. By
selecting a track from the list or by starting to record a new one,
the user opens the map view for the current track. This creates kind
of a hierarchical tree of activities (with map, stats dashboard and
graph view being 3 sub-views of the same 'place' within the app).

- The back button should work in a way that guides the user upward in
this hierarchy. (For example, when I am in the map view of a track and
then hit Back, I leave the application. I propose as an alternative
that the back button should guide me to the list of all tracks first.)

Having "All Items" as a starting point is pretty much what most
applications, be it web, mobile or desktop, have in common and it
seems to fit well with users general expectations.

The attachments show the proposed flow.

Original issue reported on code.google.com by marian.s...@gmail.com on 17 Nov 2010 at 6:00

Attachments:

• mytracks_activity_flow_2010-11-11.pdf
• mytracks_activity_backflow_2010-11-11.pdf

[GoogleCodeExporter]

Marian, we discussed this and here's our initial thoughts:
- We disagree that it should start in the tracks listing - the app should be 
ready to record as soon as it opens, since recording is more common than 
viewing tracks.
- The stack and back button already work that way in Android by design. If 
you're seeing something different, it's a matter of us reorganizing what 
activity is opening what other activity and/or how.

I'll let Sandor and Bart also comment since they were in that discussion.

Original comment by rdama...@google.com on 17 Nov 2010 at 6:53

• Added labels: Component-UI, OpSys-Android, Usability

[GoogleCodeExporter]

I agree, recording a new track should be right at hand. Please take into 
consideration that in my draft in issue 222 , recording is a very prominent 
button above the tracks list.

As for the back button behaviour, it seems to be consistent. But although I 
have used My Tracks for a while, I am still surprised every time when I'm in 
the Map view and pressing the back button closes the app. I thought having a 
real start screen which lists recorded tracks and allows for quick recording of 
new ones (plus maybe additional functions) would be a help. To me, the 
map/stats/graph view seems not really suitable for this.

Original comment by marian.s...@gmail.com on 17 Nov 2010 at 8:25

[GoogleCodeExporter]

IMHO:
1) It should be very easy to start/stop recording a track and it should be 
available on the first screen (I think this is currently both true for existing 
and proposed change). I just want to admit, that I'd personally prefer even 
faster access to start/stop, as hitting menu is already one extra step.
2) I like the proposed idea of having a central place with the track list (see 
below for a common use case in my case), however I think that after starting 
recording a track, we should switch to track progress/map window.  This creates 
a problem, because we should be able to easily stop the service from that view 
as well as start it from the main screen (as discussed in 1) above).

My common use case (while riding a bike):
1) Start MT
2) Start recording
3) Hit power button to make the screen go off
... (riding for a while)
4) Hit power button to check if the recording still works (I hope one day I 
won't need to do it :)
... (more riding)
5) Stop recording the track.
6) Share the track with friends (send an email). This step requires going back 
to tracks and selecting the most recent and sharing it.

This is a simple scenario.  In a more complex scenario, I check the map to see 
where to go, but I often to go GMM, as we currently don't support bike trails 
in MT.

For me, It'd be important to optimize 1) and 6).

Original comment by ba...@google.com on 17 Nov 2010 at 8:44

[GoogleCodeExporter]

I have to agree with Bart.  My typical use case is one of two things.
1. Start my tracks and start recording a new track. [This is not bad on the new 
version because drawing even a long old track is fast on most phones.]
2. Start my tracks and review/share the last track I recorded.

It is very rare that I look at any of my old tracks so I am perfectly happy 
making that use case a little bit more difficult.

I would be open to making this flow a different option, but I am not sure how 
easy that would be.

Original comment by sandordo...@google.com on 17 Nov 2010 at 5:48

[GoogleCodeExporter]

I'm with Bart and Sando too, with a variation, I'd like to see "edit details" 
dialogue move from after you press stop to after you press start instead or 
eliminated/simplified somehow. I find entering track details very hard whilst 
in an exhausted state. Coming back later (after a cool down/stretch/etc) and 
filling in extra details and sharing the track would be easier in my opinion.

Original comment by matt...@gmail.com on 24 Nov 2010 at 8:49

[GoogleCodeExporter]

Issue 260 has been merged into this issue.

Original comment by sandordo...@google.com on 6 Jan 2011 at 4:55

[GoogleCodeExporter]

Original comment by sandordo...@google.com on 6 Jan 2011 at 4:56

• Added labels: Priority-Low, Work-Large

[GoogleCodeExporter]

(just removing OpSys-Android label, all issues are in Android anyway)

Original comment by rdama...@google.com on 26 Jul 2011 at 1:00

• Removed labels: OpSys-Android

[GoogleCodeExporter]

Original comment by jshih@google.com on 5 Jun 2012 at 12:14

• Changed state: Fixed