Making HTML Manageable with CSS (Case)

This is a case study for use in a class like Software Development.

Please note: This case builds on a prior case called ‘From Prototype to HTML‘ and assumes familiarity with its contents.

Idea to HTML

HTML prototypeFrangelico DeWitt and his team have just started developing a new suite of software for their employer HVAC in a Hurry (a heating and air conditioning service business). Their current focus is on a web application that helps field technicians find availability and pricing for replacement parts.

Frangelico is in the midst of rendering his team’s wireframe into working HTML as a next step in the design process. The HTML version of the prototype helped him think through more details of the implementation and he feels better prepared to collaborate with his development team on its implementation as an actual application. He’s also gotten major kudos from his colleagues for being detail-oriented. The team has agreed it would be a good idea for him to continue to refine and detail the prototype as a next step (see Exhibit C for notes on his to-do’s).

The good news is that he has an early version working on JS fiddle (HTML Prototype in JS Fiddle). The bad news is that the HTML is getting long, repetitive, and generally hard to work with. He’s also finding certain things that need either CSS or Javascript to work in a reasonable way.

As a next step, Frangelico has decided he needs to organize both his existing details/styling and new additions in a CSS (cascading style sheets) file.

Making HTML Manageable

Frangelico is excited to build on his work with the current prototype. He’s also looking forward to doing a kind of ‘spring cleaning’ on the HTML, which has tons of unwieldy in-line styling that’s lately been creating errors and unnecessary grunt work for him.

He and his team settled on a general set of ‘to-do’s’, which you can find in Exhibit C . They also decided that ‘a stitch in time would save nine’, and for the sake of consistency and minimizing rework they put together a style guide. You can find that in Exhibit D.

The first prototype (Prototype 1) doesn’t look great or function beyond laying out the wireframe for the first page of the parts application. Frangelico’s started by organizing the existing styling in a CSS file- see Prototype 2. Next, he’ll tackle the items in Exhibit C.

Prototype 1: The Basics in HTML
Prototype 2: The Basics Organized with CSS

Looking at the sample code for Prototype 2, can you trace the CSS entries back to their application in the HTML? Try rounding the corners on the borders around the various HVAC parts. Does it work?

How would you tackle the items in Exhibit C? Reminder: log in to JS Fiddle to save your work. 

What else do you think is worth trying? Try it out!

Optional: Using CSS Grid

Responsive design deals with the problem of how pages will display on devices with different sizes and aspect ratios (ratios of height::width). These tools (you may have heard of Twitter Bootstrap) also generally give you more control and structure regarding layout. One currently popular and easy to use tool is CSS Grid. This facility is built into current versions of CSS. If you’re interesting in learning more (now or in the future), check out: a) HinH Prototype 2.5 where they’ve applied this and for background b) Codecademy Tutorial on CSS Grid if you want more background.

Exhibit A: User Stories

These stories are the primary focal point for the team: they describe both what the team has learned about the user and what they want to do for them. As you get into the details, it’s key not to lose sight of your design intent and what you’ve decided is important to the user.

Epic User Story

‘As Ted the HVAC technician, I want to identify a part that needs replacing so I can decide my next steps.’


Based on their observations in the field, Frangelico’s team thought through the user experience of the epic with the following storyboard: hvac-epic-story

Child Stories

User Story

Test Cases

‘I know the part number and I want to find it on the system so I can figure out next steps on the repair.’ Make sure it’s possible to search by part number.
Make sure descriptive info. appears as the search narrows (photo?) to help avoid error.
‘I don’t know the part number and I want to try to identify it online so I can move the job forward.’ Make sure it’s possible to search by make/model of units
Make sure it’s possible to search by type
‘I don’t know the part number and I can’t determine it and I want help so I can move the job forward.’ Make sure an estimate of the turnaround time for an expert to review is available
‘I want to see the cost of the part and time to receive it so I decide on next steps and get agreement from the customer.’ Make sure it’s possible to dispatch a request by email to the customer in case they order their own parts and/or carry their own inventory of spares.
NOTE: How would the customer respond so we can help structure the next steps as we would otherwise?
Make sure it’s possible to indicate priority
Make sure cost associated with priority delivery are available
‘I want to order the part so that we can move forward with the repair.’

Exhibit B: Wireframes

These describe the approach to the user interface the team’s going to detail and test further. For static mockup’s of the two concepts, see this Balsamiq file: Parallel Prototyping at HinH.



Exhibit C: Design Updates

The following is a set of quick notes the team put together:

Exhibit D: Style Guide

The greatest single visual design hack is consistency. A trained designer can help you figure out if your brand is best explained by green, blue, taupe, whatever, but if you don’t have access to that talent, just make sure to pick one and use it consistently. Don’t get me wrong: have trained designers involved early will get you a lot of mileage and is the best choice if you can manage it. However, a lot of scrappy teams don’t have access to that kind of talent, particularly in their early days.

Style Guides and CSS go together like peanut butter & jelly, like Felonious Gru and his Minions. A style guide is a way of focusing your look & feel and CSS is a way of centralizing and organizing that for digital. The style guide below is something the team at HVAC in a Hurry put together based on what they could find about their corporate guidelines and a few ‘best guesses’ about how things might look on their app.


Might this change? Yes, but they’re still better off making this explicit now and changing it later. It will help minimize and focus rework and it will make the work look better and more convincing.

Final note: For a web style guide, this is pretty minimal in terms of its specificity. That’s a good choice for the HinH team given where they are, but just for perspective, here are some expanded style guides from more mature operations:
Code for America
Lonely Planet

Exhibit E: Working with CSS

CSS centralizes the styling for your HTML, which is an important job in practice. For an example, just compare the readability and repetition in Prototype 1 vs. Prototype 2 (same thing but with CSS).

Let’s step through this example CSS entry from Prototype 2:

.catalog-part {
padding: 0px 5px;
float: left;
border-style: solid;
border-color: #808285;
border-width: 1px;
width: 150px;
height: 200px;
line-height: 200px;
display: inline;

The style elements in a CSS entry are enclosed in curly braces {} and should look familiar to you if you completed the preceding case (From Prototype to HTML). The first item ‘.catalog-part’ is a called a CSS selector. That selector specifies the HTML elements where the designated style should apply. In this example, that is elements that have a class ‘catalog-part’, like this div:

<div class="catalog-part">
<p>I am this div's contents.</p>

Matching these CSS selectors with the HTML you want to style is where a lot of the action/debugging  happens, particularly when you’re getting started. There are quite a few ways to formulate CSS selectors, but three are dominant and fundamental:
1. Element/Tag: Select all HTML elements with said tag. For example, this entry instructs all type enclosed in <p></p> tags to have the font Arial.
p {
font-family: Arial;

2. Class: Select all elements with this class. These start with a period and the ‘catalog-part’ class above is an example of this.

3. ID: Select all elements with this ID. These are used primarily for special cases and one-offs and start with a hashtag. For example, this entry instructs all elements with the ID nav-bar to have their type centered:

#nav-bar {
text-align: center;

ID’s in HTML look like the class designation you saw above, but instead they have the element ‘id’ (id=”nav-bar”). These three entries have increasing specificity and increasing precedence. For example, if an HTML element had both a class and an ID and both specified a font, the font designated by the ID would take precedence and be the one you’d see rendered.

The Resources below will help you through these and so will Google’ing your more questions.  Just like HTML, there are a lot of facilities and facets available, so I would focus primarily on working through the case and its implementation specifics. Otherwise, it’s easy to get lost in all the fun and interesting (but possibly not useful to you right now) things CSS can do.

That said, here are two few fundamental concepts you should be basically comfortable with for the case discussion:
How do you pair CSS entries with HTML elements?
What is the CSS Box Model and the role of content, padding, border, and margin?


For an introduction to the fundamentals of CSS, this is a good, quick resource: CSS Introduction. I would start here and see if it gets you through the case preparation.

If you want a more guided introduction and/or you really liked Codecademy, they have a module on CSS: Learn CSS. However, I would not plan to go through the whole thing: it’s rated at a hefty 11 hours! It’s also more than you’ll need for the case. A few lessons you might find helpful are: ‘Selectors and Visual Rules’, ‘The Box Model’, and ‘Display and Positioning’.