Week 1 - Web Development Perceptions

First and foremost, I learned that almost all of the old HTML that I learned in 1998 has or is depreciated. I'm starting to feel a little depreciated myself. I don't understand why certain tags are depreciated. For example, it is far faster to hand code a “b” element for bold than a “strong”. On the flip side, I guess most people don't hand code HTML, making what tags are used almost irrelevant so long as nothing is doubled up. It also seems to far more clear to use “i” verses “em” for italicizing things, then again this could just be an old dog whining about new tricks.

Aside from relearning some of the basics, it was also nice to try out Expression Web. I had looked at Dreamweaver a few years ago to see what was new in web design and found myself completely perplexed without any tutorials or guidance.

My current perception of web design is one of mystery. There have been so many changes since the beginning that I hardly know where to begin. I notice that the book does a good job of easing into the work, and I am glad that Internet Explorer is finally coming around to meet the standards set forth by the W3C.

I have several friends who are carving out an existence doing web design. While I don't plan on getting into it as much as they have, it is nice to know how to work with it. I like being able to help friends with simple websites and make a few bucks on the side.


Week 2 - HTML History

As with the previous chapter, I have dealt with a good number of the aspects in this chapter, but the alterations due to depreciated code keep me learning. Having FTP access has been a fun learning experience. I really like how Expression Web indicated what files are identical, and which ones are different. Previously, I had no experience with creating an image map. I can see the advantage of having a program do it for me, but I am glad that I understand how the operation works. Now I feel like I can control the output another program might spit out.

I found some of the anecdotes about the history of HTML really interesting. The first one that caught my eye was about how the big corporations thought that the concept of interconnecting computers, information, and people via the internet would remain specific to academic research. It reminds me of how Xerox didn’t think people would use a mouse, or how Apple thought that people didn’t want to play games on their computer. It seems like everything we like about computers was delivered by rouge entrepreneurs that were more innovative then the established companies.

I also thought the following quote from the W3C site was perfect at describing the growing pains:

“The HTML working group was an excellent idea in theory, but in practice things did not go quite as expected. With the immense popularity of the Web, the HTML working group grew larger and larger, and the volume of associated email soared exponentially. Imagine one hundred people trying to design a house. `I want the windows to be double-glazed,' says one. `Yes, but shouldn't we make them smaller, while we're at it,' questions another. Still others chime in: `What material do you propose for the frames - I'm not having them in plastic, that's for sure'; `I suggest that we don't have windows, as such, but include small, circular port-holes on the Southern elevation...' and so on.
You get the idea. The HTML working group emailed each other in a frenzy of electronic activity. In the end, its members became so snowed under with email that no time was left for programming. For software engineers, this was a sorry state of affairs, indeed: `I came back after just three days away to find over 2000 messages waiting,' was the unhappy lament of the HTML enthusiast.
Anyway, the HTML working group still was losing ground to the browser vendors. The group was notably slow in coming to a consensus on a given HTML feature, and commercial organizations were hardly going to sit around having tea, pleasantly conversing on the weather whilst waiting for the results of debates. And they did not.”

Week 3 - CSS History

It wasn’t until reading some of the introductory passages that I realized how separate HTML and CSS are supposed to be. When I started doing HTML by hand in high school I was taught to mash all of the content and stylization pieces together. While I strived to make clean pages, there was defiantly something lacking. With the conscious effort to separate the HTML content coding from the CSS style coding, there have been vast improvements in the quality of websites, with the exception of MySpace.

The single best advantage of using style sheets is that a web developer can create a style sheet that will take the content from any user and render it uniformly across the entire website. One clear example of this is the Twin Falls School District sites. The main page has visually been well crafted but each individual school and department site varies from ok to horrendous. If all of the content submitters were using a master external style sheet, there would be much more uniformity and a cleaner appearance.

With the sites that looked to be current, they all say that FireFox is the browser with the best compliance with CSS 3 and HTML 5 standards. Safari and IE 8 are mentioned as being good, but several sites state that previewing should be done in FireFox due to its tight compliance. The worst browsers are on cell phones and PDAs, with the absolute bottom draggers being proprietary browsers commissioned or created by the cell phone companies.


Week 4 - Web Design

Was it worth your while? Yes it was, and the humor kept it lively.

What did you find most interesting? I liked the example of having to create a website from a blank business card, without a designer in the mix. I often feel like I know what I want said, and often where to place it, but the color and font selections are what trip me up and keep me from beginning. I don’t want to reinvent the wheel, so I sit there doing nothing instead. The shift from old school HTML to XHTML/CSS allows me to get something going and use temporary style options until I settle on a final selection. I agree with the paper in meetings comment, as well as designing on paper first. I have noticed that in the beginning of the class that I lost time figuring out minute things, instead of designing what I wanted and then attacking each unknown.

What did you find least interesting? The entire article is interesting, but I have already learned about the basics of webpage anatomy, the golden ratio, and the rule of thirds with grids for placement. This comes from using PhotoShop over many years. With the depth the article went into on layout issues, I was a little surprised to not see more comments made on how users look at pages. The following links address this issue in more depth.
F-Shaped Pattern For Reading Web Content
The Best of Eyetrack III


Week 5 - Out of the Box

Was it worth your while?

Yes, it was. The code and images provided were an excellent way to get a reader to become a user. The walkthrough was a great look at modifying the standard blocky pages, even with rounded corners the basic layout is still blocky. That being said, I don’t think all or most pages should fracture the grid. I’ve debated which comes first, function or form, with friends. The most progressive view was from an architect student who worked with them simultaneously… after several of my rants that people like Hummel Architects spent too much time on looks and leave the users without function or funds to fix it. The image below is from their site and perfectly illustrates the need for balance.

The developer needs to decide if the site needs to be utilitarian, like Google and Digg, or if the user should be immersed in the site itself so deeply that the content blends with the aesthetics, like this one, or this one.

I thought the quote “Antoni Gaudi believed that the straight line belonged to man, and the curved line belonged to God” was a great way to frame the style idea and function. If a natural and organic feel is what you are after, you need to break the grid. If high speed and efficiency are what you need, then stylized boxes are what you are after.


Week 6 - Tables vs. CSS

The article was worth reading, but more for a look back at where I was then as proof that CSS is better than the old school. It seems odd that the article needed to be written, though I suppose it could have been more of a whimsical head to head battle than a treatise on why developers should stop using dead code.

I know that there are frequent changes to the status quo that seem to do more harm to the system than to benefit it, but over several iterations of changes, the best parts generally float to the top and stay there, or are added back in after public upheaval.

The most interesting part to me was looking at the rubbish I was taught in school and how I intuitively knew that there had to be, or needed to be created, a better way to hammer out a site design.

It is things like this article that make me seek out trusted people who know their field of expertise well. Then I have people who can advise me on how good the new methods or systems really are and keep myself from pretending that the old way is better out of ignorance to the new, rather than based on evaluated facts.


Week 7 - Specificity

This article, while being the shortest, was the most difficult to follow. If I weren’t such a noob, I’m sure it would have made more sense. As it sits, I easily understand the concept of specificity, though understanding the parts of the ranking system are still cloudy.

Specificity is the browser looking at how specifically or minutely a section of code is being controlled by a style. Competing styles are ranked, but not with a cumulative total. Each item in the ranking is given priority over lesser parts, so a rank of 0, 0, 1 billion, 255 will never ever take priority over a rank of 0, 1, 0, 0… that is unless you throw in the heretofore unmentioned !important code snippet. Rest assured that I have no desire to use it.

In the end, I found the article really dense, but valuable. I seemed to read three paragraphs and then go back a paragraph and cycle the process over and over until I was done. While my understanding of which parts take priority over others Is limited, this is an excellent resource that I can refer back to so that I can massage bugs out of my own code.