Well, 't is the season for gifts. So if any one out there feels the need to thank me for anything just take a look at my Amazon wish list. When you do, you can contact me through the information in my profile to request the address to where it should be sent.
Anyway, here's my current wish list.
TIA, hohoho!
Six little developers boys playing with a hive;
A bumble bee stung one and then there were Five.
Five little developers boys going in for law;
One got into Chancery and then there were Four.
Four little developers boys going out to sea;
A red herring swallowed one and then there were Three.
Three little developers boys walking in the Zoo;
A big bear hugged one and then there were Two.
Two little developers boys sitting in the sun;
One got frizzled up and then there was One.
The sad part is that I am that last one.
I am facing a dilemma, a big dilemma: should I go to a Go / No Go meeting?
It is scheduled for three o'clock leaving me little over an hour to doubt about this one. But if I can not make up my mind then what?
Decisions, decisions, decisions: they make my life so tough!
Update: I went, but did not sit down. The decision was GO. No other option really.
This post is a follow-up to my previous complaint about the behavior of colleagues and was inspired by the wonderful You park like an asshole site.
This person apparently does not understand what the blue lines are indicating. They are outlining PARKING SPACES!Hey, there are plenty free parking spaces. Why then don't you park in one of them?
The same SAAB as the photo above. Apparently he likes to leave as much space for others as possible. All right, let's call this social good behavior.
To confirm my theory another SAAB has parked also very socially as to leaving as much parking space available for others. Then again, it could also be that SAAB drivers are socially inept and avoid any contact with others. I am not sure, but a pattern seems to be emerging here.
And here's another confirmation of the theory. This is what we now call the "Wall Hugger". Again, leaving as much space as possible for others. SAAB drivers maybe shy, afraid to get into the way of anybody else.
Look very carefully for the painted wheelchair. The owners of these two cars are not handicapped. Thank you very much.
And here one other colleague who has no idea why these blue lines are painted all over the square. There were in total nine spots free but this driver decided to park as close to the entrance as possible.
I really do hope you have better behaving colleagues.
I wish I had seen this site earlier: I got have ordered the bumper stickers!
I don't know what kind of colleagues you have but I hope they are not like the pigs that work at my present employer. See the tow images below take in October and November of this year.
We have a companmy restaurant where you can get various sandwiches, soup, fruit and the lot. That is all great and you can also take the food up to your desk, because you decide to have meeting over lunch or you are so busy that you eat at your desk while working and filling up your keyboard with bread crumbs. All that is very good. It's good working spirit.
But please take back your dishes and don't just put them on the floor of the pantry!
The sign says in badly constructed Dutch: "The dishes what are brought to the department must be return by yourself to the dish washing kitchen of the catering. UNIVE and Albron"
The sign says: "When you takes dishes to your department you must return them to the dish washing kitchen yourself. Unive and Albron"
Hope you all are better of with better colleagues.
As always it is running really hard to chase one impossible deadline followed by a period of utter nothingness. You actually feel guilty for doing nothing worth while. But after a couple of cups of coffee that guilty feeling soon subsides.
Waiting for the weekend!
This post was due for a long time, but I have been just too busy running after an mission impossible.
It is many moons ago that I posted about the Google Mini and the amount of fun it was to implement it. It was easy as well.
Also many moons ago I posted about the fun it is to develop websites the right way. I wrote about the speed with which one could change the original layout from a width of 768 pixels to 1024 pixels.
Some weeks ago (it seems many moons again), after all those moons, we finally put these changes live. So, what the heck was I saying about speed and fun? Am I completely insane?
Well, I might be, for still working here, but more about that later, I guess.
As said I had the Google Mini implemented in hardly no time at all. I used a simple wrapper around the API to make it available as a very simple webservice. It had only a few methods.
These three methods are more than enough to get the information we need from the Google Mini. Actually it is more than we want as we as yet do not use the advanced search method.
The webservice methods all return the search results in the standard XML format to the calling web site. The presentation of the results in a readable fashion is deon on the side of the website. Just a short bit about our website's architecture.
We have a great many different types of pages: home page, product cockpit pages, information pages, form wizard pages that share many common elements like headers, navigation, footers, sidebars etc. To make development and maintenance easy we have structured these as containers that are loaded with general and specific components. The type of container is decided in the CMS and the code then loads the container, which then in turn loads the controls using information from the CMS.
Thanks to the wonders of Object Orientation and a good implementation of that in our framework it was a breeze to create a specific SearchContainer. Just a matter of picking the right base container type and creating a specific SearchResult component.
The SearchComponent parses the XML that the SearchService returns. Using this information some sub-components (inner classes) are created, like: the search box with prefilled the search term, the serach button, the navigation to result pages, a list of the results, with title and a snippet.
Using as little HTML as possible (the results are listed as definition list) and a special stylesheet for this container the layout stays consitent with the rest of the site.
Providing a search box on each page with of the site was also very easy to do. Only the Navigation component had to be changed and ready!
Our web site was originally designed for a maximum width of 800 px. Which is a bit an outdated requirement. Today the screen size you are looking for is slightl different. I wrote about the new standard in screen resolution some time ago. So, we wanted to stretch our site up a bit, making pages shorter and having more real estate for content.
So, not really redesigning: the face of the site would remain the same, it would only get wider. A typical case of realignment. So, a case of stretching the stylesheets and the background images. Not too difficult, but just a lot of work. Thanks again to our Container based approach (also used to split up the stylesheets) this was a relative simple job. With hardly any real code changes. The real code being C# and the unreal code being CSS.
Then when a new homepage design was proposed it was decided to implement that in one go. This caused some delay. Again this was not a too difficult task: it was after all only one container that needed changes. But there were some new content items going in.
All in all, chunks of chewable size, but together still quite a bit of work. It had impact on every page of the site. And that's where things went a bit wrong.
These months we are extremely busy with (re-)launching improved products. As a Ducth insurance company we are focussed on the health care insurance for next year. People can only change during the month of December so we should be up and running before that. Also a new Car insurance is launched in December. The wider layout was needed for the health insurance wizard as there are just so many options a customer can choose from. Presentation-wise more space was needed.
All available resources were needed for these two products. And needed for quite some time as well. So, management decided that we had to push the Google Mini / Wider Layout project to production as soon as possible. That's when corners were cut, shortcuts taken, very limited testing done. And so errors were not found before the project went to production.
The errors were not killing the site, but they are disrupting here and there. And hurting my pride.
It's not too bad to have minor and less minor errors in a production web site. It's bad if you ignore them. You have to fix them.
But since two new major products were to launch it was decided to use all the available workforce on these products and not fix the errors. resultig in more errors in the projects that are coming to the web shortly.
To me, that's not very clever and not in line with my quest for quality.
Yes, I think there is some good stuff in the Google Mini / Wider Layout project. After all, what was done was built in relative short time and thanks to our site framework it was easy to implement. We should have tested better and longer. I hope that is a lesson learned for the future.
But then again the best hope was Bob Hope.
Bob HopeMy next door neighbor just had a pacemaker installed. They're still working the bugs out, though. Every time he makes love, my garage door opens.
It's one of these times again: busy, busy, busy. And again: busy.
I stumbled on this funny site that contains an app that guesses things about you through choices you make about which of two pictures you like better. Weird.
So, dear blog reader, how well do you know me?
Well, since some time I have almost completed the rebuilding of my garage to my home office. Almost completed, yes. The odd bit here and there still needs a little twist and turn. And I need to unpack some boxes and throw old stuff away. My old IBM PC will linger for some time until this financial year is over and I have closed the books for this year. I can then start on a new much, much smaller and much, much faster machine with a new accounting application. Probably open source. Then it is a final goodbye to Windows 98 SE.
First of all and probably most of all the office is small. It's not even the complete garage that I have confiscated it's about half of it. But like my web design idea: do not do more then needed. Use as little as you can. All things extra cost you and do not deliver any revenue. In web design it costs bandwidth. In my office it costs: extra heating, extra wall paper, paint, ceiling et cetera.
I have kept things mostly straight and rectangular. Yes, I am a CSS addict. I know, I know, you can use trickery to make things appear round or soft, but hey, I just made straight and simple.
By keeping things simple and functional I have avoided the clutter of bits and pieces. I am making doors for my cupboard that will hide all the stuff that the visitor should not be bothered with. I stay away from impressive and Flashy stuff and will only use it if it is absolutely necessary and functional.
Keep it semantic, I say, use things what they are intended for. Use a chair to sit on and not for storing old invoices.
Separate stuff, one shelf for my office supplies, one for books, one for software, one for my invoices, ledgers and other financial bric-a-brac. Like separating the content, the styling and the behavior.
My office will be the metaphor of my profession. Nice, clean, stylish and above all simple and accessible.
Being the web purist and CSS addict that I am there is one thing that I have to confess. With some shame.
Here I go There is a table in my office.
I know, I know, being the semantic web aficionado I try to avoid tables, but this table I really use as a table. I tried it with my laptop on my lap, but it just didn't work out. Please don't tell anyone.
If you do then this post is not for you. Better still get out of here. You may just be one of the types that usually destroy my happiness during meetings. Get lost in another meeting. You should probably already be there anyway. Or are you reading this during a meeting? Then politely go to the toilet and bang your head against the wall, until it really hurts.
In a recent enough job the Thursday is for the unhappy few a totally unproductive day of the week. In a department of about twenty people (I haven't counted recently so it's most probably less: we're going through a disintegration phase, perhaps more about that some other post) the management has found a way to make three or four meetings (bi-)weekly with subtle differences in composition to talk for at least an hour each about what is going on in our department. Although I must admit that I can only guess this as I am one of the happy few who doesn't have to attend any of the meetings. The most important meeting (again I guess) is on during lunch providing a group of PHBs with a free lunch. The best thing about the Thursday that most of the people who are in meetings that whole day that are free on the Friday. Yep, a lot of part-timers here. This essentially gives them an effective three day work week, that is if we forget that there are more meetings on other days as well. Any decisions made on Thursday (usually avoided until it's no longer impossible to avoid) are kept luke warm during the weekend and only set loose on the Monday so there is plenty of time to sit back with a glass of wine and think it over.
Me being one of the happy few I am still not involved in the Thursday Meeting Frenzy (TMF). But fear not there are plenty of other meetings around. We have team meetings every other week (in which one of us takes notes). These last about an hour, shorter if we can help it. We have the department meeting, also bi-weekly, in which the management tries to tell us stuff that usually people already knew, but sometimes they surprise us with information literally falling from the sky. These last about an hour and a half, provided we do not raise too many questions. Then there are the project status meetings, weekly, set for a comfortable hour, so it's best to come in late. Then we have the one-on-one conversations luckily only once in every six weeks (theoretically). Semi-annually there are the performance meetings that unrelated to the performance last at least 90 minutes.
RohoOr are you reading this during a meeting? Then politely go to the toilet and bang your head against the wall, until it really hurts.
And I probably have left out a few. I am trying to block meetings from my mind, you see.
Meetings are set up usually with good intentions.
Good intentions already cost hundreds of thousands of lives in Iraq alone. So be careful with good intentions. Stay well away from them.
These good intentions never turn from intentions into reality. The meetings are more repeating findings and problems that are already discussed on the work floor or by the coffee machine (which incidentally is the best place for a meeting). Within a (project) team or a department the informal meetings are by far more effective then the scheduled hourly meetings. The informal meetings arise ad-hoc and only last as long as is needed. The scheduled meetings rarely take less time than scheduled. The informal meetings involve only the people needed for the issue at hand. In the scheduled meeting all team members are burdened with a problem that can be resolved if just two people discuss the matter at the coffee machine and make a decision. In the scheduled meeting this (pre-)decision can then be told to the PHB. When one does this the right way you can even make the PHB feel that he was the one who made the decision.
RohoAll in all most meetings are a waste of time and resources.
The idea meetings is that they form the grease to make the machine run smooth. In reality meetings take up unnecessary amounts of time and people are dragged into discussions about minor unrelated problems that do not involve them in anyway other than that they are problems of people who happen to be on the same team. All in all most meetings are a waste of time and resources.
Apart from the scheduled pain in the behind meetings also form unwelcome breaks in your work. I guess, everyone's PHB occasionally has a few days off or is ill or on a trip to an exotic place to have a demo of the new wireless mouse you don't need. And then there are these great PHB days where they gather in some luxury resort to discuss the much needed savings for the next financial year, something you can not do in a meeting room in your own building. That would cost much less.
When the boss is not there for some time you can see the department moving around a bit more easily, more productive. Did I say a bit? I mean, a lot. It's not just the lack of his or her inspiring presence, but also the lack of a load of meetings being cancelled. Suddenly, you have more time on your hands and also there are less breaks in your production. You can work on without having to go to yet another meeting. Also, less frustration ahead of a meeting and no frustration after meeting because the frustration before meeting was justified.
In these happy periods of no (or hardly any) meetings you find that meetings are the sand in the machine. The stuff that makes it squeak and go slow.
Some of the following tactics have been used by me or colleagues with some success so I thought it would be good to share them with the world.
Hope this reduces some of your meeting pain. We're all in this together.
This post is based on personal experience with several employers and on some posts I have read all over the Web. Please also read the Disclaimer.
Now, that the economy is slowly getting up to speed in Europe and my home country, The Netherlands one can see that jobs are opening up again. It is hard to look in a direction and not see new jobs being offered for good pay.
Add to that the feeling that one has a different view on market conformity in salary than the average manager then things start to tickle.
Already various people from my department have accepted other jobs, both internally and externally. The overall landscape has completely transformed from about a year ago. Add to that the rich sauce of an upcoming organizational change as part of a looming merger and whoa! a lot of unrest is being discussed in the coffee corner.
Well, as I am always very flexible to changes I don't mind looking out of the windows of opportunities and see some floating by happily. In a market of demand he who has skills is in command!
We'll see what the future brings who will be the next one biting the bait of better wage in a hopefully more stable situation.
p.s. Anyone want to dangle some bait in front of a web developer? Don't hesitate.
With outspoken criticism from many in various forums and blogs on the use of web standards and XHTML and CSS the discussion never seems to cease. If I bluntly summarize the critics I think they say “Why use difficult things like XHTML and CSS? It's just too difficult for me to understand and I can get the same result by using twenty nested tables and a few spacer GIFs!” OK, as we say in Dutch this may be a little “short through the corner”, but still, from where I stand it's close to reality.
CSS & web standards illiteratesWhy use difficult things like XHTML and CSS? It's just too difficult for me to understand and I can get the same result by using twenty nested tables and a few spacer GIFs!
Recently there has been some buzz around standards that make them hot again. Eric Meyer has produced three clear articles with suggestion on improving the W3C. Over on Vitamin an article explains why standards still matter and what we (the good people) can do to promote the use of standards. And just today A List Apart added another good entry in this arena.
These articles and all the resulting comments show that standards are still hot (and never really cooled down) and that standard conscious web designers are a growing and active community. And that in the near future standard compliant web sites might become the standard.
If you are still using the old table based design and don't care for document types and closing all tags and are of the opinion that if Internet Explorer shows it right it must be right then maybe it is becoming that you should start worrying if you shouldn't learn to build websites the proper way. It is difficult at first. It was to all of us. But doing the right thing never hurt anyone.
If you don't care and you don't want top change. Well, just simply fade away. Goodbye to all you spacer GIF loving people.
Last year we were watching a looming magical date. The date that was set as the launch day of the new version of our website. It was September 13th 2005. After that date was set some people starting to think about what the new website would be like, what functionality was needed.
As one sees it was another one of those projects where the end date was set first and then what needs to be done is scraped together. With limited resources you know you head straight into trouble. And we did. We overshot the magic date by eight months.
As one of my team mates found out just this week September 13th isn't just a random date. Over on Wikipedia is still an article (article is being considered for deletion in accordance with Wikipedia's deletion policy!) that claims that the 256th day of the year is Programmer's day. And the 256th day of the year is 13th of September (or the 12th in a leap year). This can not be a coincidence.
WikipediaProgrammer's day is a holiday on the 256th day of the year celebrated mostly by computer programmers. The date is significant to programmers as it represents a byte of data's capacity being that of an unsigned 8-bit integer, or 28.
Programmer's Day usually falls on September 13, though on leap years, it falls on September 12.
Supposedly another clue for intelligent design, but to me the date of September 13th will be a beacon of bad project planning.
On 9/11, a couple of days ago, Keith Olbermann, an American news anchor gave a commentary indicting the Bush Administration's shameful and tragic response to 9/11. The entire text can be read over on Yahoo! News.
Take some time to read it. It sums it up pretty nicely, I think.
Recently there have been some discussions on various sites about the flaws or irrelevance of CSS and XHTML. John Dvorak started with his article against CSS. Many others have reacted to that and so did I. More recently Emil Stenström started with an article titled 'Why XHTML is a bad idea'. Now all we need is an article that says that JavaScript is a big nono.
Even though I think that the current W3C standards for XHTML and CSS are not perfect and totally not up to date I feel that we just have to work with the tools at hand. And we should also strive to get better tools, better standards.
But my main problem with the two articles is that I sense that both writers come up with the objections against CSS and XHTML because they have (had) difficulty learning it. Using CSS and XHTML is too close to programming, in their opinion. Therefore we shouldn't use it. Therefore it is flawed.
Huh?
Well, maybe we should call it programming after all. I mean, using CSS is implementing a bunch of rules that say when a page element with this type of tag or this ID or that class it must be floated to the left or it has a blue background. In a very concise format every rule in CSS is a IF THEN statement. In XHTML we give meaning to the content by wrapping it up in tags and adding classes or IDs.
When one has a look at CSS Zen Garden one can see what is possible by changing the IF THEN rules, the CSS. If you take step back you are basically looking at a different presentation of the same data (= the content of the page). Continuing along these lines: every different design can be seen as a different report based on the same data.
And building reports is also close to programming IMHO.
To further clarify my issue with both these articles the following quote.
Emil StenströmStill the W3C pushes for XHTML as the new standard for the web. Despite how hard it will be for beginners to get things right.
I see writing XHTML and CSS as writing code (and I am not the only one) and I see it as part of my job as web developer. (I also code in C# and JavaScript.) Writing code or programming means that there are rules that apply. There is syntax you must adhere to. If you don't follow the rules then the results are hard to predict.
In the early days of the Internet the rules for HTML were not as strict as now and you didn't have to close all the tags like in XHTML. Browsers were and still are helpful and forgiven with broken HTML. Internet Explorer is very friendly in that respect.
But because there are rules (for XHTML and CSS) does not mean that that is bad. The rules are there to provide the same set of tools for browsers developers and web developers. So that I can expect my code to be presented in the way I intend in any browser. If it doesn't the usually I made a mistake or the browser in question interpret these rules different.
These rules, the standards are what you need to know to use the tools correctly. That takes some learning. Learning takes time and you need to invest in that. Sometimes it can be frustrating when things don't seem to work in the way you want. When this happens lean back and think of another way to do what you want.
But you must be willing to learn and keep learning. That is the point. Nobody says it easy or that will be easier. It may very well become more difficult when more and more things are added to the standard.
Working in this profession means learning, learning and learning. Every day. So, if you want to survive you will have to invest, you must be willing to learn. Over the door of my old primary school it said (roughly translated):
He who wants can.
I think the aspect of learning almost every day is one of the things that keep my job and life interesting. Also the more I learn the better I understand that there much more to learn. In the last years I have been working more and more with object orientation and design patterns. I start to recognize this within the web stuff as well (Model View Control = Content Style Behavior = HTML CSS JavaScript). And with that recognition I start to see where I have done things in an awkward way. In short the more I learn the more I know that what I have done in the past was not done in the best possible way. I would do things different now. I think I am improving always. Slowly but surely, by learning new stuff and learning how to use that the right way.
Simply saying that the old stuff is enough to do what you want is not enough for me. When I feel that there is potential for improvement of my product in some new technology then I think it is justifiable to invest time to learn it. If it turns out that it does not help to improve the product or makes it even worse then still I have learned something: not to use it in this situation.
I am moving away from the start of this post. Returning to it now quickly.
The articles I mentioned and the following discussions where mainly about technologies being flawed because they were difficult to learn and implement. I think this the wrong way of looking at them. CSS and XHTML are powerful tools despite relative little available syntax and commands (compared to something like C#). Putting them to use requires quite a bit of knowledge. Especially if you want to use it to its full potential.
The hurdles you have to overcome along the way (like the browser issues) are not a ground for stating that the CSS and XHTML are flawed or just sticking with the old stuff. The world is changing so change along with it and yes that requires learning new stuff. Every day a little bit.
Today it is exactly five years ago that planes hit the Twin Towers and the Pentagon. A further plane crashed in Pennsylvania. The world was shocked. It would no longer be the same.
Many people died that day and in the following wars in Afghanistan and Iraq. It all seems so pointless.
Sometimes I doubt that the world changed that day. It was the culmination of things that happened in the years before that. And it still goes on.
Just sit behind your screen for a few minutes and think about how to make this world a better place to live for everyone, for every persons, regardless race, nationality, religion or sexual preference or wealth or whatever.
Give peace a chance!
Getting used to vacation takes about half a day. As soon as I have left the street in which I live in my car fully packed with tents, sleeping bags and kids that's when the vacation spirit kicks in.
After coming home and getting back to work it takes much much longer to get used to being back at work. I find myself looking out the window and dreaming about Pippi.
Luckily the power company decided to help me out a bit yesterday. They created a beautiful power failure just before one o'clock and our wonderful IT department has power backup for the servers for a maximum of 30 minutes. After 30 minutes they bring down the servers and bringing these back up takes about two hours. Add to that the expected duration of the power failure of two hours and we were excused if we could not longer do any work. Well, I only had one meeting of half an hour (which was moved forward immediately) and being a developer I could not do anything. So I left early on my first day. Thanks Essent!
For today I hope Essent or some careless dragline driver helps me out again.
I have noticed considerable more readers lately since one of my posts was exposed by The Google Enterprise Blog. So all the more reason to keep this tiny crowd satisfied. But, I will lean back for a couple of weeks and enjoy the landscape that is called Sweden.
Last year I skipped summer vacation because I moved back to my home town and spend a lot of my free time this year DIY-ing around the house and garden. All very rewarding, but also energy draining. So, yes I do think I deserve some time off.
And during vacation I try to steer away from computers and the Internet to save myself from doing things that closely resemble work. It's time off completely. I will walk in the forest, try to spot reindeer and elks and Pippi Longstocking.
In my last couple of posts I have mentioned some of the projects that I am working on for my employer. Just to keep you informed here is a quick update on things:
Now, I just try to figure out what is going on in London and the world. And then I will go home and pack my stuff and drive to Sweden to get some well deserved rest.
Hope you return sometime in September!
Well, it is me. I have just quickly snapped my coffee cup (half empty at the time) and uploaded some pictures to PictureCloud.com to create a simple view from all sides. Click the image below and watch it spin!
spinning coffee cup by picturecloud.com
It may not look too impressive, but hey it's my phone camera and only twelve pictures taken from a not so steady hand as I had caffeine withdrawal symptoms while snapping.
In one of his articles John Dvorak explains why CSS bugs him. It is a relatively short article but it stirs up quite a vivid list of comments (five pages and counting).
And rightfully so, the article is a very bad piece of writing considering the aeons of experience the man has in the computing industry. It seems that he has taken a stab at CSS and couldn't get it to work for him. Or not in every browser.
This no big surprise as the learning curve is quite steep and you need quite a bit of time first understanding the styling options and after that all the weird ways various browsers render these. Finally you will have to learn the hacks to fix these inconsistencies. A little too much to grasp on rainy Sunday afternoon before tea.
Now let's pull some quotes out of context and try not to laugh but stay positive and objective. Well, hardly objective.
John DvorakThe first problem is the idea of "cascading." It means what it says: falling as in falling apart. You set a parameter for a style element, and that setting falls to the next element unless you provide it with a different element definition. This sounds like a great idea until you try to deconstruct the sheet. You need a road map. One element cascades from here, another from there.
Using the DOM inspector in Firefox or Netscape Navigator will help you to keep track which rules apply to an element and even in which order. Also some basic understanding of CSS is handy. And BTW this is not cascading but inheritance that is discussed here.
John DvorakOne wrong change and all hell breaks loose.
That is programming for you. One wrong change and all hell breaks loose. When you can then put out that fire again you show programming skill.
This is hardly a problem or bug of CSS it is an inevitable part of any programming language. If you can make it, you can break it.
John DvorakIf your Internet connection happens to lose a bit of CSS data, you get a mess on your screen.
John, are you still using a good old 14K4 modem with occasional static? I have not yet experienced this problem and have never heard of any one who had this. So you are the first to report the problem.
John DvorakThat's not the worst thing. You can live with the basic cascading mess; it's a matter of debugging. The real problem is that no two browsers, let alone no two versions of any one browser interpret CSS the same way! ... Can someone explain to me exactly what kind of "standard" CSS is, anyway?
Hello John, this is not the problem of CSS but rather of the different interpretations or lack there off by different browser manufacturers. You can not blame CSS for this.
The lack of understanding of CSS and the problems presented by the different browser in rendering that CSS is what most struck me. I was disappointed to read an article by quite a big name in the industry.
Although many people have commented on the article in much the same way as I now do there were also a great many people who blindly follow John Dvorak. Or had even stronger opinions against using CSS.
The arguments for sticking to tables astound me as there are so many reason to getting rid of all these useless <table> <tr> <td> tags. The simplest being a complete waste of bandwidth and also making the page more accessible and maintainable.
It amazes me how many people just stick to the trick they know and just do not want to learn new stuff. I think learning new stuff is one the great challenges but also satisfying pleasures of working in IT. You'll never stop learning in IT! I don't mean to say that you should learn ALL the new things out there. There is simply too much. No, one should take a look at the toolbox one has and then look to see if there are newer and better tools around and use the tools what they are intended for. You can hammer a nail in with the handle of a big screw driver but a hammer works way better.
When you type with two or three fingers like I do you should not write an article about the special Dvorak keyboard and comment on the awkward places the keys have gone. But when you take the time to properly learn to type on it, it might be different story and then review can be valuable. Otherwise stay well away from it.
When you know little of CSS and browsers rendering it then you should not write an article about the CSS and comment on the awkward things happening to your page layouts. But when you take the time to properly learn to code in it, it might be different story and then review can be valuable. Otherwise stay well away from it.
UPDATE: I have written a new, longer post on what is and what isn't wrong with CSS.
The article by John Dvorak on the PcMag website about hat's wrong with CSS has stirred up quite a bit of dust. Although, I think the article it self is pretty bad and flawed and lacks arguments and facts supporting its conclusion I feel there must be something that makes people comment with such vigor. Even I did already comment on it. Yeah, guilty as charged.
The comments are getting close to the eternal discussion why one OS is better than the other or why browser X is better than browser Y and why you are completely lost when you still use browser Z. But it still a flow of comments that stay within the normal way of conversation. No flaming yet. But hardly a discussion.
Still, there was some non-understanding flying hither and forth, but also there were some more or less valid points about CSS and what it is not so good at.
When going over the article and the all the comments I rake out the following points.
Yes, I do agree. Setting a font type and size is really smooth. You can define that at the top most level in your CSS and all text will be formatted accordingly. Yes, there are differences between browsers and operating systems, but we can live with that.
No, that is not the case. CSS can be applied to much more than just formatting text. It is quite easy to set background colors and images and define the way links behave when the mouse is hovering over it.
Although, this is really close to formatting text in my opinion. But the next point that was raised put my hair upright.
I was never a fan of using table based layouts. To be honest, I missed that part of web design. I made some sites with frames and feel a bit ashamed to admit that. But for the most sites I made I have always hand coded them in a simple text editor and hand coding table based layouts is just short of Chinese Water Torture.
Layout with CSS has many possibilities. There are quite a number of methods to create a page with three columns and a header that looks the same, but has different XHTML and CSS underneath. There are some limitations, but for most of these there are solutions available. Many, many sites offer standard layouts with 2 or 3 columns with or without a footer and cover most of the used layouts that are out on the World Wild Web.
You can try to reinvent the wheel, but you do not need to. Go ahead if you like.
Well this is turning things around a bit. The different brands and versions of browsers do not render CSS the same way. A big chunk of CSS is consistent (the "text formatting stuff" mentioned before.) and some is not.
The text formatting stuff works across the board. Hence the perception that it is the only true purpose for CSS. But it also drives the point that when more browsers support the CSS standards it will possible to do more with CSS without all these hacks.
Because of all the necessary hacks and various ways to achieve a layout from almost the same HTML source it can become quite complicated to decipher a CSS file. Especially when multiple files are used and inherentence is (ab)used extensively and NO COMMENTS and no logic et cetera, et cetera, et cetera. Well, then you are talking about a badly put together CSS file. Made by a bad developer. You can best start all over from scratch.
But on the other hand when CSS settings are grouped and comments are used to identify the various sections and the horrible hacks then things become much friendlier.
Also maintaining code created by someone else should also mean that we should be talking about a development process with documentation. And yes, one should document CSS as well as other code used. I know, that would be a perfect world. In practice grouping and commenting code makes life for the ones who come after you a lot easier.
CSS maintenance and redesign are two separate subjects. If maintenance is close to redesigning a site, like completely changing column widths and order and a complete visual overhaul is not something that can be taken lightly. But it can be done.
When only a new widget is added to a website you should best start from finding a widget that more or less resembles what you are aiming for. Try to use the HTML as basis and then add some CSS to style the widget. With a well organized CSS file, things could then be a breeze. But if your CSS file is macaroni then you are in for trouble.
The CSS showcase site Css Zen Garden is great. It shows how you can have a site with the same HTML look completely and utterly different by just using another CSS file. Some of the designs are absolutely gorgeous and it is hard to understand that still the same HTML is rendered by your browser.
The Zen GardenerThe Zen Garden aims to excite, inspire, and encourage participation. To begin, view some of the existing designs in the list. Clicking on any one will load the style sheet into this very page. The code remains the same, the only thing that has changed is the external .css file. Yes, really.
And then you look at the HTML. Oops. This looks all over the place. This is not what we call semantic HTML. There are loads of empty <div>s in the code. Why?
What we must remember that Css Zen Garden is a showcase site. It shows what is possible using (clever) CSS. It does not show you best practices of CSS. It does not show best practice in HTML. It's a place for designers and CSS wizards to show what they can do.
I would not call it bad CSS and bad HTML, but it is not the proper way to use it in day to day practice. But it is great to look at what can be achieved with CSS.
So, reading the following one can say that some time to thoroughly learn CSS and the browser quirks and using best practices in developing CSS, it is possible to use CSS to layout web sites.
However, some problems still exist.
Even though there is some support in CSS 3 this is very far from a standard (CSS 2.1 is still in draft) and browser support is (nearly) zero. One has to fall back on the various methods of laying out pages. These usually involve various extra <div>s wrapped around the content to position all the elements.
New CSS properties could potentially fill that gap.
In the old days you could draw a page layout in Photoshop and then export a complete table based layout HTML file and that was that. You had a great looking page. Trying the same thing nowadays and hoping to come up with neatly set up semantic HTML and a separate CSS file that handles the layout of the page is Utopia. I do not foresee any WYSIWYG tool in the near future that can handle all well known CSS patterns, like for instance the Sliding Doors Principle.
There has been quite a bit of criticism on the W3C Org lately. One the points is that it takes so long for new standards to be ready. In the fast moving Internet world they are centuries behind the recent developments. Seeing that they are a standards body that have to deliver products for all kinds of machines and software that connect to the web it is quite understandable that it takes a long, long time to finish new standards.
But this slow progress hinders progress of all browsers manufacturers and software and web developers who want to keep improving the products they are delivering.
Yes, there are things not perfect with CSS (and the same goes for (X)HTML), but that does not mean that you should avoid it.
The pros win it from the cons by a long way, even considering it takes time to learn to apply CSS and the lack of good tools.
CSS is here to stay and it will evolve. And as always, evolution is slower than revolution, but it is also a smoother form of progress.
Only the very alert reader may have noticed that I dropped the word "microformat" carefully in my post about implementing the Google Mini. It is too much asking of anyone out there that this is a sign that I am slowly being won over by the movement that promotes the use of microformats on the web.
Explaining the Big Idea behind microformats has been effectively covered by the wiki at Microformats.org, but to keep you here I will briefly pull a quote from said page: "Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards."
IMHO the main drive behind the microformats idea could be that there are over a million ways to markup data like business contacts and that they usually produce easily human readable information, but because of the varying underlying html it is hard for machines to understand what the data is about.
Chris MessinaMicroformats are simple codes that you can use to identify specific kinds of data, like people or events, in your web pages.
Microformats are based on standard html tags that are improved by adding standard class attributes. In the example below there is the part of an hCard microformat that holds the postal code.
<span class="postal-code">8332 KS</span>
CSS can be applied to this quite simply to make it visual appealing to the human and the standard html can be understood by the browser or an extension / plugin that automatically can add the contact to the address book, start an email, make a call or shows the location of the contact on a map. Anything could be done. No cutting and pasting involved. Simply scan the page for the specific html tag with the class name and do whatever you like with the information found.
Search engines could also use this to automatically gather all sorts of information.
The possibilities of giving more ease of use to the visitors of a page seem endless, but also for web designers / developers it means that there are more common solutions to common problems. More patterns.
Yep, here's a drawback, that means that after learning about CSS and all the browser inconsistencies and hacks and XHTML and unobtrusive JavaScript we know must also start to use microformats. It's the ultimate curse: you never stop learning in IT. But it is also one IT's charms.
The microformats are not part of any W3C standard and I don't think they will ever be. The amount of critique on the W3C has been increasing lately. More and more voices are stating that they are getting more and more enstranged from the developers community that promoted standards based design. Likely, we will see more standards being developed out in the wild and slowly but surely these standards will be adopted by more and more developers until it is absolutely insane to not use them.
For early adopters or people who want to get at least a sniff of things to come the time has arrived to start reading up on microformats and start implementing them here and there. Or maybe build a first Firefox extension that makes clever use of the data held in these microformats.
Go on you developers, go and do the right thing!
Coming back to the office after a long weekend spent DIY-ing around the house I looked at Google Analytics for this blog and noticed a little spike in the visits. This usually happens after a new posting but this time there was some days delay.
I appeared that my post about the Google Mini implementation was picked up by Rodrigo Vaca from the Official Google Enterprise Blog. I found a lot of hits coming in from the article: Rob, we're glad you had fun.
Wow! I feel honored! Yep, it was fun and today I will be setting up the test environment so within a week or two things should be live.
The Google Mini implementation together with a redesign (or rather re-alignment) of our website will be put in production on the 24th October. It took longer than this post suggests because of other higher priority projects that were implemented in the past few weeks. But hey! It is coming at last.
As briefly mentioned in my previous post I am working on the incorporation of a Google Mini appliance in the Univé website. I will go into this a little bit more detailed.
I am a sort of a DIY-person. I like to do things myself. That means most of the time that things take longer before it is finished, but when it is finished the feeling of pride and self esteem pays for that. Also along the way of any of these DIY projects I get to stages that I have to do something new with some new tools or materials. Most of these have words on the packages like "can be assembled in 5 minutes" and over time I have learned that that is the moment to be aware, to be very aware of pit falls. Usually I have picked something to use it in a slightly different way or want to use it inside a small space so it is impossible to use a screw driver to fasten it.
I think that these problems are directly related to my lack of skills, because usually (after some tears and sweat from me and cursing the people who ever designed the stuff) I can use it for the purpose that I had intended. I think of myself as a reasonably well DIY person.
The same applies in my IT skills. I sometimes wander about and pick the wrong route at first, but usually I get stuff working, again after some tears and sweat from me and cursing the people who ever designed the stuff.
But these marketing words: "up and running in NO time" still put me in a special mode. When something can not fail I know it will.
So, when we had wheeled in the Google Mini appliance I was ready for weeks of administering and tweaking to finally get some search results on my screen that vaguely would like what we would want to see.
I know I have been very enthusiastic about the stuff coming from Google in the past months, years and maybe it seems like I am a blind follower of the company at Mountain View, but I am not. But I am of the opinion that have created some very good stuff in recent years. And when they haven't created it themselves they give it a twist by presenting it for free, like Google Analytics.
After these lengthy opening paragraphs I am now returning to the subject of this post: implementing a Google Mini.
During the build of our new website we had dropped search as one of the deliverables for Go-Live. It was postponed to the Point One Release. You can have a nice long discussion about that, but don't bother we did as well and management decided to drop it and so we did.
We had acquired a Google Mini to facilitate the site search and had it hanging in a server rack for a couple of months gathering dust, but once we were ready for launch I was given time to explore its potential. I must admit, that I was a bit afraid to have a stab at it. To me it was a black box (although it's happily blue) and I did not see an opening. And misplacing the manuals was another hurdle we had to take and after some Googling on Google we found a way to download the stuff and have a go at it. Then a colleague opened his drawer and said that he had secured the manuals. Sigh!
The first things you have to do is some basic setup like giving a IP address and an administrator password. This was done very simple using a laptop connected directly to the box. Then using the web interface it was really easy to configure the crawling and after the first crawl see the first results through the familiar Googlish interface. Tweaking a bit of XSLT brought out the company colors and logo and I was ready to be enthusiastic again. This machine would provide an easy site search for our website. And so we moved on.
Well, we did not want to give visitors direct access to the Google Mini, but we wanted to really integrate search into the site context. We have added a search box to our menu bar and created a new search container or template. Communication with the Google Mini is managed through a Web Service.
Since, the Google Mini already came with an API it was relatively simple to set this all up. Cutting some corners we decided to stay with a plain search screen and leave out the advanced bits for the moment. This meant that we needed a simple Web Service method that would only take a string as the search query. Added to that we wanted have navigation from one page of search results to the other and we another method was needed for accepting the (more complex) query with page indication and the like. This second method was also used for the spelling suggestions and the keymatch results (aka Sponsored Links).
The Google Mini API is very simple in nature. All one needs to do is build a long URL with query parameters and you are provided with XML string that holds the outcome of the search request.
The XML string is then returned to the site and there it is loaded into an XmlDocument and then parsed using XPath queries and presented to the visitor in simple XHTML.
First of all, we did not want to reinvent yet another better wheel. We feel that Google does a great job of presenting search results. But being a web developer I also know that the code used to produces the list of results is not exactly what we call modern or semantic web design.
So, we liked what it looks like on the outside and decided to change the inside.
Show in the screen shot is part of what the page will look like. The similarity with Google search result pages should be obvious. We even have space for AdSense ;-)
The search results are presented in a <dl>, with the linked title in a <dt> and the snippet from the page in a <dd>. This seems to me a reasonable microformat for this purpose. Keeping the pages lightweight was and is one of our primary goals.
When I now look back at this project (just before it is moved into the final test cycle and put online) I think that we did a great job. And the Google Mini is a great way of providing site search. Implementation went smooth and the only challenges were again in getting the .NET Framework work as we want it to work.
The Google Mini once configured does not need any real maintenance. If the machine should lose it's complete settings and database then setting it up fresh and let it crawl our site can be done within an hour. The Google Mini really lives up to its expectations. It was great fun to do.
After putting it in production we have a very strong tool for our content writers to see how a search engines sees our site and how Google presents the results. I plan to work with them to make the site even better than it is already.
In that way the Google Mini will work as a benefit by providing search to the visitors, but also as a tool to improve the search engine performance of our site. Not bad for a little blue black box.
The last few weeks have been weeks with enough work, unlike the weeks, months before. I have been fixing minor issues with the new website and also working on some new extensions for it.
If all testing goes well we'll soon move to an 1024px based layout instead of the present 800px width. Also in the same release the site search will be brought back to the site. We already had search on the old site, but during the build of the first release this was delayed in favor of other features. But now it is coming back in full force: I am implementing a Google Mini.
And apart from that I am busy finishing my home office and that is getting close to completion. I have taken a couple of days off this week to race the final stretch to the finish line. I should be in business before next Monday.
So that's the reason why I have been slow with writing posts. Hopefully, I will find more time in the next weeks. I think I will as the workload is drying out again as some projects have already been postponed.
I have a laptop so I can bring that to clients and show some stuff and work at other locations than my home office. As with all computers I have owned after some time the systems can not hold all the stuff you want to take with you and become slower and slower after intensive usage.
As the machine was still good enough for its purpose it was time to give a little boost. I wanted to add some memory (I worked with a lousy 512 MB anyway, which is not very much) and my hard disk was filling up with all sorts of disk images and projects and other stuff that I needed more storage as well.
Just for some extra info: I own a Acer Aspire 6003. I am quite happy with it.
Adding some memory shouldn't be too hard now. On the bottom of the machine is a panel that hides the memory. Taking a screwdriver it is simple to remove the screw and then open the panel. Tada! There is DIMM module. I take this out with care and look at it with interest. It says 256 MB and I have 512 MB total memory. I look inside the opening, but no, I can not find another DIMM. Hmm, this is strange. I have looked at the manual and it says that there should be two memory modules. There are some more panels one that leads to the wireless card and the others are for the battery and de the media drive. Look again in the manual and all over the Acer website but I cannot find out where the other DIMM might be. So, I decide to just replace this DIMM with a bigger one.
Carefully I make a photocopy of both sides of the DIMM so I have with all information necessary to purchase the correct one later. And indeed this came in handy as there are gazillions of memory modules to choose from. I buy a 1 GB DIMM and pop that in and my laptop all of sudden has 1,25 GB of RAM. It was completely plug and play. Unbelievable that things do work like that. Starting up my system is now a lot smoother and faster since there is no swapping going on anymore.
If anyone can tell me where the other DIMM is hiding in my laptop then I might just replace that one as well.
Thanks to one of my readers, Amar, I am now aware that the other DIMM is hiding under the keyboard. Instructions on how to get to that DIMM are available on Amar's blog. But beware of all the hearts ;-)
I had already figured out that adding memory would be much less of a hassle then replacing the hard disk. I had one big requirement with this part of the job: I don't want to be busy reinstalling the OS (Windows XP) and all the applications and then for ever patching all the stuff. I wanted to copy the hard disk to the new drive and replace the old disk with the newer one.
I had the following plan:
I combined the first three steps by finding a cheap complete external 120 GB 2.5" drive with USB cable. This would double the storage of my laptop which seemed enough for now.
So I hooked up the drive and started off with grabbing Partition Magic and created some room on the new drive and then started copying the partitions across. I created a new partition in the remaining free space. This takes sometime so in the mean time I watched some World Cup.
With all copying finished I switched everything off screwed open the external casing (voiding my warranty, but what the heck) and took out the new drive. I then swapped it with my laptop's drive and switched the laptop on.
Windows started protesting that hal.dll was corrupted or missing. Googling over the Internet and several news groups I found this to be a common problem happening when people tried to do what I did. I tried several of the fruitless solutions and then tried a new approach.
One workable solution appeared to be making a copy of the existing drive without making any changes to partition sizes or adding partitions in the remaining unused disk space.
I downloaded Casper XP trial edition at Future Systems. It gives me 30 days to try it out, which should be more than enough to tackle this problem. I put my old drive back into the laptop and I told Casper XP to copy my drive to the new drive. It warns me that all info will be lost and then told it would take more than 10 hours to complete. A World Cup hardly ever lasts that long so I decided to just let it run through the night.
The next morning it was finished and thanks to some clever algorithms for copy empty space it took just two and a half hours. I swapped the drives and like a breeze my system booted! Absolutely amazing!
Partition Magic came in handy to stretch the partitions to cover the entire drive and in a matter of another half an hour I had my system completely ready.
Even though there was some problem with copying the hard drive in the end it was quite a simple job. You need to know the right approach on copying your Windows XP installation onto a new hard drive and you need the right tools. Looking back I might not have needed Casper XP I could have used Partition Magic (with the right strategy) or Norton Ghost for that matter.
A job is always easy once you know how to do it.
A sequel to this article has been made. In that I discuss the current standard screen width you could design for. Based on data from the first months of 2007.
In a post today Tony Patton over on TechRepublic discusses Determining a standard screen resolution for your application. He has some point to keep in mind when designing a web site.
All in all, a not all too shocking article, but a good summing up of things to keep in mind.
In a comment TechRepublic member Wombat Ron then adds the increasing use of handheld and smartphones that have much smaller screens. He predicts that the 640*480 resolution could be coming back into the charts. So, it is difficult to say whether we are moving towards bigger or smaller screens.
I think Ron is right, although I think these could be handled by using the mediatype'handheld' to serve special styling through a dedicated CSS file. This is where separation comes back in its full power. With a good design of the structure of your site (the html) you will keep that lean and you can then just as easily serve that to handhelds and adjust the styling so that it will fit on a small screen.
One thing struck me as quite odd in the article was the example code that was in the article. This code looks at the size of the window to determine what to present to the customer. See code.
<SCRIPT language="JavaScript">
<!--
if ((screen.width >= 1024) && (screen.height >= 768)) {
window.location="high_resolution_version.html";
} else {
window.location="low_resolution_version.html";
}
//-->
</SCRIPT>
Here the principle of separation is missed completely. The users is redirected to another page and I think that it would be more then enough to serve another CSS file.
Separation of structure and styling gives the versatile option of changing the style while still leaving the structure intact. At our new website we have a 'normal' version and an 'impaired' version. The only difference is that other stylesheets are delivered to the visitor. The html stays the same. (Mind you: this does not make the site accessible, there are still plenty of issues that we will tackle soon.)
Right now, I am working on changing the layout of the site so that it strechted from an 800 pixel wide design to a 1024 pixel wide design. I this is all relatively painful as I only need to make changes to a couple of CSS files and stretch a few background images.
What is the most odd really in the 'resolution business' is that apparently designs are made for 1024*768 or 800*600. I hardly ever design the height of a web page. The width is a valid parameter but the height of the page is usually determined by the content and as a designer you have hardly any influence on that unless it is your own site.
I usually design for a certain screen width. Also I have a preference for fluid or liquid designs.
Sometime in September 2005 Google put out the Google Sitemaps product. To help website owners all over the world to inform Google of the pages of their websites. Being a website owner, designer and developer I immediately jumped on the wagon and tried it out. I started an experiment to try the effectiveness out and see if it did really do what I hoped it would do: make my new content appear in the Google index more quickly than before.
In a couple of posts ( 1, 2 & 3 ) I outlined the experiment I did with Google Sitemaps on my site.
I created a sitemap of my website. In this XML file all the interlinked pages appear. I added two pages to my website:
Both pages had legitimate content and also link back to other pages of my website. Actually, both were to be part of my website but I merely have omitted putting links on the other pages pointing to these new pages. They are in essence orphans. But could also be seen as landing pages.
The experiment was to see if the Google crawler would visit these two pages. The first directly from the sitemap.xml and the second through crawling the links on the first page.
After having submitted the sitemap.xml I was filled with joy when I discovered that Google scanned the file within 24 hours. Moreover it appeared to come by twice a day. That did not mean that the pages appeared in the Google search results immediately, but still it gave me hope that they would after the next crawl.
Image via Wikipedia
So, I kept checking my website logs to see if any of the secret pages (A or B) would pop up in my requested pages list. And checked again and checked again.
Now for the real purpose of the Sitemaps: getting your pages crawled. The Crawl process can take some time before it happens. The predominant belief is that a fresh crawl of the Web is done every couple of weeks or once a month.
So, after uploading my sitemap I expected it could take up to a month before my hidden pages were discovered. But after a couple of days the first secret page A was crawled. Bang! The sitemap.xml really showed its purpose. The file was indeed used by the Google crawler to crawl pages.
The second page did not show up immediately. So apparently, the links on the page were not yet crawled. They were probably queued to be crawled in a next crawl. Later they indeed did show up and so that part of the process worked as well.
The experiment was successful and has convinced me that Google Sitemaps really add something to a website.
A bonus of the Google Sitemap system is that a website master also has the possibility to view reports on the last crawl results. This can be achieved by placing an html file with a name provided by Google to verify that you can manage the site. Google then provides you with a list of failed pages. Pages that no longer exist or have another error.
These statistics have been extended over the last few months and now show also the most used search strings and also the search queries with the most clicks. There is more like a robot.txt checker and error reports. All very valuable for a web site owner. Read more about these handy sitemap statistics.
By adding a Google Sitemaps file to your website (and keeping it up to date!) you can ensure that new pages are crawled at the next scheduled crawl. If you have a popular CMS there is probably already a plugin available to create and maintain a sitemap. I can recommend it to any site owner. It is worth the effort. For me it is a little bit of work because I still use static html pages on my site.
Some time ago after the experiment more goodies were added. What extras are hidden in the Google Sitemaps console?
If you, for a completely obscure reason, do not wish to create a Google Sitemap, you can rest assured. You do not need to have Google Sitemap to be able to use this functionality. All you have to do is create an empty HTML file and upload to your site to verify that you own the site. And then you start leveraging the benefits. For free.
Google Sitemaps turns itself into an absolutely awesome troubleshooting tool for all webmasters.
This interesting experiment shows that Google Sitemaps is doing what it is supposed to do: making pages noted by the Google crawlers.
As said we launched our new website on Tuesday 30 May and implemented Google Sitemaps with it. I had registered the sitemap with Google a couple of days before the launch so it was trying to download the then still not existing sitemap. On launch day around 6 AM our time the sitemap was downloaded by Google. That was the first possible moment less than two hours after the site went live.
Two days later we see already many pages in the Google Index. When I did a search on the first 100 pages changed in the last three months on Google I found that of these only 12 are still pointing to our old site. My guess was that these are there only because we had some problems setting the rewrite rules for the old asp files. That was not entirely correct as a week later we still see old pages, but those are different ones.
The Google index now already returns new pages only days after going live. Without the Google Sitemap this would taken much, much longer.
Thanks to the statistics that we receive from Google we can now track the old, no longer existing pages that are being crawled. We can see errors popping up and if necessary we can further tweak our web application or web server to gracefully handle these.
Implementing Google Sitemaps has given us already huge advantages in the first week of going live. By having the Google Sitemaps ready at go-live we have been able to have Google find our new pages and content.
I would strongly recommend implementing Google Sitemaps with any web project so the pages will appear as quickly as possible in the index. Even though we had to implement the Google Sitemaps ourselves within our site framework it was not the greatest of challenges we had.
Many of the (open source) content management systems nowadays provide Google Sitemaps out of the box or through a plugin. So, there is hardly any reason not to implement them.
The Google Sitemaps protocol has in the meantime been adopted by more search engines and is now als an integral part of the Robots.txt. So, it's nowadays even more important to use the protocol.
Better still: It's now an open standard.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=81a27c80-674f-4754-a677-97c7f570440a)
There is no crying over spilt milk under the bridge on a rainy day
