Helping people make websites

I like making websites and I love helping other people make sites.

I started learning how to make web pages, writing HTML that is, in 1996. The most important tools back then were a browser (Netscape Navigator), text editor (Notepad) and FTP client (hmmm, I can’t remember what client I used). If you saw something cool on a webpage you could just view the source and learn how that developer had made it work. You could ask anyone you met online for their homepage and they had one. It might have had midi background music and blinking text, but it was theirs and it told their story. Social media is cool, but I can’t help feeling we lost some of that personal creativity.

Fast forward to 2015 and the profession has changed… in some ways a lot, and in other ways not so much. The best tools are still a web browser (Firefox, Chrome, IE, Opera, Safari—all the latest browsers have killer developer tools), text editor (Sublime) and some way to publish your content (FTP, git, other…). Only now there are so many other tools to help with design, development and operations… I am not going to list them here, but I am going to highlight some tools I’ve made to help others.

Global alert bar editor (2015)

Global alert bar editor

My most recent creation, a simple authoring tool for creating the global alert bar used on Queensland Government websites in times of a natural disaster. It’s a simple form with live preview and markup. The initial impetus for this was to get the time element markup correct. I named it GABE for short and you can find it over on codepen:

It doesn’t publish—it just generates the HTML for old fashioned copy and paste.

Queensland Government templates and patterns (2002–2015)

I’ve helped code the CUE (consistent user experience) and SWE (single website experience) templates for Queensland Government since 2002. Rolling out a template across varied government websites and applications (and many different platforms and frameworks) with minimal conflicts and 4-week releases was a really great achievement. Centrally hosted assets (css, js and images) was the key to rolling out quick changes, and a healthy respect for the diverse platforms the template was integrated in. I might personally be a bit opinionated about troubleshooting CSS conflicts with the PrimeFaces UI framework; but professionally if that’s needed then that’s supported.

Maps with data (desktop)

The pattern library is a collection of UI elements that are supported in that template, ranging from simple content patterns (example: including document metadata in a link) to “advanced” content, such as a creating a single-page mapping application with only a simple CSV data file and some HTML templates.

Always a good challenge: balancing a quality customer experience with an easy authoring process! Two examples I am particularly tickled by are instruction-based form relevance, an approach to progressive disclosure in forms that requires no scripting (by the form author, I did the heavy lifting) and having folks run up angular apps with only CSV data and custom templates (the angular app code is centrally shared).

Form builder (2012)

Form builder prototype

I consider it a “proof-of-concept” but this single-page app has been used to create many of the email forms now live on and was instrumental in getting everyone to stop talking about putting “services” online and actually start publishing them! The rush is on now to put more advanced tools in place (bring it on!)

Click anywhere to edit, drag and drop, switch to preview. Builds forms with semantic markup (my particular flavour), including HTML5 validation and progressive disclosure. There are a bunch of poorly documented keyboard shortcuts. I’d love to polish this up one day, it has a lot of potential. (Being usable without training would be a win!)

Get involved survey builder (2011)

Edit consultation dialog (2011)
Add question dialog (2011)

Get involved is the Queensland Government consultation platform. The survey builder is not as easy to use as the form builder (above), in fact it inspired me into thinking “It should easier to make forms!” Still, I helped with the UI design (with some excellent editorial advice from Rory Daly) and it helps people make surveys, consider the language they use, and choose appropriate privacy settings.

Custom quality control tools (2007, 2012)

Diagram of quality control logging tool (2007)

I worked on a couple of browser extensions to automate some of my quality control tasks, staring with custom stylesheets and scripts in Opera in 2007 to help check pages at Department of Communities.

In 2012 we tackled editorial quality by testing for passive voice, non-preferred terms, number formats and more. Computers are great at consistently performing the same checks over and over again, the challenge lies in figuring out how to test for some of these fuzzy concepts, how to present those results in a nice UI, and how to encourage people to use the tool when available. (Okay, behaviour change may be the biggest challenge in that list!)

Content management systems (2002–04, 2012)

Workflow documentation
Workflow email design (2005)

TeamSite pops up every few years in my Queensland Government jobs. I implemented the workflows, templates and deployments for Education Queensland in 2002–04, and helped set up the environment for in 2012. I’m not a huge fan of CMS products, I like flexibility in my workflow and systems like consistency so that’s an immediate challenge. Still, I am impressed when I see authors getting stuck in and making content! I have mixed opinions about whether or not they should learn HTML along the way 🙂

Jumbostore (1999)

Jumbostore edit product wizard (1999)

Behind the online shopping mall “Jumbomall” there was “Jumbostore”—a content management environment for stores and products. I did a lot of the work on the UI and database to support this, customer support for merchants, and occasionally drew elephants for promotions.


My biggest contribution is mentoring. I’ve always enjoyed this on the job, but over at Thinkful I’ve found the best outlet for helping new developers on the path to mastery!

Yes, I do believe everyone can “learn to code” or more accurately, everyone can create.

Slidedown transition with scaleY

Here’s another “non-height” approach to slide down transitions: use scaleY (I haven’t checked this for browser support yet, I think IE9 at least will need a prefix for transform-origin).

Neat, I kinda like this one too. The overshoot on the slide down (where it goes a bit further and bounces back) is a touch of exaggeration, easily achieved with cubic-bezier timing. That sounds confusing! But it isn’t all that hard! Use Lea Verou’s amazing preview tool. Here’s the curve I came up with:,.38,.72,1.3

So this approach is still different to animating the height. The jquery slidedown adjusts the box height, revealing more content. The scaleY property squeezes the content which may look weird. Again, a little fade in while sliding may help. Also, scale is more attuned to squash and stretch so, you know, that’s something to play with!

The new life of Ben!

Today I took a leap of faith (no, I’m not playing Assassin’s Creed) at work and resigned. I’ve been a “UI Specialist” in Queensland Government since 2008 (with a stint off in a management role, then project, in 2010) and it’s been an interesting time. Great people, great flexibility (hard to beat working from home 2 days a week!) and some interesting challenges (supporting IE6 was not one of them).

I have known for a long time that it was a great job, and not a career. Some folks can step up to the challenge of middle management in the public service. I’m part awed, part horrified, by their willingness to make the shift—but it’s not for me. I love coding, I love mentoring and now I’m loving animating. I really want to work in that kind of creative space. (You say management is creative? Um. Ok. In the public service? Not my cup of tea, thanks.)

The new life of Ben begins in TWO WEEKS! I’m hunting for the next job—wish me luck 🙂

ps: Resign from a job. Bucket list: tick!

Now, off to throw a frisbee…

Interacting with digital signs

Been musing about what it might be like to interact with digital signs.

Unlike other devices, a digital sign is more active while idling (not being directly controlled). It should be doing interesting things. At quite a distance too. Even though signs are large, people may be far away from them so it may not be that different to designing for tablets and mobile really. Even more than the “10-foot UI” touted for TVs at home. Need nice large text and images. But if people came up close, that could change.

Should people come up close and interact? Should people at a distance still be part of the experience then? A multi-audience experience? Does the person standing at the sign block that view? What about left- vs right-handed? 🙂

Can people pause what they see? What if something grabbed their attention and when they reach the sign it’s gone. How easy is it to go back? What if an idea sparks them but they want to follow up later? Is there some kind of handoff to their phone or tablet? (Maybe QR codes or NFC, or something else?)

It’s such an interesting medium. Platform? Form factor? I didn’t know it was ready for front-end developers until I came across Rise Vision’s post: Web Designer Guide to Digital Signage. Cool stuff!

javascript jam

Javascript jam is a fun project tacking along nicely at work. Twice a week, giving folks a chance to try their chops in javascript and learn how it works. Feels a bit bizarre but we’ve tackled turning random website backgrounds pink, implementing a word count validation plugin, and live updates of page text from textarea input events. Is it all leading somewhere? You bet!

I wanted to keep a little piece here for posterity.

For those that are missing an invite… it’s jam every other day! 🙂

You wanted a chance to jam twice a week on javascript projects? You got it.

1–2 pm, Tuesday and Friday, at the StarBoard.
(Is it lunch? Is it professional development? Ask your team lead!)

Twice a week not enough for you?

Try one of these courses. Bring your questions to a jam.

Or play with some live code:

What’s in it for me?

Ten reasons your friends recommend javascript jams!

  1. hands on experience writing javascript
  2. your questions answered (html, css and UI design too)
  3. contribute to the form builder, QA tool and single website experience
  4. invent your own innovative product
  5. practice MVP (there’s only so much we can do in an hour)
  6. aha moments! So that’s how they did that! (bring questions)
  7. increase your geek speak vocabulary with fun terms like closure, foo and immediately invoked function expression
  8. real world practice spelling color the American way
  9. combine your interests: ukulele + javascript =
  10. everything tastes better with javascript?

Where’s our code?

Keeping it here for now:

“I’m sure I’ll take you with pleasure!” the Queen said. “Two pence a week, and jam every other day.”
Alice couldn’t help laughing, as she said, “I don’t want you to hire me – and I don’t care for jam.”
“It’s very good jam,” said the Queen.
“Well, I don’t want any to-day, at any rate.”
“You couldn’t have it if you did want it,” the Queen said. “The rule is, jam to-morrow and jam yesterday – but never jam to-day.”
“It must come sometimes to ‘jam to-day’,” Alice objected.
“No, it can’t,” said the Queen. “It’s jam every other day: to-day isn’t any other day, you know.”
“I don’t understand you,” said Alice. “It’s dreadfully confusing!”

—Lewis Carroll, Through the Looking Glass and What Alice Found There

Hello javascript, I promise to call back

I went to a job interview the other day for a javascript developer (though it was advertised as a UI developer). It was pretty tough interview, coding an MVC javascript object with Kendo UI and answering some tough questions about javascript language patterns. The toughest being: explain the difference between a defer, callback and promise (and there might have been another one…) I got sidetracked and never really answered this which has been kinda bugging me. I’m not sure I actually know the answer—this is a depth of javascript programming I haven’t explored much (and certainly don’t get an opportunity to explore in my ‘UI specialist’ job) but I’ll have a stab. Then I’ll look it up.

First up, I think they are all asynchronous techniques. Async is all the rage, I started hearing lots about it when news about node.js started hitting the blogs. There was a bit of it back when AJAX was a hot buzzword, but it was limited to handling of HTTP responses then (which pretty much had to be async—delaying your whole program to fetch a resource over the net would be too slow). Now we’re using async all over the place!

My layman’s understanding is that a good use of async removes bottlenecks. Say you need to read a file or fetch data from a server or spin off a complex computation? Have that run separately and let your program keep running. You’ll pick that up when it’s ready. In synchronous coding, your code would be stuck waiting for everything to execute in order. That’s my understand of async coding. And I think callbacks, defer and promises are async patterns.

Callbacks I know about. A function that ‘calls back’ takes another function as an argument. It will call that function at the appropriate time (when it finishes what it was doing)—for example: when a HTTP response is received, when an event occurs, when an animation completes. jQuery has plenty of callbacks.

Defer I’m not sure about. I know there is a defer attribute in html for script elements, which indicates the browser can delay executing the script. I have a feeling there might be another concept called defer which is a programming pattern though.

I have only recently encountered promises on the Javascript weekly mailing list (which is excellent) and haven’t read the articles about them. I think they are similar to callbacks, if not a specific type of callback. The name itself is also a clue, I think the ‘promise’ relates to how the function calls back. I even think it might be a callback API. And I think at this point I’ve missed it and need to do some research 😉

I’ll be back to update this article after that!

[Update: ok, it looks like promises are a pattern for callbacks which make the code easier to read. A promise returns an object immediately. That object has methods to register callbacks. ‘Then’ and ‘When’ seem to be conventions for the method names. That reminds me of behaviour-driven development, but has nothing to do with it. Well, maybe I have seen the promise pattern in some BDD code. Aha! Chainable callbacks. It seems a promise is an alternative to throwing exceptions too, nifty! I’ve added some references to the end of this post.]

[Update 2: I can’t find much extra detail on defer, unless they were asking me about $.Deferred in jQuery, which looks to be a sort of promise factory.]

I really enjoy coding in javascript but I’ve never been a full-time developer (nor wanted to be). I don’t even know if I’d even qualify as a paradev! To my workmates it probably looks like I code a lot, but there’s no pairing with another javascript coder and challenging ourselves to explore the latest best practices in javascript. It would be pretty awesome to do that every day and really push those limits—but there are lots of other interesting ideas to explore! Another article I read this week was contentiously titled Why UX Designers Need To Become Project Managers (to which I say—cool! But it better be PRINCE2 and it had better embrace product-based planning—absolutely no PINO!)

I could do advanced javascript on my own time, and I do a little—when I’m not busy with other hobbies—playing bass, gaming and family. I’m happy with the balance I have going. Also, sometimes I like to play with graphics and HTML semantics, and only get into scripting when it ‘progressively enhances’ my already useful code 😉


  1. Asynchronous Programming in JavaScript with “Promises”
  2. What’s so great about JavaScript Promises?
  3. You’re Missing the Point of Promises (this article is great!)