Screen Shot 2014-03-24 at 7.31.27 PMGame Day Monitor is a fun side project I’ve been working on with Eric Bryning who is the volunteer coordinator for our AYSO region here in Oak Park. Eric asked me for help prototyping an application to capture feedback from AYSO games.

It’s a simple form that volunteer monitors can use to submit reports to help gather data about the behavior of parents, coaches and referees at the games. The core values of AYSO are focused on providing a fun, family environment to help instill a love for the game into kids, whether they are brand new to the game or well on their way to a lifetime of playing. I’m glad to be helping with this project because it will help make it easier for the volunteers that keep the league running to gather data and to identify problems with poor sportsmanship or bad parent behavior. It’s a bummer that this thing even needs to exist, but I’m always pleased when I can make a useful tool from what was a email-based or word-of-mouth reporting. Moving forward the league will be able to collect data in a database that they will be able to use more effectively.

We’re starting very simply with a release for the spring season and as we gather data, we’ll start to layer on user management and reporting as needed. I started the project by wireframing the site out in Web Flow. As I’d hoped, by doing the initial design work in Web Flow, I ended up with a responsive prototype that didn’t take much more work beyond wiring up the PHP for the data storage and laying on some CSS to style the form controls. All told, I was able to get a viable tool ready with an evening’s work.

Screen Shot 2014-03-24 at 9.58.27 AM I’ve been helping my friend Kara Eastman on a landing page and some identity work for her campaign for a seat on the Omaha Metro Community College board. It’s been a great project for me, because it has been a mix of some design work along with an opportunity to try out Stripe payments and Perch CMS together as a lightweight set up for a landing page to collect campaign contributions.

Stripe was very easy to implement. As the rave reviews of my friends have led me to expect, the signup was unbelievably quick. I spent more time getting through the verification process for the SSL certificate on the domain than I did getting Stripe tied to the campaign’s bank account. So cool.

I needed to customize a bit, so I went the route of using Stripe’s PHP library to create my own charges. If you have really simple needs, they have a super simple popup JS implementation for checkout that only needs a line or two of code to implement.

The API is straightforward and well documented. There are lots of examples for PHP, and from what I could tell poking around Stripe’s docs, GitHub and Stack Overflow there is Ruby, Python and other implementations to choose from. Stripe give you Javascript to implement which will generate a token on your page which is then passed to the PHP to create your actual charges.

My past experiences with commerce gateways have involved days of back and forth with support, out of date or esoteric documentation and general pains in the butt all around. Stripe is a dream. I’m hooked for life.

My other new love is Perch. I bought a license for a personal project a while back and never got around to using it. Like Stripe, the thing that hooked me was the documentation and ease of implementation. I’ve been after a way to move past WordPress as a go to for a long time. I’ve long felt that what I want out of a CMS is to be able to start from scratch without a predefined content paradigm and to start from writing some good clean static HTML as a base for my templates. I also want to be able to make the barest minimum of administrative functionality. Perch lets me do all this.

ke_mccFor Kara’s landing page, I started with a simple Bootstrap-based landing page template. Currently, some of the content is static HTML and only a couple areas are managed through the CMS. I’ve only created content managed areas for things that are likely to be edited. I added a custom form for the Stripe integration and set up a Google font that is a close relation to the Lubalin Graph slab serif I’m working with for Kara’s logotype.

This was a fairly quick turnaround to get live, but the pieces are all easy to implement. I expect that the Bootstrap, Perch, Stripe recipe will be my go to setup the next time I need to build a landing page or microsite.

“HTML5, or as some people call it, HTML” – Jon Buda.

Just about a year and a half ago, I had the distinct pleasure of hosting my first ever Chicago HTML5 Meetup at the COOP coworking space in Chicago. Our presenters were Jon Buda and Sam Rosen. Sam presented the business case and design thinking behind Desktime ( and Jon Buda presented the tech stack and dev methodology.

It was a great night. A seminal moment for the Chicago HTML5 Meetup that set the tone for the blend of strategic, design and tech content that has become a staple of our monthly events and our great mixed membership.

I thoroughly enjoyed the event, but the thing that sticks out in my mind more than anything from that evening is the quote from Jon above. Not least because I was one of the folks on the losing end of the HTML5 v HTML naming argument.

Which brings to mind another statement on naming. At Brad Frost’s session at SXSW 2013, he was talking about the debate over what to call what we all now just think of as Responsive Web Design and mentioned AJAX as a great example of another epic naming battle. The thing I remember, his point, was that folks might have been freaked out over what to call AJAX, but nobody, NOBODY was arguing the fact that we needed a browser standard for the asynchronous exchange of data using Javascript.

Likewise, we might complain about the naming or even the contents and recommendations contained in the HTML5 specification, but we can all agree on the need for a standard. Well, most of us anyway.

Even though it’s still not fully supported everywhere, and still evolving, the buzz and adoption of HTML5 as a defacto standard has had a huge impact on our industry. The support for HTML5 by the browser vendors has resulted in significantly reduced uncertainty. We’ve moved out of Beta v VHS territory to a place where the risk of investing time, resources and money are much lower risk.

As a result, you can now find HTML5 in the dashboard of cars, in refrigerators, in smart tv systems and many other places where proprietary device native development once would have been the sole option for building an application.

I might be biased, but given that I’ve been a web developer since that was ever a thing one could do with their life, being able to use my core skillset to create things that might be just as likely to appear on a desktop computer screen as a vending machine or an in-dash entertainment system feels like a really good thing.

As a result of this new found stability, I’ve seen my peers turn their attention away from figuring out how to fix bugs in browsers that have dropped the ball on this feature or that. I don’t believe we’ll ever get away from progressive enhancement or graceful degradation. We need to do these things, but having clarity around what the browser vendors support now and at least a general idea of what they will support in the future means that progressive enhancement can legitimately be considered as more of an afterthought than the main event it used to be.

Freed from the drudgery of fixing bugs in browsers, and armed with the power of Github, we’ve seen more and more folks turning their attention to creating new tools to make our jobs easier and more efficient so that we can focus on even more innovation and the building of cool shit.

Good times my friends. Good times.

Our first event of the year was a smashing success.The theme for the night was Show and Tell. We featured multiple presenters given 10-15 minute talks about their favorite tools and techniques.

Attendance was great and the presentation format was very well received. I think this is due in large part to some great content that, while well within the interests of the group, covered a decent range of topics.

I kicked things off with an overview of one of my tools for remote debugging and analysis, Charles Proxy ( Charles has some great features that allow you to observe and manipulate HTTP requests and responses. My favorite features are it’s ability to mirror content to a local directory while browsing a site, along with Charles great throttling and remapping features. The demo is well worth checking out for anyone that is interested in tinkering with server traffic without the learning curve off messing with network config files.


My co-organizer Mark Rickmeier presented some of his favorite applications from the ever-evolving landscape of mobile prototyping tools. There are new tools coming to market regularly so depending on your needs, you have lots of options. My favorite of the tools he showed is POP ( which is a tool the allows you to sketch on paper and then to capture your sketch and add interactivity on your mobile device.

Adam McCrimmon covered old school, low budget prototyping with PDF files. He aptly pointed out that since a lot of folks are already
producing PDFs to present to clients, the barrier to providing at least rudimentary prototypes is pretty much non-existent. This was a reprise of a presentation he gave at Prototype Camp in Chicago. He has posted some resources here

Mike Gibson from Table XI, who currently holds the #1 spot on my list of favorite presenters cover the Autoprefixer tool for parsing CSS and adding vendor prefixes based on Can I Use data. Check that out on Github –

Matt Wagner also from Table XI, shared some tools and techniques for keeping remote teams working together smoothly including one of my favorite new tools Screen Hero ( and the new multi-user chat client Slack (

Our last speaker of the night, Andy Richardson from Kohactive introduced Middleman ( a tool for outputting static sites from modern templated front-end coding tools.

Big thanks to Zach Schneider for live tweeting. He posted recap at