Photo of source code from this site

Websites are Software

Posted on:
April 28, 2015
Posted in:
Programming, Web Dev

About 10 months ago I gave a presentation at eduWeb 2014 in Baltimore called “Websites are Software, not Documents.” I’d been meaning to repost the slides here since the presentation was when I decided I would put myself out there as a voice in the higher education web development community.

Presentation Slides

Here are some thoughts after having some time to reflect. First, about the presentation itself, and then on its content.

Good Decisions

1: I presented on a topic important to me. I’m a big advocate for code competency – I believe that people who edit and maintain web pages should understand the actual code that makes their pages work (or at least the principles behind that code).

2: I walked the walk. The presentation slides are a simple web app made using EnyoJS. I’ve left the code un-minified and fully commented so that the attendees can get a look at the code and see that it’s not so difficult.

3: I had a live demo. About halfway through the presentation I have a discussion about some code samples and show some ways to write better code. It’s much more effective to show than it is to tell.

4: I stole ideas. I had the luxury of presenting on day 2, so I took some ideas from presentations I saw on day 1 and incorporated them into my presentation.

5: I dressed up. Maybe I didn’t need a tie, but wearing a business suit was a good idea. It’s important to remember your audience – eduWeb is a marketing conference first and foremost. If I was at JSConf then maybe a cool ironic tee would’ve been more appropriate.

Bad Decisions

1: I procrastinated too long. While it was nice to be able to steal ideas from other presentations the night before, I also ended up writing about half of the presentation the night before. You don’t need that stress the night before a presentation.

2: I didn’t practice. I should’ve practiced with a room full of people. Instead I found out about 3 or 4 lines in that I had a huge case of stage fright and nearly fainted. My only advice to first time presenters is to go ahead and hide behind the podium if you need to. It’s normally a no-no, but it’s okay if you need to get your sea legs first.

Also, if I had practiced more, I would’ve noticed that I put all the text in the slides. Slides in a presentation should illustrate and punctuate, not narrate.

3: I responded to a “heckler.” I put that in quotes because it’s not totally right – the guy didn’t actually intend to give me a hard time, he just disagreed with a point I was making. Nothing bad happened, but stopping to address one attendee’s point meant (a) breaking the rhythm, and (b) ignoring the rest of attendees for a few seconds. I should have made a mental note and called on him first in Q&A.

4: My demo wasn’t interactive enough. It was good to have an interlude and it helped the pacing, but next time I’ll try to make sure the attendees have something to do.

5: I didn’t leave a clear enough call to action. For the marketing people, the call-to-action was clear: learn to code. That translates easily to links to code.org, codecademy, and Khan Academy. But for web developers, I had nothing for them to take home or do except maybe a slightly different point of view.

General Thoughts

I’m glad that I was able to get the thrust of the presentation down to one simple point:

Every web page, as delivered to the browser, is its own little web application.

The problem, of course, is where the rubber meets the road. HTML is ostensibly a document format. Our web servers are designed and optimized primarily for the efficient delivery of static content. The CMS I use at work doesn’t even interact with users – it creates static documents that get transferred to the production web server. And while most CMS don’t have that specific failing, most of them still conceptualize the website as a collection of semi-discrete documents.

We have over 200 users. There are maybe 1 or 2 (yes, I counted) whom I would trust to write production code on the website. Almost none of them can code in any capacity. Almost none of them are charged with maintaining the website as a significant job duty. An alarming percentage seem to take a sort of Luddite pride in the fact that they don’t understand computers or the website they maintain.

So yes, there’s a logistical problem in this shift – not just a problem with the technology, but also with the people charged with making the website and their skill sets.

Thinking Too Big

My biggest problem is that I spent the past few months trying to think of how this basic thought could revolutionize university website design and development and, to be honest, I can’t figure that out. I don’t have a revolution in the waiting. The actual conclusions I’ve come to are much more modest.

1: Many little web applications. I’ve come to realize that your page as delivered holds the potential to be several little web applets instead of just one big application. The Live Search isn’t an application in its own right – but it’s this little piece of an application that runs on every page.

2: Fill in the CMS blanks. Since the CMS we use doesn’t really allow for any front-end dynamism, we frequently use JavaScript to fill in the blanks. We load news posts, calendar events, and directory profiles from dynamic systems through JavaScript and JSON requests because our CMS can’t interact with those systems in any meaningful way.

3: Create better interfaces and interactions. We all love seeing an impressive “CSS-only” demo, but they’re usually limited by some critical caveat. If you’re comfortable using JavaScript you can usually do the same things but with far fewer limitations.

For example, I recently created a megamenu concept where we only wanted one drawer open at a time in desktop mode, but to allow multiple drawers to be open in mobile mode. The solution was to handle this behavior through JavaScript and have it use the most recently opened drawer as the only drawer when switching from mobile to desktop layouts.

4: Build more robust code. By understanding the way that JavaScript operates, you can build code that’s less error-prone, more reusable, and insulated from the other code in your document.

5: Create room for growth. Now that I’ve got my code better contained and worked into library-like structures, I can write page-specific code without fear of overlap or conflict. This has already allowed me to make some new custom designs and layouts for the University magazine and I’m hoping to use these techniques going forward to create a robust redesigned website.