August 1, 2012

Save Button? What Save Button?
Why Software Applications should behave like Video Games

Written for the Design For Use Blog

I recently had the opportunity to play Pitfall on the Atari 2600 (a game 5 years older than I am). To my delight, I was reminded of a time when video games didn’t offer “continues”, “save points”, or even passwords! There was only progress and failure (usually death). I had three opportunities (lives) to accomplish as much as possible before starting over, from scratch.

Since 1982 there have been significant advances in the technology used to develop video games. With the introduction of Internal Hard Drives came the ‘Auto-save’ feature. In contemporary Games, Auto-Save functions to (nearly constantly) save the user’s progress up to the point of failure. Sadly, failure (death) in most games which feature Auto-Save is now inconsequential. It is too easy to pick up where you left off, rethink your approach and then capitalize on some sort of newly acquired knowledge.

In fact, auto-save -- and the ease of overcoming difficult challenges -- actually creates a problem for gamers. They want to rescue the princess or triumph over evil…but they don’t enjoy it when it’s too easy; gamers like to fail.

“Failure is central to the experience of depth in a game, to the experience of improving skills. Studies support the idea that growth, the experience of learning, of adjusting strategies, of trying something new, is a core attraction of video game.”
Fear of Failing? The Many Meanings of Difficulty in Video Games


What Gamers have to say about auto-save

“I enjoy Autosaving because I can put down my controller and go do something else at any time. I don’t have to worry about reaching a savepoint or having to re-tread pre-trodden ground.”

“Today's games also offer embarrassingly little customization options for saving games. I want more save-file control in-game and less automation.”

“My biggest hang up are games that create a new file location every time they auto save as opposed to merely over writing it. However sometimes it's a life-saver to have at least one secondary load location.”



It’s important to acknowledge that playing Video Games and working in Software Applications are two entirely different animals. A Game, by rough definition is “The voluntary attempt to overcome unnecessary obstacles” (Jane McGonigal). Work, on the other hand, is defined as “exertion or effort directed to produce or accomplish something” (dictionary.com). It’s also worthwhile to recognize that both activities yield different Personas with unique short-term goals. According to Michael J. Apter’s reversal theory, people seek low arousal in normal goal-directed activities such as work, but high arousal, and hence challenge and danger, in activities performed for their intrinsic enjoyment, such as games (Kerr and Apter 1991, 17).




In addition to the primary differences between Video Games and Software Applications, the saving mechanisms of these two interfaces also varies. Here are two scenarios that have caused me a great deal of frustration: 

Scenario 1: I am working diligently on a project that needs to be completed by the end of my workday when: my computer freezes! All attempts at recovering my recent progress since my last save fail. I now have to manually re-do the work.

Scenario 2: I am making major edits to an open document when: I notice that I have made a critical mistake. I Ctrl + Z (undo) as many times as possible in hopes that the system has saved a state that benefits me. No dice.

When we fail while using Software Applications for work, we aren’t having fun. Losing progress is irritating, it’s stressful and a waste of resources. If succeeding in a game has become too easy, why is recovering from error while using Software Applications still so difficult?


Blue-sky Thinking: ideas for future functionality

In an effort to improve the user experience and overall satisfaction with software programs, there are many ways to improve the save capabilities. Below are a few ideas I played around with on paper while writing this post.

Retain “Save” and “Save As” Functionality (Soft Saves & Hard Saves)
Soft Saves are files being saved to the same location with the same name. currently realized as “File>Save”. A hard save is any time when you choose to save an open document as its own file on your computer. This is currently realized as ‘File> Save As’.

Introduce Limitless “Document States” (Auto-Save)
Regardless of whether you are working on a project which is an original or duplicated version, the software program should retain a history of user actions since the creation of the document. Users should have the ability to go back, all the way back, to the beginning. For example, a MS Word document could create invisible background data attached to each document, storing an unlimited number of user actions.
When creating a new document, Users should have the ability to enable or configure some sort of auto-save feature. It would be nice to have the option to specify the frequency of auto-save based on the system’s recommendations. If my hardware specifications are not blue-sky, I should be able to adjust the frequency according to the system or simply disable the feature. The settings for an auto-save feature should also be adjustable at any moment while the document is open. Think of this like an unlimited number of Edit>Undo, or Adobe CS Actions Window.

Show a Timeline
Another way to improve the auto-save experience in software applications is to include a timeline window or panel where users can review the changes they have made. This idea is half realized in Adobe CS within the Actions window, but it is not as useful as it could be. An auto-save timeline should also be treated with actual frames of the states the user has created. It would be gratifying to see some sort of iconography where the user has performed a Soft Save or Hard Save.

Finally, I would like to acknowledge that workflow, like gameplay, has come a long way. As with all domains, there are still rich user experiences yet to be designed, innovation not yet realized and many problems that have gone untouched or unnoticed. I feel strongly that Games and traditional UX medias have a lot to learn from each other. Moving forward, there is value in maintaining distinction between the two. It would be foolish, however, to dismiss Games as mere Child's Play just as it is equally foolish to assume that great things cannot be born in a word processor. Here's to hoping Work becomes a lot more fun, and Games a lot more stressful. Cheers.

Written for the Design For Use Blog

No comments:

Post a Comment