cyclestreets / mobileweb2011 Goto Github PK

... which makes the journey map undraggable, as the crosshairs create a large dead spot in the centre of the screen.

Suggested workaround: check for Opera with user-agent, and set the height of the crosshairs to about 40px. Probably the best we can do.

Would be nicer. Should namespace, too.

Need the HTML5 cache manifest installed, so that download times are reduced.

http://diveintohtml5.org/offline.html
has some useful pointers.

The native iOS app works the same on iPhone, iPod and iPad though is not optimised for the latter.

Therefore this commit
cyclestreets/mobileweb@2d0e29e
should be changed so that all three devices have the same behaviour, namely to advertise the native app.

The active state isn’t cleared on the other buttons

On m.cyclestreets.net I see you're using google maps API. It would be good if you could figure out how to show the OpenStreetMap credits alongside or instead of the google logo or terms of use. We need more examples of people doing this properly. Best I've seen so far is http://www.busitlondon.co.uk

http://www.cyclestreets.net/views/feedback/6565/

1. We have two favicons - one at /favicon.ico and images/favicon.ico - let's just have one :)
2. Should we add a bunch of apple-touch-icons as referenced in the headers? and what should these be?

Not good in landscape mode on many phones (okay in portrait).

Should adjust height of crosshairs to deal with this / rethink overall layout / enforce portrait mode?

On journey and photomap pages: code is running, and no javascript errors, but click events on locate-me and on route-type are simply not being heard.

Other click events (e.g. on instructions footer and on map) are being picked up fine.

Observed in Android browser + Fennec.

No idea what's going on. Probably need to ask jQM forums.

It should be fairly simple to extend the interface so that multiple waypoints can be set before planning a route.

It would work in a very similar way to the android version, like a stack:

The first tap sets the start.

Successive taps add new waypoints giving the option of either planning the route or adding a new point.

Remove simply removes the last waypoint.

The API is currently limited to 50 such points.

http://www.cyclestreets.net/link/formats/

has various link formats which would be nice to support on mobile as that's exactly the scenario where nice short URLs that avoid using an interface can be useful for more advanced users!

The mobile app is currently running blind. By this I mean that when a waypoint is set by tapping or by search by name, there is no attempt to locate the nearest point on the cyclable network. This leads to a lot of failed routing, similar to the report at #30 where undefined values are set for waypoints.

This problem is easily reproduced by setting a waypoint over the sea.

The enhancement is to use the API call at: http://www.cyclestreets.net/api/nearestpoint/ to snap to the routeable network before trying to generate a route.

Bug I observed on an Android device.

The map tiles weren't coming through (they did eventually), but there was no indication in the OS that the tiles were loading. On iPhone, if HTTP traffic is coming down, e.g. tiles loading, the OS top bar has a spinner showing this. Does Android have the same, and is there something we need to do to make it work?

Fennec (Firefox Mobile) needs "mouse mode" to be enabled before it can drag maps.

This is confusing for users who don't know about mouse mode, and annoying for those who do.

In fact, the desktop site works better in Fennec, because you don't have to move the map by dragging, you can put a marker anywhere that's visible.

What should we do about this? Options:

1. Auto-detect and redirect Fennec back to desktop site
2. Add a bunch of custom code for Fennec - could re-add our original draggable markers code, but it's extra code for everyone else to download, plus a maintenance overhead.
3. Just warn Fennec users about mouse mode with a toast message

I'm certainly leaning away from 2, given that Fennec is less than 1% of the mobile browser market: http://gs.statcounter.com/#mobile_browser-GB-monthly-201008-201108

Dependent on fix for cyclestreets/mobileweb#7

We're currently using beta 1 of jQuery Mobile. jQM just released beta 3, but I'd be tempted to wait until 1.0 comes out and upgrade then (it's currently scheduled for end-September).

I'll be happy to pick this up, to keep myself up to date with jQM developments!

Observed on Fennec and Opera Mobile, on both Nokia and Android. Not unusable, but not ideal.

Re Fennec support, see also: https://github.com/cyclestreets/mobileweb/issues/33

Shaun reports via personal email:

"I have just uploaded a photo through the mobile Web interface and it's given the photo a date of 1/0/1970. See attached screenshot."

This is the photo in question:
http://www.cyclestreets.net/location/44119/

I think the reason is that that photo doesn't seem to have any date info in it. (Download the original from that page and inspect.)

I have therefore tested it with CycleStreets' htc Wildfire Android, Feste to upload this:

http://www.cyclestreets.net/location/44120/

... which works fine.

We have interest from abroad in internationalising the apps.

So it would be good if we could soon get the strings moved to a translatable file, as has worked well with Cyclescape:

https://github.com/cyclestreets/toolkit/blob/master/config/locales/en-GB.yml

Experienced on both Android and Blackberry playbook.

Trying to drag the map sometimes causes the whole page to scroll either horizontally or vertically.

This is quite disconcerting when using it to pan around. I think that this is perhaps something to do with making the map fit fully inside the browser's viewport correctly so that scrolling should never happen.

This is the trickiest part of the project so far!

We set the map height by looking at window.height, but it seems mobile browsers are not particularly consistent about how they handle this.

Sometimes window.height includes the browser's address bar, sometimes it does not. This can lead to the map falling off the bottom of the screen in some browsers (observed in Fennec on Mac), or whitespace at the bottom of the screen sometimes (observed in Opera Mobile on Android).

Investigate and, if necessary, apply per-browser fixes.

Very important: the map is missing attribution in the bottom-right corner.

Basically should use the same strings as: http://www.cyclestreets.net/cyclestreets.js

... with Twitter links etc to full page.

Observed in Android browser. But working fine in Chrome.

Something to do with different browsers presenting the JavaScript Date object differently? Or simple caching? Or localstorage differences?

Investigate.

Just had an API request failure appear in our logs, caused by:

http://www.cyclestreets.net/api/journey.json?callback=journey&key=...&start_latitude=undefined&start_longitude=undefined&finish_latitude=51.777985&finish_longitude=-1.262946&plan=balanced&speed=20&_=1315953002289

(also, I wonder what the _= is?)

Basically add a directory function (i.e. Find places nearby...).

The long-awaited expansion of placestypes.xml is almost complete. Requesting placestypes.xml gets the list of keys, and places.xml gets the locations for that key.

Might be nicer if ordered by date.

Throughout CycleStreets we've stuck to Start and Finish to describe the ends of the journey. That says it perfectly: 'end' can refer to either start or finish.

Also 'Click' has been used rather than 'Tap'.

The interface says 'Click to set end' that should really be 'Tap to set finish'.

'Remove end point' => 'Remove finish'

There are probably other places too.

Reported:
http://twitter.com/#!/jugglerchris/status/111365421596282881

though it is beta.

Leave this bug report open till we know it works, or that Android Firefox non-beta is fine.

1. Should really be the three pastel colours used at the bottom of this flyer:
   http://www.cyclestreets.net/promote/#flyers

2. They also take up quite a lot of screenspace. I wonder if they could be squished to about 60% of their height.

3. Having clicked 'Next' to enter a route, they aren't really needed at that point. I wonder whether clicking Next should:

• Remove the Q/B/F buttons
• Remove the Home button and replace it with a 'Back' button that takes the user back to the selection screen.
  This would mean that following the route gets more space, and means that leaving the route is a deliberate action, one which currently can accidentally be done half-way through following a route if Q/B/F is clicked on.

"Full link to photo page (for tweeting etc.)"
is a bit wordy. I suggest

"Tweet this | Share on Facebook | Permalink"

with the URLs being

http://twitter.com/?status=Great+photo+on+%40CycleStreets%21+http%3A%2F%2Fwww.cyclestreets.net%2Flocation%2F%2F
(i.e. Great photo on @cyclestreets! http://www.cyclestreets.net/location// )

http://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fwww.cyclestreets.net%2Flocation%2F%2F

http://www.cyclestreets.net/location//

Where is the photo ID obviously.

We could even have nice 16x16 icons by making a copy from:
http://www.cyclestreets.net/images/icons/extras/facebook.png
http://www.cyclestreets.net/images/icons/extras/twitter.png

Note that http://www.cyclestreets.net/ rather than m.cyclestreets.net should be used, as we always want to make the www the primary link target, as www will then decide whether the user is mobile or not.

Add non-redirecting link to desktop site - in footer perhaps.

Make sure link to donate page does not redirect.

Shaun writes 16 Jun that:
66
I find that on the mobile photo map pages the photo is so low resolution that it is impossible to read what is in them.
99

http://lists.cyclestreets.net/mailman/private/mobile/2012-June/000625.html

and provides a screen snapshot.

Should be straightforward to move GET parameters into localStorage or cookies to tidy up our URLs.

[Mon Feb 06 15:25:01 2012] [error] [client 86.6.24.38] File does not exist: /websites/mobi/content/journey/favicon.ico

1. Go to home page
2. Go to journey planner via map page. Move map to a known location.
3. Click back to go back to home page.
4. Go to journey planner page again. Map position will revert.

Should be grey on black, not black on black

Occurs on the journey page when the instructions footer spills over to 3 lines.

When moving from 3 to 2 the footer height corrects leaving whitespace.

Only an issue in portrait mode on small screens but would be good to fix.

http://ipadpeek.com/
shows a problem that I've also found consistently on my iPhone.

On first load, shortly after the crosshair appears, it then moves about 5px or so to the right.

It then feels instinctively (though I've not measured it) like it's then not quite centred!

Share http://m.cyclestreets.net/ results in a poor link-extract because there's basically no images, just a pile of divs etc.

A simple solution would be to add the splash image to the very end of the front page so that users don't routinely see it, but so that Facebook and other sharing solutions pick it up.

Perhaps there is a better way to do this.

Could use 'heading' feature in geolocation to display direction of travel.

Definitely not urgent, post release.

There is no spaces in the user name field and I can't login. Using android firefox.

This is when following the upload form to upload a photo to the photomap.

Via email: On Thu, February 16, 2012 10:17 pm, Shaun McDonald

Several people have asked that individual photo pages have a map added - as otherwise they don't know where the picture was taken. This is mainly because of people following the Message Of The Day see the picture directly.

Perhaps use a static maps API of some kind just to get a map PNG?

On htc Wildfire saved routes page I'm seeing one route listed, followed by text: 'You don't have any saved routes yet.' and the button 'Clear saved routes' all shown simultaneously.

Also on entering this page I briefly see a white screen flash with '-->' at the top left.

Shaun sent this to the mailing list today:

The search by name on the mobile site doesn't seem to be working with the attached error on my Samsung galaxy s2 with ice cream sandwich in google chrome beta. The same problem occurs in the built in browser. Mobile Firefox fails too. I sometimes get to the page http://m.cyclestreets.net/route-without-js.php

I've easily reproduced it at:

http://m.cyclestreets.net/#route-by-address

Use fallback in cache-manifest, store journeys in localstorage, display saved journeys as text when offline.

Simple facility to add a route number. Submitting the form takes you to the URL for that number, e.g.

http://m.cyclestreets.net/journey/#1075111

http://m.cyclestreets.net/location/#9056
shows "0/8/2006" for the date, but the main site version doesn't have this problem:

http://www.cyclestreets.net/location/9056/
"Date: 2.57pm, 10th September, 2006"