Since I got to test GPSapp for real this past weekend on some long previously unknown-to-me routes. In the course of doing so I got to thinking about what could be better, particularly from the usability aspect. Obviously my opinion is simply that, but I thought that I'd share some of my ideas as a starting point for further discussion.

I'm not really going to discuss known bugs or issues here; Jan has a handle on them already, and I'm going to assume that they'll get fixed along the way.

Modes.
Currently GPSapp has 3 modes. A satellite strength screen, a graphical route display screen, and a textual route display screen. The method of switching between them is a long 'down' press, with the textual route display locked out until a route is loaded. In addition, 'No route loaded' is displayed in the graphical route display until a route is loaded. (I think there is a bugette here anyway - it's a pig to get into that mode until you load a route, when it then becomes easy. But it's still possible. I'm not sure Jan intended for that mode to be locked out in a similar fashion to the Text mode or not. I don't think it should be locked out)
What I think that we need in the future is 4 basic modes;

1) Satellite Strength. Much the same as before.

2) Graphical Map mode. Basically the same as before. But I'd like to see the 'No route loaded' warning removed, or at least "#ifndef SOME_MAP_SUPPORT" in the code. The recent progress made by siberia37 with roadmapgps makes more possible the use of GPSapp with map data, hence raising the usability of GPSapp without a route. Perhaps the better solution would be;
if (!(MAP_SUPPORT && valid_map) || route) popup_display(No route or map);
but I guess that would be a change to the roadmap derivative of GPSapp rather than GPSapp itself.
I'm not going to discuss enhancements to the graphical display itself - for non-roadmap purposes it works well, and Jan's already heard some ideas for that.

3) Text mode. I can't see any changes needed.

4) Background mode. Similar to emphatic's background mode, GPSapp hands back most of the screen to the player. It would be cool if we could configure this mode to keep a small display of 'distance to next waypoint' in the top right of the screen.
Of course, I'd want GPSapp to awake before the next waypoint. (Assuming that a route is loaded). I think that the current pop-up happens a bit late sometimes, but along the same lines. I'd also want GPSapp to wake up if we go too far off-route. I'd be quite happy for GPSapp to wake to the last 'route' mode used (Text or Graphical), and for user input to be required to put it back to sleep, or maybe GPSapp could determine that we took the correct turn and then display the next directive with the distance to it before going back to sleep.

After this point, we should consider possible extension modes, e.g;

5) Map pan/zoom mode. Although this is really a roadmapgps request, I'll mention it here simply so we can discuss where to put it.

6) Location search mode. Same as (5).

This raises the question of switching between modes. I find the current implementation a bit cumbersome - the satellite screen is fantastic, but rarely used in-route whilst driving. I'd accept a little more hassle to get to satellite mode if it meant that switching between Text and Graphical modes were easier. At the same time, satellite mode is a useful startup mode. The proposed roadmap specific modes (5,6) would also rarely be used whilst actually driving.

What I think could work nicely would be to use a single knob press to toggle between the 2 'route' modes, use a long knob press or top button to go to background mode, and put everything else in a menu system, accessed through the down button from *only* the satellite screen. Pseudo code below;

switch (mode):
case Satellite:
L/R -> nothing.
Top -> background, return to hijack menu.
Bottom -> Open Menu
Short Knob Press -> Last route mode used (graphical if first time)
Long Knob Press -> Background, return to hijack menu.

case Graphical:
L/R -> Zoom
Knob L/R -> change waypoint
Top or Long Knob Press -> Background (hijack menu)
Short Bottom -> Popup next route directive and distance.
Long Bottom -> Satellite
Short Knob Press -> Text Route

case Text:
L/R, Knob L/R -> Scroll.
Top, Long Knob Press -> Background via HJ menu.
Short Knob Press -> Graphical.
Long Bottom -> Satellite.
Short Bottom -> 'auto-scroll to next waypoint', in case we manually scrolled away.

case Background:
GPS route event (eg approaching next waypoint) -> Awaken to last 'route' mode.
Selected from HJ menu -> Awaken to last 'route' mode.
*Note that buttons should be unbound here, so these are the only 2 events that we should care about.

case Menu:
Top, Short Knob Press -> satellite
L/R, Knob L/R -> scroll menu items.
Bottom, Short Knob Press -> Enter.
Long Knob Press -> escape menu, then background. (Just for consistency really).

case Menu_item:
Item-specific. Load menu works well as is (not sure if subdir support was ever added though).
For eg Roadmap Pan/Zoom mode;
T/B/L/R -> Pan.
Knob L/R -> Zoom.
Short Knob Press -> Satellite.
Long Knob Press -> Background.
...but that is specific to a derivative of GPSapp, and not GPSapp itself. The point is that the base modes of GPSapp are well defined, and new extensions can be added via the menu.


TTS and beeps
It would be cool if GPSapp could speak the turns. This would be especially useful in background mode. We already have sound overlay support within modern HJ kernels, so GPSapp would be able to talk over the music. For an easy small implementation, it would be possible to use a small vocabulary of pre-recorded pcm files played through pcmplay code. e.g, "Turn left" "1 mile", followed by "Turn Left" "Now" a little later. An advanced implementation would include dynamic TTS, but the current TTS implementation on the empeg is a bit resource hungry at the moment, so I don't know how feasible this is right now. Of course, some people may not want TTS, so we need some options. Another option should be to beep the user instead. The beep ioctls are in empeg_audio3.c in the hijack source, as are midi note definitions. With beeps we have 2 options; one is to use a static beep volume set within GPSapp. This would be useful for those people who don't use player beeps otherwise. The other option is to read the current player beep volume and then use that (should be in /proc/empeg_state, byte 0x11, bits 7-4 and byte 0x12, bit 0... needs further decoding though). Ideally we'd be able to select any of those 3 options.

In addition, it would be useful to beep the user with different beeps if the following happen; we go off route by x distance, we lose satellite comms or quality of fix deteriorates to a point where we'd care (for x seconds - we don't want to beep under every bridge), fix comes back, we get back on route, etc. We have the whole midi scale to play with, so finding distinct beeps that won't be confusing should be fairly easy.

We could also mimic player beeps (at player beep volume) within the menu structure if so desired. I think we should.


Anyway, I think that's probably enough to start the discussion...