Micro Sites

Micro sites are parts of an intranet that are "owned" and populated by people within an organization that may not be part of the main intranet team. For example an insurance company may have a main intranet team that develops the architecture and templates. They are experts in this field, but will know nothing about the numerous underwriting conditions that the company covers. It is in these situations that micro sites come into existence, with small pockets of people starting to spring up within the business that have the required expertise in their particular field and are also prepared to publish onto the intranet directly.

The main issue that standards-focused developers will come across with micro sites is that of keeping pages valid. As I mentioned above, you need to have micro site owners (sometimes known as devolved publishers) who are willing to work on the intranet. There will be some situations where someone, because of their position, has intranet publishing as a consequence of their job. For example, in our insurance company, you may have one team responsible for all policy referrals, and within that team there is one person responsible for communicating that to the rest of the business. Computers and web sites are not something that inherently interest them, but they are involved in this field as a consequence of their job. Although they will be concerned that the intranet page looks as it should and all of the information is up to date and accurate, they probably won't care at all about the underlying code. If you care about standards, this can be a nightmare!

Take this line of code which can easily be generated by a WYSIWYG editor:

 <p><font face="Arial"><font color="#000000"><font size="2"></font><b><i> </i></b><font size="2"><a href="#TOP">TOP</a></font><i></i></font></font></p> 

This makes me have panic attacks just looking at it! The only part of the code above that we actually need is hidden right in the middle. The rest is presentational code that simply bloats the size of the page. What we really need is this:

 <p><a href = "#top">Top</a></p> 

If you think that the above line of mangled code is something you'd never find, think again! Having devolved publishers who don't really have an interest in the Web but have to publish to the intranet as a consequence of their job is something that you will have to live with.

What Can We do to Try and Resolve this Situation?

There are plenty of ways to create the micro-site HTML files. We'll look at a couple of the different ways and see what is best from a standards perspective.

"Save as HTML"

Microsoft Office programs such as Word, PowerPoint, and Excel all come with "Save as HTML" functions. In theory these are great and allow the easy creation of HTML files that can be viewed in a browser. This is all well and good, but have you ever looked at the code that is produced? If you are in any way fussy about your code it will immediately turn you off this approach. Office 97 will fill the code with endless font element bloat and add alignment to every single table cell even when it was completely unnecessary. Office XP now adds several hundred lines of style information before even getting to the main page body. It also clutters up pages with totally unnecessary bloat, which can increase download times. Take this example for an empty paragraph that was generated in Word XP:

 <p class=MsoNormal><span lang=EN-GB><o:p>&nbsp;</o:p></span></p> 

When all that was needed was:

 <p>&nbsp;</p> 

Save as HTML maybe handy, but it is not really the way to go. There are ways to correct it, such as Macromedia Dreamweaver's Clean Up Word HTML command, or the Office 2000 HTML filter (http://office.microsoft.com/downloads/2000/Msohtmf2.aspx), but neither of these options are a substitute for using correct code in the first place, and add an extra step to the creation process.

WYSIWYG Editors

The best way that a devolved publisher can create documents to put onto the intranet will be by using a WYSIWYG editor such as Dreamweaver, GoLive, or FrontPage. This setup will allow them to produce intranet content themselves which will free up the main intranet development team.

Some of these editors are better than others. If we are looking at both coding to standards and accessibility, Dreamweaver MX should be high on your shopping list. It codes both HTML and XHTML (and can convert one to the other pretty well), has much improved CSS support, and also now comes with a large amount of accessibility options and a built-in validator. The Web Standards Project (http://webstandards.org) has been involved with the development of this piece of software, so we can be confident that it is pretty good. A less expensive option, also from Macromedia, is Contribute. This new piece of software allows a non-technical person to update an HTML page, and allows an administrator to lock certain areas of a template, so the updates don't break the page, its standards-compliance, or accessibility. Adobe's Golive also has a built-in accessibility checker, and a free plugin called InSightLE for checking section 508-compliance.

However, just because a program supports standards, it doesn't follow that the micro-site creators will know how to use them. It is therefore important to make sure they receive the relevant basic training if you want to avoid problems, and the compliance of the site breaking.

Cascading Style Sheets

One way that we can help to reduce the type of tag soup that we have seen above is to use CSS. Setting up a stylesheet for parts of the intranet that a devolved publisher will use will dramatically increase the quality of the code and also make everyone's life easier. For example you could quite easily set up styles to enhance the presentation of standard HTML elements. For example, you might want space between your bullets in a list. Instead of this:

 <ul> <li>Grant Lee Buffalo<br /><br /></li> <li>Tom Waits<br /><br /></li> <li>Chantal Kreviazuk<br /><br /></li> </ul> 

we could just have written a style declaration along the lines of:

 li {margin-bottom:2em;} 

which would give you approximately the same effect and would mean that you would only ever have to code:

 <ul> <li>Grant Lee Buffalo</li> <li>Tom Waits</li> <li>Chantal Kreviazuk</li> </ul> 

Using this in a linked, external stylesheet means we can use this over and over again. Our code is cleaner and if we ever want to change the spacing, we'll only have to alter the stylesheet and not hunt out every unordered list we've written.

Another example of this would be to use CSS to set the background color and text style of your table headers. This would mean that every time a new table is created, it will look the same which is ideal for a corporate intranet. Dreamweaver's CSS pallet is useful for this. One of the intranet developers can set up a stylesheet with all the required styles in it, which can easily be applied by anyone with a small amount of training.