Windows Server 2008 - The Server Unleashed

My first production web site built using Silverlight 1.0 is live!

There were a lot of lessons learned in building this site, and it is far from perfect. Basically we have a video player in the background showing the robot. These video's were created by Digital Domain of Transformers fame. The navigation items float left and right because when we had them also going up and down the site crawled to a stuttering mess. Even the way it is some people feel it uses too much processor power.

One of the craziest things that I learned was that the scroll wheel on a mouse isn't handled the same way between IE, Firefox, and Safari. In fact I don't think that it works at all on this site with Safari. Silverlight doesn't have this built in, and it sounds like it won't be included in Silverlight 2.0 when it is released later this year.

Let me know what you think of this site, and I will attempt to document some of the difficulties in building it.

Localizable Silverlight

In my previous post I discussed Silverlight SEO, and the strategy I'm using to enable search engines to crawl my sites. Even though most of my site is in Silverlight, search engines are able to crawl it because the content itself is actually in the HTML of the page. Then I transform it using some basic JavaScript.

At McCann Worldgroup one of the most important tasks is making a site easy for subs to localize. Most of the time the subs don't have the experience with Silverlight or the money to pay for localizing an HTML version and a Silverlight version. With this method that I am trying to describe here, the subs only need to localize the HTML. All of these international groups have experience converting US English HTML into their language/dialect. With this methodology they can retain those same techniques to localize the HTML site and the Silverlight site at the same time.

In order to do this though, you need to be conscious of the fact that not all languages have the same length of words as we do in the US. Beyond the obvious problem that many English words have extra characters (colour?) there are words in German that will put a strain on your design. Also Chinese is a bit of a problem, but I don't have any direct experience with that one yet.

When designing a site for Silverlight (or even CSS/JavaScript) you should keep in mind that what content will fit in your 250px by 300px box looks great in US English may well not work at all in another language.

Silverlight Accessibility and Portability

What's the big deal with having your content in a separate file anyway? Beyond SEO and the single responsibility principle there is what I consider to be the single most important reason: Accessibility.

When I write about accessibility I really am talking about 508c compliance. If the person viewing your web site is hard of sight or cannot see at all then your site is worthless to them. I won't go into the legal reason of why your sites should be accessible (search "Target accessibility web site" to know more about that). Your site should function without the flashy bells and whistles that CSS, JavaScript, and Silverlight provide. The page should make sense to navigate in its pure text form. You should have main site navigation, but perhaps that should be near the bottom of the page. The most important thing about the page is the content, not the navigation. Maybe have a named link at the top of the page to quickly scroll to the navigation section, but make sure that the site content is first on the page.

The site navigation should be simple and you should have a site map. All of these suggestions are SEO best practices, but really you are doing a favor for anyone that is coming to your site that relies on a screen reader to navigate the web.

I'm not going to go through all the best practices of accessibility here, I'm sure over time I'll compile a full list of suggestions. Just know that you need to keep this in mind as you are building your site. If your HTML is clean and free of design elements or extra JavaScript cluttering up the page your are well on your way to building an accessible site.

Since writing the content HTML is the first step of building a site. Launch it. Use the site without CSS or JavaScript. Can you get to all the content. If you turn off images, is there enough information on the screen to understand what the image was?

Once you've reached this step you can do two more things. You can build a simple CSS for people that want to print your site. In this print version of your CSS turn off the navigation and anything that is not content.

Next add a little bit of flair with CSS to your site and make things look better than 12pt black Times New Roman on white background. Throw in a little color and some font sizes here and there. Use this as the WAP version of your site.

Constantly building from the rock solid framework of content only HTML and adding CSS and JavaScript using external files will help you create a site that can be used on all of the lowest common denominator systems out there.

Once you've finished with this, you can finally go to the holy land... Silverlight. This is when you can turn on all of the bells and whistles. You will need to invest some time in writing an HTML to XAML converter, but it will be worth it. When you launch your site and everyone on the Internet can enjoy your site you will have a site worth being enjoyed.

Silverlight Centrally Managed Content

In my previous posts about creating a Silverlight site that plays well with search engines I have only focused on SEO and SEA. There are a lot of other benefits to this model and I hope to map them out in a few posts. The difficulty is in finding out where to start.

The main crux of this idea came from the Server Unleashed site that I was working on at the time has a separate HTML version of the site. This was particularly frustrating to me because I am a firm believer in the write once and test it then never write it again. That includes content. Content in one place makes it easier to make changes as they come in, and it actually makes it easier to localize a topic I'll get into in a few posts.

There are thousands of Content Management Systems (CMS) on the market. I would even be willing to bet that every day sees the birth of at least one more. My own web site that you are reading right now uses a custom CMS that I wrote because I wanted bragging rights. Now I see the trouble with doing your own custom CMS is that you have to maintain it. Maintaining a site for someone that is willing to pay time and materials is one thing, but finding time to make changes to your own code is a bit more difficult. That's why there are some issues with this site that haven't been updated in a few years.

I digress. If your CMS is a static HTML file or if it's Microsoft Office SharePoint Server 2007 as long as your content exists in one place you are in good shape to maintain the content moving forward. If you find that your content needs updating you only have to make the change and test it in one place.

More on Silverlight SEO

In my last post I described a method of building web sites that have the ability for search engines to crawl the site. This is important in Silverlight because traditionally all of the content within a Silverlight site is contained within the XAML. With the method described, all the content is still in the HTML.

The question remains, though, why do I care? The first and most obvious answer is: if you don't how will anyone ever find your content?

The second answer is a little more complicated. When you write a commercial web application you want to increase its visibility in search engines because another method of getting people to your site includes paid search. What does one have to do with the other you ask? Well if your site performs well in the search engine, then the cost of your paid search placement will go down. The closer to #1 your site is when you search your keyword terms, the less you have to pay for the targeted paid search.

I'll describe more benefits to using this method of creating your Silverlight sites, but if any of this post doesn't make sense, please comment and I'll try to explain it better in a future post.

Silverlight SEO

So you've downloaded the SDK, and you finally installed Visual Studio 2008. You crack it open and get your "Hello World" project running. Now you are ready to dive head first into a complete Silverlight site.

Getting buy-off from the various organizations will be your first hurdle. They are interested in how well the site will perform in the search engines. You don't really care about that because you want to be able to have a stronger fidelity between what your designer has created and what you can deliver to the web.

Search Engine Optimization will be the engine that drives traffic to your site, but if the search engine's spider cannot crawl your site then your site may not even exist. So what are you to do?

The official line from Microsoft is that they are working with the major search engine sites to help them crawl XAML files. After all XAML is just XML and is plain text. However, with Silverlight 2 all of those XAML files will most likely be packaged up into a XAP file. A XAP file is essentially a ZIP and I'm not sure that search engines have the time to unzip the XAP just to index the contents.

Well if you think about it, what do search engines index very well? If you guessed HTML pages then you'd be right. If you wrote your HTML page with content only then it is 100% pure gold for search engines.

Not to get off track here, but I am a big proponent of the Semantic Web. Although I probably won't go so far as to say that you should be writing RDF triplets only, but I believe in the ideas of using elements that make sense. If you are writing a paragraph of text enclose it in a <P> tag. If you want to emphasize something enclose it in an <EM> tag. Also careful use of ID's and Classes make your HTML much more readable and makes it more friendly to search engines.

Why do I bring that up? If you are careful enough to keep your style information in CSS and your dynamic actions in JavaScript you should be able to just transform your HTML into XAML and let Silverlight control the display, style, and actions. JavaScript can be used to translate the HTML into XAML if you are in Silverlight 1.0, but if you are using Silverlight 2.0 then just use the .NET Framework's XML classes to do an XSLT transform on your XHTML into XAML.

Although this will create a bit of work for you in creating the XSLT the benefits you'll get go beyond just SEO. I'll investigate this more in a brief series of posts that will be published over the next couple of days.

We Know Job One, What is Job Two?

As a software developer the first thing you need to think about when writing new software is, "Why am I writing this code?" If, after popping the why stack, you don't answer, "because it solves a customer story" then you are doing something wrong. I talk about this a bit in an old topic, "1, 0, 0 in x seconds", and Coding Horror had a post entitled "Can your team pass the elevator test?" last week that talks about something similar.

Today, I want to focus on what is job two. For me Job two is a simple three letter acronym; S.U.M. Sure you can write code in no time that will pass the "Why am I writing this code" test, and I bet you could hire a high school kid to do it in no time flat for very little money. The next step is hard though.

S.U.M. stands for Security, Upgradability, and Maintainability. I know the second word isn't really a word, but it fits my acronym. Most college classes now do a good job of teaching security, and anyone that's been developing for more than a year has thought about it. Second to getting the application to do what it is supposed to do, security is the most important task a developer needs to think about.

After Security comes upgrade-ability, or the resiliency of your application to not break when you make changes to it. If you practice a good agile method of constantly refactoring your code. This helps make changes effect as few moving parts as possible. As you are coding, an experienced programmer will find common patterns and pre-factor those to save time later.

This leads into the final step, Maintainability. Someone is going to have to maintain your software, and although part of maintenance is adding new functionality, another part is tracking down those remaining bugs that can be nasty. If your code is laid out well, you use common coding standards, and you've documented your code the task of tracking down bugs or bringing another engineer up to speed on your code can be less difficult.

The problem with "Job Two" is that nobody wants to pay for it. A customer will comment on the fact that if job one is getting the software to work to their specs then there really isn't a job two because the software is done. In my professional career I've found that companies that are licensing their software and charging for yearly maintenance will usually care more about job two than companies that charge for time and materials. In fact I've found the most frustrating aspect of being independent is to sell my clients on job two. This becomes especially true when they have it in their mind that job one is all they need and they can hire a high school student to do it.

Maybe I'm not seeing something here, but how do you sell Job Two to your clients?

Edit: I had a link to a blog post titled "Popping the Why Stack" that exemplified the Why am I doing this? Question nicely. However, I now see that link is dead. The link to Coding Horror's blog from last week is still good though.

The little BR that should not...

Last time I explained why you shouldn't use <B> and <I> and alternatives that are semantically correct. Today I'd like to complain about the over-use of <BR /> in the web.

<BR /> is a line break. Some people just type <BR> and they shouldn't do that. You should always close your tags, even if they are empty. I'm happy that more than half of the BR's that I see are closed, but at the end of the day they shouldn't even be used.

<BR /> is a line break. Yeah, I know I just said that but the thing is that <BR /> is a line break. Was the third time the charm on that one? No? Well, how about this: A line break isn't data. It is formatting. There is no semantic value in <BR />. You wouldn't sell a stock because the stock price had a line break in it. You wouldn't change medication because the news report on it had a line break in it. It is purely formatting.

What have I said about formatting? It belongs in the CSS, not in the HTML. HTML is for data only. For that reason the next tag that I am going to eliminate from my vocabulary is:
<BR />

(Bonus cool points if you found my ironic use of a line break above funny.)

Death to B and I

In the first of what I am sure will be many posts regarding HTML, I would like to bid farewell to my old friends <B> and <I>.

You may find them in various places on my current web sites, but from now on they will just be elements that I once ran with. The reason is that they hold no semantic value, and they really are just elements for styling the data. The web is comprised of three legs: HTML, CSS, and JavaScript. (I really need a graphic for that... maybe I'll work on that as well.) These three legs nicely separate data, style, and function. There really shouldn't be any mixing of rights between them.

Some people may think that the proper usage is to replace <B> with <strong> and <I> with <em>. In most cases that is correct, but not for the reason they are thinking. Although many browsers default to displaying <strong> as bold text, the reason to use <strong> over <B> is that semantically you are marking that bit of data as important. The same is true with <em>, you are trying to emphasize that bit of data so you surround it with the <em> element.

You should not rely on the browser's default for styling these two elements. Proper use of CSS will ensure that these two tags appear the way you want them to, but that is a CSS discussion. Remember, HTML should only contain data. HTML is not the place for style or functionality.

Paper Sometimes Wins

John Guin writes a blog called OneNote Testing. Today he has a post titled, "Trying to use OneNote to go 100% paperless on a trip, and not hitting that goal". The interesting part of his story was not the thought of him trying to get the bar code reader to scan a bar code contained within OneNote, the interesting part of the story is the description of testing data that has a lifetime of 5-10 minutes. In that case paper wins. It's small and easy to throw away.

I have been using my laptop for a little over a year now, and I still miss the notebook. The biggest problem I have is form factor. Although I have a small laptop, sometimes a 2"x1.5" Post-It note is the best tool for the job.

"Paper Sometimes Wins" means to me that sometimes paper is the best tool for the job. I'm going to continue trying to switch to OneNote for everything, but I recognize that this is an unobtainable goal. Maybe I can get over 75% though.