Tag Archives: user experience

Default Profile Image

Posted on by

37signals decided to shift up their dull default profile image for a random one, assigned presumably on sign up, which is much more colourful. This is decent idea. Much more interesting than the grey silhouette.

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.

POST/REQUEST/GET Pattern in PHP

Posted on by

The “do you want to resend the POST data to the website again?” error message a user gets when they try to refresh or go back to a page really scares them. Understandably, since the browser often says “this could mean you’ll pay for the item twice!”.

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:

My Project is Unsuitable for Paper Prototyping

Posted on by

I was really looking forwards to paper prototyping, and read Carolyn Snyder’s (US) book. I was planning on creating my widgets and elements this and last week but keep running into problems…

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.

A fairly messy looking paper UI...

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.

Week 1 in the development of Sound Tiger

Posted on by

Just a quick run down post for what I did with my ten hours or so during week 1 of the year.

Sticking with my gantt chart, I spent the week analysing and reading a lot about user interface and user experience design.

There’s a lot of small aspects of design which people have put entire research in to, like a journal I read looking into if right handed people respond better when you treat their mouse as if it’s their right hand, and so have controls on the right hand side of the screen (they do).

After reading a few of these journals with their ideas, I decided to test them out in the real world and had a few of my friends fill out a questionnaire I made in a few hours. I got feedback which was sometimes a little surprising; almost everyone had bought music from within their media player (I was curious if a piece of software which has always been a media platform can easily translate its business model into a sales platform – they can, apparently), people rarely use album art as visual aids for navigation but they do still like to have them around to add colour to the player.

As a programmer — especially one who’s just read “don’t add useless parts of the UI” in many journals — finding out that some elements just don’t fill a purpose make me wonder why they’re still there, cluttering up the UI. Specifically here I mean the “genre” attribute. I know for definite that all my genre list either says “alternate”, “alt rock”, “alt” or is just blank. Most people agree with me, when asked how they felt about the genre column the majority responded “it’s almost always wrong”, or that it doesn’t affect what they listen to. Why is it still there? It’ll be off by default in Sound Tiger.

I’ve also seen how important it is to spend time writing a good questionnaire. Previously it’s been a method thrown together to look like you’ve done some research, and so I approached it the same lackluster way this time around too. I wrote in my natural voice, which is often leading. That meant the questions were biased where they should have been neutral. Although there was always an “Other” option, with a plain textfield alongside it, leading questions could be why the answers were often so uniform.

All my conclusions about my research have been talked about in my analysis of current media players. This isn’t complete to the standard I’d like it just yet. The Gantt chart overlord still says I have a week left, though I doubt it’ll change too much.

This week, I’m more excited since I’m actually getting down to technical stuff.

The project timetable for this week has me designing ERDs for the database schema for storing meta data about the music. I’ll likely start on some class diagrams too, specifically for each track, album, and artist.

I’ll also be doing some research into how I’m going to get audio to stream to the browser. This’ll have to be MP3 files predominately, in Firefox 6, IE 9, Opera 11, Safari 5, and Chrome. I know that there will be some licensing issues with MP3 amongst some of the more cautious browsers, so I’ll have to look around for ways around that.