Normal Modes

Combating CSS Entropy: Four Steps Towards Scalable CSS

Scalable CSS Banner

Of all the tools we use in web development, CSS is the most susceptible to entropy: the idea defined by the second law of thermodynamics that the amount of information required to completely define the system is increasing. In other words, the quality and complexity of your CSS will only get worse over time.  

Programmers make use of object-oriented concepts like modularity, abstraction, and inheritance to reign in entropy in application logic, but such concepts aren’t natively supported by the CSS language and language enhancements like Sass aren’t yet widely accepted by CSS authors.

Why should we avoid CSS entropy?

CSS entropy leads to code bloat, and code bloat is a hurdle to building CSS that is scalable across many pages, many developers, and many users. Obviously, bloated CSS means that you need to download larger CSS files to the user’s browser, meaning greater server and bandwidth requirements, slower page rendering times, and lower page speed ratings from Google. It also increases the number of CSS classes that your developers need to understand in order to code up a page.

Code bloat vs. CSS entropy

Although code bloat is the most readily identifiable symptom of CSS entropy, I want to distinguish between the two concepts. Code bloat encompasses all those extra lines of CSS that separate the current, complete representation of the CSS for your website, from the ideal, minimal CSS required to completely represent your website. In other words, if the ideal, minimal amount of CSS required to represent your website completely is 16Kb, and your current CSS files are 64Kb, then you’ve got 48Kb of bloat.

Code bloat is a static concept, whereas entropy includes an element of time. It is the nature of CSS that it becomes more and more bloated over time. It’s important to make this distinction because we need to be adopting practices in our CSS that reign in CSS’s propensity to bloat as well as the bloat itself.

So how do we do minimize CSS Entropy?

  1. Avoid using ID tags in CSS selectors. ID tags are not reusable by definition. So every time you use them in your CSS, you are creating an opportunity for entropy. Sure, you can make a good argument that the wrapper div is unique on a page; and that the drop-down navigation is unique as well. But then you get into grey areas, where more often than not, you’ll be wrong in your assumption of uniqueness.
  2. Define your basic CSS classes before you start laying out pages. Too many CSS classes are created as one-offs to style a single page. You already know you’re going to need an array of button styles, form elements, and a couple of different table styles at the start of the project, so design them up front. This way any customizations you need to make down the road can build upon the existing classes, instead of being built from scratch. Moreover, a strong set of basic CSS classes encourages reuse and discourages customization. The best example of this approach that I’ve found is the MailChimp Style Guide.
  3. Make your CSS more object-oriented by breaking up your CSS mega classes into small, reusable components. We’ve all seen mega classes like .users-table or .registration-form that define every structural and aesthetic attribute of the HTML element. The thing is, if there’s a users table, there’s also often a products table or a posts table. By separating the structure of the component from the aesthetics (or context) of the component, you can create CSS classes that have a lot more potential for reuse.
  4. Use CSS language extensions, like Sass, smartly. Sass is great for creating modular and DRY CSS, but it also contains within it the power to generate enormous bloat. Mixins, by nature, create redundant lines of code that must be downloaded to the browser. The @extends directive is preferred because it creates a shared class definitions. And while I love the logical organization allowed by nested class definitions, I’ve found they encourage mega class definitions, rather than small reusable components. (Nesting also increases the number of comparisons the browser must make to match the CSS class to the HTML element, thus slowing rendering time.)

Our Recommendation:

Actively resist CSS’s tendency to degrade by adopting CSS policies that discourage entropy by encouraging class reuse.


If you liked this post, then you’ll love our Scalable CSS Frameworks webinar.

March 8, 2012 at 12pm CT. If your development team is struggling to make your current CSS work, or Google is penalizing your site for slow downloads, you can’t afford to miss this webinar. Learn more


UX Tips: Identify Opportunities to Reduce Friction

Friction is anything that gets in the way of getting tasks done. And one of the best ways we make an experience better is by looking for opportunities to reduce friction.

For example, this is the automated attendant at a parking garage near our offices. There’s so much friction to completing the task of inserting a ticket and paying by credit card that the parking company has supplemented the interface with a note – complete with numbered bulletpoints and  strategic highlighting – to explain how to operate the machine.

In this example, much of the confusion is created by the machine’s three different card slots. (Two on the right, one on the left.)  Imagine how much simpler it would be if there were only one ticket and credit card entry slot?  Why do you suppose there are three?

Note, too, that the handwritten instructions create additional points of friction.  While the word yellow is highlighted in yellow, the word green is also highlighted in yellow. And the word white is highlighted in pink.

Points of friction aren’t always so obvious.

Every application has points of friction, though some have more than others. Oftentimes we’re not aware of the friction points until we see the users of our application in action.

One way to identify points of friction is with a usability technique called contextual inquiry, in which users are observed completing tasks in their natural setting and asked probing questions during the process.

So, in parking meter example above, the observer would actually stand by the parking meter and watch people use it, asking questions as needed along the way. During the observation, the observer should take detailed notes, which include:

  • the sequence of tasks (pulls ticket out of ashtray -> inserts into box 2 -> stops to read sign -> pulls credit card out of wallet -> notices flashing light -> restarts process -> etc…);
  • points of confusion, along with any user articulated expectations for how interface should work;
  • failed attempts vs. the total number of attempts to complete the process in order to estimate how many attempts are required to figure out the process; and
  • any other observations that would reduce confusion or increase the usability of the application.
It’s important to watch people using applications on an ongoing basis.  We recommend that each team member (UX, visual designers, product managers, and developers) spend at least 4 hours every other month or two hours/month observing users interacting with their application.  Depending on iteration length, observation time can be built into the agile lifecycle with one observation session per iteration.  Not only will these observations help eliminate points of friction, they’ll also help fill the product backlog with meaningful, user-generated enhancements.

 

Our Recommendation  

To improve the user experience, look for opportunities to reduce friction.  Every team member should make it a habit to spend at least 2 hours each month watching real people using their applications, a process known as contextual inquiry.

 


If you liked this recommendation, then you’ll love our Ultimate UX Bootcamp

March 15-16, 2012 in Houston.  Featuring boots-on-the-ground data about specific UX & usability practices you can put to use right away. Learn more

Related UX Tips

 


Calculating ROI on UX & Usability Projects

 

From time to time, we hear about teams who are asked to deliver metrics that demonstrate the value of UX. Unfortunately, the basic metrics of the web like click-through-rates and subscriptions aren’t applicable to most software development. Oftentimes the request comes on the heels of a successful, but expensive, initial UX initiative when the team goes back to management for funding for future phases.

 

Defining one “correct” formula to calculate ROI can be a bit tough since the components of ROI change with every company/project.  

For example, the metrics of success for an oil trading platform are measured in absolute dollars ($), while the metrics of success on a usability for electronic healthcare record project might be measured in terms of $ and lives.  Our engagement with the Department of Veterans Affairs in Houston, for example, was designed to save $5-10 million/year AND 50-100 veteran lives.

For some companies, the key metric might be revenue for the company through new customers, with cost savings associated with additional operational efficiencies.  Sometimes this can be extended to non-dollar factors like lives saved, disasters averted (oil spills), and people influenced (e.g. politicians),  among others.

 

That said, ROI is always calculated in terms of increase or decrease of a key variable.

These increases and decreases usually fall into one of six categories:

  • Increased sales - either incremental revenue from add-ons or through an easier sales process, which is typically called “conversion rate” though that often gets mixed up with “website conversions”.  The metrics for this are typically found in the sales and finance department.  Coupled with the estimated costs of usability testing and UX development, you’ll be able to work out over what timeframe it will take for the UX work to pay for itself.
  • Increased productivity - Most often found when there are large pools of employees completing certain repetitive tasks. Metrics are found in operations, HR, and finance (for overhead items like office space, equipment, etc.)  For example, if you optimize the UX on a series of screens so that what was once a 5 minute task is now a 2.5 minute task, then you’ve increased a person’s productivity by 100%.  That’s huge.  HUGE.  If the company has 100 phone agents who have an average salary of $40,000 + benefits (~$8,000) (+ an unknown amount for overhead), you could either release or retask those agents on other activities with a savings of $2,4000,000/year. (half of 100 agents x $48,000)
  • Increased customer satisfaction and loyalty - This is extremely difficult to measure, and should be used as a primary cost justification only in extreme cases.  That said, one method of measuring customer loyalty is in terms of customer retention.  (Important especially in organizations that know when their customers are most likely to defect to a competitor or a more mature product offering.)  The calculation takes into account the cost of new customer acquisition and amortizes the cost over the average customer retention period. Increasing average customer retention is a cost savings for the company, and can cost justify UX & usability work related to customer loyalty.  The metrics of success will come from sales and marketing.
  • Decreased training and support costs - If customers generate calls or support tickets or other uncompensated overhead costs to the business, then those costs should be measured.  The easiest way to do this is how airlines handle the it.  When a passenger, for example, calls an agent to check flight status, the airline knows how long that call will last, and based on the average cost/minute for phone agents (including salary, benefits, and overhead like the phone line, office space, electricity, etc), the airline can assign a $ value to the cost of the call.  Because airlines handle large volumes of calls every day, if there is an increase of 2500 check flight status calls/day at a cost of $2.00/call (theoretical cost!), then we could expect that would increase uncompensated support costs by $5,000/day.  If the airline wanted to do a $50,000 eye tracking usability study to get that number down to 1225 calls/day (assuming a clean 50% improvement), then that usability study would pay for itself in 20 days.
    • Be wary in cases where training and support are part of the company’s core business model – otherwise it doesn’t make sense to decrease these costs, (i.e., if the company’s revenues are earned from consulting)
  • Decreased development time and costs - Measured in terms of development resources and time to market. For example, if moving to a system with design patterns and object oriented CSS will decrease the need for an additional UX hire and 5 developer hires (a reasonable ratio), then that’s a cost savings of all of those non-hires salaries + benefits + overhead (computers, software, office space, desk, etc).  Similarly, if a strong UX framework decreases the development time from 6-months to 3-months for a project that will increase revenues by $100k per month, then bringing the project to market 3 months early adds $300k to this year’s revenues.
  • Decreased maintenance costs - Again, this is a function of the number of developers needed to complete project work.  Bad UX is often a reflection of poor design and complexity in the underlying code. A hallmark of good UX is the elimination of unnecessary or marginal features. This reduces the complexity of the code base, making it more robust and less buggy. As a wise man once said, “there are no bugs in the code you don’t write.”

 

Always estimate ROI in terms of annual dollars.

Of course, all of these increases/savings must be compared to the costs associated with UX, usability, and development endeavors.  I recommend that all metrics be stated in the terms of increases/decreases over the course of a year – annualized costs – because that’s a term the folks in budgeting will understand, and a dollar amount that provides the most realistic impact.  (Not too much, not too little.)  So, if your project is designed to increase revenue by 20% on a million dollar revenue stream, then the dollar amount should be reported as “$200k annually.”

 

DO NOT wait to estimate ROI on an ex post facto basis.

I always recommend the estimated ROI for UX & usability projects be accounted for at in the project proposal or requirements phase, in order to avoid the ex post facto “prove the value of this project” situation many teams find themselves in at the end of the project.  When ROI isn’t calculated in the project vetting phase, it’s really easy to disagree about the metrics of success – what was the business objective?  cost savings or revenue generation? – and thus dismiss the value of the work.  Also you get in a situation where perhaps multiple factors for revenue and saving costs are at play, and then you’ve got a real mess to sort out in terms of reporting a “value.”

 

Ideally, every single potential project should be assigned an ROI value – either in savings or revenue – and projects would be racked and stacked according to that metric and complimentary fits,  e.g. If I’m already making a change in feature X, then I can combine that work with features Y & Z to be more efficient.

 

Calculating ROI on UX & usability projects helps get projects funded.

Finally, in organizations where usability is a political issue, the ability to assign a dollar value to UX & usability projects helps win over even the most skeptical critics.  Most often these critics see UX as an intangible, frivolous “design” activity.  When we approach these critics with a robust project plan to improve things – along with a hefty price tag - it’s easy to  say no to something that’s intangible and frivolous.  But if we approach them with a project plan that states the project costs and benefits in terms they understand, then we’re improving things for everyone – the critics, the users, and ourselves.

 


If you liked this post, then you’ll love our Ultimate UX Bootcamp

March 15-16, 2012 in Houston. (It’s a great time of year to visit!) Featuring boots-on-the-ground advice about what specific UX & usability practices companies can quickly and cost-effectively implement. Learn more

 


UX Tips: Provide Sufficient Form Field Lengths

It’s incredibly frustrating for user to have a form that needs to be filled out, only to be thwarted in their endeavors by thoughtless form field length issues.  And no where does this happen more than it does with last names.

Those with names that are quite long – like Stephanopoulos, at 14 characters - are often limited by an arbitrary 10-12 character restriction. For folks with last names greater than 15 characters, it’s even worse.

Similarly, folks with some of the most common last names on earth – like Ly, Hu, Ma, Ng, Xu, Fu, and Yu, at 2 characters – are foiled because someone randomly decides that there needs to be a minimum character length on last names.  It’s almost like the programmer completed an additional step to make it unusable.

For example, this image of a Facebook complaint appeared on imgur this week with the title “Asian problems.”

 

When form fields are insufficient length for user needs, we find several user behaviors:

  • Problems with data integrity as users try to game the system,
  • High abandonment rate, with commiserate increase in requests for support, and
  • Low response rate as users just give up.

Corollary: The Hyphenated Last Name

Users with hyphenated last names often suffer a similar fate, as hyphens return error messages for “invalid character.”  In response users game the system, producing data integrity errors.

 

Our Recommendation

When declaring form field lengths, consider the worst case scenario. Scrub an existing database for the longest character length and round up to the nearest ”5″.  If you have to declare minimum character length for last names, make it “2″ to accommodate every possible common scenario.  Accept hyphens, too.

 


If you liked this recommendation, then you’ll love our Ultimate UX Bootcamp

March 15-16, 2012 in Houston. (It’s a great time of year to visit!) Featuring boots-on-the-ground advice about what specific UX & usability practices companies can quickly and cost-effectively implement. Learn more

Related UX Tips

 


Ultimate UX Bootcamp – March 15-16 in Houston

Normal Modes will be hosting a two-day Ultimate UX Bootcamp on March 15-16 in Houston.

Day 1 will be a workshop on User Experience Design, you’ll learn:

  • Identify the characteristics of your users — their needs, fears and motivations
  • Organize content into intuitive navigation structures
  • Develop intuitive user experiences by using UX guidelinesclear, consistent, capable and nice.
  • Calculate the ROI of UX

Day 2 will be a workshop on Usability Testing.  We’ll focus on these practical essentials:

  • When to conduct usability testing
  • Identifying the right testing methodology — from paper prototypes to remote usability testing
  • Planning a usability test
  • Recruiting real users as participants — sorting out the bad from the good, and providing proper incentives
  • How to conduct a usability test! 
  • Analyzing test results to produce meaningful reports
  • Effective strategies for handling political situations

Register before Friday, March 2 and get 20% off by using promotion code LINKEDIN.


The typographic grid: still as useful today?

Either on your own or in school, you probably learned at some point about the origins of the typographic grid. You know grids were developed with measurements from the golden ratio, the measurement that defines good aesthetics. You may also recall that layout/design using the golden section is scientifically and psychologically proven to be the most visually pleasing for the printed word. No doubt that principles of grid layout laid foundational work for all of graphic design today, but in a time when there are so many variations in how users absorb information, is the typographic grid still as applicable?

 

The Golden Ratio

 

In short, the answer is: of course. The eye still gets tired after reading 7-10 words per line. Only now, eye strain is even worse because people are reading on a glowing screen all day. Additionally, multiple available touchpoints and a constant barrage of distractions make for a decent design challenge on its own. But a user experience designer has an opportunity to meaningfully forecast these issues and make a difference for users. It’s a thankless job–sometimes your only job is to get people to read the core message, not to do it beautifully. Grids are more important to us now than ever–they can adapt to screen sizes and change a user’s experience instantly. And as always, grids give us an opportunity to quickly and beautifully get content to users.

Use the grid across platforms and devices

Many companies today reach people in multiple ways, so web and user experience designers are expected to adapt to sending a core message in several different ways. No problem! You can use the same grid on a website or a mobile device. This may seem impossible, as column widths obviously would seem so much smaller on a mobile device, or completely overwhelm a large monitor–but here’s where one of our heroes, the fluid grid, enters the scene.

There has been a lot of top-notch attention lately given to  fluid grids, especially since the advent of responsive/adaptive design. Here’s why: fluid grids combined with screen-size-sensitive media queries allow you to create one online experience that adapts to countless devices (some companies will be able to kiss their mobile sites goodbye!).

In order to calculate the measurements for your fluid grid, you probably will need to start with a design that already has some elements defined in pixels: the container and maybe a couple of columns, for example. Once you have those, you’re ready to see magic in the math.

 

 

To get the correct measurements for your fluid grid, Ethan Marcotte, founder/leader of the responsive web design movement, says,

“We take the target value for each element’s font-size in pixels and divide it by the font-size of its container (that is, its context). We’re left with the desired font-size, expressed in relative, em-friendly terms. Or to put it more succinctly: target ÷ context = result”.

That number is converted into a percentage and that determines the column width (Ethan’s article on responsive web design does an excellent job illustrating this technique). Therefore, even your carefully-crafted grid can adapt and be responsive to multiple devices while still maintaining a consistent visual harmony. And, provided your media queries are correct, telescoping on a mobile device should not be necessary.

 

 

Why use the same grid on multiple devices? Not only does using the same one grid save an immense amount of time and energy, you can reuse all assets by using a single grid. This saves even more time and energy. The same image asset can be used on a mobile device and an email, a landing page or a kiosk screen. The image doesn’t need to be cropped or renamed. Additionally, by using the same grid across touchpoints, your site is likely to be easily modularized, if it’s not already. Take one piece here, plug it in there. Seamless.

Grids are not limiting

I have heard some user experience designers claim that they find grids limiting. I completely cannot relate, because the grid is actually an incredibly liberating design device. You probably already know (thanks to a template or style guide) where the headline will likely go, how a callout will work, where photos will appear, etc. Influential graphic designer and educator Ellen Lupton famously said, “To say a grid is limiting is to say that language is limiting, or typography is limiting.”

The best page layouts, in my opinion, are ones you don’t even notice. Swiss design taught us this. Their minimalist aesthetic and thoughtfulness towards human behavior set the standard for how we read the printed word today. Think about reading a really engrossing book: do you even notice the page numbers, the width of the margins, or the leading? Your mission as a user experience professional is to get people to the core message, and the grid enables designers to present that core message in a meaningful way.

The medium of the printed word has certainly evolved and changed–a glowing screen, after all, is the new “printed” word. However, the underlying principles of good layout and typography really have not changed. The thought leaders on web grids have poignantly reminded us that we need to be mindful of the grid as not only a powerful layout tool, but a necessary structure for commanding information and most importantly, getting our core message to users.



Lacey Graves Gerard is a design generalist living and working in Houston, TX. She specializes in designing experiences for the web, mobile devices, and kiosks and infuses each of those touch points with her passion for and understanding of graphic design. And, she can make a mean bowl of popcorn.  You should follow her on twitter here.