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 ‘Making HTML Manageable with CSS‘ and assumes familiarity with its contents.
Grinding it Out
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.
While rendering the teams ideas into working prototypes, Frangelico has pretty much come to the conclusion that to code is to debug. Working through the issues and getting the code to do what he wants has been a great education in being detail-oriented and test-driven. Focus has been important. Having a nice clear idea of they wanted to do in the first place, in the form of users stories and wireframe prototypes, has helped him to focus.
He has a working HTML/CSS prototype on JS Fiddle- HTML & CSS Prototype . As a next step, Frangelico needs to sort out a couple of bugs/issues he’s noticed.
A Series of Small Problems
The Google Slide embed below describes the current issues–
Using the Chrome DEVTOOLS, Frangelico is working through and fixing the issues on the HTML & CSS Prototype. Use whatever process you like to do the debugging EXCEPT comparing this current JS Fiddle to other versions from the associated cases. That is a shortcut that won’t help you with your analytical debugging skills.
To get started with the DEVTOOLS in Chrome, just right click on the JS Fiddle and select ‘Inspect’ from the menu you’ll see.
Here’s a general set of steps you may want to consider (for each individual issue):
What is the HTML element concerned? How does it relate to the elements around it?
What are the applicable CSS selectors (classes, ID’s, etc.)? What CSS entries do you see for those? Note: the DEVTOOLS will show you which CSS has precedence if there’s overlapping entries.
You can fork and save the JS Fiddle to preserve your work for the classroom discussion.
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:
|‘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: Using the Chrome DEVTOOLS
There are even small practice exercises for you to use in-context as a warm-up. A few things I would be sure you can do by the end of reviewing these and applying them in the case (or wherever you like):
- Identifying an HTML element
- Identifying the element’s Box Model properties and changing Those in Live-Edit (HOWEVER I would not worry about ‘persistent authoring’)
- Understanding the ‘Styles’ vs. ‘Computed’ styles in the Elements menu, and how to live-edit a given CSS attribute
- Targeting the correct line/area in the correct CSS file and updating it on your live site/asset