Best Practices

Details
Written by: Gary Elsbernd

The thing about best practices is they never stay the same.

Long ago, best practices told us fixed-width websites using table-based design were the way to ensure a consistent experience for users (of course, all users were surfing using desktop computers, and you had to choose 800×600 resolution to get all of them). Best practice also led us to the era of “looks best in Internet Explorer” or Netscape Navigator. Back then, I thought I was keeping up with the trends to help anyone who came to my site see things the way I intended.

My problem, and the problem shared by the people who created and popularized the best practices — was I’d chosen a my own familiar, comfortable context for the sites I’d build. I was building websites for my context: the browsing conditions that I was used to. I was doing my work on a fast computer with a modern browser, large high-resolution monitor and a high-speed internet connection—that’s what the web was, to me.

We have to change our context, from providing the web the way we intend, to allowing visitors to consume our web the way they desire.  That could mean on a mobile device, using a variety of browsers, or on a 3G connection. Our web resources have to be flexible enough to adjust to the context of the visitor, instead of allowing ourselves to set the ground rules. That means keeping up with the latest best practices, and being willing to challenge or even reject “best practices” that don’t serve our visitors.

Dashboards: Ideas with Action

Details
Written by: Gary Elsbernd

To quote a Japanese proverb, vision without action is a daydream.

I was working on dashboards within a logfile collection last week, when I was challenged how to determine the right components for the dashboard, and had several insights.

  • There is not one "dashboard" - there are dashboards for each stakeholder. The data of interest to each stakeholder depends on his or her entry perspective.

  • Dashboards are meant to provide a synopsis, not the whole story.  A user needs to be able to identify issues at a glance, with as little involvement as possible.  Pie charts, bar charts, and averages all provide a high level indicator that can be drilled down if something looks amiss.

  • The level of information isn't the same across stakeholders. Trends over time may be significant to an executive, but an engineer may need specific details at the transaction level. A system wide response time number is relevant to a user who knows tolerances and expected values, but a global number may mask small components within the average. Drill-downs, trends and thresholds are all contextual to the user viewing the dashboard.

  • It isn't enough for the data represented to be interesting. Seeing where in the world our users are connecting from may be interesting, but have no impact on me or my plans. I have to be able to act on the information, or I am just presenting trivia.

This leads me to my overarching recommendation on dashboards:

"Identify the highest level of visualization for each stakeholder that provides meaningful information, leading to action."

 

Presenting a United Front

Details
Written by: Gary Elsbernd

Have you ever tried justifying hiring an artist for a project? In this age of the Internet and nearly limitless clip art, it can be daunting to ask for more money to create one-off imagery for your app or site. Why should you purchase bespoke images for your project?

Remember “Who Framed Roger Rabbit?” In that 1988 movie, Roger Rabbit hires Eddie Valiant, a real world private detective, for a job in Toontown. While the groundbreaking interaction between the live and animated characters was visually compelling, the styles clashed. The toons were overly bright, flattened and followed different rules of physics than the real-world characters.

When you mix clip art styles, you get much the same effect, without the wonder and enjoyment. Flat active tabs next to overly rendered, gradient tabs with shadows look like an obvious mistake. Icons with flat graphics interspersed with images drawn with perspective lend different meanings to the buttons that are unintended. Even things like using solid silhouettes for your icons along with outlines is setting you up for misunderstanding. People will always assign meaning to their cognitive dissonance, and usually their mental models have little or nothing to do with the developers’ intent.

Spending the time or money to have a consistent look and feel to your interface provides the polish and experience that allows the interface to fade into the background and the activity to come to the forefront for the user.

For more information on mental models, check out my That Old Black Magic - Identifying and Dealing with Superstitious Users.

Pets vs Livestock: Making the Move from Unique Creatures to Commodities

Details
Written by: Gary Elsbernd

An analogy that caught the industry interest recently is a comparison of IT delivery styles with how we treat pets versus cattle.*  In a nutshell:

  • Pets are owned in small numbers, uniquely named, hand reared and lovingly cared for — they are, by all considerations, members of the family. They are unique, lovingly hand raised and cared for. When they get ill, you nurse them back to health.

  • Cattle are owned in large numbers, tagged using a standard system, identical, managed in herds, and bought and sold as a commodity — they are, in effect, food. When one gets ill, you replace it with another one.

  • Many traditional IT departments are pet owners. Servers and applications are designed from an enterprise perspective — services are tightly coupled, relying on scale-up systems and relational databases. They are lovingly and expensively cared for, with great attention and affection.

  • Modern commodity server users are cattle ranchers. Applications are designed to require little maintenance, to handle failure and to scale out. Services are loosely coupled and stateless. If a server fails it is easier to replace than fix — there is no emotional attachment.  Moving from pet owners to cattle ranchers would allow us to be more nimble and focus our efforts more on writing application code that makes us different.

I was feeling pretty good about myself for proposing moving to commodity servers, until I realized I am guilty of the same thing.

In my CSS files, I often write a quick patch for a specific use, and name it with something that seems relevant at the time.  I sometimes ignore the larger applicability of the style, or flexibility within SCSS, or neglect to migrate these larger style patterns to common repositories.  These styles are pets, and lead to anarchy and redundant CSS.

Going forward, we are adopting the BEM standard for CSS naming. BEM stands for Block, Element, Modifier. It is a method used to construct CSS class-names so they are consistent, isolated, and expressive.  The naming convention follows this pattern:

.block {}

.block__element {}

.block--modifier {}

.block represents the higher level of an abstraction or component.

.block__element represents a descendent or dependent of .block that helps form .block as a whole.

.block--modifier represents a different state or version of .block.

This standard focuses us on global uses for styles and makes it easier to find a style than guessing what unique name was chosen at a given time.

A few good resources for learning more about BEM methods are:

• CSSWizardry

• CSS-tricks

• Smashing Magazine

 

*This analogy was developed by Bill Baker at Microsoft, and expanded on by presenters at CloudScaling and CERN

Knowing where you are going doesn’t always require you to know where you’ve been

Details
Written by: Gary Elsbernd

I teach orienteering and GPS navigation to Boy Scouts, and hear a lot from older Scouters on both sides. Map and compass guys always tell me they would never trust themselves to a battery-powered device when they are in the wilderness, and GPS guys scoff at the sets of directions like “go 342 degrees for 120 feet” and can’t believe anyone still does that. On the one hand, if you use a map and compass, you have to have a better feel for the topology around you and understand each step (pardon the pun) of getting from point A to point B. If you use a GPS, it doesn’t matter where you start, you can get to point B as long as you trust the technology implicitly and it doesn’t fail.

I see parallels in the discussions I have at work sometimes. There are older coders (like myself) who grew up with computers we programmed from the ground up, going through DOS and Unix commands, working intimately with the file system, and understanding HTML from the foundational levels. That gives us a strong background on which to understand the performance model of the software and what could be wrong when things don’t work as expected. On the other hand, younger coders don’t care that you used to have a DOS layer with Windows on top and a browser above that. They have been digital natives their whole lives and can take for granted much of the early years of computing because they rely on tools and frameworks that shield them from the minutia. They have difficulty when the code doesn’t perform as expected, because they don’t really understand everything that it is supposed to do in the first place. Having said that, they also can keep pace with change better because they don’t have a ton of bad habits to break, and they don’t have the same blinders on about what is possible and what isn’t. Not knowing something is impossible is often the first step to making it possible.

I am grateful I grew up when I did and have an understanding of what came before, while being able to take advantage of tools that don’t require me to code everything by hand anymore. It’s a balance that everyone has and I’m sure years from now the young coders today will be complaining that the new coders of the day don’t understand the CSS and Javascript libraries they are using in the next generation of technology. To quote Battlestar Galactica – “All of this has happened before, and all of this will happen again.” So say we all.

Page 4 of 6