Robot Has No Heart

On my Mum’s digital camera, when you look at a movie, you get a still from the movie and two options: delete this frame, delete all frames. Delete all frames does not delete all frames of the movie. It deletes everything on the camera. We lost all our Christmas photos, and also a photo of my cake which is kind of depressing.

Don’t use ambiguous or unclear terminology in your UI. “Frame” in my mind refers to a frame of a movie, but the camera used it to refer to a photo – this is likely a case of a system term seeping through to the user interface (or bad translation – it’s a Japanese camera I think).

My brother was impressed by the feature: “Hey cool, you can delete individual frames from your movie”.

Rephrase important decisions in the confirmation, and provide important information. “Are you sure you want to delete all frames?” is useless. Try “This will irrevocably delete all 324 photos and movies on your camera. Are you sure you want to continue?”. And always provide ‘undo’. It’s not that hard to have a ‘trash’ area, only permanently delete the files when you really need the space.

If anyone has any spare Christmas shots they’re not using, please link them up. Mum’s pretty distraught.

Poverty.com

The dynamic map in the header hits home hard, along with the real time death roll. Real people dying right now. This is a masterful example of boiling down your message and making it count. Even though they just make the names/photos up, it still works.

Found via FreeRice (partner site), a slick vocab game following in the footsteps of Ripple Search – get advertising revenue, donate to charity.

A recent post on the humanized weblog has got me thinking about mode errors in software I use often.

One particularly nasty one occurs on my Nokia 2100 phone when sending SMS messages. After selecting “send”, a box is displayed to enter the destination number. To select a contact from your address book, you press button A. However, if a number is already present in the entry box (if you are replying to a message, and in other circumstances whose criteria I am uncertain of), the same button A sends the message!

The implication? My reflex action is to press button A immediately after selecting “send” to go to my address book. Twice in the past two days there has already (unexpectedly!) been a number there, causing me to send a message to the wrong person.

What potentially embarrassing or disastrous mode errors do you deal with regularly?

Obviously, you have to synchronize your client data with the server. How do you do this when the client is entering data? A naive solution* might send the client data and refresh itself when a confirmation or update message is received from the server. This works great on local testing, but what happens when you are getting lag? The client will notice delays between them doing something and the UI reflecting the change – a Bad Thing. The UI must be responsive at all times. The way around this problem is client-side prediction. In most cases, you can assume that the user will enter “correct” data. Think about it – how many times do you enter invalid data into a game? This means that in most cases, we can update the UI to reflect the change as soon!
as it is entered, then we double check that our assumption was correct when confirmation from the server is received, and if not, rollback the changes.

Unfortunately, It’s not quite that simple. It will work if the confirmation consists of a complete data refresh, but often this is not the case. For reasons of bandwidth, usually only incremental changes are sent to clients. Consider the following example, where we are using client-side prediction: There are 4 donuts on a table. Clients can pick up a donut, but they may only hold one at a time. If they try to pick up another, their current donut is put back on the table. There is lag between the server and clients. Imagine the following chain of events:

1. Client picks up iced donut
2. Client picks up cinnamon donut (iced donut goes back on table)
3. Client receives iced donut picked up message
4. Client receives iced donut drop message
5. Client receives iced cinnamon donut picked up message

If we are blindly trusting updates from the server, by the end of this sequence our display will be correct. But imagine there is considerable lag between steps 3 and 4. At this point, the client will be showing that we have picked up both donuts, yet we know this to (most likely) not be the case!

One method of dealing with this problem involves keeping track of an “expected reply” from the server. This method assumes that a full data refresh is sent from the server on error (reasonable, since they are infrequent, and removes the need for sophisticated event histories). If we receive a message from the server telling us we have done something we know we have made obsolete (does not match the expected reply), we can safely ignore it. In the event that an error occurs (say, someone picked up the cinnamon donut before out message arrived at the server), we can rollback to the data provided by the server.

It is impossible to have the UI be correct at every single point in time, but using this method we have reduced the time to only when an erroneous action is made.

An easy way to test these sort of UI issues is to add a sleep(500) before the line that dispatches your messages in the server code.