Table of Contents
This is a case study for use in a class like Software Development.
Putting Ideas to Work
Frangelico DeWitt leads a digital transformation team at HVAC in a Hurry, an HVAC (heating, ventilation, and air conditioning) service firm. After spending a few weeks in design sprints to figure out what would move the needle for HinH, they’ve decided to test a web application that helps HVAC (heating and air conditioning) technicians check on the availability and pricing of replacement parts.
They have a set of user stories they think are solid for a first go. They drafted two parallel concepts for these based on comparables and after some exploratory user testing, they’ve settled on ‘concept 2’.
Frangelico has a working prototype he’s pretty happy with. However, he’s noticed some issues with how the page looks on certain devices- his phone, for example. He asked his dev. colleague about this (Sri), and she recommended he implement a responsive grid with CSS Grid.
Toward a Four Corner Design
Frangelico has a new working version up here: HVAC Part Detail Page with CSS Grid.
Where will Trent the Technician be and what device will he be using when he interacts with the application?
Looking at the sample code on JS Fiddle, can you identify how the new CSS class ‘parts-display’ is now controlling the div’s related to the catalog parts?
Some items are now commented out of the existing ‘catalog-part’ class. Why?
Suppose you wanted to increase the width of the catalog parts- how would you do that? What if you wanted to increase the space between them?
Are you able to confirm the effect of your changes? In Chrome DEVTOOLS, click on the ‘grid’ button to analyze the details.
What else do you think is worth trying? Try it out!
Exhibit A: User Stories
These explain the design intent for the team’s new web application.
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: The Job of Responsive Design
In the olden days, a web designer or dev might ask you ‘What resolution should I design for?’ This was expressed in pixels (ex: ‘800 x 600’), and there was never a great answer. You could take your best guess about what resolution your user might have. Even then, there was substantial variation depending on whether they had a laptop and/or an external monitor, an old-ish or new-ish computer. But what happened to everyone else? Really, this was about punting in a not-so-great way: the right answer would be to make sure that within reason the application or page performed reasonably on a big-ish or small-ish screen.
Then mobile happened and fortunately that forced the community of practice to really think about this problem and come up with a more reasonable approach. Basically, the sane thing to do is think about your design (for a given page) in terms of its four corners. In the case of extreme wideness or narrowness, what happens? You can see some examples of this with the HinH page below.
Does this mean you always need to make sure your design works great on every possible form factor? In a word, no. All the core product design principles you hopefully learned from me (or someone else) still apply here. Declare explicit hypotheses about the following and test them before you waste scarce design and engineering time:
Who is my user?
What is the underlying job/problem I think is important to them?
Where will they be (and what device will they be using) when they interact with my solution?
How do I instrument analytics into what I’m doing so I’m continually testing my answers to the above?
And comparables- those are still super important! Check out how relevant applications handle the various form factors you think are most important to your UX and consider those as you wireframe and develop.
Below are a few examples of how the current JS Fiddle looks in various form factors. You can try these out for yourself by opening Chrome DEVTOOLS and clicking on the ‘toggle device’ button (indicated by the black arrow).
Happy Baseline
If only life was always this simple…
iPhone X
The coolest phone you can buy at the time this was written.
iPad Pro
Not so bad with a horizontal orientation, but what about vertical?
Super Wide
Go wide…
Exhibit D: The Operation of CSS
This case assumes a general familiarity with CSS, but if you are new to it, you can check out the exhibits in this preceding case: Making HTML Manageable with CSS.
Exhibit E: Finding the Right Solution with CSS Grid
Conveniently, it’s native to CSS and doesn’t require any additional libraries. The basic idea is to declare the container for the content in question (often a div) a grid. You can see this in the sample code in the ‘parts-display’ class and the declaration is made by setting the display property to ‘grid’:
.parts-display {
display: grid;
…
}
That’s it, as far as getting started. At this point, I would take 10-15 minutes to review the following tutorial from W3Schools: CSS Grid Layout Module. This will give you a brief but general perspective on CSS Grid.
Like so many things in coding, there are a lot of options/facilities within CSS Grid and for any given page you’ll only need a few of them. In the balance of this section, I’m going to go over the application of a few of them from the sample code. However, the best way to approach your project is to think about what you want to have happen (aka design) and then look around for notes on how to implement that design. For example, knowing that design pattern of the rectangular HVAC parts is often called a ‘card’, I Google’ed “css grid card layout” and found this article I used as a starting point: How to create a card layout using CSS Grid Layout.
Let’s step through the specific example of the CSS grid properties at work on the div class applied to the HVAC parts:
.parts-display {
display: grid;
grid-template-columns: repeat(auto-fill, 150px);
justify-content: center;
grid-auto-rows: auto;
grid-gap: 0.25rem;
grid-auto-flow: row;
}
display: This is set to ‘grid’, which is what enables CSS grid. There are a couple of other arguments that also do that (like ‘inline-grid’), but those are more the exception and you’ll find them if you need them.
grid-template-columns: This specifies how many columns I want in the grid. There are a number of ways to specify this, but here I used a function called ‘repeat’ and I’ve supplied it two inputs: a) the number of repetitions and b) the wide of the columns. For ‘a’, I actually specified ‘auto-fill’, which is equivalent to saying ‘put in as many columns as you can’. For ‘b’, I set the width the 150px, which has been the width of the individual parts. In the ‘.catalog-part’ class sample code, you’ll notice that I’ve commented out the width there since that’s now controlled by this CSS Grid property.
justify-content: This controls the alignment of items within the container. I’ve set it to ‘center’, but you can try setting it to ‘start’ and you’ll see that brings the parts left-ward to the start of the container.
grid-auto-rows: Given I don’t know how many rows there might be, the value ‘auto’ tells it to make as many rows as it needs.
grid-gap: This is the space between the items in the grid (the HVAC parts), which I’ve set to ‘0.25rem’. rem is a unit of measure that’s set relative to the type size- so this moots the 2px margin that was in the ‘.catalog-part’ class, but does the job in a slightly different way.
grid-auto-flow: This controls where elements go. The row argument says ‘create new rows’.
Optional Resource (Use Sparingly, If At all)
If you want more depth on this, check out the Codecademy Tutorial on this: Learn CSS Grid. As a reminder, just do enough so that you’re comfortable to go back to the case. This tutorial is very long and covers a lot of material you won’t end up using (but could likely learn by example as you need it).
Exhibit F: Using Chrome DEVTOOLS to Analyze Your Grid
Chrome DEVTOOLS offers excellent tools for CSS Grid. To access DEVTOOLS, on Chrome go to any of the options under View >> Developer or right-click on the item of interest in click ‘Inspect’. For the item that’s a CSS grid, you’ll see a ‘grid’ button that toggles DEVTOOLS’ description of the grid. For more, see their tutorial: Inspect CSS Grid.
