Fail.
oooh, Flickr have a lovely new iPhone site (though it doesn't get lovely till after you've logged in).
Maybe I talk to Aaron too much, but I'm obsessed with geodata this week. So today the crazy mess of code that is jerakeen.org understands lat/longs on pages, and presents little 'has a location' links next to the tags (I've tagged this one with 'where I'm sitting' as an example). When I syndicate flickr photos, I'm pulling any geotagging data across as well, so you'll be able to see lots of geotagged photos as well.
In the same vein, I've added georss to the Dopplr journal feeds. Items are tagged with the lat/long of the tip or city that they're about. Trip items get their location from the city the trip is to. Not every item will have a geotag, but everything that I can tie to a location will do.
Feedparser (which I use to pull my Dopplr feed into jerakeen.org) needs a patch to be able to parse the GML properly (that patch doesn't apply clean to the 4.1 release on code.google.com, but can be bullied into working pretty easily). So I also pull the lat/longs of my Dopplr updates into jerakeen.org.
I have no idea what I'm going to do with this data. It just seemed a shame to leave it lying around unexposed. I've put it into my RSS feeds as well (I love django), so the stream feed can be dropped into Google Maps for prettiness. And eventually I'll make the 'has a location' links do something more interesting, I guess.
There's a common misconception that iCal uses WebDAV to upload calendars to remove servers. This bites me every so often, as I wrote the Dopplr iCal upload code and people tend to assume that if iCal can upload calendars, so should any other local calendar client that uses WebDAV. And they can't - things break.
iCal actually does the simplest thing that could possibly work, and I love it for this. You give it a upload url, a username, and a password. The calendar you're uploading has a name. iCal url-encodes the calendar name, and builds a calendar URL that looks like http://upload_url/calendar_name.ics. Then it does an HTTP PUT (authenticated with the username and password) of the contents of the calendar to that URL. Then it gives the url to the user and tells them that their calendar is here.
(As an aside, this means that you can upload more than one calendar into Dopplr, as long as they all have different names.)
That's it. Exactly one HTTP call, one verb (Well, ok, there's another verb. When you unpublish something, iCal sends an HTTP DELETE. But you knew that). It's a subset of WebDAV, which is why iCal can also publish to WebDAV servers. But I was able to implement 60% of the iCal upload feature in Dopplr during the tea break in the middle of the meeting where someone came up with the idea, because adding support for a single extra verb to a single extra path is easy. Implementing WebDAV? Harder to get right.
After my raving earlier I felt I should mention the new release of Byline for the iPhone. Amongst the release notes are:
- Adds a setting to increase the number of items loaded for each list from 25 up to 200
- Adds a "sort by oldest" setting for new items
Fixing the 2 most annoying things about it. Yay! On the other hand, Byline is a great way of blowing through terrifying amounts of bandwidth while on holiday. Oops.
update 14th october: they moved my screenshot link. Serves me right for deep-linking other people's images. And they've changed the look-and-feel in version 2.0. Curses.
I should write up 'things learned from taking only an iPhone to the middle of nowhere where there's no internet access'. One of those things was, I really want a 'that worked' for updating my twitter status using Twitterrific. And anything else that does a write over the network.
If a read operation fails, meh. But if I just wrote a twitter update, and it doesn't go through, I want to know. Twitter might fail, the app might fail, the connection might fail. I want success notification, rather than 1 minute of waiting for a failure message that might not arrive. THIS IS NOT A NORMAL SITUATION. But nevertheless. Maybe the rule should be 'avoid notifying users of success where success is expected'.
Another useful app - Byline is great when there's wobbly bandwidth - usable even when the only connection is a spotty non-edge GSM link. Admittedly, you have to just put the phone down somewhere with a connection for 10 minutes while it slurps. But things stay slurped. It'll pull the associated images of RSS items too, so I can look at my Flickr feeds easily.
It's got disadvantages - you have to switch to Google Reader to read your feeds for a start. In the absence of a local Mac GUI client to rival NetNewsWire, this is painful (Fluid helps). And Byline doesn't do 'folders' (tags? what does google reader call them? I'm new to this), so you just get a big flat list of unread items, which could be annoying if you subscribe to lots of feeds. I've recently gone through a grand purge of all my feeds and mailing lists, so my traffic levels are pretty controllable.
Except that my Economist subscription feeds did their weekly 'the magazine shipped' thing, and dumped 90 unread items in the list. And these are unread items that are interesting and might need reading. Unlike with the iPhone NNW client, I can't selectively drop subscriptions from being visible on the phone - it's all or nothing here, and Byline loads only 25 (I think) entries at a time for off-line reading. The Economist provides only a partial feed, so I had to sit where there was bandwidth and go through them in batches, 'starring' the ones that looked interesting then hitting 'fetch more' and waiting. Once I'd done this, and it didn't take too long, the experience was great - I had the full content of the Economist articles synched locally for convenient reading (and the Economist has a nice one-narrow-column layout that lends itself well to iPhone reading).
Until yesterday, Flickr's photo pages had a little bit of text in the bottom right, 'Place this photo on a map'. and taking this photo got me thinking about that. 'A' map. Not 'the' map. I was on the tube at the time of taking that photo, so I have no GPS fix for it. But even if I had one, it wouldn't be meaningful. I want to place that photo on the tube map, because that's where I was, between stations.
So this example isn't terribly good. But there are 'hidden' tube stations, or closed stations. I'd like to put photos of them on the tube map, because that's where they are to Londoners. I'd like to place screenshots of World of Warcraft on a map of Azeroth. Putting them on a real map would be useless, it would bear no relation to other photos taken nearby, and would be missing the point. For Londoners, the Tube is a different place from the surface, and tagging every screenshot I take with the location of my computer seems pointless. But I'd love an in-game 'photos taken near here' feature. (Not that I play WoW any more. Not this month, anyway.)
Kicked off by a conversation in a pub with blech and the flurry of geolocation stuff from aaron about Flickr's new croudsourced geolocation work. Which, alas, changed the language of the link, and undermined my point.
A curiosity of the notes application - it's got a really ugly font. But it can be forced into a less ugly one on a per-note basis using an international keyboard. I assume the Market Felt font isn't Unicode-complete, because if you insert a single (for example) Korean character into the note it'll change its font to something more sensible that includes that glyph. And it won't change it back if you remove the character.
This isn't exactly convenient, and isn't a system-wide setting. But I only have one or two notes on the phone, and I'm not willing to jailbreak it just to change the font. So I like my workaround.