Tag Archives: Web Design

Opera Web Standards Curriculum released!

Just released!

I haven’t the time to delve deeply, but I imagine that this will be quite excellent. The parent company – Opera – makes the Opera browser and was instrumental in the development of Cascading Stylesheets and their subsequent encapsulation as a web standard.

http://www.opera.com/wsc/

Advertisements

My Web Design Process

Introduction

I have looked long and hard for a good process structure for creating a web site – especially one that scales well regardless of the project size. I found that process on A List Apart. It follows the same attention to detail that I encourage. Read the full article or browse the major points below:

Additionally, anyone interested in a web site should be aware of the many factors affecting a good web design. Read Educate Your Stakeholders!, also from A List Apart, for a brief but concise overview of what’s important.

Beginning Assessment

  • Who do we want to visit the site? (Target Audience)
  • What are we publishing that those visitors will find important?
  • Where are our visitors in terms of geography, ambient environment, and client platform?
  • When should the site be launched, phased, maintained, and finally taken down or redesigned?
  • Why does the sponsor want the site built—what are its business objectives?
  • How are we going to build the site—what tools are we using, and what’s the budget?

The Design Process

  1. Assess objectives and requirements
  2. Conduct scenarios
  3. Produce wireframes (and establish site architecture)
  4. Produce sketches, comps, and (if necessary) prototypes
  5. Draft the style guide (Read Writing an Interface Style Guide also from A List Apart)
  6. Produce templates and stylesheets
  7. Write code
  8. Test presentation and behavior
  9. Reconcile test results (if possible)
  10. Publish

Benefits

  • Well defined scope: Since the assessment defines exactly what needs to be built and the resources that will be made available to build it, time and progress management are made easier.
  • Earlier identification of user experience issues: Scenarios probably won’t catch all of the possible UX flaws in a site or application, but they will reveal many of the flaws likely to force multiple production iterations—before design, much less production, even starts.
  • Context and purpose are well-established: The wireframes ultimately define where everything goes. Armed with this knowledge, the developers can devote their energy to implementation and production, rather than dithering with edge cases or internal disagreements.
  • Team members become fairly accountable for all of their own decisions: Each member of a development team makes decisions that affect the timeline. The stakeholder lays out the work for the engineer. The engineer scopes the work of the producer. The producer defines the online toolset of the designer. The designer’s work informs the schedule of the stylist. The fortunate stylist needs the other team members to normalize their work product in ways that minimize exposure to browser bugs and junk markup. A style guide makes all of these interactions predictable, and encourages dialogue between team members about problems that otherwise would remain invisible until the site goes into production.

Vocabulary

  • Assessment: A formal and detailed assessment of the project allows its scope to be properly defined.
  • Personas and Scenarios: Executed with care, scenario roleplaying identifies likely obstacles to positive user experience, which can then be removed from the design prior to signoff.
  • Wireframes: The guidelines established by wireframes enforce layout consistency, discouraging the designer from composing everything as if it’s intended for print.
  • Style Guide: Adoption of a style guide allows collaboration between all team members to the end of finalizing the site’s design. Even clumsy execution of a style guide requires the graphic designer to “think out loud,” allowing needless edge cases to be caught and stopped before work begins on the prototypes of the work that will actually be put into production.

My Web Design Philsophy

Introduction

The following statements summarize my beliefs on how web sites can and should be best implemented. They comprise over 8 years of personal research into how and what makes the web tick.

I. There are Web Standards.

I follow the web standards as determined by the W3C as much as popular practice and implementation allow. I avoid the use of proprietary HTML tags and code implementation that requires selective web technologies for viewing and general use.

II. Web Pages are Fluid.

There are those within the HTML community that believe web pages are just like printed pages – i.e. they should all be a certain size (8½ by 11), etc. These people incorrectly treat web pages as if they were static and unchanging like their traditional counterparts. This view stems from a basic misunderstanding of how web pages differ from traditional printed pages and how best to use them.

When implemented correctly, web pages are fluid – they may change shape and size to fit the needs and requirements placed upon them. These requirements come from:

  • the hardware, (Web pages can be viewed on computer monitors as well as the smaller Cell Phone and PDA screens.)
  • the operating system, (The Macintosh OS consistently displays fonts smaller than the Windows OS.)
  • the screen resolution, (800×600 and 1024×768 are currently the most common, but still differ in width by 20%.)
  • the web browser, (Once, Netscape dominated the market and then Internet Explorer came along. Will Firefox be next?)
  • the user, (Users don’t have to maximize their browser windows and can customize their browser interface.)
  • and spyware. (Spyware can make changes to your computer without permission that inhibits normal activity.)

Fluid web pages allow for a customized fit of their content while ignoring most external factors. Although no approach is perfect, it is best to make use of this inherent strength given the sheer number and variety of variable requirements.

III. Separate Content from Presentation

Your content is your information. It should never be lost and it should be accessible no matter how it is stored. This might be in a tabular format in a PDF file, as a list in a word document, or viewed on a cell phone as a web page. It should just work.

Things start to break down when the presentational aspects (style and design) have to come along for the ride. The future tells us only one thing: information will remain important but the form it takes will inevitably change. By separating the two, the information is kept ready for whatever the future holds. As a very nice side-effect, it’s MUCH easier to manage and update both parts to any web site.

IV. Small is Beautiful.

Just like Steve Gibson of GRC.com (who may have coined the phrase above), I hate waste. Web pages should contain the necessary code to make them load correctly in a web browser and no more. Too many “modern” programmers (including those who create web pages) generate a lot of waste and superfluous code. They take shortcuts by letting their software do the work for them. Software can’t optimize itself. It will often include extra components and features that aren’t fully utilized. Furthermore, software will never be able to achieve the efficiency of a good, manual programmer.

Take Microsoft Word as an example. It is probably the best known word processor on the planet and as such does a good job. As a web page creation tool, however, it is absolutely horrible. The pages it creates are horrendously bloated with superfluous code. I am referring specifically to the 97 and 2000 versions. Hopefully, newer versions will do a much better job. Earlier versions of Microsoft FrontPage are equally bad at producing unnecessary code.

Instead of creating code that is bloated, takes longer to download, takes longer to process, and wastes both memory and disk space, I create web pages that only contain what is necessary. My sites load fast because their pages and images are optimized (all things being equal). A lower page size translates directly into a faster transfer and more bandwidth available for other purposes. And the faster a page loads, the less likely a user will go somewhere else because they don’t like waiting.

V. Neither Aesthetics nor Functionality must be sacrificed.

I have seen web sites that functioned well but would never win any awards in the looks department. I have also seen web sites that must have cost a fortune, looked like a million bucks, and were effectively useless, empty shells. They lacked either usable content or functional navigation. Given the choice of these two extremes, the former is definitely better but why be forced to pick? You can have proper functionality AND good looks at the same time.

VI. Content is Key.

Someone once said the most important thing to remember when starting a business is “Location, Location, Location.” If that person were alive today, they might say the most important thing to remember when creating a web site is “Content, Content, Content.” The old adage “if you build it, they will come” does not apply. It is content that brings the masses to your web site. It is equally important that the content be appropriate, unique, and organized. Without proper content, visitors will go elsewhere as your web site is passed over for more interesting, meaningful, and fulfilling sites.

Now, what is content you may ask? It’s all the stuff that is available on a web site. It is the sum total of all the information contained in all of a site’s pages. It can be text, images, movies, songs, and more. It is the substance, the subject, and the reason for the existence of a site. Think of all the stuff you can access in a multimedia encyclopedia and you’ll have the right idea.

Mozilla Firefox Web Development Add-Ons

For web development, you just can’t beat Mozilla Firefox and the excellent community extensions available specifically for that purpose. Here’s a short list of my favorite add-ons for web development:

(Go to https://addons.mozilla.org/ and install the following:)

  • Colorzilla
  • DOM Inspector
  • Firebug
  • FirefoxView and IE View
  • FireFTP
  • IE Tab
  • Image Zoom
  • McAfee SiteAdvisor
  • MeasureIt
  • Nuke Anything Enhanced
  • Print Preview
  • Total Validator
  • Web Developer
  • YSlow

Fluid Web Pages

Yes, you heard that right. Web pages are fluid. They can and should use the entire available browser window space and stretch as needed to fill that space. To quote my Design Philosophy page,

“When implemented correctly, web pages are fluid – they may change shape and size to fit the needs and requirements placed upon them.”

Don’t think of a web page in the same way you think about an 8½ by 11 sheet of paper. There is no real limit to the size of any web page or how far it might scroll. You are probably reading this because you want to know how to implement a fluid web page or understand how one is made.

It’s quite simple really. All you really must do is use percentages with your layouts instead of exact sizes. Oh, and be careful of software programs that allow you to “see” your web sites as you are editing them. If you are allowed to simply click on a table border or div layer edge and drag to resize it, chances are you will be setting an exact size for that tag. Let’s look at a little code:

<table width="100%">
<tr><td></td></tr>
</table>

Now, whether you are using tables for your layouts or not (since this is now considered out-dated in favor of stylesheets), this code example will still help you understand fluid web pages. The width is set to “100%”. The “%” is required. Without the “%”, the browser would see width=”100″ and interpret the 100 as a measurement of pixels, not a percentage.

So, that’s basically it. You must explicitly set percentages for your widths. This holds for tables, table rows, table cells, divs, spans, and other container tags, but a one-cell table isn’t the best example. Here’s some more realistic code:

<table width="100%">
<tr>
 <td width="200"></td> <!--Left Navigation-->
 <td width="100%"></td> <!--Right Content Body-->
</tr>
</table>

Yes, the above code will work just fine, and no I didn’t forget the “%”. I left it out on purpose. The browser will set aside 200 pixels for the cell on the left (the navigation) and then give the remainder to the cell on the right (the content) since the cell on the right AND the table both have widths set to 100%. Pretty cool, eh?

Other variations work too. How about this three-column table?

<table width="100%">
<tr>
 <td width="160"></td> <!--Left Navigation-->
 <td width="100%"></td> <!--Right Content Body-->
 <td width="160"></td> <!--Right Navigation-->
</tr>
</table>

Or this two-column layout?

<table width="100%">
<tr>
 <td width="50%"></td> <!--Left Content-->
 <td width="50%"></td> <!--Right Content-->
</tr>
</table

For help with fluid web pages that use stylesheets, visit Little Boxes.