My History with Tablet Computing and my Views on the Future

In high school, more than anything I wanted a Tablet PC.  Yes, one running Windows XP with a stylus that everyone seems to hate so very much now.  I ended up getting one, a Toshiba M405, which was the first in a string of Tablet PC purchases.  Speed School started a Tablet PC program the year I entered and I was very involved in making it successful.  I co-founded the Student Tablet User Group and created software that was specifically designed to work with digital ink content.  I also managed to have a class project focused on handwriting recognition and my thesis was based on algorithmic organization of digital ink.  Not all of my work was based around pen enabled input.  My capstone project was a touch enabled card game engine that was built on top of Microsoft Surface technologies.

At this point, I have four Tablet PCs which are essentially being used as Laptops.  Thanks to Google, I now have a Galaxy Tab 10.1 running Honeycomb 3.1.  In the past, I was not a huge fan of Java development, specifically Eclipse, but that has since changed.  My use of AppEngine as a web based development platform along with Android application development and some other small side projects, it has become one of my most used programming languages.  PHP and C# are still used for many of my projects, but Java provides unmatched flexibility.

The past is always interesting to talk about, but my real concern now is the future.  The success of the iPad can not be viewed as a bad thing for the general public, but personally I am not a fan.  While I realize that for some people the iPad provides the integrated experience they want, it will always be lacking in certain areas.  The best explanation that I have heard is that it takes a day to master the use of an iPad while you will still be learning how to use an Android tablet even after weeks of use.  I agree with that statement and must assert that it is a good thing.  Android provides a flexible and open architecture that allows for a more dynamic computing experience.

The real issue to me from a productivity standpoint can be best summarized in a single question.  Can it run Eclipse?  I think this is a good benchmark to determine the level of productivity that you can have on a device.  Since Eclipse is based on Java, it can in theory run anywhere.  The complexity and scale of Eclipse makes it a sizable application that can run slow even on modern computers.  Eclipse will never run on the iPad.  The real question for me is not if it will run on an Android Tablet, but will it run on the Chrome Book that I am expecting in the mail soon.  The core issue here is productivity and the question can be re-framed.  Does a "windows" based computing environment provide the most productive computing environment?  I would argue that for certain tasks the command line is the most productive.  Just as the command line is still a tool of power users a, windowed environment may turn into the same type of tool.

The future will be in the clouds, probably more than anyone expects.  It seems silly to have so much computing power in your pocket (considering battery life) when it could simply be offloaded to another location (that includes an AC adapter).  The devices that we use in our day-to-day lives will simply turn into I/O devices, providing screens and various means of input (keyboards, touch, pen, and voice).  From this respect I think the "windows" interface has only a few years left (I'll pick the arbitrary number of 4) before the vast majority of computing is performed using other interface constructs.  The concept of the traditional window simply does not scale properly to the dozens of screens we are surrounded with.

Mobile phones have introduces the concept of the "app" which is best described as an application that has full screen interfaces that provide a focused computing experience.  While this is a useful construct, I do not believe it is the most ideal.  Personally I am waiting for an immersive augmented reality heads up display to become my primary interface into the digital world.  This concept strays far from the slate based tablets that are rapidly growing in popularity.  Android is the most likely platform to embrace all forms of input (keyboards, touch, pen, and voice), which puts it in the best position for the future.  Android also provides a highly flexible way to have the same application target multiple computing interfaces and hardware types.  Windows also has all of theses features and Windows 8 may extends Microsoft's dominance for another 10 years.  Apple will continue its success, but based on their approach can not change the world by themselves.

The real trick to become the next paradigm in computing is to become transparent.  In the future, it will seem silly to say, "I'm going to go use the computer" because there will be dozens of computers around you at all times.  I'm already surrounded by half a dozed computing devices and this number will only increase.  The future I want to see will be ruled by open source and therefore ruled by no single individual or company.  The question about tablet computing and the future is the wrong question.  There will simply be computing and the entire range of devices must be supported and integrated using the cloud.

Building an Android Application in One Week

While I have decided to keep Track and Field Clipboard closed source, I will reveal a little bit about how I created it. I keep all of my source code for all of my projects in a Subversion repository. Since I always strive to create the highest qualify software, this is definitely a powerful tool. It also provides a great way to keep backups of my code secure. As a data geek, I also appreciate all of the information that is captured by using a version control system. I used StatSVN to generate a report based on the repository.

As you can see from the chart below, I began coding on Monday May 30,2011. The majority of the code was written in the first three days of the project. This work mostly consisted of building the model that was use to represent the field events and participants. This code would have likely taken longer to create if I did not include the Simple XML third party library. Unlike the XML serialization capabilities built into .NET and C#, Java has no built in way to quickly and easily serialize objects into XML. While I could have used binary serialization, that had the possibility of causing problems in the future.

Using the Simple library was so quick and easy, I will likely use it in some other Java based applications that require some trivial XML parsing capabilities. The most attractive feature of Simple is the fact that it is very small. The APK for Track and Field Clipboard is only 156k, which has the library bundled with it. Other libraries were in the multiple megabyte range by themselves.

Android provides a variety of ways to store data persistently. I settled on using files and not an SQLite database to dramatically simplify the process. The process involves writing and reading the serialized object's XML to and from a file. Initial testing on this approach was very promising. The file was read using an AsyncTask and then the appropriate Activity was launched. Since all of the manipulations to the object were being performed in a single activity, this approach worked perfectly. When the activity was paused, another AsyncTask was dispatched to save the object back to the file so nothing would be lost. While I did have some performance issues, it turned out those were primarily cause by having the debugger attached to my device.

The weekly activity graph for this project is very interesting since the project is only a week old. The number of commits peaked and then fell indicating that the application was starting to stabilize. Since the project was a straight forward application there were very few stumbling blocks that I encountered during the process.

At the moment, I am currently between the end of my college career and the start of my first full time job. This means I have had several weeks (and still have several weeks more) where I can decided how to spend my time. Unlike many geeks, I am not a night person. I tend to wake up fairly early and do not stay up late into the morning hours. I have code commits as early as 9 AM and they only go as late as 2 PM. The drop in the number of commits in the later hours is likely when I was hungry and tended to take a break from coding. My lunch breaks were obviously much shorter. The graph reveals my peek productivity times: after lunch and before I go to bed.

This is obviously a very new project and I am confident that there are still a number of bugs in the code. There are also some simple features that did not make it into the initial release. Spending the past week creating this application has been my form of relaxing. Learning how to write an application that targets Honeycomb was definitely worth my time and effort.

Introducing Track and Field Clipboard

It is a fairly simple idea and I had even talked about it before, but this past week I decided to actually build it. As someone who has been around Track and Field meets since I was very young, it was a perfect opportunity for me to build an application for an Android Honeycomb tablet. The basic idea is to replace the clipboard, paper, and pencil used to record scores for field events with a tablet.

When Google gave a Samsung Galaxy Tab 10.1 to everyone attending Google IO (including myself) there was a less than subtle nudge to "go forth and create apps." Not wanting to spend all of my time playing Angry Birds and now Plants vs Zombies, I decided to actually build a fully functional and useful application.

While I have one other application on the market and another long term project that has an Android component, I wanted to specifically focus on Honeycomb. While the application I build could have targeted phones, that was not my goal. The use case for a small screen is far less attractive, but the biggest motivation for only focusing on Honeycomb was simply to learn some of the new APIs and methodologies. I have spent some time working with the compatibility API for fragments and developing a pure Honeycomb application seemed like a more enjoyable activity.

Now a little bit about the application itself. I finally settled on the name Track and Field Clipboard for the application. Breaking with my long tradition of open sourcing my side projects, I have decided to keep this application close source. However, it is available for free on the Android Market. There is the possibility of me adding some advanced features in a paid version of the application if it gains some adoption.

The application is designed to be very easy to use. You create an event, add participants, and then record marks. The field events that are supported include Discus, Shot Put, Javelin, Long Jump, and Triple Jump. High Jump and Pole Vault are not supported since the rules for those competitions are significantly different and more complex.

The main benefit of using this application as opposed to an analog piece of paper is the automation that it provides. If the competition has flights, the athletes that qualify for the finals along with the order is automatically determined. Each participants best mark is highlighted to provide an accurate summary of the results at the current moment. Additionally, each participants current place is also available along with a view that summarizes the results. After you have finished with the event, the results can be emailed.

My goal here is to have this application just be slightly ahead of its time. There is not a large adoption of Android Tablet users at track meets yet, but with some luck that may change in the next year.

I need to thank Cassie for her help with the graphics (as always). I also need to thank my father for helping me work out some of the details to make sure they matched what would be expected by the user. He also served as my first actual user at the Bluegrass State Games yesterday.

In the end, my goal is to help bring technology into a new area and provide a good user experience. Hopefully I can find some users. More likely, I hope some users can find my app.