Yes, it takes some time and discussions between the disciplines but you can win so much time in the future if done right. Doing stuff right depends on some crucial things:

• Work interdisciplinary and as (almost) equals. It’s easy to say what you think out the whole plan yourself, but if you do that, others are not inclined to think with you. Each new idea becomes just another bump in the project instead of a good contribution to a discussion to get a better understanding of a problem. By putting your problem on the table and make team members real team members, you get a real discussion. And a better product in the end
• Make your work public. You also get a whole other situation if you know that other people (clients or the community) are keeping an eye on you. In the positive sense of the word, that is. You have to think (just like Twitter) what is really useful outside your little bubble. And you might get good feedback to make your code even better/stable/useful.
  By thinking hard how to make stuff usable for the outside world, you’re instantly making a very usable and learnable tool for anyone who’s going to work at your firm.
  Making open source software could also motivate people. They’re not just working hard for the company anymore, they’re also working on something that can also be useful outside of the company and the greater good. That can be the motivation to work a more on it outside work time.
• Results before deadlines or budget. Ok, projects with limitless budgets aren’t realistic. But making reusable code or applications without keeping an eye on its usability or not even testing isn’t realistic either. To get quality reusable code you do not only need to write it, you have to think it out, write it and rewrite it and rewrite it. If you’re not prepared to do that, just save yourself the trouble.
• Continuous testing. Don’t wait until the very end of the project to measure its quality. You cannot remove the concrete slabs below an ill-constructed house either. Everybody has to at least check the end result of the finished component before moving on to the next target.
• Reusability is epic. Don’t kid yourself: Most of the stuff you do now has been done in the past as well. Talk with designers, programmers and developers to aim for reusability while preventing that all websites start to look the same. Getting some framework that works for everybody is everybody’s priority.
• Keep it simple. Some projects need solid plans. Others don’t. Some stuff does not have to be written out in threefold as long as the basics are known and the outer borders have been drawn. Be wary if the 5th version of the plan is mailed in PDF form to all team members, project time already gets out of hand and no real work is done yet.

No related posts.

Problems with my current codebase

Well, I already have a codebase, but it has some problems. The important one is that it only covers the very basics. That’s because designs can be very diverse and as a developer I want to stay true to the design. So it’s hard to build a codebase with grids and blocks if all design differ from eachother.

Another problem major issue is something I have more control over: the codebase and the documentation is a bit scattered. The last problem I have is that I have no demo page of my standard CSS code, so there’s no easy way to check the template on browser compatibilities.

Now my jQuery plugin project has reached version 1.1, I had the time to do some thinking about a new codebase that would be solid, extendable, easy to deploy and would replace all other codebases and documentation.

Let me make it clear: this article is about my considerations about building a solid framework for myself. It may not apply to you and my ideas not unique either. It still may be helpful for you to get an idea of what sort of codebase you need.

Existing examples

The most important thing about a codebase is to decide how to set it up and how to store it. I like the way open source grids like Grid960 and YUI have organized their code into little reusable bits and have created a demo and test page for each and every component.

I must admit: I hardly ever used these grids. Most of those grids talk the language of the web developer, not of the designer. And the designers I know don’t have to limit themselves to a 24-column grid system. Not to mention the designers that are totally ignorant of such a system and whose task is to design a website and mail the Photoshop file to some other company that has to build it. Although I have my reservations towards grids, I like the way these codebases are organized. It can serve as a good Blueprint for my own codebase.

I also get my inspiration from Nicole Sullivan’s talk on Object Oriented CSS (OOCSS). OOCSS basically means that you build your components in such a way that they become extendable objects. Just like in real object oriented programming. Just have a look at her talk about OOCSS on Yahoo! Developer Network.

Prefix classes

By adding a (relatively) unique string before the name of the class you have created your own CSS namespace. It will minimize any interference of other CSS styling that is not part of your own code. Some real life examples can be found in the code that is generated by the CMS systems I have experience with: Sitefinity and Sitecore. The CMS Sitefinity for example prefixes all CSS classes with “sf_”.

Grids, blocks and text

All CSS code will be split into different categories that work relatively independently of each other. Until now I can come up with 3 of them.

Grids

Grids are the frameworks of placeholders in which we put our content. You know: header, visual, column1, column2, column3 and footer. There are lots of grid templates around like Grid960 and Blueprint. My view is that those templates only work if the designer agrees to work within the limits of that framework. My ambition is to write a framework that makes my work easier while still being flexible enough to keep the designers happy.

Blocks

There are as many block as the designer can come up with. I think it will be a real time saver to talk with the designer and write down all the types of blocks he thinks he’ll like to use often. Or even better: just open the last 20 or so web designs he/she made and destil the common blocks and its common features. like menus, news article lists, homepage spotlights, etc. Finally you create basic blocks of it in your template system.

Standarization is not always popular with designers but if it means that projects can be created cheaper there may eventually be budget left to build cool stuff. At least, I hope…

Text

Basic text styling is also a relatively independent component in CSS code. You always define a basic font color, family, size and line height that serves as a base styling for the whole websites. More specific text styling in blocks should be kept to a minimum and preferably relatively to the base text style. So if you have a base style of font: 1em/1.5em normal Arial, sans-serif, you ideally should style a header in a block like this: font-size: 1.5em; line-height: 1.2em;.

Although font-weight is not something you can set relative to a base style, it’s not likely that it will look ugly in combination with some design if you add font-weight styling to a block. Setting the font-family in the styling of blocks on the other hand will most likely interfere with design, since designs tend to depend heavily on a particular font.

Create base templates and extend themes

The code for each grid system and each block will be stored in a seperate base CSS file. Each grid or block can be extended with extra themes or styles. Each style extension will have its own CSS file and presumes that the base file is already loaded.

Optimizing CSS

Having all code seperated in small snippets is great for maintaining an overview. As long as you can see what a CSS file does by looking at its filename, its will be easy to add and extend styling to a website.

The template code is not optimized for speed, though. If we don’t do anything about the fragmentation, the server will have to load a bunch of little CSS files. It’s important to stress this: It’s not just the total filesize that matters, each http request costs time. Check out YSlow if you want to know more about this and if it affects your site.

YUI

That’s why all CSS in the website has to be exported, merged and its code minified to one single CSS file. Normally I use YUI compressor for it.

Less

But you can do more than just minification. Less is a system that extends the CSS syntax with stuff like variables, nested rules and mixins. Less was originally built in Ruby, but there’s also an ASP.NET port. I hope it will help me create very flexible grids.

By exporting CSS into optimized code, you can focus on making the most readable CSS source file because all comments and spaces in the code will be removed in the end. This is also what I do with JavaScript code and certainly will continue to do.

Related posts:

1. Too advanced CSS selectors
2. The last resort in CSS debugging
3. Tips for using and debugging of Less CSS code
4. Crucial stuff for your company’s internal projects

DEL is your friend

Those cases happen rarely but when they do, I always resort to a tested and tried technique: isolate the problem by removing or commenting all unneeded markup. Isolating the problem may take some time but when you have a web page with a minimum of HTML while keeping the styling bug intact, you get in most cases the bug fixed in no time.

Why does isolating code work so well? Well, most of the time you can find styling bugs by experience, but when you’re stuck, every bit of styling on a tag becomes suspicious and that’s just too much to test. The bug becomes a needle in a hay stack.

Removing the easy way

The best way to remove blocks in a page is by just adding a display: none to its styling via a developer tool like Firefox’s Firebug, Opera’s Dragonfly, Webkits developer tools or IE’s Web Developer Toolbar. Just cut away big blocks and each time you remove something, you test if the bug still persists. You continue until you find the block that is triggering the bug. Most of the time you’ll have to continue the same technique of removing bits of code within that block until you can isolate the problem.

Hiding a block by adding a 'display: none'

Removing a block of HTML completely

Removing the source code

Sometimes it’s better to have direct access to the source HTML than doing temporary changes in the developer tool. But if the HTML is (partly) created server side it’s hard to easily remove stuff. In those cases when I’m really desperate, I request the HTML source from the browser and save it in the directory the original web page resides. Then I can make dramatic changes to the code and test in multiple browsers without affecting the site itself.

Is this an efficient way of debugging? Definitely not, but sometimes you just need to do it. It happens to me once or twice a year or so and by debugging that way I always managed to find the root of the problem.

Related posts:

1. CSS debugging
2. Tips for using and debugging of Less CSS code

For example: progressive enhancement in practice means that if you want to implement rounded corners, you’d use the border-radius style instead of a stack of images of rounded corners. But what if rounded corners are one of the corner stones of the corporate design of the client? Loads of users on IE7 and IE8 would miss that recognizable feature of that corporate design.

The design choice of rounded corners are sometimes a matter of taste, but most clients care for their corporate identity. So if you are ready to slaughter someones design in IE7/IE8 with progressive enhancement as your alibi, make sure that the features that will be missed in those browsers are not an important part of their corporate identity.

Related posts:

1. Do you create your design in Photoshop or Notepad?

Download Estate Developer Tools

Features

• Compare page with original design fast: You can compare the current page with an image of the original design within the browser.
• CSS reload: Reload the stylesheets without reloading the page. Extremely useful when designing websites with many Ajax calls.
• Console.log fallback: If you use clog(), debug messages will be routed to console.log() if available. If not (eg. you’re developing in IE), the message will be printed in a log box in the web page itself.
• Autofill and test forms: Auto fill forms with text that might cause errors like non-western characters, malformed HTML, JS injection and SQL injection. Autofill also works with the new HTML5 form fields.
• Timer: Do performance test by checking how long some operation takes.
• Works in: IE6+ and all recent versions of Firefox, Chrome, Safari and Opera. I did not check all possible browser versions, but it should work. let me know if you have problems with older browsers. The developer tools do not work in IE’s Quirks mode, but that’s something you should avoid anyway.

Quick overview

Sorry for the bad sound quality.

Installation

Step one is to download the tool. If you unpack the zip, you’ll find example page in the (what else) “example” directory.

Open the file called “index.html”. The developer tools are loaded just before the closing body tag: <script type="text/javascript" src="devtools/javascript/estate-devtools.min.js"></script>.

If you want to change the library to your own needs, you can load the source code instead. It’s in 4 seperate files that are in the same directory: Estate.js, Estate.Develop.js, Estate.Develop.FormTester.js and Estate.Develop.DesignTester.js.

After the library has been loaded, you can add items to the top right menu like this:

	Estate.Events.AddEvent(window, Estate.Develop.ToggleVisibility.Init, "onload")
	Estate.Events.AddEvent(window, Estate.Develop.ReloadCSS.Init, "onload")
	Estate.Events.AddEvent(window, Estate.Develop.FormTester.Init, "onload")
	Estate.Events.AddEvent(
		window,
		function() {
			Estate.Develop.DesignTester.Init({
				designAnchor: document.getElementById('DesignTester'),
				xOffset: 10,
				yOffset: 5
			})
		},
		"onload"
	)

The example above will most likely be enough in most cases. The only thing you might have to configure is the Design Tester. That’s because the design image needs to be positioned relative to the main body of the page. Therefore you need to define an anchor by supplying a reference to an HTML element and define the optional offset.

You can also use jQuery to supply an HTML element like this: designAnchor: jQuery('#DesignTester')[0]. The Form Tester is also configurable. Please refer to the object reference for more information.

To install the Estate Developer Tools into your own website, you’ll have to copy the JavaScript code at the bottom of the page to your own and copy the devtools folder to the root of your own website.

After that you only need to create PNG files of the original design and save them in the folder/devtools/design-images/. If a page is loaded, the Design Tester looks for a PNG file which file name resembles the URL of the page. If that image cannot be found, the Design Tester will asks for that file either by printing a message in the console log or in its own fallback log box in the page. You just have to look up the right file and rename so that the Design Tester can pick it up.

Helper functions

Some functionality is not included in the menu

console.log fallback

After the library has been loaded, two global functions are available: clog() and dlog(). You use clog() to send a string to console.log() if available. If console.log is not available, the debug message will be printed in the log box in the website. If you can also choose to always use the log box of the Estate Developer Tools by calling dlog().

Timer

If you you want to optimize, you can use the timer to see how much time JavaScript needs to complete an operation. You just create a new instance of the timer object, set an ID so you can distinguish multiple alert from an another, start the timer, run some function or lines of code and the stop the timer. By stopping the timer, you’ll get a message how much milliseconds the operation costs. Here below is an example:

var oTimer = new Estate.Develop.Timer()
oTimer.SetID('Your time to response')
oTimer.Start()
alert('Press "ok" to see how much time it took to respond')
oTimer.End()

Reference

All public objects and methods have been documented with JsDoc Toolkit. Read the documentation.

Adding more tools

It’s possible to integrate your own developer tools in the menu of the Estate Developer Tool. This code will create an extra menu item and runs some code when a user clicks on it:

/**
 * @namespace Creates extra menu
 */
Estate.Develop.ExtraMenuItem = ( function() {
	var menuButton

	function doSomething() {
		dlog('Menu item pressed')
	}

	/* START PUBLIC */
	return {
		/**
		 * Initializes extra menu button
		 *
		 * @example
		 * Estate.Develop.ExtraMenuItem.Init()
		 */
		Init: function() {
			menuButton = Estate.Develop.Menu.AddMenuItem('Extra item')

			menuButton.onclick = function() {
				doSomething()
			}
		}
	}
	/* END PUBLIC */
})();

It’s also possible to attach a keypress event to it

/**
 * @namespace Creates extra menu
 */
Estate.Develop.ExtraMenuItem = ( function() {
	var menuButton

	function doSomething() {
		dlog('Menu item pressed')
	}

	function pageKeyPress(KeyID){
		dlog('KeyID: '+ KeyID)
	}

	/* START PUBLIC */
	return {
		/**
		 * Initializes extra menu button
		 *
		 * @example
		 * Estate.Develop.ExtraMenuItem.Init()
		 */
		Init: function() {
			menuButton = Estate.Develop.Menu.AddMenuItem('Extra item', 'Press any key')

			menuButton.onclick = function() {
				doSomething()
			}

			// Handle global key events
			Estate.Events.AddEvent (
				document,
				function(e) {
					var KeyID = (window.event) ? event.keyCode : e.which;
					pageKeyPress(KeyID)
				},
				"onkeypress"
			)
		}
	}
	/* END PUBLIC */
})();

No related posts.

Yeah, Netscape 4. Now that was a browser that just did not want to die. Netscape wasn’t updated after 1998 but in 2001 still about 5% of the internet users used Netscape. I got curious how the web would look like in a browser that is more than a decade old. So I downloaded Netscape 4.7 and loaded some major websites to see how they would look.

The level of accessibility of websites varies enormously. Let’s start with one of the worse:

Amazon.com

Welcome to our new and improved web shop

How the Amazon website should look like

As you can see: Netscape renders the page but context is virtually lost. And it clearly can’t handle the sprite image in the top left corner.

Twitter

A Twitter page in Netscape

How this Twitter-account should look like

The lack of solid white background color in combination with a rich-contrast background image that does get loaded is a serious problem. Not to mention all the hidden information that becomes visible. This website too is not very usable anymore.

Yahoo

Yahoo just blocks you

Yahoo has another approach: It just says that you’re browser is ancient and offers download links to newer browsers.

Google

...while Google just does it's thing

Google doesn’t complain and shows a page that looks remarkably well in Netscape 4. The links in the search results will still send you to websites that look like jigsaw puzzles, though

So you can’t browse with an ancient browser. So what?

Ok, this is indeed not a drama. But think of it this way: the web is a web of content. Content that becomes increasingly inaccessible if you don’t rebuild its content container, the website, every few years. Most organizations do that to be up to par with the latest browsers and designs but some just have to.

Help browsers with a handicap

Keeping content accessible is not just a hobby. It’s a major issue for websites of (semi)government organizations for example. They have to make sure content is open to anyone. Although they focus on handicapped internet users rather than handicapped browsers, one goal remains the same: a user should be able to use a website without the need of CSS, JavaScript or any other ‘fancy’ technique. A :hover is no use to a blind user, neither will color and JavaScript animation. That’s why such a person uses a different browser without such capabilities. And that’s why we have guidelines like WCAG.

It’s not surprising that many websites that follow WCAG guidelines or something comparable  do reasonably well in Netscape 4. I’ll repeat it again: that’s a browser from 1998.

www.section508.gov

Unique: this website looks almost identical in Firefox and Netscape

www.section508.gov in Firefox

The web design of www.section508.gov just don’t look like it stems from the 1990s, it also uses ancient techniques from that era like tables for layout, image spacers and sparse use of CSS. All big no-no’s nowadays, but the website rendering is great.

Dutch web guidelines

In black and white, but ordered and readable.

The same website in Firefox

The difference in rendering between Netscape and Firefox is striking. Netscape is unable to read the CSS, but that’s a good thing here. Accessibility dictates that an HTML document should be structured. So when there’s no CSS to style the document, the document structure will remain.

But why does Netscape not load the CSS? It appears that the media attribute link markup is key here:

Netscape won't load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" media="screen, tty" />

Netscape *will* load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" />

Dutch semi-governmental website (www.groenendestad.nl)

The website in Netscape

In Firefox

The last site is a semi-governmental website developed at the company I work, Estate Internet. It’s a relative new site (2 years old) but still usable in both old an new browsers.

Hurdles

So it is possible to make websites that are still usable in ancient browsers. The main obstacle is that old browsers try to render stuff like CSS and JavaScript but choke on it halfway. In case of CSS it’s possible to block Netscape by adding the media attribute, but that’s still a hack. Old browsers should be protected from itself. One option is to just disable everything at the client side that could harm the rendering.

It would be nice if you could send unsupported browsers just the HTML, while others also receive CSS and JavaScript. But browser detection can be error prone. The only stable solution I know that is easy to implement is IE version detection through conditional comments. Consider this piece of code that only gives all non-IE browsers and all IE7+ browser the site’s stylesheet.

<![if !IE]>
    <link href="css/main.css" type="text/css" />
<![endif]>
<![if gte IE 7]>
    <link href="css/main.css" type="text/css" />
<![endif]>

Conditional Comments will help us giving a soon-to-be ancient browser like IE6 the treatment it deserves .

Now it’s time to close Netscape again and start waiting for the new Firefox that supports basic CSS animation.

No related posts.

The Bright Lines, as seen through 'readability'

Lately I came across Readability. It’s a bookmarklet (works only in FF, Safari and Chrome) that alters any website into a more readable one. It does so by presenting it in a book form. At a first glance I thought it as a nice  tool, but I wasn’t sure I was going to use it. Then I thought that it was a real good example that you as a user have more to say than you think.

We always accept the usability of the websites for what it is. If it’’s good, it’s good. If it’s bad it’s bad. But the frontend of the website is built on your computer, in your browser. You have a certain level of control over the HTML, CSS and Javascript.

The most common way to make a website better is by using ad blockers. Yes, some people do live of advertising, but I don’t think that means you should be obliged to see them if you don’t want to. Especially when they distract. The best thing about ad blockers is that it doesn’t require any knowledge of web development at all.

Another example is CoolIris that convert image pages of popular websites like Google Images or Flickr into a 3D wall of images.

A more techie Firefox plugin that I use is Stylish. I use it to add my own CSS to websites I regularly visit. Most of the time I use it to remove section that I regard useless with a simple display: none. A more powerful variation of Stylish is the plugin Greasemonkey. With Greasemonkey you can alter the websites with Javascript. And just like Stylish, you can publish your customization of the website through the plugin.

So that’s a reminder for me to see that websites are not cast in stone. Popular websites will on the client side be hacked by a small minority of users to cater their own needs. And if a site is really in need of improvement, plugins that help non-technical users would spread like wildfire.

Related posts:

1. Popups dodging popup blockers

• The menu on the top right was large and clunky. Because of that it didn’t leave much room for more links.
• The ‘logo’ on the top left did not feel like a real logo mainly because it was … well … just not designed well.
• The shadow effect on the columns looked cool, but because it was made with PNG8 images instead of PNG24, it wasn’t possible to add an background image to the page.

What I did like was the scalability of the website. you could as easily view the page on your (i)phone as it would be on your large, wide computer screen. I dropped support for mobile phones. There are lots of Wordpress plugins to cater the mobile devices. I have to dive into that some time. For now anyone with a mobile device can grab the RSS feeds.

I still have to fix a few styling glitches but I thought the design was good enough to make the switch. Here are the most important aspects of the design:

• Use of rgba as background color. This makes it possible to set opacity for just the background instead of the whole box. rgba is not supported in IE, so you will have a solid white background then.
• Using opacity in the columns makes it possible to use large backgrounds. That gives me a reason to pick up my photography.
• The use of webfonts. This was something I was eager to use. This is something designers and web developers alike have been waiting for. The implementation isn’t perfect, but it looks well in Firefox and on the Apple. IE and Webkit on the PC still need some tweaking. I’ll go in to more detail in an upcoming article. For now I’ve been glad to be able to experiment with a real web site instead of running some tests with webfonts.
• Less data: I removed irrelevant data where I could. It’s most apparent in the list of articles on the homepage where I removed information like categories, tags and dates.
• Links become visible with an underline when a column is hovered. This will make the website look less crowded. It’s a bit like the folder tree view in Vista’s Windows Explorer: you will only see the folding icons (the plus and minus icons next to the folders) when that section is active.

There are some things I have to do:

• Make a logo that is suitable for creating a favicon
• Tweaking the fonts for IE & Webkit on PC.

No related posts.

Creating something from scratch can be empowering. It also gives a sense of control, because you can determine what the specifications should be of a product. Better: you don’t only know the specifications by heart, you also know just what strings you need to pull in your code. Getting to know a product that you didn’t code from scratch seem hard to master. And it can even harder to know it’s limitations. That’s not a situation that you want to be in, when talking to a customer. And so it seems better to stay in control and build an application of your own for your own needs.

A CMS for everyone

And so in-house coded CMS systems pop-up everywhere. But why? Are the ideas of those companies about Content Management Systems so different compared to what is already on the market? Most likely not. In many cases the euphoria of having your own CMS will turn to into a slowly simmering frustration because the time needed for bug fixes and feature request doesn’t match at all with the time that’s available.

We all know that creating a product needs time. But what we tend to forget is that keeping a product “healthy” and up-to-date also costs a lot of time in the long run. And so we have a plethora of CMS systems with loose ends and incomplete functionalities. Most of the time with an unfinished “help”-function.

For years I was accustomed to do as much as you can yourself. But now that the internet is getting bigger and bigger, you see companies specializing. Some companies are focusing on only one or a few products like a CMS, while the creators of websites ask themselves: “Am I better in building a CMS or in creating websites?” In most cases it’s the latter. And so it’s better to find a product that helps you to do the job fast instead of slowing you down.

Example: a quick flash video player

Now you may think that a CMS is an obvious thing you shouldn’t build yourself because the codebase is so large. Well, lets take something that needs less lines of code: a simple Flash video player. Many companies have developed their own Flash video player. Because it’s just relatively easy to do. But again: why? Most of the time such a in-house coded player has minimal documentation, if at all. And if you find documentation it’s likely out of date. What really bugs me if you’re asked to just “Fetch that player from our previous project”. Like that’s an acceptable codebase.

I recently decided to go with the open source Flow player. I fell for the various options to customize the player. Soon I discovered all kinds of advantages you wouldn’t have with your own code: Forums, wizards and extensive documentation. I could send a designer a link to a wizard that enables him to skin the video player at a basic level. I also could pass the player to another team member without having to explain every step in the code. The documentation is online, help yourself. Let me continue with my work.

Another example: Javascript libraries

Libraries really can speed up your work. They do not only provide lots of canned functionality, but libraries like Prototype, Mootools and jQuery can also really speed up your own coding. jQuery really helped me to code faster, more stable and in less lines of code. It made coding in avascipt even more fun.

There are lots of resources out there. As a web developer you need not only to know your code languages, you also need to know when to use some existing code and know where to find it.

No related posts.