UI Redesign

[developerfromjokela]

Hello. I have redesigned the UI as a whole. Old UI is still available by toggling a setting, but new one is modern and clean. Any suggestions/fixes are welcome.

Main improvements:

• Better UI elements
• Material 3 design
• Car visualisations now include car doors, charging port, headlights and spinning wheels when car is driving (only Roadster and Leaf A/ZE0 ported, other ones use old graphics)
• Simpler structure and all using NavHost + Fragments

Screeshots:

[developerfromjokela]

Issues #141 related

[dexterbg]

DFJ, welcome :-)

I like your new UI. We should get others to test it ASAP. I'd like to provide a test branch including a signed build for those willing to take the dive, but creating the APK fails with this error message:

/home/balzer/Android/Open-Vehicle-Android/app/src/main/res/layout/fragment_charging.xml:166: Error: @+id/startCharging is not a sibling in the same ConstraintLayout [NotSibling]
                app:layout_constraintTop_toBottomOf="@+id/startCharging">
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Explanation for issues of type "NotSibling":
   Layout constraints in a given ConstraintLayout or RelativeLayout should
   reference other views within the same relative layout (but not itself!)

I had a quick look at the new layout definition, but could not easily determine how to fix this without breaking things. Please have a look.

I also was about to write a list of bugs (crashes), but that will become a long list. Maybe you can better see what happens yourself and eliminate the majority of the crashes by adding some other vehicles in your test installation, which include App UI modifications, especially the Renault Twizy and the VW e-Up. There are also crashes on the Tesla Roadster, e.g. when opening the map config page. If you need test data, I can create some test vehicles on my server, but you'll see most of the issues already without live data.

On the Twizy, which remaps & extends the homelink functions, the "…" button does not open a popup, but immediately executes button 1 (that would switch a driving profile on a live Twizy).

When starting the App in the "old UI mode", the UI colors are broken, with menu entries and input boxes, and many labels being nearly unreadable (dark grey / black). I also noticed the App will always start in old UI mode when launched from the widget or from the service notification, regardless of the config.

I like the new messages layout, but I Setting the monospace option and changing the font size for the messages window does not work yet.

Generally, I mainly miss the direct info on the current range estimations & charge time predictions on the main page. These are essential infos for any driver, they should be displayed prominently. I think you tried to place them in the button, but that a) fails (too long, get cut off -- see screenshot) and b) is outside the viewport on many devices.

The six "main" buttons on the main page need to be vehicle specific, or better yet: user configurable. Many vehicles do not support lock / valet mode / climate control, and most do not use the homelink feature at all or map it to some custom commands, mostly climate control as a workaround for iOS users. For the Renault Zoe, the buttons can be configured to control EGPIO ports. An actual Homelink device is really only available on the Tesla Roadster.

Regards,
Michael

[dexterbg]

The "Minor fixes" commit solved the build issue. I'll now create a branch & publish the signed build.

[developerfromjokela]

I had a quick look at the new layout definition, but could not easily determine how to fix this without breaking things. Please have a look.

Hi. I forgot to push the layout fix :)

And about tests, please create other vehicles too! Would be highly apperciated. I've been currently testing on the DEMO roadster and my leaf. About actions on home screen, I will focus next making it customisable. Its structure is highly customisable by design so should be piece of cake.

I realised too when testing that range info was not the most convenient place to put. I plan to put there efficiency info from trip information and move range estimates near battery SoC.

[dexterbg]

Signed test build can be downloaded from here:
https://github.com/openvehicles/Open-Vehicle-Android/tree/test-dfj-ui/latest

Please spread the info to beta testers. Will you post a note on the developer mailing list?

[developerfromjokela]

How could I spread info? I am not aware of mailing lists :) please tell more about it

Edit: found the list, thx!

[developerfromjokela]

@dexterbg about charging time estimations not being shown, I've programmed them to be visible once car is charging up. You would like it to be shown even when car is not charging?

[dexterbg]

Yes, charge time estimations should be shown regardless of the car state. Users need to know these to be able to plan their next charge stop.

[developerfromjokela]

@dexterbg can you compile a new release? New version contains charge time estimations and most importantly customisable quick actions

[dexterbg]

Done.

[developerfromjokela]

I've now addressed many of the issues, see how it works now :)

[dexterbg]

Yes, much better already, you're very quick 👍

New issues found:

• With an e-Up, I've now seen MP command 204 being called once without parameters, I assume because the App had no config yet. That crashed my module, and I've just pushed the fix to the firmware repository. Basically, the API implementation is flawed, because there should be a Query command along with the Set command, but that has been omitted for the e-Up. For now, the Set command can be called without parameters, but only with an up to date firmware build. There is no real solution for this, other than fixing the API and App, which isn't part of your rework as it was broken before -- hopefully won't affect too many until then.
• With the Twizy, the profile buttons on the main page are mapped to wrong parameters, they should send keys 0…3, but send 0, 2, 3, 4 respectively. And they don't work at all in the controls page.
• With the Twizy, the selection status for the toggle buttons in the Logs fragment is nearly indistinguishable (color light blue vs. light grey -- very poor contrast).
• Speaking of contrast, I also suggest optimizing that for the battery backgrounds, as the dark grey on black is very poorly readable. Please keep visually impaired users in mind.
• Not sure about the new indicators for staleness, but I've got no better idea than the color coding used in the old UI, which also wasn't that self explanatory…

[developerfromjokela]

Yes, much better already, you're very quick 👍

New issues found:

• With an e-Up, I've now seen MP command 204 being called once without parameters, I assume because the App had no config yet. That crashed my module, and I've just pushed the fix to the firmware repository. Basically, the API implementation is flawed, because there should be a Query command along with the Set command, but that has been omitted for the e-Up. For now, the Set command can be called without parameters, but only with an up to date firmware build. There is no real solution for this, other than fixing the API and App, which isn't part of your rework as it was broken before -- hopefully won't affect too many until then.

• With the Twizy, the profile buttons on the main page are mapped to wrong parameters, they should send keys 0…3, but send 0, 2, 3, 4 respectively. And they don't work at all in the controls page.

• With the Twizy, the selection status for the toggle buttons in the Logs fragment is nearly indistinguishable (color light blue vs. light grey -- very poor contrast).

• Speaking of contrast, I also suggest optimizing that for the battery backgrounds, as the dark grey on black is very poorly readable. Please keep visually impaired users in mind.

• Not sure about the new indicators for staleness, but I've got no better idea than the color coding used in the old UI, which also wasn't that self explanatory…

It requests command 203 every time user open the charging page. The solution is not optimal, but it's mainly needed for querying charge stop mode, which doesn't come in car data. If you check my repo, I've implemented 203 for eUP. If that could be patched in main repo, I see no issues.

Stale indicators could be better, but I'd like to have some kind of timestamp for the state. Make a label that says ie. 10 min ago. This needs to be implemented in OVMS first.

I'll check twizy buttons, I think I checked the codes somewhere in old UI. Maybe I misread some of it 😂

[dexterbg]

The buttons now work, but the profile numbers are still shifted by 1. Btw, works correctly in the old UI mode.

[developerfromjokela]

The buttons now work, but the profile numbers are still shifted by 1. Btw, works correctly in the old UI mode.

strange. I checked numbers are correct. I'll try to log commands and see if I can get it recreated

Is this happening also in controls page?

[developerfromjokela]

Ok, figured it out :) It was indeed wrong numbers

[dexterbg]

New test build done.

I really like your custom action button option. But the custom action specification should not divert from the interactive user command syntax standard of the App as defined by the notification/command page and the OVMS.action.COMMAND intent. See: https://github.com/openvehicles/Open-Vehicle-Android/wiki/Command-Execution-via-Broadcast-Intent#interactive-command-execution

I.e. the standard mode should be text (= V2 "SMS" / V3 shell syntax). I also suggest addding the minimal syntax help from the command/notification page's help menu, and the placeholder of the command input, to make this obvious to users.

Users also normally have already created stored commands for their frequently used custom actions, so it would be neat to be able to simply select an entry from the list for a new custom action button alternatively to entering the command.

New issue found:

• When in "Modify quick actions" mode, opening the other pages is still possible, but the title remains and leaving the page crashes the App.

[dexterbg]

I've fixed the Twizy charts and added some missing german translations (not complete yet). Please pull my changes from the test-dfj-ui branch.

Not sure what still needs to be done before merging this into master, I think this is pretty usable now.

Regarding translations: you reused some strings that probably need a new separate instance for the new UI, for example text12VBATT for the voltage display -- if we assign that a better label for the new UI, it will break the old UI.

Also, some format strings need to be turned into translatable strings, for example the range estimation display due to the used abbreviations "I" & "E".

[dexterbg]

Not sure if they did before, but the custom actions should display the command result (output). Currently only errors result in a Toast. All text commands give no visible feedback, as the module always returns result code 0 on these.

Hint: you should be able to simply use the CommandActivity to handle the complete command execution. Just send it an com.openvehicles.OVMS.action.COMMAND intent as documented, it handles conversion of the user syntax, queueing with other commands & displaying the result.

[dexterbg]

Quick & dirty CommandActivity test:

class CustomCommandQuickAction […]

    override fun onAction() {
        //sendCommand(ApiService.makeMsgCommand(command))
        if (context != null) {
            val appPrefs = AppPrefs(context!!, "ovms")
            val intent = Intent(context, CommandActivity::class.java).apply {
                setAction("com.openvehicles.OVMS.action.COMMAND")
                setFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION or Intent.FLAG_ACTIVITY_NO_HISTORY or Intent.FLAG_ACTIVITY_NO_USER_ACTION)
                putExtra("apikey", appPrefs.getData("APIKey"))
                putExtra("command", command)
            }
            context!!.startActivity(intent)
        }
    }

→ works.

[developerfromjokela]

Quick & dirty CommandActivity test:

class CustomCommandQuickAction […]

    override fun onAction() {
        //sendCommand(ApiService.makeMsgCommand(command))
        if (context != null) {
            val appPrefs = AppPrefs(context!!, "ovms")
            val intent = Intent(context, CommandActivity::class.java).apply {
                setAction("com.openvehicles.OVMS.action.COMMAND")
                setFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION or Intent.FLAG_ACTIVITY_NO_HISTORY or Intent.FLAG_ACTIVITY_NO_USER_ACTION)
                putExtra("apikey", appPrefs.getData("APIKey"))
                putExtra("command", command)
            }
            context!!.startActivity(intent)
        }
    }

→ works.

Does it still show progress? Because underneath QuickCommand sendCommand it listens for events and updates progressbar in the quick action accordingly.

[dexterbg]

I didn't check for specific stuff the sendCommand() method does, it was meant as just a quick code example. As it switches to the CommandActivity opening an overlay UI as soon as a result is received, I'm not sure the progressbar needs to be updated at all. The progress bar becomes invisible, and is gone when popping down the overlay.

[dexterbg]

But the still present bug of the App thinking it has no data yet (staying in "Loading data" until the next update) becomes annoying with the activity switch.

[dexterbg]

The new UI seems to be pretty stable now, been using it for 3 weeks.

I'll merge this now, so we can continue on master.