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

My most popular blog post (a code snippet on how to fit all markers on a Google Map) largely is the only place that gets a response with the occasional comment. However, they’re usually “thanks for the help”, which I really do appreciate but I don’t feel that was the point of the blog post. Otherwise, it’s people asking for further support which I just can’t give over the comments of a blog post (mostly because people don’t check back).

Pingbacks – letting a blog know you’ve mentioned it in a post on your blog (WordPress does this by default) – seems the most sensible way to have a conversation online. It forces well thought out comments rather than spur of the moment outbursts.

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.

Bad UI: What the hell is this?

I had to install Opera to test something out, so this is the first time I’ve actually ever used it.

I’m testing the <audio> element, and for some reason I just assumed that this slider was an audio slider. I thought “oh, that’s quite smart actually” (there may be audio playing somewhere on the page, but you’ve no idea where, so just use this global or tab-wide one), but no it’s actually a zoom slider.

Who on earth uses zoom so much that it needs to have its own unlabeled part of the UI?