Table of Contents
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
Frangelico 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.’
Storyboard
Based on their observations in the field, Frangelico’s team thought through the user experience of the epic with the following storyboard: 
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: Understanding the CSS Box Model
First introduced at the turn of the millennium, the CSS Box Model is still foundational to how HTML elements appear on a page. Essentially, it frames all HTML elements as boxes on a page and provides a standardized way to manage how they appear. You see the Box Model for any element on a web page just by going to (for example) Chrome DEVTOOLS, making sure you’re on the ‘Elements’ tab and then selecting the ‘Computed’ in the right pane of DEVTOOLS. Here, you can see just that for one of the HVAC parts.
Zooming in on the Box Model visual detail in the right pane, we can observe (from the middle, out) that:
1. the selected item (catalog part div) is 150 pixels wide and 200 pixels tall
2. that the div has 5 pixels of padding on the left and right between the core element and its border (padding is the space between an interior element and its border
3. that the element has a uniform 1 pixel border
4. the the element has a uniform margin of 2 pixels (margin is the space between the item’s border and the next HTML element).
Here’s a zoomed in view of the Box Model visual overview:
The Box Model does not really describe the items position on the page: is it at the top, bottom, right, some weird place between things? For this, there are various CSS display properties like ‘float’ and ‘display’ and also grid systems like Bootstrap and CSS Grid (see case: ‘A Four Corner Design‘).
Exhibit F: Understanding CSS Precedence
CSS at scale, meaning a large site or application, has many overlapping CSS files. Central to the way teams manage CSS at scale is the concept of precedence: if two CSS entries say different things about the same HTML element (ex: ‘be red’), then which would should prevail? The guiding principle in CSS precedence is that the most specific entry should prevail. For example, the major precedence levels are:
- ID: ID’s are supposed to be unique, so this has a very high precedence
- Class: Classes are pretty specific, but not as much so as an ID, so this is the next level
- Element: You can create HTML element wide entries (ex: ‘all div’s) and these will have the least precedence.
Understanding the concept of precedence is important both to how you design your CSS and how you debug it.
Exhibit F: 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>
</div>
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?
Other CSS Resources
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. And don’t forget- AI’s are a great way to ask questions, particularly as you’re going through a specific bit of code.
