Tag Archives: work

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?

Designing With Audio: It’s Doesn’t Have To Be Annoying

We’ve been working on a project around here that is very audio-focused, and that’s a little unusual for us. Most of the time, the visual is the primary medium, and if there’s audio at all, it’s an ornament. Flipping the script, if you will, has been eye- and ear- opening. Some of what we’ve learned we will be able to use back on our more traditional projects.

The first pre-conception that some of us had was that audio was annoying, or a nuisance, or something that was frivolous. Surely, when it’s used poorly, it can be all of those things.

But as I type this blog post, I’m listening to the sound that the keys make as I strike them. It’s a feedback mechanism — in addition to the tactile one, of course, but an important one nonetheless. I still long for (and keep threatening my workmates that I’ll get) the old, heavy, metal IBM-style keyboards that really made a ruckus when you typed on them. The deeper tactile feedback was useful (and it really built finger strength!), but the more solid tapping/thunking sound was a key part of it.

If you’re an iPhone/iPad user, think of the beeping sound you get when you invoke Siri. You don’t have to be looking at the device to know what you did — it’s immediately obvious. How do you know? The sound. It becomes an interface-navigation feedback piece.

Then there’s the more traditional navigation feedback — where audio *is* the interface. The clearest example of this is hands-free interfaces in cars, but they exist on all kinds of other devices, too. Navigation systems that read out turn-by-turn directions, for instance. The audio is so important that it’s a selling-point, a key feature.

As we delved further into this audio project, we realized that by being mindful of the audio design as much as (or more than) the visual design, we could achieve a similar combination of functionality and beauty. We just had to toss our preconceptions at the door – and open our ears.

Getting to Forest Height

I’ve just gotten back from a lovely vacation, spending some time relaxing and away from the pressures and day-to-day of work. While the vacation glow persists for another day or two, it got me to thinking about the tremendous value of just stepping back for a bit.

It is a truism that we often miss the forest for the trees; that is, we get so enmeshed in the detail of things that we can miss large-scale trends or broader context. That’s not to say the details aren’t important — in fact, in terms of execution, they’re incredibly important — but in isolation, they can be crippling.

Getting even just a few days away from the current project can be helpful to come back to it with fresh eyes and a fresh perspective. New approaches are more obvious, as are (more importantly) new questions: Why are we doing it this way? Are we really on track to meet the intended needs? Does this all still make sense?

The tech world mythologizes the start-up work environment where everybody works 20 hours a day and sleeps in their cubicle (or works around the clock from their bedroom). There are times when that may be necessary or desirable. But I’d submit they are pretty few, and if they’re not interspersed with time for recharging and replenishing both cognitively and emotionally, you may end up confusing motion with progress.

When Is It Done?

When you’re working on a development project for a client, it’s often pretty easy to figure out when you’re all done with it.

After all, you did a requirements document before you started, right? So you know you’re done when the requirements are all met, and the client is happy. Easy peasy.

But on a design project, it’s not always so easy. There’s always something more you could tweak. One more adjustment to that logo, one more look at the spacing on that text. Where does it all end?

Well, on projects where we work by the hour, we usually apply what we call the 90-10 rule. If the last 10% of minor fiddling is going to take lots of time and be virtually invisible to the client, we stop at 90%. Then, when we show options to the client for feedback, we review what additional things we could do (and how much time they’d take). That way, the decision is the client’s.

But on projects where we have a flat fee, it’s a little tougher. At some point, there’s a diminishing return, but when you’re immersed in a project, it can be difficult to see it. So as designs are nearing the end stages (before getting final client sign-off), we do an internal review, and have a discussion about what’s where, and what could still be done, and figure out if it makes any sense.

These discussions are often spirited, and also often lead to great design outcomes. We do it on the dev side, too, but usually earlier in the product cycle.

It can be difficult when you’re head is down on a project to see that you’re done. That’s why we rely on others to help.