As we get ready to start the Spring 2010 semester, I should get working on my resolution to write more reflective pieces! This is inspired by a desire to “practice what I preach”—specifically, being a reflective practitioner. In my case, I see that as being relevant to higher education and software development, among other things.
Yesterday, I published an application on the Android Market called “Connect The Dots”. It’s a simple dot-to-dot application that is briefly explained over at http://sites.google.com/site/androiddots/. (By the way, you are encouraged to add the “La la la la!” after singing the title of the application.)
One reason for making the application is that my son, who is nearly three, seems to enjoy dot-to-dot puzzles, as I remember enjoying when I was young. This application was a way to make something that I could share with him. My wife is quite crafty and does all kinds of neat artsy things with him, but it’s harder to share my love of software creation. This was a personally fulfilling use of my time.
More to the point of this blog, by developing and publishing a mobile phone application, I have gained experience in the processes that I will expect my students in CS345/545 to follow next semester. One of the most important parts of this process is reflection. We’re studying human-computer interaction, after all: this cannot be done without adopting some qualitative research methods, at least stopping to think about what we’ve observed.
I feel like I should mention that I’m happy with the Android documentation. I appreciate that it goes beyond the engineering-technical into the design-technical, dealing with best practices of application design from both the performance and UI points of view. I think this will make it a valuable teaching tool, and I found it quite readable. I am eager to see how students with much less programming and UI experience take it, but I suspect most will enjoy it more than a traditional textbook.
The evolution of the “dot” design is interesting. From the beginning, I knew that the dots had to be large so that they could be easily touched. Also, the area that is sensitive to touch is actually larger than the dot, since fingers are not very accurate on touchscreens. The initial design looked like a conventional dot-to-dot, with the numbers outside of the dots.
It’s connect-the-dots, right? How hard can it be? (Incidentally, I did not originally take screenshots during development, but through the magic of version control software and intelligent commit comments, I was easily able to roll back to this version and grab a screen capture. Subversion for the win!)
As I continued development and my team (i.e. wife) started making puzzles, I realized that I needed to move the numbers around. In a conventional dot-to-dot, the numbers are manually placed so that lines don’t cross over them. Even in the silly test image above, you can see that the line between 3 and 4 crosses over the “4” slightly. I started sketching some ideas of either computationally guessing where to put the numbers or incorporating another field into the puzzle description language (more on that later).
Then, after discussions with my wife and watching my son play the game, I realized that I had failed to question my assumptions. Context matters. In a conventional dot-to-dot, one uses a pencil with a very small tip to connect the points, so the points can be very small. The numbers go outside the dots, because the pencil marks through the dots, not the numbers. On a touch screen, if I need bigger dots, then I should just put the numbers inside the dots. It’s hardly genius, and in retrospect it seems obvious. However, I think it’s a great example of failure to question assumptions. Initially, I was just thinking “take paper dot-to-dot and make it electronic”. With this mindset, I had missed an obvious place for positive adaptation to a different environment. Now, in the version on the Market, we have two-state (pre-click and post-click) dots with numbers within, as shown below.
It was very exciting to me when I first gave Alex this puzzle. He went through it patiently, and as soon as the image drew, he smiled and shouted “a car!” Aside from being glad that my son was pleased, it meant that this actually is fun. It’s easy to lose sight of that when knee-deep in an API.
Later posts will address some other aspects of the application design and development process that I found interesting. Thanks for reading!