You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The POIs, automated circular leisure routes, and promoted leisure routes, are quite hidden away now, being hooked into the marker-setting system. However, in the case of POIs, this is really something that is needed both for marker-setting but also browsing. In the case of promoted leisure routes, it's not really part of marker-setting at all, so needs its own top-level menu/tab entry. Similarly, for leisure routes, this is a great facility that is basically hidden away and should really be considered a separate thing to A-B routing, i.e. with its own top-level menu/tab entry.
There is also now the need to add in the GPS tracking layer (see #91).
So we're getting to the point that the app has too much functionality to be able to fit within the traditional apple '5 menu icons at the bottom' model. It's a real shame that things like the leisure routing is not very discoverable, yet is a highly innovative feature.
The Android app has been reworked last year to use the Hamburger Menu pattern, which means the left-side can have effectively an unlimited number of sections, though obviously there needs to be caution to avoid overload. The build file specifies which to enable.
The Hamburger Menu pattern does suffer a bit from lack of discoverability, and is seemingly going in and out of fashion, so it is not necessarily the perfect solution, but something like this needs to be considered. Though I'd rather we avoid the Google Maps model which basically seems to have buttons that launch functionality all over the place in a seemingly rather random fashion, but with a Hamburger Menu for layer toggling.
One option could be to enable the Hamburger Menu pattern but to have some kind of first-run/periodic-reminder type system that points users to it. But again that feels a bit non-ideal.
Either way, the app is now at the point where its expansion depends on resolving this problem.
The text was updated successfully, but these errors were encountered:
Agreed it's too cluttered but a hamburger menu is just the same issue with discoverability and context. My current thoughts are along the lines of tasks, i.e. create a new route, use an existing route, report and issue etc, this is the approach Citymapper have taken. this segregates non related functionality, promotes underused items while retaining the function-specific granularity of options. This is UX issue and requires some serious brainstorming as it will require significant work to do.
There are now quite a lot of available sections ('layers') available for different builds (CS, Hackney, CNS, future branded versions):
These are listed with screenshots at:
http://www.cyclestreets.net/services/customapps/
The POIs, automated circular leisure routes, and promoted leisure routes, are quite hidden away now, being hooked into the marker-setting system. However, in the case of POIs, this is really something that is needed both for marker-setting but also browsing. In the case of promoted leisure routes, it's not really part of marker-setting at all, so needs its own top-level menu/tab entry. Similarly, for leisure routes, this is a great facility that is basically hidden away and should really be considered a separate thing to A-B routing, i.e. with its own top-level menu/tab entry.
There is also now the need to add in the GPS tracking layer (see #91).
So we're getting to the point that the app has too much functionality to be able to fit within the traditional apple '5 menu icons at the bottom' model. It's a real shame that things like the leisure routing is not very discoverable, yet is a highly innovative feature.
The Android app has been reworked last year to use the Hamburger Menu pattern, which means the left-side can have effectively an unlimited number of sections, though obviously there needs to be caution to avoid overload. The build file specifies which to enable.
The Hamburger Menu pattern does suffer a bit from lack of discoverability, and is seemingly going in and out of fashion, so it is not necessarily the perfect solution, but something like this needs to be considered. Though I'd rather we avoid the Google Maps model which basically seems to have buttons that launch functionality all over the place in a seemingly rather random fashion, but with a Hamburger Menu for layer toggling.
One option could be to enable the Hamburger Menu pattern but to have some kind of first-run/periodic-reminder type system that points users to it. But again that feels a bit non-ideal.
Either way, the app is now at the point where its expansion depends on resolving this problem.
The text was updated successfully, but these errors were encountered: