What I use my iPad for - one year later

Last year on April 3rd Apple released the iPad. I stood in line to get the new device day one and one week later I wrote a post here about what I was using the iPad for. Today marks the iPad's one year anniversary. So it's time to see if my usage has changed over the past year and if my usage patterns hold up for others.

Games

When I pick up my iPad it is still very often to play a quick game on it. It really is the perfect device for playing games: the screen is large enough to show a decent play field and touch controls are natural for many of the casual games that I've grown to like over the years.

The number one game for me of the iPad's first year has been Plants vs. Zombies. You can play the Flash/PC version of this tower defender game for free on this ads-supported site, but I only every played the $9.99 iPad rendition. It has quick play, mini games and a fun campaign mode that I must've played through half a dozen times by now.



Although Plants vs. Zombies by far ate the most of my time in the past year, there are many other games that I play or played regularly. There's the inevitable Angry Birds, which is nice but gets boring and frustrating for me after a while. It shares that problem with the beautifully made indy game Steam Birds.


Angry Birds


Steam Birds

You'd almost think I don't like games that are difficult, but I regularly play both Rush Hour and Sherlock as proof that that's not true. Sherlock is a classic puzzle game that my wife and I have been playing since the good old DOS (EGA graphics) days. Seeing it revived on iOS is wonderful and I gladly paid the $2.99 admission fee.


Rush Hour


Sherlock

More recently I've been wasting too much time with My Kingdom for the Princess, which is a time/resource management game with a very cute look. Click the link to play it for free on your PC. And Trade Nations has also been keeping my attention. I'm not sure what it is with these building games, but keep playing them - even when I've clearly mastered their mechanics.


My Kingdom for the Princess


Trade Nations

The last game that deserves a mention is Tiny Wings, which has firmly confirmed my suspicion that iPad games must include birds and physics to be successful.

Tiny Wings

Reading

After playing games I probably spend most time on my iPad reading. Instapaper is still a favorite, as ability to transfer web pages to my iPad with one-click (while improving their readability at the same time) makes it a killer app for the iPad in my book. If only I would spend less time on games, so that my reading stack would get somewhat smaller.



While Instapaper is great for reading articles, I still don't like the iPad as an e-reader for books. In the past year I read three books in the sames series: two on my Sony Reader and one on my iPad. The reading experience on the iPad is nice, with cool animations at times. But I stick to my opinion that lengthy reading sessions are simply less strainfull on an e-ink screen than they are on the iPad's LCD screen.

That said, the iPad has grown into my favorite reader for all shorter length reading. In addition to Instapaper I now also regularly read my RSS and twitter feeds on the iPad. While many people like Flipboard, I couldn't really get used to it and (for the moment) stuck with two specialized clients: Reeder for RSS and TweetDeck for Twitter.


Flipboard


Reeder


TweetDeck

Video

I wasn't too much into watching video on my iPad at first, but that has changed over the year. The iPad is of course great for watching video while on the plane, as long as you remember to buy and download the videos before boarding. But I also now use my iPad for watching video while exercising on my indoor rowing machine. Before getting an iPad I used to listen to audio books, but the iPad has solidly taken the Shuffle's place here.

Video from iTunes of course work great, but comes at a price. For the past few months I've actually been watching content from iTunes/U, which has lots of great material for free. For the techies amongst you: download CS193P and learn iOS programming while you exercise. This does by the way require the use of wireless (bluetooth) headphones.

Aside form iTunes, I also subscribe to Netflix and Hulu+. Although both have great content, I've been having some problems keeping the wifi connection stable while exercising. I have no idea what could be causing this as the iPad is literally less than 15 feet from the wireless access point. But I also haven't bothered too much figuring it out: iTunes/U for the moment has enough content to keep me "entertained".

Creativity

An unexpected category of apps doing well on the iPad are the creative creation apps. While the iPad has proven more a consumer than a producer device, this seems untrue of creative applications. Think of music creation apps (my favorite subcategory), image editing apps and video editing apps. The large multi-touch screen of the iPad has proven a great "build your own instrument/control" option for some of the more creative uses.

Although I don't spend nearly as much time in these apps than I should, I have a few favorites that I regularly return to. Everyday Looper is one of those. It is extremely simple in concept and user interface: you record multiple audio-loops in rapid succession. Doing this allows you to build a song in relatively little time. While I wish the app came with a few more features (such as repeating a "background" loop or creating patterns of the loops you've recorded) it is powerful already enough to keep me coming back every once in a while.

Everyday Looper

I really wish I could add GarageBand to this category. But unfortunately I haven't yet been able to test it on my iPad. The download from the appstore keeps failing. Maybe this will solve itself when I finally take the time to update my iPad to iOS4.

If you're more visually oriented there are multitudes of drawing and photo editing tools on the iPad. Given the gorgeous multi-touch screen, that was bound to happen. The image creation app I am most happy to see on the iPad is ArtRage. For a while I used this program extensively on my laptop, using a Wacom trackpad for drawing. Even though I've never painted in the real-world, the controls were very intuitive and precise. That this is in a large part to thank to the Wacom trackpad and its stylus becomes very obvious when you start using the iPad version or ArtRage. Although the interface is very similar, some of the more precise control is definitely lost. That said, it is still very much fun to use a photo from your albums as a background and start painting on top of it using water paint, oil paint of even chalk. The auto-color picker makes it incredibly easy to produce reasonable pieces of "art". Fun!


ArtRage

Work

The last category of apps I use regularly is sort of a mish/mash, but I think they all have to do with using my iPad for work. Only in the past few months have I started noticing that I tend to open my laptop less often in the morning. I like reading most RSS feeds, tweets and emails before I head out to the office. I used to do this on my laptop, but since early this year notice that I do this more and more on my iPad. The iPad is the ultimate media consumption device in this sense, which fits great with my morning pattern: I read/scan a lot, but respond fairly little - leaving longer responses until I get to the office.

Of course being a software developer means that I also use my iPad for development. Not for writing code (although I would love that), but to test if our software works sufficiently on mobile safari. Somehow my searches for "software to program for the iPad from the iPad" haven't resulted in anything too useful yet.

But since I bought a Bluetooth keyboard an iTeleport Connect, I can access the MacMini at home while I'm at the office. Using the keyboard for text input and the touch screen as a (not too accurate) mouse. While the experience isn't perfect, it does allow you to get some things done without having access to the physical machine. I can't wait to see what will happen when VMware launches their iPad viewer app. The iPad is completely silent, using very little power - it may well be the ultimate thin client.




Two more work-related uses, those are the last... I promise.

At one point I was about to board for a transatlantic flight when I got an email with the ever-interesting combination of question marks and exclamation marks: "why isn't this done yet ?!?!?" I had completely forgotten about a report I promised to write days earlier. The long flight and the iPad proved to be job-savers here: the flight was long enough to get a decent version of the report drafted before touch down and the iPad is small enough to fit in front of me on the table in coach.

Lastly I sometimes use my iPad for presenting. Our company is a Windows shop, so everything get prepared in Powerpoint. But once the PPTX is done, I drag it into dropbox, open it on my iPad and use keypad to present it. Now if only the projectors we use were as silent as an iPad...

Summary

So in summary I don't think my iPad usage has changed too much over the year. It's still the "computer" that is closest by when I want to do something for a few moments: whether it's a quick game, looking up a video that we're talking about with friends or doing some catching up on articles and blogs on the couch. It's taken over quite a few tasks that I previously used laptops for and has come up with new tasks that I previously simply wouldn't do.

Three ingredients to a better bug report

At work I've recently been going through lots of bug reports. It is part of my job to determine the priority of each defect that gets reported and whether we should still fix it in the upcoming release. With multiple testers trying to break the product in all possible ways and a deadline approaching rapidly, analyzing the newfound defects seems to take more and more time.

What did you see?

People entering defects can actually do a lot to reduce the time it takes to analyze their entries. You'd be amazed at the number of defects that say something along the lines:

• 
  "when I do A, B happens"
  

There are of course cases when this is all there is to say about a defect. For example:

• 
  "when I click the Ok button, the browser shows an internal apache error"
  

Granted, it would be more useful if the report said a bit more about the error message. But it is at least clear that an internal error message should not be shown to the user.

What did you expect to see?

Unfortunately things are not always so clear:

• 
  "when try to I delete the last item from the list, I get a message saying at least one item is required"
  

When I get an error report like this, I'm not sure what to do with it. Most likely there is an internal rule in the program that this list may never be empty. And the program seems to enforce this rule by giving a message when you try to delete the last remaining item. So there is a "business rule" in the program and the developer wrote code to enforce that rule. Where is the defect?

In cases like these I ask the person who entered the defect why they think this behavior is wrong. Typically I get an answer like:

• 
  "if I can't delete the selected item, the delete button should be disabled"
  

This added information makes things a lot clearer. So the tester didn't disagree with the fact that there should always be at least one item in the list, they just didn't agree with the way it was handled.

Why do you think your expectation is better than the current behavior?

But the above leaves me with a problem. There is a clear rule in the program that the list must never be empty. The programmer implemented this one way, someone else thought it should have been implemented another way.

In cases like these I ask the tester (or whoever reported the defect) to explain why they think their expectation is better than the current behavior. In the example we've used so far, the reason could be something like:

• 
  "clicking the button when there is only one item in the list will always show an error message - the delete action will never be performed. Buttons that don't lead to an action being executed should be disabled."
  

This is a clear - albeit somewhat abstract - description of the reason why the person expected the behavior to be different.

Prior art

In this example I doubt whether anyone will disagree with the reasoning of the tester. But there are many cases where someone will disagree. Especially the developer that implemented the functionality will tend to defend the way it works.

That's why I normally prefer the defect to point to other places where similar functionality is available in the way the tester prefers it. So in the example defect:

• 
  "in screens B and C we have a similar list and there the delete button is disabled if there is only one item remaining in the list"
  

This type of argument works especially well when the functionality in screens B and C has already been in a released version of the product. The users of the product have experienced the functionality and they will expect the new screen to behave in the same way.

If no similar functionality is available in the application, I often look for other programs that have similar functionality. On Windows the notepad application is one of my favorite examples. Everybody has it and the functionality as not substantially changed for at least a decade. Of course the functionality your program has might not be in notepad. In those cases I often refer to programs like Microsoft Office, Outlook, Firefox or the Google home-page. Not because I think these are perfect programs, but because they're so ubiquitous that most users accept them as a reference point for the behavior they expose.

Summary

So a bug report should at least contain the following ingredients:

1. What did you see?


2. What did you expect to see?


3. Why do you think that 2 is better than 1?

Now if everyone starts filing their bug reports like that, I will have to spend a lot less time on analyzing them and can get back to fixing those defects sooner. Who knows... maybe we'll make that deadline after all.

It's all about the data, not about the code

As I've probably told before, I administer (and contribute to) a few photo blogs. Since I wrote the software for the blogs a few years ago, actually most of the time I spend on it is small tweaks to the code. Adding a feature here and there. Nothing big, but enough to keep the editors happy and myself busy.

But recently I noticed that I've been putting of adding one of the requested features. And I wondered why. The feature in itself isn't very spectacular. The blogs work with a scheduled system, where all editors can see everyone else's posts. Since this is the holiday season, editors are sometimes planning their posts weeks ahead of time. And this can get confusing to the editors because it sometimes isn't very clear anymore where we are today. And something that also slightly bothered me is that some of our editors like to read posts from the administrative interface before they appear on the site. We even get answers to some of our "guess what" photo's before they're available on the public site.

It is time to do something about this. Like I said, it is pretty simple: don't allow the editors to see each others future posts in the administrative interface. So they should still see each others "old" posts, which is a great way to quickly find something you want to link to. But into the future, they should only be able to see their own posts.

The heart of the administrative interface is a table with a row for each post. It's very basic and the code is like:

    for each post
       write post to grid

Any half-decent programmer will know how to add the feature:

    for each post
       if (postdate <= now || currentUser == author)
           write post to grid  

But this is where it becomes problematic. The editors can sometimes also post on behalf of other (guest) authors. And of course, they should be able to see the posts that they created on behalf of guest authors. So the condition should be more like:

    for each post
       if (postdate <= now || currentUser == editor)
           write post to grid  

In here we added the concept of an editor: the person who created the post in the system. And this is not necessarily the same as the author: the person who created the content of the post.

This would indeed very easily implement the feature. One additional if statement and I'm done.

There is only one problem with it: I don't keep track of the editor of the post!

The information was never needed, so it has never been recorded. That means that I have about a year and a half of posts for which I don't know who the editor is. Which means that I have to figure out a way to either manually gather that data now (something I don't look forward to), add an exception for the cases where the data isn't available (resulting in uglier code) or somehow programmatically extract the information from the data that we already have. That last option sounds like the least manual work (both now and in later maintenance). But it means that I'll have to write code that touches all 500+ posts we have in the system.

When I realized this, I finally knew why I'd been putting off adding this feature. I don't have any problem modifying the code, even when I hardly use version control and backups of it. Why? Well, simply because I know that if I break it I can just as easily fix it again. That's the benefit of a one man software project. I wrote the code, so I know how everything works. But I am reluctant to touch the data. Why? Well I didn't write most of the data, so I have no idea how to restore it if I "break" something in that area.

This realization reminds me of something I always say to fellow developers: "it's all about the data, not about the code". The code can be re-written without any problem. All it takes is time and a developer. It doesn't even need to be the original developer, because a good set of data allows for lots of reverse engineering. But the data is often gathered from many sources. And if it's lost, it's lost. It will take much more work to find all those sources of data again, if it's possible at all.

Now that I've talked about it this much, I'll probably bite the bullet and add the feature anyway. I'll even do it the right way: by modifying/augmenting the existing data to include information about the editor in addition to the author field we already have. But I'll be sure to first do this in a development environment. And even when I know it works, I'll make some extra backups before applying it to the live environment. It might be a lot of work that is most likely not needed. But I'd rather do the extra work than run the risk of corrupting some of our precious data.