Snap Tournament is a web application for managing large scale game tournaments. The idea came from attending tournaments at game conventions (e.g. GenCon, Origins, PAX Unplugged, etc). These conventions always ran daily tournaments, with final championships involving 100+ participants. Management of them took place largely in cumbersome spreadsheets. I felt there just had to be a better way.

I wanted my solution to be built on several major principals:

• Simplicity
  

  The application should feel friendly and familiar to the people running tournaments. Asking all the appropriate necessary questions, without burdening people with too many options. Tournament attendees should be able to find their information without help.

• Speed

  The application should be faster than their current process. Since attendees would be viewing the site from slower mobile phones and overburdened cell/wifi networks, caching and limiting application size was important.

• Responsiveness

  The application needed to be platform and device agnostic. Whether used from a small touch screen device, or a full-fledged desktop; all features and abilities of the tool should be accessible.

This project was too large for me to take on myself, so I recruited my friend Justin Kirby to develop the back-end and API, as I developed the frond-end. We also found a partner from an event management company (Cascade Games LLC) willing to guide and help us generate requirements.

We began by interviewing our partner with Cascade Games (Liz). She was an invaluable resource and helped us understand the individual components of a tournament event frequently overlooked.

From our research, we generated a list of features and requirements. We ran pointing sessions and slimmed down our list to a reasonable set for a minimum viable product.

From here, I began mocking up our application using Balsamiq. I am a fan of the tool for its rapid ability to prototype. Mockups come out quickly, with a focus on layout and feature functionality. Its sketch like quality and lack of polish helps not waste time on style. I also subscribe to Bill Buxton's approach to design. Keeping fidelity low, until ideas pass the rigor of review and discussion.

After mocking up, iterating, and reviewing a fair amount of the application, I pivoted to web development. HTML's defaults and box model marry nicely with mockups. CSS allows you to layer on styling later, while you initially focus on structure and layout. Fidelity can be increased without duplicating efforts by remaining in a mockup tool for too long.

We were able to complete an alpha version of the application, which we used to run the Ascension World Championship at Gen Con 50. The application was a huge success at the event. Cascade Games found our implementation to save between five and seven minutes per round. This translated to almost an hour off the total time for the tournament.

Development of the tool stalled shortly after the tournament. This was a wonderfully fun personal project which I am still looking for partners and opportunities to continue.

I play a lot of boardgames with my friends, and often find things missing from the games. Whether it's a decent way to track score, or a better mechanic for choosing who goes first. GeeGee Gamekit was created to fill those gaps.

I built the app using straight HTML, JavaScript, and CSS. This allowed me to bring the app both to the web, and Android with a single code base. It also allowed me to experiment and learn the capabilities of WebView.

I made the app responsive, by hiding delete functions (in scoreboard and dice roller) behind a swipe gesture on smaller screens. Imagery also scales to screen size (in spinner and timer) to offer the best visibility.

After finishing development on my updated device, I tested my app on older versions of Android. I found that many of the modern (but widely supported) web styles and properties weren't available in WebView until Android 5.0. Unfortunately, I had to target my app for this tiny segment.

I'm still working on legacy support

Mic List is a personal app, not yet released.

There are a lot of list/task apps available. Everynote, OneNote, Google Keep to name a few. All of these apps force you to tediously peck out items on the software keyboard. With Mic List, I focused on speed and simplicity of entering items.

Most list items I generate are short (less than 5 words per item). Things like: wash car, clean fridge, take out trash, etc. If it's a grocery list, they're even shorter: bananas, milk, bread. I wanted a way of creating these kinds of lists as fast as possible. I did that, with dictation.

Items are entered by pressing a mic button and saying what you want to add. A pause in speech will add the item to your list, then immediately listen for your next item. Speech-to-text isn't perfect, and there are times it doesn't enter what you're saying correctly. That said, I found it was faster/easier to say the item again until I got it right. After, I could go back and quickly remove the incorrect entries.

While I use this app several times a week, and with great utility, I feel it's not yet ready for market. I'm continuing development until then.

After creating the FlashLight app, I wanted to make something heavily themed. One of the alarm sounds in Android at the time was a corny rooster crow. The sound birthed the idea of a rooster/farm themed timer app.

The theme is based off the quintessential American farm. A red wood barn, brown picket fence, chicken eggs, and (of course) the rooster. Chicken clucks and short crows are also incorporated.

A timer is a short-term need. Long term needs are solved with alarms. So, I focused on providing the simplest interface for sub four-hour timer needs. Things like taking a nap (1 hour), boiling an egg (10 minutes), or brewing coffee in a press pot (4 minutes).

To reduce buttons, I settled on: one hour, ten minutes, one minute, and ten seconds. Entering time required less cognitive load and created a theme appropriate pecking gesture.

There's no undo/delete button. If a person enters a wrong time, their only option is to clear it, and start again. To alleviate mistakes, I added audial and haptic feedback to every button press. With four of five senses being used, I found I didn't miss often, and flow was retained.

Rooster's utility has largely been replaced with additions to the Android OS. But it remains in my heart as a fun and helpful learning experience.

I created my FlashLight app as a way of learning some basic Android development. With thousands of flashlight/torch apps on the market, I didn't want it to be just another of the same. Rather than focusing solely on producing the most amount of light, I decided to concentrate on "just enough" light.

There are tons of situations where you need just a little bit of light. Navigating a bedroom where others sleep, checking on a sleeping baby, reading something without ruining your night vision, etc. I wanted a tool that was more than just blinding light, and useful in these situations.

FlashLight controls brightness in two ways. One, by drawing a colored circle to the screen. And two, by changing the screen's brightness. Both are adjusted through one fluid gesture. Swipe up the screen for a larger circle and more light. Swipe down the screen for a smaller circle and less light

Color is another important feature. While white light gives you the best range of brightness, red light helps you see at night. Blue green, offers the best dark adaptation recovery. Also, photographers often paint with light in night photos. To address this, I added a color picker that spans the entire color gamut a screen can produce.

Lastly, in situations where the most amount of light is needed, the ability to turn on the camera flash was added. I didn't want to clutter the screen with more buttons. I settled on a double-tap gesture to toggle between screen light and camera flash.

The need for a flashlight app has been reduced with additions made to Android OS. Still, I find an almost daily need for FlashLight's screen light features.