The annoying thing is that I don’t need X-UA-Compatible on my web app. The only reason I need to use it is to stop Internet Explorer incorrectly telling people “this website is probably broken, you know. Click here to fix that.”

Websites, including html5boilerplate, appear to be telling people to use <meta http-equiv="X-UA-Compatible" content="IE=edge" />, which means to say “this is supported in every future version of IE, and current ones”. I don’t find that to be a sensible choice though. If you’re going to use this invalid meta element, why not actually have it work properly?

For Sound Tiger, I decided to set it to IE=9.

• Fairly old (Firefox 3 era) A List Apart article: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
• 456 Berea Street: X-UA-Compatible and HTML5

The first way to fix that is by sending all form data over an AJAX request. But if the user has javascript disabled then you’ll need to fall back to my next suggestion anyway.

The POST/REQUEST/GET (PRG) pattern removes that possibility by never allowing the user to fall onto a page which POST data has been sent to. Putting it simply, whenever you want POST data, you take it and then immediately redirect them.

You do the redirect by using a HTTP1.1 303, and although that sounds a little hacky it’s what was intended for that status to be used for.

You can see a gist with sample code here.

In that example I used a SESSION in order to give feedback. Although as a stackoverflow post points out, you could also send data back using GET variables (as the pattern truly intended). Sessions are handy for when you don’t want the user always coming back to the page, or when you don’t want to put sensitive data in the URL.

PRG is particularly important these days with single page Javascript applications becoming more popular. I came across this with my notebook application, where trying to refresh would annoyingly bring up “would you like to resubmit [your log in data]?”, which adds friction to the flow.

Further reading:

• HTTP Methods and Redirect Status Codes
• this has got to be the worst web usability problem that still exists today; do regular users have a clue what this means? – reddit
• Wikipedia article

I wanted to use this technique based on advice from my tutor to figure out if my UI is intuitive enough; I’ve managed to fit all the elements I want to show of the media player on one screen, and have missed off a few widgets (like the song progress bar, and length and genre information) which could be considered risky. It’s of wasting a lot of time coding I could jot the idea down on paper and ask a focus group of users to let me know what they thought of the idea on paper. Super quick, in theory. If they don’t like it, I can literally pencil the changes in.

It could also help with the flow of the application, removing the will the user understand that they have to click this bit of the UI to get to this page..? worry. You ask them to do a task (“Can you add a song by Coldplay to the now playing queue.”) and then see how they go about doing it. Was it easy for them? Could they instantly find the play button?

But as I mentioned, problems occurred.

The first issue was that I did it on paper. “Paper prototyping” is a misnomer, as paper is too light. Too easy blown away by a sneeze, and too hard to pick up to move around. You need something heavier, like card. This wasn’t an issue though, I could just get some card (I actually had a tonne of card stock lying around.) However, it meant redrawing what I’d already done onto the card.

The drawing was very, very hard for me. Simple boxes would end up being horribly unaligned, in such a way I couldn’t fit the rest of the elements on (which would easily fit on a screen when done with CSS). My play button looked more like an oversized equilateral when next to the badly drawn next track button. The book mentions, as well as everyone else, that good drawing isn’t a requisite. But it wasn’t something I could be any more than embarrassed about.

My ill fated attempt with recreating my UI on paper

I decided to try an do it all on Photoshop, and print the elements onto card. That’d get rid of my issues with drawing. I spent two hours today in a lab trying to use Photoshop to create an empty rectangle with a stroked edge. That’s definitely not a piece of software you can pick up and play with. You need training, which I can’t get and don’t have time for. This is not a rapid way of doing testing, like the book boasts.

My prototype would have to be fairly data heavy too; sample track titles and artists on individual bits for the user to be able to drag around. Once they move to another view, I’d have to spend a few minutes sorting on the paper, only for the user to potentially decide to “go back” and have to redraw it all again.

Paper prototyping is usually carried out by a number of people – at least three really. Snyder says maybe two, but that’s an absolute extreme. Pushing myself down to a session with just one person is incredibly hard, I expect.

None of these issues are issues with the testing method. It’s more a reflection on my constraints. All of them can be fixed with having more people, and one of them with marginally better skill at drawing sketched boxes. However, it is what it is, and I won’t be able to use Paper Prototyping.

I’m glad I learnt about it though, and will definitely be trying to use this again in the future when I’m in a team at work.

The need to group a set of songs by album is obvious when you’re trying to create a page which lists unique albums, and lets the user click through to view the tracks in the album.

When a user gives a set of MP3 files, all the data I have about the files is in the ID3 tags, and looks a little like this:

    array
      'title' =>
        array
          0 => string 'I Feel Fantastic' (length=16)
      'artist' =>
        array
          0 => string 'Jonathan Coulton' (length=16)
      'composer' =>
        array
          0 => string 'Jonathan Coulton' (length=16)
      'album' =>
        array
          0 => string 'Our Bodies, Ourselves, Our Cybernetic Arms' (length=42)
      'year' =>
        array
          0 => string '2005' (length=4)
      'encoded_by' =>
        array
          0 => string 'iTunes v4.9' (length=11)
      'comments' =>
        array
          0 => string '00001630 00000344 0000E27C 000031E5[...]
          1 => string 'From the soundtrack for the Future [...]
      'track_number' =>
        array
          0 => string '2/5' (length=3)

(That’s the data from Jonathan Coulton’s I Feel Fantastic, which you can download for free under a CC license.)

The similar data between tracks for each album are: encoded_by (not helpful, different tracks may have been obtained in different ways), comments (not helpful, same reason as encoded_by), year (potential candidate), album title (very helpful), artist (somewhat helpful).

None of that data is actually helpful to find a unique album since all the data may be used by another completely different album.

For instance, the album name alone doesn’t help; there are many albums called Resurrection. And even the artist name doesn’t guarantee a unique album; Westlife have two self titled albums, and two ‘Greatest Hits’ albums. Both of these cases can be solved by including the year though (though, this is assuming that the year is the same across the entire album).

It gets more complicated when you think of compilation albums; same album name, but many different artists.

For this iteration I’m going to focus on grouping albums by artist name, band name, and year on the track. Compilation albums won’t be supported in this three month development release, but instead they’ll show as a different album for each artist on the compilation.

I think that’s a good fall back because you can still listen to the music, and saves me a lot of time coding in work arounds for compilations and exceptions (which will have to be done in the second three months of development).

When I start a new class, like the Import one I’ve just been working on, I like to write out the methods with their parameters I’m expecting. This was easy this time, since I had class diagrams to follow, but usually this helps me notice logical inconsistencies in the way I think it should work. Then I quickly run through and fill out the methods with their general purpose.

At that point, I usually notice small bugs, or since I just want to have something to ship, edge cases which aren’t handled well. Typically I’ll add a double-hash-comment, like ## This will fail if we've not been given an absolute path. And then later, once I’ve done the main focus of the class I’ll do a directory wide search for ## and fix those issues.

I realised that’s a fair bit informal, and can lead to unexpected results if anyone but me uses the software. It’s easy to miss these comments if a search doesn’t pick up on them, or I forget to look out for them. They’re very much “out of site out of mind” issues.

That’s why I wanted a super lightweight bug tracker (though, my purpose is more of an issue tracker I suppose). I wanted to use FogBugz, but they don’t have a free version. Trac and Bugzilla are both too overkill, especially for a one man team.

Stackoverflow pointed me towards Unfuddle though.

Unfuddled dashboard for Sound Tiger

It’s much lighter than the alternatives, or at least the UI makes it feel less intimidating. Most importantly they have a free package for people with small teams, like me.

Also, which was a nice addition, they let me upload my git repo. That’s another place I can consider my software backed up.

For instance with a <pre> tag, trying to indent that nicely with the rest of your page will make the output shifted massively to the right. The only way to fix it is to have the pre tag the only piece of the source that isn’t indented, which looks uglier than having no indentation at all.

Which inefficient weirdos are debugging by looking at their source and not using Firebug anyway? In your editor you should have “highlight matching tags” turned on. It adds completely useless characters to the page, which are literally invisible. You’re paying for those bytes, and the user is being made to wait fractions of seconds (which Google ranks you on) longer.

Just stop doing it!

I’ve ended up using another player called jPlayer. (Demo on my prototype page.) It’s a jQuery library which uses HTML5 where ever possible but is able to fall back to Flash if it’s needed, like in Firefox.

The Flash player is invisible when you end up using it, and you control it entirely through the Javascript, which means your UI can be however you want it to look.

I was raving about jsMad, but it doesn’t look like it’s up to the task just yet. The people behind it are planning to spend more time on it in the future though, so that’s definitely exciting.

Hardware failure or loss of data is a constant concern since there are so many variables which make them so likely. It’s actually surprising how few cases of data loss I’ve come across. Between losing a flash drive, or a hard drive dying, or burst pipes destroying my machine, and the many hundreds of other ways which data can be lost, it’s always important to have a back up.

To guard against this risk though I’m using a distributed version control package (Git) to keep my code (and all my course docs) in a number of places, and all synced up at any one time. I have a repository on my laptop, on my desktop, and on my server. My server is hosted with AWS, and so is redundantly backed up by Amazon all over the world. To guard against bad administration of my server, and losing data that way, I have various snapshots of my server which I take once a week and keep for a month or two.

Another unlikely but constant threat is prolonged illness which means I can’t get work done on time. To avoid this I could make some lifestyle changes, like eating more fruit. However, if I do fall ill I have given myself a week at Christmas, and almost three weeks before the deadline which are empty on my Gantt chart. This time could be used to catch up.

An immediate risk is to do with the legal and technical issues around having the browser play an MP3 file. I’m not sure if modern browser support the playing of MP3 encoded audio files. This is an important issue since the majority of people keep their music in that file type. Without the ability for them to be listened to Sound Tiger will be almost useless.

Some quick research tells me that Firefox (my main browser, and so the one I most definitely wanted to support) doesn’t intend to add support for MP3 files. MP3 is a patent encumbered file format, but as is GIF and that’s still supported in every browser. Nevertheless, Mozilla have decided against adding support. There are javascript based tools to bring MP3 playing abilities to Firefox though. That means I’ll have to rely on the support of a third party library.

I’ve given myself a week of research time into the methods of playing audio though, which will including experimenting with that javascript library. If at the end of that week I haven’t been able to work out how to play MP3 files in Firefox I’ll have to withdraw support for it (as a user, and for Sound Tiger). Another way around this would be to attempt to convert the file formats into a more open format on the server, once a user uploads their music.

Ignoring the fact that I might not be able to use MP3 files for a moment, simply playing the files could be considered a risk to the project. The <audio> element, which would be used to avoid using Flash, is still fairly young both in the specification of HTML5 and in support for it with browsers. At any moment, a browser manufacturer could decide to withdraw support for it.

This isn’t very likely however. Other the past few years, most noticeably with Internet Explorer, browser creators are beginning to see that the way forward is a standardised web, rather than a competitive one. More browsers are happier to follow the standards set out by W3C. The likelihood of W3C removing the audio element is almost zero; and even if they did, the committee works so slowly there would be discussion of its removal for many years before anything actually happens.

I thin support for the <audio> element will only get more widespread, rather than revoked.

In the unlikely event, a contingency for this would be to use Flash, however. Despite the fact that I really wanted to avoid using it, as much is said in my project contract, it will be the ultimate fall back. This is also the case for if there is really no way to have Firefox play MP3 files.

All in all, I think those issues aren’t likely to crop up, and if they do I have thought out contingencies which will allow the project to be finished by the deadline.

Both these books offer really interesting ideas about the development process of software.

Inside RAD talks about rapid application development – making a piece of software in 90 days or less. This fits my project perfectly, since I wanted to have two release iterations of ninety days each anyway (I have until April, so that works out pretty well). It’s a quick, agile method which I’m really attracted too.

Paper Prototyping deals with the novel idea of having actual paper versions of your user interface, and then getting a few actual users to “use” the application in the medium. It allows you to see what a user is expecting to happen when they “press” a certain button, or see their flow of actions when you ask them to do something. You get all this user experience research before having even written a line of code. If you need to change something, you just rub it out and sketch in a new design whilst the user is still sitting there!

The issue I’ve come across with both of these methods though is that they are tailored for a group of people working on the project. RAD requires meetings and discussion from a number of people who are experts in their role, and then a scribe to take minutes. Paper prototyping requires a person to watch the user, and give instructions, and write down their actions, and also someone to act as the “computer”.

Whilst the ethos of both these methods will definitely help my project, and lessons will be learnt, actually putting them into practice needs to tweaking or outright rewriting of the techniques.

Regardless though, I’m planning on doing some paper prototyping in early December. I’ll likely have to train a friend to be the computer, whilst I take lead. I’ll also be sticking to the two 90 day iterations.