The relevant piece of CSS is this, on line 905 in the style.css:

.wp-caption .wp-caption-text:before {
 color: #666;
 content: '\2014';
 font-size: 14px;
 font-style: normal;
 font-weight: bold;
 margin-right: 5px;
 position: absolute;
 left: 10px;
 top: 7px;
}

Removing chunk will stop the dash appearing. However, this change will be overwritten when you update your WordPress next. The best way to fix this would be to make a filter which applies to the wp_head() function to output:

.wp-caption .wp-caption-text:before {
  content: none;
}

The CSS content attribute appends some content to the selector.

First make the animation you want to show, or just nab one from Ajaxload. Put that into a <div id=”loading_gif”> on the the page, where you want to to be displayed, and then set it to hidden.

You want the graphic to display when there’s an active AJAX request, and hidden when there’s not, and fortunately it’s incredibly simple by adding to the AJAX object.

Each element can be assigned a .ajaxStart() handler, which is triggered when the first AJAX request is started. (It only gets triggered once if there are two running at the same time.) The function you pass it here should be to unhide your loading gif.

To compliment that, once all the AJAX requests are finished, .ajaxStop() gets triggered.

$('#loading_gif').ajaxStart (function () {
   $(this).show();
}).ajaxStop (function () {
   $(this).hide();
});

The selector given when applying .ajaxStart and .ajaxStop doesn’t actually matter, and is only used to give context to the handler function.

But hasn’t this problem already been fixed before with Gravatar? As their blog post says, people don’t often have a picture they want to use right at the moment they sign up, so why not let them use the one they’ve chosen as their identity to the web? Let Gravatar focus on that business – and 37signals should focus on their business, which has little do with profile pictures.

For a company obsessed with efficiency, it’s a shame that they probably wasted a day on this “problem”.

Previous if you saw that a user was using the default profile picture you were forced to look at their name. This is fine, but the process would have been quicker if they had their own image to recognise them by. This doesn’t get fixed with assigning them a random one – what happens when two people get the same icon? This is slowing down fluidity, at the cost of a bit of colour. Jamie from the comments of that article says it well:

I learn over time to recognize Bill by his orange and purple generic icon. Then if Janice is added to the project and she chooses the same icon, I will, out of habit, glance and think her comments are actually coming from Bill.

Not as colourful, but Trello solves this problem by not actually having an image, but putting the user’s initials in its place.

The listing of members for the Fog Creek Software page shows a few members without avatars.

It also adds the possibility that a person can have a private avatar that can only be seen by those with the privileges to. If you want your work friends to see your photo, but not the outside world this fits really well.

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.