Improve UX for android app

[zod]

The android app feels a bit alien to the android platform because it doesn't follow current guidelines for user design. Especially for first-time users of the app it's quite hard to get started as can be seen in the Google Play Store reviews.

The user experience (UX) for first-time users of the android app which discover it using Play Store and don't read any prior documentation should be improved. Therefore the design of the android app should be more in line with other apps and follow the usual navigation patterns. In addition there should be more documentation inside the app which explains the concept to new users.

To break down this task into smaller pieces this issue is intended to be a milestone/epic issue which collects other issues and pull requests to achieve this goal. The discussions should therefore only concern the overall goal and not some specific designs or implementation. To discuss any of those points listed in detail please create new issues or comment on a PR if it exists.

• [ ] Use android layouts instead of custom views
• [ ] Split views to fragments and use Navigation
• [ ] Add first-start wizard which explains app and configures profiles
• [ ] Add settings dialog to configure profiles and basedir
• [x] #413
• [ ] Migrate README to markdown and display in app
• [ ] Extend documentation available in app

[afischerdev]

It's true the app is a little outdated when you look at the design.

But in my eyes it is a tool of which the user mostly only sees / uses the download part. The main thing is that the parameter selection and more is done in external apps. The main focus is on the routing function.

If you think it's worth applying new design principles, please do so.

But we should release the current version (#312, needs a last little update) first and start with a new milestone.

[zod]

In my opinion it's not only about the looks but also how the user should enter the data. I agree that most of the operation is only via the service but the selection of routing profiles is rather complicated. While this is normally done only once for a new user it's still complicated.

I totally agree that these changes should be done after the release but I wanted to start the discussion to see if the goal is something that you think is relevant

[EssBee59]

Hello, I liked to describe a possible enhancement for further discussions: As mentioned above I think also, the management of profiles could become better and simpler. Enhancement A Most of my bike friends have big problems to understand, that the current profile is set in the Brouter and not in the navigation-app itself. So, for my usage I made an extension in Brouter and in my navigation-app (OSMAnd) to control the profile to be used from the navigation-app. Many reasons fort hat: simpler to configure, and I have to change the profile very often I am using the MTB, Fastbike 1/2/3, car, hiking … profiles AND … I created many variants profiles (as example with/without the option „consider_elevation ») (See attached picture) In my simple extension on OSMAnd the profile name for the Brouter is extracted from the OSMAnd-Profile name and send to the Brouter in the IPC-request. Further I send the option nogo yes/no, but in future this should be replaced by the nogo-list itself in order to get rid oft he API-10 version. Yes, a real challenge here is that an extension in the navigation-app´s is also necessary, and this have to be negotiated with the corresponding developers.

Enhancement B Today users that want to add or modify a profile have to use a file manager on their smartphone: It would be nice to get a function that help the user to create profile variants, as example based on the options defined for the Brouter-web in order to make simple modifications on a base profile (Example consider_elevation y/n

Of course, the current version should be released fisrt! Regards Ess Bee

[poutnikl]

Most of my bike friends have big problems to understand, that the current profile is set in the Brouter and not in the navigation-app itself.

This does not apply to LocusMap, which can directly choose Brouter profiles ( Brouter defaults, offline external, LocusMap Brouter online, LocusMap Brouter embedded )

[EssBee59]

Hello Poutnikl, Do we have a confusion here? Yes, I do not know LocusMap but... currently the Brouter do not accept a profile-name as IPC parameter. How can LocusMap control the profile to be used in Brouter? My description is possibly not clear: The goal is to set the Brouter-profile name in teh navigation-app, not in the Brouter... Regards

[poutnikl]

LocusMap (LM) is able to communicate the profile code via BRouter API, after close cooperation of respective authors. Similar advantage LM has ( or at least had ) is Brouter based navigation hints communicated via BRouter API as well.

P.S.: Unless there is a recent change, OSMAnd can follow BRouter navigation hints only when navigating along GPX track, generated with OSMAnd compatible hints by BRouter-web or local BRouter application.

[EssBee59]

Oh yes, you are right! This is another solution where the brouter profiles are managed inside the navigation-app. Thank for the information.

I think we have now all the informations to discuss the future possible enhancements. Regards

[EssBee59]

Hello

Till now, changing a standard profile or adding a custom-profile is a complex task (editing and saving the new .brf file in ./profiles2/. is only possible with a file manager)

I think, it is possible to add / change profiles in a simpler way, here an example:

• New profiles (when not available on internet-pages) should be created and tested using the Brouter-web (screen of PC is better, Brouter-web offers different ways to change a profile with options or full code)
• A lot of possibilities exist to transfer the .brf file to the Smartphone (Mail, Messenger, etc.. by need a special function using QRcodes)
• Now with a minor extention in Brouter-app, the .brf file could be saved in ./profiles2/. with a simple click on the attachement of the mail or messager

I tested successfully the necessary extention is the Brouter-app (add intent-filter in manifest.xml and a peace of java code to store the ,brf in ./profiles2)
Very easy to use… a further advantage is, no problem with access-rights (Android-11 !!) as Brouter itself store the .brf file

By interest I can provide my manifest and the peace of java code

Regards Ess Bee

[afischerdev]

@EssBee59 Great. I think it could be added to the current update #312. Not so heavy change. What do you mean?

If you like to make an PR please wait a minute to finish pending #351 and some other changes.

[zod]

Thanks for your feedback @EssBee59 To keep this issue I suggest to discuss the details of the changes in their own issues/PR and use this issue more as a general issue to track the progress of the individual tasks.

As @afischerdev mentioned the last suggestion is rather small, so perhaps it shouldn't be part of this bigger issue

[afischerdev]

@EssBee59 I'm ready for now. Will doing some more testing. If you like you could start.

[EssBee59]

Hello! Glad to get your positiv feed back! As I am not expert for PR, I put here the sources of my test-app. The change is simple, but a small integration with UI should be made to give the user a result of his action (succes or not) Regards See https://github.com/abrensch/brouter/issues/362#issuecomment-963366624

[zod]

Hi @Erlkoenig90, I just came across your comment in #244

The file-based router interface probably can't be made to work on Android 11, so this probably needs to be completely converted to a Service-based one. A prettier, more user-friendly and localized GUI would probably also be nice. To avoid a lot of complexity, it would probably be a good idea to drop some backward-compatibility, perhaps doing this as a 2.0 version, which then would only work with accordingly-updated client apps.

Would there be any interest to refactor brouter like that?

As you can see in the issue I'd like to update BRouter to a more modern UI and drop some legacy stuff on the way (like app specific coordinate readers). I'd still like to retain compatibility with older apps though. If (after almost two years have passed ;)) you still want to improve the BRouter android app we can try to tackle it together.

[Erlkoenig90]

Hi @zod , unfortunately I don't currently have the time to work on the project. Also Locus Map now integrates BRouter as LoRouter and automatically manages updates, which really simplifies the process already.