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

Created: Thursday, 08 October 2015 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

 

Sliding Panes and Navigation Drawers

Created: Monday, 13 July 2015 Written by Gary Elsbernd

The menu itself is nothing new; sidebar menus with links to various parts of an app/site have been used since the early web (and probably elsewhere perhaps earlier still) to provide contextually relevant navigation. Also, buttons that toggle hidden content or optionally allow dragging to reveal content have also existed for much longer than touchscreen smartphones; the drawer in older versions of QuickTime Player and OS X’s color picker swatch drawer are good examples of this.

The patterns and terminology are getting muddied lately. After going through designer idea books, the iOS and Android guidelines, there is no consistency in behavior is lacking. I will attempt to describe each of the relevant patterns and proscribe their use.

Sliding Pane

A Sliding Pane starts “off screen”. When the user taps a navigation icon (often a “hamburger” button), the pane slides in, often from the right, OVER the current content and dims the main content. The menu is presented as “above” the current content, and therefore has prominence in the display. This menu is modal (the user cannot interact with the main content until the menu panel as been interacted with or dismissed). Tapping the dimmed content dismisses the menu. Drawer.js is one popular implementation of this pattern – http://git.blivesta.com/drawer/

The pane content is meta content intended for temporary access (navigation buttons, chat contact list, etc.),

The activation button is always visible, and featured in the header immediately next to the side the drawer will appear on.

Navigation Drawer

A Navigation Drawer also starts “off screen”, but the drawer is part of the same page grid as the content. When the user taps the navigation icon or drags the screen, the drawer slides in, often from the right, pushing the main content to make room. This pane is non-modal (the user can interact with the main content or the menu panel) and on the same level as the main content. This can be implemented as a persistent object (stays onscreen until actively dismissed), or it can be dismissed when an option is chosen. This pattern is seen most often in apps and website focused on information consumption that use a left-to-right hierarchy. Snap.js is a terrific implementation of this pattern – http://jakiestfu.github.io/Snap.js/demo/apps/default.html

In either case, in a responsive website shown on a large screen (desktop or tablet), the menu may be shown persistently without the ability to dismiss.

These menus scrolls in the same way a view scrolls, independent of the main content.

 

Change is Inevitable, but is it Invisible?

Created: Tuesday, 07 July 2015 Written by Gary Elsbernd

The internet is full of stories of a website making what they consider a small change, only to have their user base revolt, often leading to rolling back the changes.  Facebook is often attacked whenever they make any change to their timeline, layout, or even their logo.  While these changes are noticed and talked about ad nauseum, I recently read an article by Kathryn Whitenton from the Nielsen Norman Group about Change Blindness, which is the other end of the spectrum. 

But first, a magic trick:

 

Mentally, select a card and concentrate real hard on it…

Don’t click on it or even point at it though…let’s keep this difficult…

 

Change blindness is the tendency of people to overlook alterations in images, especially when those changes appear immediately after a visual interruption such as a flickering screen.  If your website reloads when the user clicks a button, a change to the menu, a notification or a secondary option can be easily overlooked.  If those changes are important to the user in performing the task, that change blindness can severely impact your user experience.

The factors that impact this effect are proximity to the user’s fixation point, interruption of our visual perception and speed.

  • Proximity – As the user works his or her way through the site, their fixation point moves.  If the change you make is in the menu, the header, or a notification that is away from where the user is focused, or worse yet, off screen, the chance of the change being noticed is low. I purposely moved the link to click away from the cards to increase that distance.
  • Interruption of visual perception – your vision is interrupted when a page reloads, when we blink, when our eyes are quickly jumping from one fixation point to another, or when a screen display shifts as a device reorients from vertical to horizontal presentation. I took advantage of the screen change to interrupt your visual perception.
  • Speed – Fast changes in visual details are more likely to be missed by even brief interruptions. The blink of an eye is typically 300-400 milliseconds; change blindness has been observed when an image is interrupted for just 67 milliseconds. With the refresh, the change was nearly instantaneous.

In reality, all of the cards from the first set were removed and replaced by similar cards. No matter which card you had chosen, it would have “disappeared.” The change blindness, however, caused you to miss the fact that all cards were gone and just focus on your card. 

How can we design for change blindness?

If seeing a change is important to the user experience or the user’s ability to successfully complete a task, you want to minimize change blindness.

  1. Make changes obvious – use color or size to draw attention to the change.
  2. Make changes close – ensure any changes to instructions, notifications, warnings, etc. happen inline or as close to the user’s interaction as possible.
  3. Make changes without a refresh or scroll. Instead of refreshing, switching pages or tabs or any other shift of context to reveal a change, work inside the page with AJAX calls.
  4. Slow changes down. A slower animation, such as a fade, can draw attention to a change on your screen.

And if you want to write me to complain that a good magician never reveals his tricks, remember I never claimed to be a good magician.  

“Change Blindness: Why People Don’t See What Designers Expect Them To See” Kathryn Whitenton, 2015.

 

Ideas with Action

Created: Monday, 22 June 2015 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."