MOVING FROM HTML TO XHTML

March 10, 2008

HTML has progressed through a number of versions since its inception. The latest
standard is version 4.01, which was released by the W3C in late 1999. This is the last
release of HTML in its current state. The next generation of HTML is called the
Extensible Hypertext Markup Language (XHTML).The W3C released version 1.0

of XHTML in January 2000; a revised version was released in August 2002. As defined
in the W3C XHTML recommendation (www.w3.org/TR/xhtml1/), there are three
“flavors” of XHTML:

  • XHTML Strict—Use this when you want clean structural markup code, free
    of any markup tags associated with layout. Use XHTML Strict with
    Cascading Style Sheets to get the font, color, and layout effects you want. If
    you are beginning a new Web site, you should code to this recommendation.
  • XHTML Transitional—This type of XHTML is designed for people writing Web
    pages for the general public.The idea is to take advantage of XHTML features,
    including style sheets, but make small adjustments to your markup code for those
    viewing your pages with older browsers, which can’t understand style sheets.
  • XHTML Frameset—Use this when you want to use frames to partition the
    browser window into two or more sections.You can learn more about frames
    by reading the “Working with Frames” chapter on the Online Companion
    Web site for this book.

How do these three types of XHTML affect you as a Web developer? Your goal should
be to create code that matches the strict recommendation, using Cascading Style Sheets
for all of your display information. The benefit of the transitional type is that it allows
you to gradually migrate from existing HTML code that may still contain font and display
information to the more syntactically correct, cleaner markup code necessary to match
the strict type.

The frameset specification is important only if you plan to use frames to
partition the browser window, as described in the “Working with Frames” chapter posted
on the Online Companion Web site for this book.

The Limitations of HTML

HTML is a markup language, a structured language that lets you identify common
sections of a document such as headings, paragraphs, and lists. An HTML file includes
text and HTML markup (or element) tags that identify these sections. The HTML
markup tags indicate how the document sections appear in a browser. For example, the
<h1> element tags in the following code indicate that the text is a first-level heading:

<h1>WelcomeƒtoƒMyƒWebƒPage</h1>

The browser interprets the HTML markup elements and displays the results, hiding the
actual markup tags from the user. In the previous code, the user sees only the text
“Welcome to My Web Page” formatted as a level-one heading.

HTML adopts many features of SGML, including the cross-platform compatibility that
allows different computers to download and read the same file from the Web. Because
HTML is cross-platform compatible, it does not matter whether you are working on a
Windows PC, Macintosh, or UNIX computer.You can create HTML files and view
them on any computer platform.

HTML is not a What You See Is What You Get (WYSIWYG) layout tool. It was intended
only to express logical document structure, not formatting characteristics. Although
many current HTML editors let you work with a graphical interface, the underlying
code they create is basic HTML. However, because HTML was not designed as a layout
language, many editing programs create substandard code to accomplish a certain effect.

You cannot rely on the HTML editor’s WYSIWYG view to test your Web pages.
Because users can view the same HTML file with different browsers and on different
machines, the only way to be sure of what your audience sees is to preview your HTML
files in the browsers you anticipate your audience will use.

Despite its limitations, HTML is ideal for the Web because it is an open, nonproprietary
language that is cross-platform compatible. All of the markup tags are included with
every document and usually can be viewed through your browser. Once you are familiar
with the HTML syntax, you will find that one of the best ways to learn new coding
techniques is to find a Web page you like and view the source code. (You have a chance
to view the source code of a Web page in the Hands-on Projects at the end of this chapter.)

Ten Mistakes in Web Design

March 8, 2008

1. Bad Search
Overly literal search engines reduce usability in that they’re unable to handle typos, plurals, hyphens, and other variants of the query terms. Such search engines are particularly difficult for elderly users, but they hurt everybody.

A related problem is when search engines prioritize results purely on the basis of how many query terms they contain, rather than on each document’s importance. Much better if your search engine calls out "best bets" at the top of the list — especially for important queries, such as the names of your products.

Search is the user’s lifeline when navigation fails. Even though advanced search can sometimes help, simple search usually works best, and search should be presented as a simple box, since that’s what users are looking for.

2. PDF Files for Online Reading
Users hate coming across a PDF file while browsing, because it breaks their flow. Even simple things like printing or saving documents are difficult because standard browser commands don’t work. Layouts are often optimized for a sheet of paper, which rarely matches the size of the user’s browser window. Bye-bye smooth scrolling. Hello tiny fonts.

Worst of all, PDF is an undifferentiated blob of content that’s hard to navigate.

PDF is great for printing and for distributing manuals and other big documents that need to be printed. Reserve it for this purpose and convert any information that needs to be browsed or read on the screen into real web pages.

> Detailed discussion of why PDF is bad for online reading

3. Not Changing the Color of Visited Links
A good grasp of past navigation helps you understand your current location, since it’s the culmination of your journey. Knowing your past and present locations in turn makes it easier to decide where to go next. Links are a key factor in this navigation process. Users can exclude links that proved fruitless in their earlier visits. Conversely, they might revisit links they found helpful in the past.

Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

These benefits only accrue under one important assumption: that users can tell the difference between visited and unvisited links because the site shows them in different colors. When visited links don’t change color, users exhibit more navigational disorientation in usability testing and unintentionally revisit the same pages repeatedly.

> Usability implications of changing link colors
> Guidelines for showing links Cartoon - guy being crushed under wordy ‘terms and conditions’ legalese

4. Non-Scannable Text
A wall of text is deadly for an interactive experience. Intimidating. Boring. Painful to read.

Write for online, not print. To draw users into the text and support scannability, use well-documented tricks:

    * subheads
    * bulleted lists
    * highlighted keywords
    * short paragraphs
    * the inverted pyramid
    * a simple writing style, and
    * de-fluffed language devoid of marketese.

> Eyetracking of reading patterns

5. Fixed Font Size
CSS style sheets unfortunately give websites the power to disable a Web browser’s "change font size" button and specify a fixed font size. About 95% of the time, this fixed size is tiny, reducing readability significantly for most people over the age of 40.

Respect the user’s preferences and let them resize text as needed. Also, specify font sizes in relative terms — not as an absolute number of pixels.

6. Page Titles With Low Search Engine Visibility
Search is the most important way users discover websites. Search is also one of the most important ways users find their way around individual websites. The humble page title is your main tool to attract new visitors from search listings and to help your existing users to locate the specific pages that they need.

The page title is contained within the HTML <title> tag and is almost always used as the clickable headline for listings on search engine result pages (SERP). Search engines typically show the first 66 characters or so of the title, so it’s truly microcontent.

Page titles are also used as the default entry in the Favorites when users bookmark a site. For your homepage, begin the with the company name, followed by a brief description of the site. Don’t start with words like "The" or "Welcome to" unless you want to be alphabetized under "T" or "W."

For other pages than the homepage, start the title with a few of the most salient information-carrying words that describe the specifics of what users will find on that page. Since the page title is used as the window title in the browser, it’s also used as the label for that window in the taskbar under Windows, meaning that advanced users will move between multiple windows under the guidance of the first one or two words of each page title. If all your page titles start with the same words, you have severely reduced usability for your multi-windowing users.

Taglines on homepages are a related subject: they also need to be short and quickly communicate the purpose of the site.

7. Anything That Looks Like an Advertisement
Selective attention is very powerful, and Web users have learned to stop paying attention to any ads that get in the way of their goal-driven navigation. (The main exception being text-only search-engine ads.)

Unfortunately, users also ignore legitimate design elements that look like prevalent forms of advertising. After all, when you ignore something, you don’t study it in detail to find out what it is.

Therefore, it is best to avoid any designs that look like advertisements. The exact implications of this guideline will vary with new forms of ads; currently follow these rules:

    * banner blindness means that users never fixate their eyes on anything that looks like a banner ad due to shape or position on the page
    * animation avoidance makes users ignore areas with blinking or flashing text or other aggressive animations
    * pop-up purges mean that users close pop-up windoids before they have even fully rendered; sometimes with great viciousness (a sort of getting-back-at-GeoCities triumph).

8. Violating Design Conventions
Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That’s good.

The more users’ expectations prove right, the more they will feel in control of the system and the more they will like it. And the more the system breaks users’ expectations, the more they will feel insecure. Oops, maybe if I let go of this apple, it will turn into a tomato and jump a mile into the sky.

Jakob’s Law of the Web User Experience states that "users spend most of their time on other websites."

This means that they form their expectations for your site based on what’s commonly done on most other sites. If you deviate, your site will be harder to use and users will leave.

9. Opening New Browser Windows
Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet. Don’t pollute my screen with any more windows, thanks (particularly since current operating systems have miserable window management).

Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user’s machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button.

Links that don’t behave as expected undermine users’ understanding of their own system. A link should be a simple hypertext reference that replaces the current page with new content. Users hate unwarranted pop-up windows. When they want the destination to appear in a new page, they can use their browser’s "open in new window" command — assuming, of course, that the link is not a piece of code that interferes with the browser’s standard behavior. Cartoon - woman (at car dealership): ‘How much is it with automatic transmission?’ - sleazy salesman: ‘I’ll give you a hint - it’s an EVEN number…’

10. Not Answering Users’ Questions
Users are highly goal-driven on the Web. They visit sites because there’s something they want to accomplish — maybe even buy your product. The ultimate failure of a website is to fail to provide the information users are looking for.

Sometimes the answer is simply not there and you lose the sale because users have to assume that your product or service doesn’t meet their needs if you don’t tell them the specifics. Other times the specifics are buried under a thick layer of marketese and bland slogans. Since users don’t have time to read everything, such hidden info might almost as well not be there.

The worst example of not answering users’ questions is to avoid listing the price of products and services. No B2C ecommerce site would make this mistake, but it’s rife in B2B, where most "enterprise solutions" are presented so that you can’t tell whether they are suited for 100 people or 100,000 people. Price is the most specific piece of info customers use to understand the nature of an offering, and not providing it makes people feel lost and reduces their understanding of a product line. We have miles of videotape of users asking "Where’s the price?" while tearing their hair out.

Even B2C sites often make the associated mistake of forgetting prices in product lists, such as category pages or search results. Knowing the price is key in both situations; it lets users differentiate among products and click through to the most relevant ones.

How to Add Background Music to Your Web Page

March 4, 2008

Issues Surrounding Background Music

Before you start, you should be aware that background music that automatically starts playing when a web page is loaded may not be appreciated by a large number of your visitors. Some of them, when greeted with the sudden blaring of music from their speakers, may immediately hit the BACK button of their browsers. This may occur even if you’re playing a piece of music that you think is well loved by everyone: remember, there are people who surf the Internet in public libraries, at work, or in the dead of the night when others are asleep. Others may already have their favourite piece of music playing on their computer speakers, and your auto-playing music file will only cause them to be annoyed.

Even if you are satisfied that your website has the type of target audience that will enjoy your background music, there are alternatives to automatically playing music that you might want to consider. For example, giving visitors a link which they can click to play music would allow you to showcase your music while remaining sensitive to your visitors’ preferences. Instructions on how to accomplish this, as well as how to implement autoplaying music, are given below.

Playing Music Only When a Link is Clicked

If you have a MIDI file that you want played when a visitor clicks a link, put HTML code like the following on your page:
<a href="yourmusicfile.mid">Play background music</a>

Replace the "yourmusicfile.mid" with the appropriate filename. Note that the above HTML code works for ".wav" and ".mp3" files as well (or anything else for that matter).
How to Embed Background Music on Your Web Site

Update (21 May 2006): Please note that this article was written at a time when Netscape 4 and IE 4 were the browsers used by the majority of people. When it refers to "all versions of Netscape" it means Netscape versions up to version 4, and not newer versions. Similarly, "all IE versions" does not necessarily mean IE 6 and later versions. As such, this section should be considered obsolete.

The problem with embedding background music is that the different browsers out there have their own methods of implementing embedded music files.

For all versions of Netscape, as well as IE 3.0 and above, you can use the following code:
<embed src="yourmusicfile.mid" autostart="true" loop="true"
width="2" height="0">
</embed>

The width and height attribute given above causes the player to be invisible. If you do not want it to be invisible, you can specify your own dimensions to suit your site decor.

For Opera and all IE versions, the following code works:
<bgsound src="yourmusicfile.mid" loop="infinite">

As you probably have noticed, IE 3.0 and above support both methods, so you cannot simply put both those tags into your web document in the hope of supporting all browsers. It will work on Netscape and early versions of IE, but the newer versions of IE will recognize both tags, leading to problems when IE tries to load the music file twice.

The workaround that I’ve seen on some sites, that seems to work for me, is to enclose the BGSOUND tag inside NOEMBED tags, thus preventing IE from interpreting the second tag.
<embed src="yourmusicfile.mid" autostart="true" loop="true"
width="2" height="0">
</embed>
<noembed>
<bgsound src="yourmusicfile.mid" loop="infinite">
</noembed>

This code appears to be compatible with all versions of IE, Netscape and Opera.

Fixing Your Web Server’s MIME Types

If, after putting the above code on your site and uploading your music file, your music does not automatically play in IE, Netscape or Opera, it is possible that your web server is not sending the browser the correct MIME type. In order for the browser to know how to handle the file, your web server needs to be configured to send the correct information about the file. For example, for MIDI files, the web server should send the browser a "Content-Type" header of "audio/midi".

You can find out if your server has been correctly configured by starting up Netscape, invoking the "View" menu and selecting the "Page Info" item on that menu. (I’m referring to version 4.7x of Netscape - the item may be labelled differently on other versions of Netscape.) The MIME type of your music file will be displayed (among other things).

If the MIME type is incorrect, contact your web host to have them fix it. If your website runs on an Apache web server, and your host has configured it to allow you to override its settings using a .htaccess file, you can set up the MIME type yourself. For example, if you have MIDI files with a file extension of ".midi", you might add the following line to your .htaccess file:
AddType audio/midi .midi

If you don’t have any existing .htaccess file, you can simply create one using an ASCII text editor and upload it to the top directory of your website. Remember, Microsoft Word and Wordpad are *not* ASCII text editors. Also note that this method only works for Apache servers configured to allow .htaccess overrides. If this is not the case for you (for example, if your site runs on a Windows machine running IIS), you will probably have to get your web host to fix the problem.

Browser Plug-in Problems

Sometimes you may encounter a situation where the embedded code works for you but not for others using the same version of the same browser.

This situation may occur when the person has installed some other software that has replaced the default browser plug-in to handle the music file type. For example, various multimedia players (like QuickTime) replace the browser’s default plugins when they are installed. The replacement plugins may not function in quite the same way as the default plugin for the browser, leading to your code not working as expected.

There’s probably little you can do to prevent this from happening, short of posting notices everywhere on your site telling people not to install such-and-such a software, which is of course ludicrous. If you insist on putting auto-playing sound files on your web page, my recommendation is that you ensure that your page makes sense whether or not those sounds are played on your visitor’s machine. That is, don’t auto-play a sound file that provides vital information that the visitor needs to understand your web page - unless of course you also provide a clickable link on the page that allows him to hear the information should his browser not autoplay the sound file.

Like many other aspects of coding for the web, putting music on the web requires a certain amount of defensive coding. Even then, there will probably be a percentage of visitors who will not be able to view/hear your site the way you intended.

Variables in the Web Design Environment

March 2, 2008

The Current State of HTML

In this section you will explore the evolution of HTML and its future as a markup language for creating Web documents.  You will analyze current design limitations of HTML, the need for style sheets that allow separation of style from structure, and the usage of hypertext as a means for organizing information.

HTML:  Then and Now

When Tim Berners-Lee first proposed HTML at the European Laboratory for Particle Physics (CERN) in 1989, he was looking for a way to manage and share large amounts of information among colleagues.  As the idea developed, Berners-Lee named the mesh the World Wide Web.  He created an application of the Standard

Generalized Markup Language (SGML), a standard system for specifying document structure, and called it the Hypertext Markup Language. 

When Berners-Lee created HTML, he adopted only the elements of SGML necessary for representing basic office documents such as memos and reports.  The need for new markup languages and standards to address these demands is handled by the World Wide Web Consortium (W3C).

HTML and the World Wide Web Consortium

After the initial surge of interest in HTML and the Web, a need arose for a standards organization to set recommended practices that would guarantee the open nature of the Web.  The W3C was founded in 1994 at the Massachusetts Institute of Technology to meet this need.  The W3C, led by Tim Berners-Lee, sets standards for HTML and provides an open, non-proprietary forum for industry and academic representatives to add to the evolution of this new medium. 

The Limitations of HTML

HTML is a markup language, a structured language that lets you identify common sections of a document such as headings, paragraphs, and lists.  An HTML file includes text and HTML markup elements that identify these sections.  The HTML markup elements indicate how the document sections appear in a browser.  For example, the <h1> element tags in the following code indicate that the text is first-level heading:

<h1>Welcome to My Web Page</h1>

HTML adopts many features of SGML, including the cross-platform compatibility that allows different computers to download and read the same file from the Web.  HTML is not a What You See Is What You Get (WYSIWYG) layout tool.  It was intended only to express logical document structure, not formatting characteristics.  Because HTML was not designed as a layout language, many editing programs create less-than-standard code to accomplish a certain effect.  You cannot rely on the HTML editor’s WYSIWYG view to test your Web pages.  Despite its limitations, HTML is ideal for the Web because it is an open, non-proprietary, cross-platform compatible language.

The Need for Style Sheets

Browser developers to help HTML authors bypass the design limitations of HTML introduced style elements such as <font>.  Designers and writers who are accustomed to working with today’s full-featured word processing programs want the same ability to manipulate and position objects precisely on a Web page as they can on the printed page.  Mixing style information within the structure, as is the case in most of the Web today, limits the cross-platform compatibility of the content.  Whether you come to the Web with a Personal Digital Assistant (PDA), a Personal Communication Services (PCS) telephone, or Windows CE device, the Web server can determine the type of requesting device and supply a style sheet that matches the device.

This separation of style and structure was accomplished in 1996 by the W3C’s specification for a Web style language.  The style language, named Cascading Style Sheets (CSS), allows authors to create style rules for elements and express them externally in a document known as a style sheet. 

Get free blog up and running in minutes with Blogsome | Theme designs available here