In early June I was granted the opportunity to teach a 3-credit hour course in basic website design and development at Vincennes University. I’ve taught classes before, or at least been involved in other classes, but always with a catch. Either the class was an hour a week, had no software or was an optional “extracurricular” activity. This was my first time teaching in a true academic capacity.
My students were high school age, though they were enrolled in a college-level program, so that’s the course they got. I wouldn’t have made it any different if they were middle schoolers, high school honor students or special needs or if they were college students or adults. Teaching a web course is either done right or it’s not.
My course was condensed into two weeks, but it was the same amount of time in any standard college-level semester.
My approach would have been different if we didn’t have a client to work for, but in this case, we did. Red Skelton, the famous comedian and clown from the early days of television is from Vincennes. He has a museum and foundation in his honor and the foundation was in need of a website redesign.
Here’s the site we ended up with: http://justifystudios.com/labs/skelton/
How we did it
My students had no prior experience in web development. No grounding in color theory, design theory, typography, etc. They had no understanding of CSS or DIVs or semantic markup, either.
To start, I ran the projector from the instructor’s machine and we talked about the site. We talked about what we did and didn’t like and they had a lot of productive comments on this matter. We talked with the client at one point about what they did and didn’t like and the students took notes on that information. We looked at other museum websites for inspiration and each student spent some time looking up sites that fit what we were trying to do.
Next, we walked through the process of sketching the site. I had each student come up to the board and sketch an idea in general terms where the navigation should go, where the logo should go, etc. This allowed us to have discussions and sometimes heated debates about whether or not the navigation should go across the top or down the left side of the page. My goal throughout this process was to play the devil’s advocate and mention the downsides to all the suggestions they offered.
Why just the downsides? Because it gets them thinking about the problems they may run into later. It allows them to think out into the future and make more appropriate plans now. It also let them understand, first-hand, the importance of planning in a large scale project. That’s something I didn’t appreciate when I was their age, probably because the projects we worked on in school were so simplistic that planning just took a few minutes.
Eventually, the students took the good ideas they liked from each other’s sketches and merged them into one. I did nothing more but stand in the back and question their motives to keep them thinking.
After they had all agreed on a sketch with a basic premise of content placement, it was time to mockup the site. We used Fireworks in my class because I’m most comfortable with it and I believe its the best product available for mocking up sites. However, you could have just as easily used Photoshop or Illustrator, if you prefer.
Everyone in the class mocked up the site along with me, as I drove the instructor’s machine. This was for a couple reasons. One, it keeps the students engaged and clicking in the software first-hand, as opposed to my driving and leaving them to sit and watch a lecture. Second, it ensures I have “the master copy” of the mockup to hand to the client. Keeping in mind they were expecting something usable out of this endeavor, they needed some assurance of a quality product. My maintaining the same files as the students ensured things were done well enough. Some students may have missed a step here or there resulting in slightly different mockups for each, but they were all “similar enough”.
The mockups were done similarly to the sketches, where students voiced input on things like the color scheme, typography, content placement, navigation hierarchy and more. It was during this time that took up the most of the class time. This is where we discussed things like color theory and cool vs. warm colors, we talked about serif, sans-serif and script fonts and we talked about grids, layout techniques and content architecture. The students were quite adept at recognizing redundancy in site content (i.e. a “Feedback” page and a “Contact” page present on the current site).
The most difficult part of the mockups came in the color choices. This was extremely difficult because each student had a distinct opinion and colors are hard to get right anyway, even for professionals. The color choices ranged from stark blacks to hot pinks. We made use of Adobe’s Kuler app, which helped and opened a dialogue about colors that are analogous, complementary, triad, etc.
Once we got past those issues and we all agreed on the layout of the homepage, I emailed all of my students my master mockup so we could all be precisely the same. I knew that working with pixel dimensions as we coded the site would cause confusion if my square was 905 pixels tall and the student’s was 895 pixels tall.
We proceeded into Dreamweaver where I spared no time. I had the students walk through, with me, the basics of inserting a DIV and a Class, inserting images, modifying font colors and text and explained the various parts of the page like the <head> and <body> tags. While I could have used HTML5, we used XHTML as the software we were using, Creative Suite 4, has less support for HTML5 than does the CS5 edition. This period allowed me to explain the parts of the pages, what we used to do with tables and what we do now with DIVs. I also explained ALT tags and why we use them. One student actually had a grandfather that used a screenreader, which made the explanation much easier. We also had a discussion about how Google and other search engines work, both with text and images. This led us into discussing Heading tags, too, and how a good webpage is modeled closely after a well written book.
The actual website code
After we messed around for an afternoon in Dreamweaver making up a simple page layout, I launched right into making the client site. We didn’t have time to waste making simple “About Me” pages that are so prevalent in web instruction and anything that wasn’t covered in the hour-long demo of the basics could get covered as we went along.
Students struggled the most here, as I imagined. They all coded the site right alongside me and the variations were vast. Some students handily picked up the material, some did not. Some students thought they had it, moved ahead, but realized they made mistakes along the way and that caused more trouble later. In retrospect, keeping students engaged here is hard because as soon as one student has a problem, you end up spending a few minutes looking for the missing comma or semicolon or closing tag, which is almost always the case. For me, it’s like finding a needle in a haystack multiple times in a row day after day and other students stop or slow down when you’re not actively talking.
The alternative, however, is more simplistic sites that are slower to produce, one-line-at-a-time, alongside the instructor. I preferred my students make mistakes because after a few missed semicolons that caused them several minutes of frustration on their own, they were more apt to remember it next time.
We went along for almost a week coding the site. We discussed all matter around links, tags, headings, page titles, SEO, semantics, syntax, and more. Students found it frustrating at times and became visibly disgruntled at their progress because they could not get a DIV positioned where they wanted it or, more likely, because it appeared different in Firefox than Internet Explorer or another browser. This resulted in an explanation of browsers, rendering engines and how they differ and why they differ the way they do. Sometimes this involved very politically incorrect responses like, “Apple doesn’t want to support such-n-such technology from Microsoft, so they do it another way.”
After 3.5 days of coding the students had developed their own copy of the homepage and each had been assigned to one of the pages we agreed as a class needed to be in the site, like an About, Contact, Donate, etc.
Finishing up
After the students wrapped up their work, which by this point was self-driven by them without my guidance beyond assisting with troubleshooting, I invited the client back in to see the site. Ordinarily we would have involved them after the mockups were created, but our time was too minimal.
I had explained to the students that the client will likely have a lot of changes, and they did. My goal was to prepare them to not be upset or take it personally. Likewise, before the clients arrived, I took them outside and prepared them on what to expect. I even told the client about specific areas I knew were weak or sub-par and asked them to make mention of those items. For example, one student decided to layout some text on her page in a different font and style than the other pages. Her reasoning was that it would “make the page unique compared to the others”. Even after discussing matters of consistency and having the other students agree with me (the other students are your secret weapon to persuade one or two people one way or another), she stood her ground. I respected her opinion, but knew it wasn’t in the best interest of the site, it was her trying to make her mark on the site.
The clients peppered the students with question after question for nearly 40 minutes. After which, the students were a little stunned so much of their work was called out, including some of the things I helped them lay out, such as the page templates.
This is where I spent time explaining some of my experiences with clients in the past. I told them about a client who demanded all the text on her site be blue and not black because she used to work in Hospice care and thought black was “too somber”. I told them about a client who once asked me to lay out a website based, precisely, on the mockups they did in Word. The students laughed at these and, to an extent, realized that clients have their wishes and demands and its up to as the problem solvers to balance those demands with what’s best for the industry and end users.
The last few days of the class were spent fixing up the pages they worked on and preparing them for publication. This was done by having all students send me their HTML and CSS for their page and I included them into the “Master Site” I was maintaining.
In retrospect
In all, the clients were 90% pleased with the work they had received. The students were proud of their work, too, and happy to see their names in the footer of each page. The 10% of problems from the client came from a lack of expectation management on my part. I needed to prepare them that some things they wanted, like a store and an interactive timeline, are beyond the scope of my 100-level class.
I told the students that the work they had done in my class was more intense than three and four hundred level courses I had taken at IU on similar subject matter.
I’d argue with anyone that believes website development isn’t an “academic” course and is instead a “technical” course that they’re only about 50% wrong. The students learned a great deal of user experience psychology, content hierarchy and web writing skills, advanced artistic appreciation, how to research online in addition to the technical matters they seem to think is “beneath” a “real” college course.
For anyone teaching a similar course in the future, I would encourage you to have “break activities”, too. At times students needed a break from the work at hand, but rather than letting them play games and check Facebook, I instead had them working on Photoshop tutorials, Illustrator tutorials and more. They may work on those individually or we may do them as a group, such as when I walked the students through an Illustrator tutorial to re-create Homer Simpson (a visually simple character to draw digitally). I noticed, too, that students most enjoyed working in Photoshop modifying pictures they had of themselves in their Facebook galleries. The trick for me was finding online tutorials that helped them make use of those photos.
The work was hard for me as an instructor, because it wasn’t as simple as opening a textbook and having them read the instructions. Doing that just teaches people how to use instructions and most of life does not come with a manual. Instead, I assigned no text book, nor did I give tests or quizzes. I quizzed students orally at random times by identifying a student and asking, “We’re using what kind of font here?” and awaiting the response of “serif” or “sans-serif” and other quick quiz-like questions. Their grades were based on participation, 10% a day for the 10 days we were together. My deal was simple on day one: “I won’t give you a test or stuff to study so long as you come in here and give 100% every day.” As a result, I think the students were more engaged and learned more.
If and when I do this again, developing ways of making this more real-world may be beneficial. Such as requiring time tracking, invoicing and other “business” matters. The students are always more excited at the prospect of learning something that can translate into real-world value, and when explained well, web development can be that for them.
