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...

There is something wrong with mozilla/css or fonts on my laptop, so I can't give a really long response (basically I'm typing blind now)

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.

Switching can also be done with 'down-left-down' i.e. there is a menu-option 'sats/map/text'.

Also the text screen is not locked down, that is the one that shows the no route loaded message. The graphical display has the large speed digits on the right and shows the track we've followed.

Ahh...that makes sense.

shameless bump.

The patch seems to be missing.

Oh, Thread is opened, so my 2 cents:
I tried GPSapp every day with new routes (I'm driving much) and have an iPAQ for comparing. Well, the iPAQ does the job better. Today :-). I would really appreciate voice messages and simply a pointer to my destination like:

---->
I
I
I

Alsong with the voice I won't need many graphical items (but anyway they are nice!).

Rolf

New versions Roadmap- the program I've been merging with GPSApp- does have support for saying the names of roads at intersection. Unfortunately it has no route finding/following engine yet so it might be difficult for it to say "turn left" etc.. but that should be a possibility for the future

I am going to merge GPSApp with a new version of Roadmap soon but Roadmap releases have been pretty frequent so I'm kinda waiting for them to stabilize.

I’m still using the first version of GPSapp+RoadMap, and I don't really have any complaints, yesterday I had a wedding to attend, 183 miles away, with specific directions, it took me about 30 minutes to plan the route, with intermediate destinations on maposnus.com, finally got it to take me on the exact route for the directions I received

My vote is this is the coolest 3rd party, most useful program yet. I had full maps on my whole trip, and didn’t get lost once. I just didn’t have time to setup a return route

Any chance in releasing, one of your builds, from updated roadmap sources? I just checked out their website, and it looks like they are waiting for the 2003 map data now to update their map sources, then 1.0 should get released.

I've got an all-day-drive trip coming up next weekend, and I've already got the routes programmed into GPSapp and all is well.

But I realized something... I still have to print out paper directions and have them ready just in case. The reason? Reliability.

GPSApp still has that bug where it locks up and stops responding to key input after it's been running for a long time. I know this when it happens because I hear the music hiccup once and then the display freezes.

The last trip I took, it happened just two miles short of a critical turn, and I hadn't made the mental connection between the music-skip and the GPSapp lockup. And since I was on a straight freeway at the time (just a straight line on the screen), I didn't notice that the screen wasn't changing and the speed wasn't updating. So I was blithely cruising along at maximum freeway speed when the exit came up. Probably would have kept going straight for another 20 minutes if a nagging thing in the back of my mind hadn't told me that the exit name looked familiar.

i also noticed this on my trip, it was only a 2.5hr drive, but i was thinking it was just my crappy junk gps receiver in my nextel phone, sliding all over the dash board while turning, and accelerating.

Or when i would skip songs with the remote control, it would cause gpsapp to freeze until the player stopped reading the song from the hard drive. Luckily I had a good down-down-down shuffle and not one of those not random enough shuffles

But every time gpsapp would freeze, it would resume within maybe 10 seconds at the most. I didn't have a complete lockup, but i also left gpsapp active on the screen, and only used the remote to change volume, and skip tracks (slowly, i would wait for gpsapp to update my speed, then skip to another track, then repeat)

Also, are you using just gpsapp? or gpsapp+roadmap?

Just GPSapp. And it's a complete lockup with no recovery, not just a caching pause. The music keeps playing but the front panel buttons stop responding to input. It's always preceded by a skip in the music, and it only ever happens after GPSapp has been running nonstop for a long time.

I've noticed this too with GPSApp- but the broder issue I notice is that Hijack seems to have a problem when user-land apps crash. When I'm debugging GPSApp+Roadmap and it crashes (happens alot right now)- the userland app screen will just sit there- and the music will play in the background. There is no way to get the Player's screen back unless you do something to force hijack to display something on the screen like issue a "exec site rw" from ftp which causes a pop-up to appear. I think it would be nice if hijack could notice and respond to userland app crashes.. Mark are you listening?

Actually, I've been looking into that problem.

What seems to happen is that the player seems to restart or reinitialize for some reason. The serial port settings are actually changed, and hijack notices the player restart and seems to forget about the bindings for the userspace app. Because gpsapp isn't getting anything from the serial port (wrong baudrate) and isn't seeing any key presses, it just sits there, frozen.

I could also be completely wrong, but this is what I had one time it froze up. Gpsapp was still running just fine, waiting for input that never came.

Sounds logical.

However, I'm not sure it's the exact same thing that I've experienced. You say that the player app restarts. But if the player app restarts, doesn't it re-load the music databases at that time? In that case, wouldn't it be about a 2-3 second pause in the music? When it happens to me, the skip in the music is brief, just a slight blip, less than a second.

But if the player app really does restart that quickly, then this does sound like exactly what's happening to me. I wonder why the player app restarts like that? Never does it in normal playback, only after I've had GPSapp up and running a while.