Occasionally, I stumble across the website alistapart.com and should visit it more regularly. It seems to never fail to give me good tips but the one I have to tell you about is the article "Never Get Involved in a Land War in Asia (or build a Website for No Reason).
This is one of the few articles that I keep using in my job again and again. In fact, I have actually printed a copy of this article and each and every time that I visit a new client/customer/user, I begin the meeting by handing them this article before we begin any discussion.
Afterwards, the conversation is really simple. I simple ask to fill in the blanks below when asked to develop or modify a web site:
The purpose of this web site is:
To convince... BLANK... (Whom)
To do… BLANK… (what)
instead of… BLANK... (Who's the competition or what problem are you trying to solve)
because… BLANK... (Why)
For example, alistapart fills in the blanks as follows:
To convince… ALA readers
to use… strategy to define the purpose of a website
instead of… ignoring it and moving right into production
because… strategy brings focus to the project and serves as a framework for all the components that make up a website (IA, copywriting, design, development, marketing, janitorial services, etc.).
Read the article.
Tuesday, October 25, 2005
Thursday, July 21, 2005
SharePoint Style Designer
James Milne has created a tool called SharePoint Skin to assist you in creating cascading style sheets for SharePoint Portal Server and Windows SharePoint Services. The Beta version is now up and running. Take a look at it over here.
These postings are provided "AS IS" with no warranties, and confers no rights
Friday, April 01, 2005
.Net Applets
Want to know how to go about creating a ".NET Applet"? - a Windows Forms control hosted within a web page? A good tutorial is available at
http://www.developerfusion.co.uk/show/4683/
http://www.developerfusion.co.uk/show/4683/
Not as nerdy as I used to be
Thank god age means something. I recently took the nerdy score and am now only somewhat nerdy. A big improvement from the past. I think memory loss and old folk habits helped reduce the score. Click the link below and find your own "nerdy score."
Table Rendering
From Microsoft Blog.
“IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. Internet Explorer 6 introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
“IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. Internet Explorer 6 introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
Mark of the Web
From Microsoft Blog
A comment from Dave P on this blog touched on the interesting aspect of table rendering.
Dave said “IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
A comment from Dave P on this blog touched on the interesting aspect of table rendering.
Dave said “IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.
There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.
Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.
Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.
Monday, March 14, 2005
On Perfect Software: It's the Process, Stupid!
Recently an old article I'd seen several times before surfaced on a couple of blogs, and I went back and re-read it. It's about the On-board shuttle group, and how they write perfect code. And I mean PERFECT. This is the software that makes the Space Shuttle go. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have ever achieved. The last three versions of the program -- each 420,000 lines long --had just one error each. I've lifted out and edited a few lines to save you some searching and reading time; what follows is really the essence of this whole concept:
This is all the work of 260 women and men based in an anonymous office building across the street from the Johnson Space Center in Clear Lake, Texas, southeast of Houston. Their prowess is world renowned: the shuttle software group is one of just four outfits in the world to win the Level 5 ranking of the government's Software Engineering Institute.
But, HOW do they write the right stuff?
The answer is, it's their process. The group's most important creation is not the perfect software they write -- it's the process they invented that writes the perfect software, and the process can be reduced to these four simple propositions:
1. The product is only as good as the plan for the product.
At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. The specs for the current program fill 30 volumes and run 40,000 pages.
Most organizations launch into even big projects without planning what the software must do in blueprint-like detail. So after coders have already started writing a program, the customer is busily changing its design. The result is chaotic, costly programming where code is constantly being changed and infected with errors, even as it is being designed.
2. The best teamwork is a healthy rivalry.
Within the software group, there are subgroups and subcultures.
The central group breaks down into two key teams: the coders - the people who sit and write code -- and the verifiers -- the people who try to find flaws in the code. The two outfits report to separate bosses and function under opposing marching orders. The development group is supposed to deliver completely error-free code, so perfect that the testers find no flaws at all. The testing group is supposed to pummel away at the code with flight scenarios and simulations that reveal as many flaws as possible.
The results of this friendly rivalry: the shuttle group now finds 85% of its errors before formal testing begins, and 99.9% before the program is delivered to NASA.
3. The database is the software base.
There is the software. And then there are the databases beneath the software, two enormous databases, encyclopedic in their comprehensiveness.
One is the history of the code itself -- with every line annotated, showing every time it was changed, why it was changed, when it was changed, what the purpose of the change was, what specifications documents detail the change. Everything that happens to the program is recorded in its master history. The genealogy of every line of code -- the reason it is the way it is -- is instantly available to everyone.
The other database -- the error database -- stands as a kind of monument to the way the on-board shuttle group goes about its work. Here is recorded every single error ever made while writing or working on the software, going back almost 20 years. For every one of those errors, the database records when the error was discovered; what set of commands revealed the error; who discovered it; what activity was going on when it was discovered -- testing, training, or flight.
4. Don't just fix the mistakes -- fix whatever permitted the mistake in the first place.
The process is so pervasive, it gets the blame for any error -- if there is a flaw in the software, there must be something wrong with the way its being written, something that can be corrected. Any error not found at the planning stage has slipped through at least some checks. Why? Is there something wrong with the inspection process? Does a question need to be added to a checklist?
The way the process works, it not only finds errors in the software. The process finds errors in the process.
In the history of human technology, nothing has become as essential as fast as software. Virtually everything -- from the international monetary system and major power plants to blenders and microwave ovens -- runs on software. In office buildings, the elevators, the lights, the water, the air conditioning are all controlled by software. In cars, the transmission, the ignition timing, the air bag, even the door locks are controlled by software. In most cities so are the traffic lights. Almost every written communication that's more complicated than a postcard depends on software; every phone conversation and every overnight package delivery requires it. And yet, 80% of major organizations basically write software that sucks, because they don't have a process.
Think about it.
This is all the work of 260 women and men based in an anonymous office building across the street from the Johnson Space Center in Clear Lake, Texas, southeast of Houston. Their prowess is world renowned: the shuttle software group is one of just four outfits in the world to win the Level 5 ranking of the government's Software Engineering Institute.
But, HOW do they write the right stuff?
The answer is, it's their process. The group's most important creation is not the perfect software they write -- it's the process they invented that writes the perfect software, and the process can be reduced to these four simple propositions:
1. The product is only as good as the plan for the product.
At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. The specs for the current program fill 30 volumes and run 40,000 pages.
Most organizations launch into even big projects without planning what the software must do in blueprint-like detail. So after coders have already started writing a program, the customer is busily changing its design. The result is chaotic, costly programming where code is constantly being changed and infected with errors, even as it is being designed.
2. The best teamwork is a healthy rivalry.
Within the software group, there are subgroups and subcultures.
The central group breaks down into two key teams: the coders - the people who sit and write code -- and the verifiers -- the people who try to find flaws in the code. The two outfits report to separate bosses and function under opposing marching orders. The development group is supposed to deliver completely error-free code, so perfect that the testers find no flaws at all. The testing group is supposed to pummel away at the code with flight scenarios and simulations that reveal as many flaws as possible.
The results of this friendly rivalry: the shuttle group now finds 85% of its errors before formal testing begins, and 99.9% before the program is delivered to NASA.
3. The database is the software base.
There is the software. And then there are the databases beneath the software, two enormous databases, encyclopedic in their comprehensiveness.
One is the history of the code itself -- with every line annotated, showing every time it was changed, why it was changed, when it was changed, what the purpose of the change was, what specifications documents detail the change. Everything that happens to the program is recorded in its master history. The genealogy of every line of code -- the reason it is the way it is -- is instantly available to everyone.
The other database -- the error database -- stands as a kind of monument to the way the on-board shuttle group goes about its work. Here is recorded every single error ever made while writing or working on the software, going back almost 20 years. For every one of those errors, the database records when the error was discovered; what set of commands revealed the error; who discovered it; what activity was going on when it was discovered -- testing, training, or flight.
4. Don't just fix the mistakes -- fix whatever permitted the mistake in the first place.
The process is so pervasive, it gets the blame for any error -- if there is a flaw in the software, there must be something wrong with the way its being written, something that can be corrected. Any error not found at the planning stage has slipped through at least some checks. Why? Is there something wrong with the inspection process? Does a question need to be added to a checklist?
The way the process works, it not only finds errors in the software. The process finds errors in the process.
In the history of human technology, nothing has become as essential as fast as software. Virtually everything -- from the international monetary system and major power plants to blenders and microwave ovens -- runs on software. In office buildings, the elevators, the lights, the water, the air conditioning are all controlled by software. In cars, the transmission, the ignition timing, the air bag, even the door locks are controlled by software. In most cities so are the traffic lights. Almost every written communication that's more complicated than a postcard depends on software; every phone conversation and every overnight package delivery requires it. And yet, 80% of major organizations basically write software that sucks, because they don't have a process.
Think about it.
Tuesday, March 01, 2005
March 1
Already the first of March!
Some people say that "the squeaky wheel gets the grease" but I say "the squeakly wheel gets REPLACED!!"
Beautiful day today.
Some people say that "the squeaky wheel gets the grease" but I say "the squeakly wheel gets REPLACED!!"
Beautiful day today.
Friday, February 25, 2005
Things to be happy about
- Democracy
- The ruins of Machu Picchu
- A detailed road map
- A loving spouse
- ESPN
- Delighting someone
- Not letting the snow stop you
- Wondering whatever happened to....
- Someone to do the dishes
- Plush theater seats
Subscribe to:
Posts (Atom)