Over the two weeks including Thanksgiving Break, my CS349 group developed a prototype of our Surface application for the Davis Museum. I was involved in creating and programming the artwork objects that appear on the GUI, and programming the file i/o for the user responses. Because this was our deep, “risky area,” I implemented this fully and created a system for populating the responses (that had been saved earlier) on the screen. Finally, I also worked with my teammate Helen on having the Surface recognize the placement of our tags, and over the next week will develop an algorithm for sorting the words of the native screen based on the tags that are placed.

The development process was an interesting one – I experienced several trials and tribulations when installing the Surface development environment on my computer, and after purchasing and installing Windows 7 (twice – always install the 32-bit version, people) was heartbroken to discover that my computer’s resolution (1440×900) is just shy of the vertical requirements to run the Surface Simulator. No worries, though, an external monitor came to the rescue – but this was and is a definite setback.

When it came to actually developing for the Surface, getting the grid structure to behave the way I wanted it to presented some confusion, but the great result was that I developed some very reusable sample code that may help inform other CS349 projects in the future.

After plenty of researching, one happy surprise was that doing file I/O – and particularly with XML – is extremely intuitive on the Surface. After learning about the correct syntax and structure, implementing the input and output was fairly simple (unlike, say, on the iPhone, which is melting my brain right now). After demonstrating our application and attempting to tweak the output from the responses it’s become apparent that when the file saves it does so to a local file, which so far I am both unable to locate and edit. Furthermore, a next step is to only retrieve the most recent five or so responses.

At this point, the most significant tasks left to do are improve the display of information, the methods of “cleaning up” the screen, include guards against “dummy” data, and develop the sorting algorithm mentioned above. The great thing is that because our architecture is very modular it shouldn’t be difficult to work with our structures, and the most challenging final step will probably be to improve (and render as usable as possible) our aesthetic.

Click here to cancel reply.