Richard Fairhurst wrote:Watch this space.
I sure will...
Richard Fairhurst wrote:Watch this space.
Richard Fairhurst wrote:Yes and no! I've gone some way towards that with the interface at https://cycle.travel/map/mobile which is a little more app-like.
The big challenge I've found is that JavaScript map interaction tends to be very pernickety on mobile - the library used by cycle.travel (and everyone else), Leaflet, was originally developed for desktop use and is a lot less smooth on mobile than a mobile-first library. There's all sorts of really exasperating frustrations in real-world use: for example, I find that using the web interface on a cross-city ride, every bump in the road makes the iPhone think that I've shaken it so it blocks the screen with an "Undo typing" message! Each of these is ultimately fixable, but there's so many that to get a decent mobile experience I'd really need to rewrite the interface from first principles... at which point I might as well build a proper native app.
It's also harder to do offline mapping with web technologies than it is with a native app, and I think that's important for medium/long-distance rides - I'd like people to be able to download a whole country onto their phone.
The iPhone app is mostly there now - there's a lot of little details that need tidying up but the core of the app works well. Once I've got that released I'll port it to Android, which should be much quicker given that much of it can go straight across (the vector map styling, the turn detection algorithms, that sort of thing). Watch this space. :)
I would assume a native app must be more power/battery efficient than a web/javascript app (but that is a guess - I can't cite any tests on it). And battery life can be an important aspect to using a phone on a bike (even if just to get routes and load them onto a GPS).
Angstrom wrote:Using a smartphone as an "always-on" tool akin to a GPS device to display real time on-screen mapping and give turn-by-turn instructions will require tethering the phone to an extra battery or to a generator on the bike for charging, in my experience.
mjr wrote:Angstrom wrote:Using a smartphone as an "always-on" tool akin to a GPS device to display real time on-screen mapping and give turn-by-turn instructions will require tethering the phone to an extra battery or to a generator on the bike for charging, in my experience.
Not my experience. Turning the screen on only when it's wanted (near turns or only when stopped or only when prompted) is sufficient to let the battery last all day.
Vorpal wrote:mjr wrote:Not my experience. Turning the screen on only when it's wanted (near turns or only when stopped or only when prompted) is sufficient to let the battery last all day.
That depends on the phone, the battery, and what else might be going on in the background.
mjr wrote:Angstrom wrote:Using a smartphone as an "always-on" tool akin to a GPS device to display real time on-screen mapping and give turn-by-turn instructions will require tethering the phone to an extra battery or to a generator on the bike for charging, in my experience.
Not my experience. Turning the screen on only when it's wanted (near turns or only when stopped or only when prompted) is sufficient to let the battery last all day.
Angstrom wrote:I don't have an app that turns the screen on just approaching turns. If there is, I'm interested to know about it.
LittleGreyCat wrote:It would be nice if the software knew this and offered the choice, in the way that my car SatNav does - a prompt "this route includes a ferry" or similar. Cherry on the top would be adding "only open at weekends, summer, 11 to 4" to aid decision making for the hard of thinking such as myself.
However I don't know how this information could be incorporated in the mapping database.
Edit: I've just noticed that a ferry counts as a "track" for planning purposes. I can't decide if this is accurate or misleading for the local ferries. It does mean that you have to get off your bike so it may be a fair assessment.
RickH wrote:LittleGreyCat wrote:It would be nice if the software knew this and offered the choice, in the way that my car SatNav does - a prompt "this route includes a ferry" or similar. Cherry on the top would be adding "only open at weekends, summer, 11 to 4" to aid decision making for the hard of thinking such as myself.
However I don't know how this information could be incorporated in the mapping database.
Edit: I've just noticed that a ferry counts as a "track" for planning purposes. I can't decide if this is accurate or misleading for the local ferries. It does mean that you have to get off your bike so it may be a fair assessment.
Cycle travel does say in the instructions that you are going on a ferry - a prompt, at least, to look for timings.
cycle.travel ferry indication.JPG
LittleGreyCat wrote:Well, yes, I knew that the route was via a ferry as soon as I looked at the map.
I was thinking about an "are you sure you want to to that?" style of prompt.
Being used to car satellite navigation I tend to expect notifications such as "this route involves a ferry" or "this route involves a toll road" so that you are aware before you finalise the route.
At the moment it seems that you have to look at the detail of the route to pick up that there is a ferry involved.
Which can be vital, because in the example I gave you can end up with a route which is only possible at weekends in the summer.
At least if you are warned up front by a prompt at an early stage in the planning you can check when the ferry runs.