For a web guy, I've got a pretty rubbish website, part 2

To recap the last installment:

Most of the time, I don't have anything particularly substantial to offer the internet, and insubstantial contributions are best made on third party sites, not my own. Therefore this site lies mostly dormant. I don't add content to it very often, compared to how often I add content to other communities. Because there's no genuine bulk of content, there's no "return on investment" on the development work necessary to make this website something impressive, either technically or in 'experience' terms, and that also serves as a bit of a vicious circle. Knowing my UX / design is pretty unimpressive dissuades me from creating content... and round and round.

But there are still a few projects which I feel merit having a website and doing some bespoke development to deliver something beyond what would be possible on generic social media / aggregator platforms. Obviously in an ideal world this would be where I show off said completed amazing projects, but unfortunately I don't work that quickly, so it's more an overview of works in progress.

Flickr on Google Maps mashup

I'll start with the "most finished".

This was a classic case of "scratching an itch". As a means of "showing where my photos were taken on a map", flickr's map view has a glaring flaw, to render it basically useless in my opinion.

As shown here, you only get a dot on the map for each photo that fits in the 'active' region of the strip of photos along the bottom. Which, with the resolution I took the screenshot at, means 29 photos. I have many thousands of photos. I wish to see where "all my photos" are taken, not just 29. That's not even enough to show me where all my photos of one particular album/set are taken. It's rubbish.

Flickr map view

On the principle of never coding something that someone else already has, I had a poke around for flickr-on-google-maps mashups, and swiftly found This was almost perfect.

Only a few small grumbles: loading all those thousands of thumbnails takes literally minutes. Also, they're so big that it can decieve, suggesting that I've completely "covered" a certain area, when in fact, if you zoom in, I've only taken a couple of pics.

Mypicsmap view

What really did my head in, and pushed me to start coding, was the incompleteness of the photos loaded. I've illustrated this on the right, with a blended overlay of mypicsmap and my own "product", you can see there are heaps of dots where mypicsmap shows no thumbnail. As far as it's concerned I haven't touched the riverbank around Ham, or visited Ham House, or the modernist church, but as far as I know, I definitely have, and that annoyed me probably slightly more than is healthy.

With no way of plugging directly into the cache/database mypicsmap uses and knocking up some scripts to force population of the missing items, I set about making my own 'clone' of the entire thing. Given the straightforwardness of the flickr and google maps APIs, as well as existing helper libraries, this wasn't especially difficult to get up and running.

Mypicsmap view

The result of my labours is shown here, in comparable zoom to the previous two examples. You can clearly see how useless flickr is at serving the same purpose with its tiny handful of dots.

A slightly closer comparison to mypicsmap will reveal that the 'missing items' problem is fixed, and you'll see that I use much smaller dots instead of thumbnails, to solve the other issues that bothered me.

For those interested in the technical things, the build was pretty straightforward. The two aforementioned APIs do most of the lifting. Rather than hit flickr with 9000 API calls every time, I obviously cache things in my own mysql database. A thin PHP wrapper spits out the necessary data as json, which some javascript/jquery loads and uses to populate the map with dots of whatever colour.

My mashup map

The colours are determined by the control panel on the right. You can variously colour and filter by year, month or time of day taken, as well as tags and albums (sets). In all honesty, the only one I regularly use is colouring by year, but owing to the fundamental similarity of the operation required, once I'd written the code to do that, it was pretty straightforward to abstract it one or two more levels to handle numerous other options.

On a technical level, I suspect a pure javascript expert would find much to query in my code. Javascript being what it is, I'm sure there's a more elegant way of handling some of the 'metaprogramming' in there, where different parameters need to be compared in different ways in different modes (that is, in some I'm asking is A equal to B, in others I'm asking if A is in B).

On a UX level there is also much to explore and to be honest I probably need to write a whole separate blog item to do so, as this piece is already getting on and I'm not 1/3rd through yet. Suffice to say that this is a UI built to satisfy a personal itch, and it shows. It's quite fiddly and unpolished and I'd need to do a great deal of work before I went trumpeting this around as a 'thing' for public use. To quickly pick a few examples:

  • I have so many albums a list box is quite inadequate for selecting, even if it is alphabeticised. You really need what flickr provides internally, a list with 'autocomplete' as you type.
  • Handling of multiple modes simultaneous is not supported. That is, you can't filter by year (show only 2014) and then colourise the remaining dots by month. Worse still, the UI does not clearly reflect this. To do so, when selecting from the 'month' palette, the year palette could auto-select "off" and auto-disable / "grey out" sub-options to indicate it is now inactive, for example. I didn't implement this because if you dig into it there are plenty of nuances and edge cases of what does and doesn't make sense, what would or wouldn't be annoying, and at some point I want to add the ability to combine multiple modes, anyway.
  • The "time" mode is mostly useless because the data on flickr, despite my fastidiousness about correct metadata in most other regards, is really shoddy. Lots of 00:00 after a battery change that I didn't bother setting = umpteen wrongly timestamped photos.
  • The pattern of offering 12 options fits nicely with time, but is inadequate for tags, where some full list or (autocompleting) free text entry should really be offered.

Anyway, if you want to play around with it "live", it can be found here.

London hills

The next project I've been working on is an updated, expanded and newly bespoke-packaged version of my Skyline spotting from London hills piece.

It's one of the few pieces on this site to pick up a trickle of genuine traffic from google, and that's probably not surprising, because it's one of the few pieces of content with any actual substance, and probably the only one which covers a remotely under-served topic. There are bazillions of travel blogs with better write-ups of Slovenia than mine, but with London's skyline being relatively young / in-progress, I don't know anywhere else on the internet yet which similarly catalogues the best places to go and look at it.

My London hills pages in desktop mode

From a content point of view, it will be expanded in that I've visited several more excellent hilltop viewpoints since writing the original. From a presentation / technical point of view, there was really one key challenge I needed to get struck into: photo size. See, when I first cobbled this site together I made a few choices, some solid, some dubious.

Firstly, I decided that I already have all my pics on flickr, I'm not going to (re) load them all into this drupal CMS too. Duplication. Repetitive. Pointless. Use flickr. This decision was sound.

Secondly, rather than explore drupal's flickr module as a basis for a field in a custom content type, I decided to just paste in the HTML from flickr's embed photo widget, into my drupal content. I'm a web developer, I can handle a bit of raw HTML, no biggie right? This decision was poor.

Thirdly, I knew I wanted the site to be responsive. Specifically, to be readable on a mobile phone. Specifically, my mobile, since I didn't go buying any others to test it on. But with mobile viewers in mind, I was keen not to deliver huge pages. So when it came to embedding the photos via flickr's HTML, I settled on the small, phone sized 500px version.

Since I wasn't using an API or any fancy programming, just pasting static HTML, I was committing to this version everywhere. Even on large desktops. On one level this is OK: you can click on the photo to see the large original on flickr, which is almost better for me in that it encourages loggable views in my flickr stats.

But ultimately, for a photo showcase website, I want to be delivering my photos to eyeballs as large as possible. The current format for my 'articles' just doesn't do it.

At this point, I took the decision of again ignoring that flickr module, and doing it myself manually. This may yet prove unwise, again, but I suspect not. I don't really need the overhead of drupal for this. I'm not committed as a developer to doing everything in drupal, just for the sake of it. Such a stance may have much merit in a corporate environment where the need for other developers to maintain work in future must be considered. But nobody's going to be maintaining this after me, and even if they were, a standalone package of mostly HTML with a dusting of standard-issue jquery glue and PHP/PDO wrappers isn't a problem.

What I've got so far is a system which, when you click on any link to a flickr image, pulls that image ID of size CurrentSize from flickr via the API into a nice large "viewing pane" of CurrentSize within the layout. Except actually it doesn't because that's way too slow; I cached it all in a local database instead so it pulls the image HTML from there. Except actually it doesn't, because that was still too slow, I wanted the photo to change in an instant, so it preloads all the images from this cache into the DOM and when you click on any relevant link it just fiddles the DOM accordingly. Except then I started running into annoying edge cases where you click on one link while it's still loading other things in the background...

Anyway, in general it all works fine now in "big desktop" mode. But I still have to write my mobile layout / CSS (wireframe done, mentally, and for the special sake of this article I even MS Paint-ed it), and possibly do another breakpoint in between, and complete all the content (I've only written up about a quarter of the hills so far).

A basic wireframe of my planned mobile mode

London (trackside) graffiti

The final project I've been toying with, this one more at the mental pondering and online research stage than actual development, is how to write-up / showcase all the graffiti photos I've been taking.

It started, more or less, when I saw this, and surprised myself by managing to grab a half-decent picture of it through a moving train window:


See, before that, graffiti had meant two almost entirely separate things to me.

There was the style of artwork as seen in music videos, advertisments, documentaries about early NYC hiphop, and so on - colourful, skillful, intricate, crisp, playful, creative... generally impressive.

And then there was the illegal writing I saw on the streets, on trains, bus stops and so on. Which seemed almost completely monochrome, illegible, lacking in apparent skill, lacking in aesthetic value, and generally just vandalism.

But this - this was both at once. This had the colour and complexity I'd only really previously seen on legal walls and/or in the US, but it was bona fide graffiti, illegally painted in a dangerous location (an extremely busy train line), no studio job or "street art".

And so begun a mini-obsession. All the train journeys I was taking to go and photograph some skyscrapers, or a canal, or whatever London stuff was on my agenda, were transformed from dead space to a window of opportunity, photographically speaking. I watched keenly through the windows to notice new or quality pieces and attempting to photograph them.

It rapidly got to a stage that many would probably consider quite silly. To do a good job capturing these trackside works, while the train speeds along, you need to be prepared, ready to pan-and-scan before it's even in sight. You end up memorising where they are, learning the rhythm of each train route, "this bridge, that signal box and then that factory on the left after that has a ton of paint to capture..." You end up taking specific trains at specific times of day, so that you can not only get a window seat on the correct side for the day's targets, but have the sun shining on them, too.

Initially, it was as much about the photographic challenge of getting a usuable shot in these difficult conditions, as it was about the graffiti. But before long I was not only noticing, but appreciating and bothering to photograph the type of graffiti I was previously ignoring. Single colour stuff, basic tags: even the unimpressive "noise" above which the colourful and detailed pieces initially stood out, soon started to make a kind of sense.

And like the skylines thing, the other thing that stands out to me is the sheer absence of comparable info/content on the internet. It's actually kind of remarkable. Only a handful of blogs and forums, and they're mostly dead. Searching graffiti writer's names only finds three things: uncontextualised, unsorted photos on flickr and instagram, irrelevant nonsense, and, occasionally, a news article about them being jailed.

You can hardly find anonymous discussions, let alone interviews. The work stands alone in the real world, unsupported by any internet community obsessively building a comprehensive db or wiki of everything in the "universe", in a way which seems very uncommon these days, where every cultural movement seems to come with this online complement. In a way that's part of the appeal, but it does leave a "gap in the market", as it were, for an interesting (hopefully!) exploration of the topic.

Anyway, I'm getting ahead of myself here and writing the damn article, instead of writing the preview of what the article will hopefully do, from a web perspective.

The overall point is that I've avoided writing the article for a while because of indecision over the many different ways it could be approached. I initially intended to approach it chronologically (as I did above, pretty much). Me starting clueless, then showing stuff in roughly the order I saw it, and explaining how my knowledge and interest grew along the way.

But alternatives started to nag at me.

The actual experience of this work, in reality, was geographical. You travelled along a given line and saw one piece then another, different writers along the track. And the works relate to the particular surface / structure they're on - fitting the width of a bridge support, or splitting letters between arches, and so on. The "real" context of a given SOETA (for example) was that it was on the bridge support in Earlsfield, between a SOIR2 and a LAGER, not that I saw it in May 2014, a week after a COSA in Blackfriars. That's meaningless, surely?

And part of me thought this whole notion of "writing up" the graffiti scene of an entire metropolis (well, even the south half) was pretty stupid, particularly as a complete ignoramous on the subject, and maybe I'd be better off tackling it as a series of smaller chapters. Routes/lines are too big for that train of thought, so the obvious option would be focus on one of my favourite writers at a time, explaining the aspects of their style that I've come to particularly like.

Of course, this only sent me further up the garden path, wondering if it's possible to do some mega interactive presentation that lets you explore by any of these means of "slicing" - at once. Some kind of map view, or animation along a train, which can also be scrolled in time, and simultaneously filtered by name.... ahhh... no, come on, let's think "feasible" here.

Back to reality, I'm looking at some combination of text and pictures, which should be straightforward, but it's amazing how difficult it is to get the information architecture absolutely right, even when you only have two such incredibly basic types of content. As proven by my existing articles. See, the trouble is matching the length of text to the height of photos. Sometimes you might have very little to write: "then I came upon this stunning valley" - it's some random valley, it doesn't have a Wikipedia page, or deep history to ramble on about, but you have 8 photos of it. So by the time you scroll to the 8th (in my current layout), the one or two sentences setting up the location are long off the page.

Other times you visit a historic house which deserves a lengthy diversion into the story of its owner's life, but the house is not photogenic so you only have one token shot, meaning a long narrow wall of text with no photographic life alongside.

There's no easy silver bullet for this. In many ways it makes me wish I'd stuck with DTP and gone into print design, instead of hopping on the web bandwagon in the 90s. At least a piece of paper stays the same size once you print it. This responsive lark is great for information dissemination, philosophically speaking, don't get me wrong, but it's a pain in the backside for when you want to craft a "coffee-table book" kind of visual experience online and be assured it's of the highest quality regardless.

Thinking around all the options I've seen, probably the best toolkit for tackling this problem is Shorthand. If you don't recognise the name, you've probably seen it nonetheless. It's the thing where you scoll and there are big pictures that change as well as scrolling the text, and, oh here's an example, you know what I mean.

Anyway, Shorthand itself is not really priced for personal use, but I've had my standard sniff around for existing libraries and found that the likes of skrollr or scrollmagic should let me build my own vaguely comparable pages, with blocks of text pinned while multiple photos scroll, and/or vice versa, as the article progresses.

So, that's on my agenda for this website too. But first I do need to decide if I structure by time, line or writer...