Author Archives: aaron

Retro Tech: Whiz Kids

From time to time here, we like to go into the wayback machine and look at some our formative tech influences from early in our development. Well, this week, it’s a pop culture tech entry: the TV show Whiz Kids.

Never heard of it? It ran only for one season. And it featured plotlines like trying to defeat Russians who break into US databases and steal the data — or, in another episode, cybercrimes like online theft. Ripped from the headlines, no?

Except this show ran from 1983 until 1984! Talk about ahead of it’s time…

Of course, there, we lose the realism a bit. Sure, the technology that was employed in the show was pretty true to what was current in that time, and some of the storylines were prophetic. But the overarching plot was about some precocious young hackers who ended up saving the day each week. Which made it pretty unrealistic, but made it a must-watch for this young hacker at the time. That could have been me!

It turns out I’m not alone, either. Not only was it pretty popular among the hacker/geek contingent in the US, but it went over to Europe (in France, it was called Les Petits Génies) and was big among the same group there. According to one French blogger, there are IT professionals across Europe who attribute their interest to watching this show!

Lamentably, in 1983, even though WarGames (a seminal tech movie, and Matthew Broderick’s film debut) was the movie of the summer, the potential audience for Whiz Kids wasn’t big enough for it to last. So after only one season, it went away. (And one of the female leads went on to be on ALF. Talk about adding insult to injury!)

But it still holds a special place in the heart of many, including me.

Scope: It’s Not Just a Mouthwash

A decade or two ago, I worked on a project team to lead the development and implementation of a statewide data and reporting system. It was very visible and high-stakes, and we had the luxury of creating from scratch. It was the best kind of situation: we had a big, hairy problem to solve, but the way we solved it was up to us to decide.

One of the members of our team, Bill, a database guru who also could be a bit irascible at times, would get agitated every time some new idea or feature was brought up. “Scope! Scope!,” he would cry. After several times of this, we began to take with a grain of salt and some friendly chuckles, but his fundamental point was a sound one.

Scope creep is one of the biggest dangers in our work. We’re building a web application that does x and y. Why not just spend a little more time and do z as well? It’s all related, and it’s not that big a leap. It won’t even take too much extra time. What’s the harm?

Well, to channel Bill for a moment, there are several harms. First, planning to accommodate that extra feature wasn’t done from the beginning, so it’s unclear how many other parts of the system it touches, and what other adjustments need to be made. Also, how does it affect the testing and release processes? And what sort of additional back-and-forth conversations will there be with the clients about it all?

Having allowed the scope to creep on projects large and small, I can tell you that those extra bits of functionality or work are often the ones that end up being a time vortex – not because of implementation, but because of the client discussions and fixes. Because they weren’t covered in the initial planning, all of those upfront conversations have to happen at the end, where they are longer and more costly to make work (and when everybody is, frankly, ready for the project to be done).

Bill was pretty good about helping us stay close to our outlined scope. And when the multi-year project was done and we were disbanding and exchanging end-of-project gifts, what did Bill receive? A giant bottle of — what else? — Scope.

Designing for Hierarchy

Not all information was created equal. Or perhaps you could say that some information is more equal than others. Regardless, there are few times in which, as a designer, you want to splay it out with equal weight on the screen.

The vast majority of the time, you want to determine the information hierarchy. What should the viewer see as the top-level, categorizing content? What should they see as the important detail? As we view web pages (and, indeed, life in general), we as humans are always building mental models of what we’re experiencing. That helps us fit experiences into patterns and then know how to react.

So when people experience one of our web applications or websites, we want to make sure it feels at least a little familiar (even when we’re designing something way-wacky, there has to be something for the user to grab onto). So one of the first things we do when wireframing or mocking up pages is to determine the information hierarchy.

Once the chunks of content are bucketed that way, it becomes a matter of how to represent that in the design. There are several ways to do that, including through spacing, through padding or placement, through color, and through size.

This is an important header!

Virtually all of those four were employed in the above header, and as the eye scans the page, the viewer will assume that’s an organizational point for the content. But you need not be so obvious about it – often, we will use some subset of the characteristics to consistently denote hierarchies.

For example, one more subtle way to accomplish this is through strategic shading. Of course, we don’t use shading where it will impede accessibility or readability, but some light changes can help the eye determine where the important content is and where it isn’t. (Or, to be more generous, where the slightly less-promoted content is.)

In any event, the conversation about information hierarchy is one that comes pretty early in our discussions with almost every client project. And it’s a key fundamental of visual design.

Getting Better (Or: We Used To Be Worse)

I’m a bit of a pack rat. Somewhere, I have encomia that goes back decades. And in the digital world, this is true as well.

So when I got a new computing device recently and needed to migrate a bunch of data, I had an opportunity to look back at projects we’ve done over the years, and that I had done for at least a decade before. What I found wasn’t all that surprising, but it was instructive.

Starting with my early work, it was, well, fair. I mean, it worked and all (in fact, one web application I wrote a decade ago is still in production use on a public website – think about how much on the web has changed in that time!). But it wasn’t coded all that well, and the emphasis was on getting it done quickly and briefly. (In other words, the code was hard to read and not well documented.)

Then I look at a project from five years later, and it’s all different: sure, sure, it works – that much is the same. But under the hood, the code isn’t just quick, it’s efficient. And there are actual comments throughout. The front-end design and the ‘look’ of the work is leagues better (by that time, I didn’t do it myself, and we had a team with expertise in that area). It’s a professional product.

Then I turn to a project we finished last year, and it’s more advanced yet. The amount of growth isn’t as dramatic, but it’s still there. Development patterns are being used effectively and both programmatic and business logic is easily intuited from the code (and its documentation), and the separation of functions allows for easy manipulation of pieces and parts. It’s a great result.

This progression is hardly unique, I think – every person and every firm, if they’re stretching themselves and striving for self-improvement, has something similar. But we don’t talk about it much, because we worry that clients (or, more specifically, prospective clients) think “we get better all the time” means the same as “we aren’t really ready for prime time yet.”

But that’s pretty shortsighted thinking. Even the best sports pros are always working on their game. We can always improve – after all, that’s the whole point of professional development, right?

It was heartening to see that transformation over the last couple of decades. Who knows what the next project will bring?