Introduce menu handling with one button
As introduction I've to write that I'm not really sure if we should add this complexity to the device. Besides the effort to implement this, the OBS should be easy to use and additional functionality always adds complexity for the user. At least we must do it as intuitive and usable as possible for a one button device. Looking at #28, #52, #53, #60, #86, likely others and the demand to switch between different presets stored on the OBS we seem to need such a functionality. Please share your thoughts.
Idea: Long press of the button (+1s?) is used as a different action than the current short press. If a long press occurs, the OBS goes to menu mode where you can cycle through menu items (short press) and select items with a long press. There can be a hierarchy of menus, 1st item is always < back (do we internationalize this?), there must not be more than 5(?) items on one level. Likely all functions will be paused while in menu mode.
The 1 char of the item shows the action < is back, > leads to a sub menu, * triggers a direct action, ? triggers an action after a additional confirmation.
Main
< back
? delete last
* mark private
> pause recording
> select preset
> info
> system
Main - delete last
Delete last overtaking
* yes
* no
Main - pause recording
Paused
< back
Main - select preset
< back
* Bike 1/Art3mis
* Bike 1/Parzival
* Bike 2
The preset contains things like the left and right offset, user id, ...
Main - info
< back
* version: v0.3.444
* 30 cm left offset
* 30 cm right offset
* 454 reports
* 5 sats
* 12:00 2020-11-24
* 3.2 V
* ...
* filesize: ???
* ....
(all actions go back to the active mode)
Main - system
< back
? restart to server
? restart
? halt
* demo
? erase
I think all of this would be sooo much easier with a second button. Here's an idea:
- Add a second button to the display case, a very small one, maybe mounted sideways or somewhere else, where there is space.
- Have it pull up the button line through a 10k R. This, combined with the 10k pull-down R1 on the PCB, should form a voltage divider at 50% VCC.
- Read analog values. As far as I can tell, the button is on pin D2, which is an ADC pin. Or am I looking at the wrong device?
- Now we have 2 buttons on one wire. No need to upgrade the PCB or the cable.
This would be a "hack" that the firmware can support easily. Then we don't have to mess around with the PCB, only adjust the case for the display slightly. It could even be optional.
I try to come up with a simpler solution here. A menu would allow very sophisticated things but also introduce complexity. From my view and the input of the listed issues, there are the following reasonable cases:
- [x] At device start I want to select server mode
- [x] In server mode I want to upload new tracks
- [ ] On the road I want to pause the recording for privacy reasons (Note: this is not be possible for the already recorded part, but you can switch off future recording for some minutes)
- [ ] At road mode start I want to select the to be used bike profile
- [ ] At speed == 0 display some statistics (could be last 5 pass distances; GPS quality; ..)
- others?
These cases can be detected via the context and if I do not miss sth. can be implemented in "simpler" way without menu.
Heyo, I have a new idea: A bootloader-style menu. You know GRUB? Yeah, like that.
When the device boots, it always shows the bootloader menu:
> Start recording
Run config server
Toggle profile [P1]
Just like in GRUB, if you don't interact with it, then the top entry is selected. A timer would show up in the bottom right corner (e.g. a little circular progress indicator). Pressing the button moves the menu selector one down. A little icon or so in the bottom left corner could indicate this. Contrary to GRUB, this does not disable the timer, but just restart it. After 3 or 5 seconds, the then active entry would be executed.
Pros
- One button operation, no need for hardware changes
- Does not affect button behaviour during recording or during server mode
- Does not change how to start recording (turn on device -> wait)
- Is way more intuitive than the current solution, where you need to know how to enter config server, the device does not teach you
- Extensible for further actions
- No more pressing the button while switching the switch on, which is rather complicated and not easy to do if you have only one hand (or only one free hand, e. g. while debugging)
Cons
- Changes how to enter the config server. Although we could consider changing the default entry on boot to be the second item if the button is pressed during power-on. Also, this change would IMO make it easier to enter the config server mode, so that's not necessarily bad.
- Adds a little delay to boot.
- Does not handle more complex operations than selecting a single action to perform (e. g. "toggle profile").
- This menu navigation pattern will not work during ride, as it is time dependent and you don't want to force people's attention to the device for navigating a menu while they are sitting on a bicycle in traffic.
Cons Does not handle more complex operations than selecting a single action to perform (e. g. "toggle profile").
Actually one could stack menus for more complex operations. e.g. "select profile" opens a menu to be navigated in the same style to switch between bike profiles (handlebar width) that are again selected via delay.
That is true. Or Change handlebar width could lead to a "menu" where pressing the button moves a slider around slowly and a number shows the selected value and then when you release and wait the value is committed ;) All kinds of complex menus behind that. But definitely not feasable for use while cycling ;)
I would suggest the following button action for menu navigation
- single press: navigate through menu items
- double press (like double click): enter selected menu item
But I 100% agree with @amandel having context based actions would be better than having large menus