Rollin' with Rollyo

Every so often someone comes up with a really cool idea for a website that's so useful you find yourself asking "why didn't anyone think of that until now?" or "why didn't I think of that!"

We're all familiar with Blogrolls, well make room in your vocabulary for Searchrolls.

A Searchroll is a personalized search engine that provides results from a hand selected collection of trusted sites on any given topic.

Rollyo, the handiwork of Dave Pell, Angus Durocher, Dan Cederholm and Alex Wright, allows you to search a group of sites of your choosing with one query. This is particularly useful if you know of a handful of reference sites on a particular subject and don't feel like wasting time searching each one separately. So for example if you want to be able to search for something on your favourite design sites, or all of the really cool JavaScript sites you've bookmarked, you just create yourself a searchroll with those sites' URLs and away you go. Rollyo is powered by Yahoo! Search so you can be sure that the search technology is up to snuff.

What's really cool is that Rollyo doesn't just give you a search tool, it creates a community of sorts by allowing you to explore searchrolls. So other people can use your searchrolls and vice versa. Rollyo then lists the most popular, the high rollers, those of note, and of course the new additions. So if your searchroll is used by a lot of people, you'll rise in the ranks and may even get your mug on the front page.

You can be a High Roller too if your searchroll becomes popular with the Rollyo community. Think of it as our version of Star Search.

They've already got a few tools to help your searchrolling experience along. For example, you can create searchrolls with your bookmarks by uploading them, you can add Rollyo to your Firefox toolbar, and soon you'll be able to put a Rollyo searchbox on your site and search from your desktop with the Rollyo widget.

BLEACH is the new AJAX

Well, we've all heard of AJAX but did you know that BLEACH is the new AJAX? Of course there was AJAX's predecessor: CLOROX, but that didn't do to well.

Yes, of course I'm kidding. Yes, you may leave a comment with your own witty acronym.

Invalid markup: does it matter?

Don't get me wrong. If you know me, you know that I'm the first one to push for valid markup. I'm a perfectionist at heart, and nothing pleases me more than seeing that beautiful message on the W3C's Validator: "This page is Valid XHTML 1.0 Strict!" But the more I think about it and the more I talk to people about it, the less I see a need for it. Yes, I know, it ensures accessibility, it ensures compatibility across multiple platforms, it's machine readable and it follows all the rules, but so long as the mainstream browsers don't stop accommodating bad markup, what's the point?

I wish there were a more solid reason for conformity. Like, say for example, if the browser behaved like a compiler. Rather than doing its best to patch up faulty markup, what if it spat out a list of errors that need correcting. Then maybe people would make more of an effort. Or if the server simply refused to serve up documents that didn't validate. But as things are right now, there's no real incentive to make sure all of your tags are closed and all of your ampersands are escaped. The worst of it is when a document is declared to be XHTML, no matter the flavour, and doesn't validate, but the browser* still parses it! I mean, isn't XHTML a reformulation of HTML 4 in XML 1.0? And isn't XML unforgiving to the point that an XML parser must stop if it reaches a fatal error?

So I ask you, what's the deal? We fight for standards, we expend all this energy, and yet the major browsers in use today could care less if the document they're parsing is well formed. How are we supposed to be taken seriously as professionals if as far, as the browser's concerned, tag soup is as good as a valid document?

I say let's start a movement, "a zero tolerance for invalid markup" campaign of sorts. Let's really take back the web, let's browse happier. Any takers?

* I don't specify browsers by name because all of the popular ones are equally guilty.

Why "the simple web"?

The name "the simple web" was inspired by my fascination with simple solutions to complex problems. Engineers call it an elegant solution. As it applies to my work, I live for elegant solutions to complex programming and user interface problems. The simpler the better. The art and science of simplifying the UI and improving user experience is called usability.

Recently I saw a wonderful example of usability in action in a couple of Google's projects. In particular, it was Google Maps that stood out to me as a perfect example of simplicity flying in the face of the status quo. What do I mean? Well, does anyone remember MapQuest or MapBlast and the arrows on the borders of their maps? Remember how you'd have to click those arrows and then wait while the entire page reloaded just so you could move the map by a few pixels? Then what did Google do? Their map just let you click and drag it wherever you wanted. Pretty simple and intuitive huh? Well, why hadn't anyone implemented it until then? The status quo is why.

A friend of mine who was studying psychology once told me that there was no such thing as a truly original thought. She said that all ideas were derived to a greater or lesser degree by some observation outside of ourselves. I think that this is more often than not the case in web design. Not that we don't have creative people in our midst. But for the most part we design on a pretty high level of thought which is based on some fundamental principles that are rarely brought into question. It's like walking onto a construction work site in order to build a house. You may have a pretty creative design for the building you're about to erect, but for the most part, you don't question the brick, mortar, steel and glass you'll be using. After all, a door is a door, and a floor is a floor. Right?

Well, that's the reason why when one mapping company began to compete with the other, they both adopted the same form of navigation. The same can be said for web based email providers, portals, any site with top and side navigation bars, and the list goes on. The problem isn't that these are necessarily bad. The problem is that once a "standard" is established, everyone just sort of follows like a heard of sheep. Only once in a while does someone stand up and say, "Hey! I can do this better!" And of course, by better I mean simpler. After all, what's the most appealing feature of "innovative" technologies? Their simplification. You might be saying, "No, it's their increased speed, decreased size and increased power." But I submit to you that those are all means to an end and that end being an increased ease of use.

It's kind of like the 4-minute mile. Once the psychological barrier of "we can't do that" is broken, innovation flourishes until we hit another psychological plateau.

Well, that's my motivation. Breaking the psychological barriers surrounding web design. Questioning existing practices and not settling for the status quo. Don't get me wrong. Just because I want to question the norm doesn't mean I think myself capable of pioneering new paths in our profession. Then again, who knows. But you've got to start somewhere. Below is a three point summary of the simple web philosophy as I see it:

What & Why

Determine the core need. What needs to be done and why? For example: the client doesn't need to proceed to the checkout page. The client needs to be able to buy your product. Identify the real need.

How

Ignoring established norms, determine the simplest, most intuitive method of addressing the need. For example: Click and drag the map in the direction you want to go.

Get it done

See if current or past solutions can be used or adapted to address the need. If not, start from scratch and make it happen. Just because it hasn't been done before, doesn't mean it can't be done. Innovate, innovate, innovate!

Oops! Trouble in commentville

Well I don't know how that happened but it seems like I had comments set to "only registered users." Here I am trying to increase readership and participation, and I've restricted commenting to only Blogger users. Sorry about that everybody. Things should be okay now.

Image tag vs. Image replacement

One of the most regularly recurring questions that I have to answer when building a site is: "should I use an image tag here, or a CSS image replacement?" This is especially the case when working with a design that's been given to me by a graphic designer, because I'm not the one who thought out the design. When I work on a design from the beginning, I approach it with the mindset of a web developer. I consider what elements will be lists, what will be headings, etc. Even while working on a purely graphical design. That's both good and bad. Good because I can foresee and circumvent potential implementation pitfalls. Bad because of its limiting factor on creativity.

In the past, "image tag or not" wasn't even an issue. You wanted an image, you used an image tag. But now, with Web Standards and a focus on semantics, I have to carefully consider the meaning of every element that goes into the page. So, in order too answer one question, I need to ask another: "what does this image represent?" Is it a product? A brand? A design element like a rounded corner? Or a particularly nice font that you can't get without using an image?

When trying to decide whether to use an image tag or not, ask yourself: "what does this image represent?"

Depending on your answer, you've got three possible options:

For design elements use background images

If your image represents a design element such as a rounded corner, it has no semantic value and should have no impact on the actual content of the page. For implementations such as these, background images are the best.

For products, brands and other tangible elements, use the image tag

If your image represents a product, then it's a quantitative part of your content and should therefore be represented semantically with an image tag. Take for example these sites. If you view the pages without stylesheets you'll see that only the products themselves use the image tag. Everything else is rendered using the background-image CSS property. Likewise, this site's brand is preserved by the use of an image tag.

When styling content, use an image replacement technique

In the case where you've got actual content that needs styling, such as a headline that needs to be in a specific typeface, then use one of the many available image replacement techniques.

All of this really amounts to using the right tool for the right job. And in the end, isn't that what web standards are all about?

AJAX: What's in a name?

What do a Greek hero, a town in Ontario, a household cleaner, a play by Sophocles, and the revival of JavaScript have in common? They all bear the name AJAX.

I don't know about you, but as much as I'm a sucker for buzzwords, I just can't bring myself to use the acronym AJAX in a conversation without feeling like a sellout. Maybe it's because the closer I look at AJAX, the less the acronym seems to apply.

Take the "X" in AJAX. It stands for XML, but a lot of "AJAX" apps being built aren't transferring XML via the famed XMLHTTP. Rather, they use an IFrame to make the connection and the data is in the form of JSON, HTML or even just plain old text. In whose case the acronym should change to AJAJ, AJAH and AJAT respectively. But it doesn't, and so I'm stuck saying "AJAX" when I really mean "AJAJ."

Likewise, the asynchrony of some AJAX apps is also iffy at best. Though they fetch data after the page has loaded, they still rely on the user's input and the fetch tends to be pretty synchronous. Amazon's diamond search is an example of the JS code fetching data only when the client modifies the search filters. While Google Maps only loads data when you move the map. To the best of my understanding of the word asynchronous, these apps seem pretty synchronous to me.

I can't harp on Google though. They never claimed to be doing any AJAX. Their engineers just call what they're doing JavaScript. Which in effect, is all it really is. Which is why I personally refer to the AJAX phenomenon quite simply as the revival of JavaScript.

Ultimately, once you come up with an acronym, you set boundaries (however ethereal) on something that's capable of doing so much more.

Internet Explorer Developer Toolbar Beta

Hot on the heels (!) of Chris Pederick’s Web Developer Firefox extension, Microsoft has put together the Internet Explorer Developer Toolbar Beta.


The first thing you’ll notice when you install it is how plain it looks. No logo, no icons, just plain text buttons, which makes it hard to use since you don’t know if a button is hiding a dropdown or if it’s going to pop up a window. I’m writing this one off to it still being in Beta.

One of the most useful tools that I can no longer work without is Firefox’s DOM Inspector. Now, finally, IE has its own “View DOM” button in the toolbar. It allows you to traverse the DOM, but doesn’t have that handy pointer you can use to localize an element by clicking directly on the page. It also allows you to see and modify the CSS style rules of the element you click on, but that’s it. You can’t pinpoint which classes, in what sequence, from which sources apply to the element (like you can in the DOM Inspector).

One feature that it has which its Firefox counterpart doesn't is the ability to highlight elements by positioning type. So if you want to see for example, all of the elements that are positioned relatively, or absolutely, you can.

For the most part though, a lot of the functionality you get with the Web Developer Firefox extension is replicated in the IE Developer Toolbar. But it’s obvious that it’s a first step, as a lot of the features are relatively limited and/or basic. But basic or not, it’s a toolbox that any serious web developer will welcome with open arms.

In an ironic footnote: I used the IE Developer Toolbar to validate the download page where I got it from and it returned 35 HTML errors and a lot of CSS errors.

Blogger, know thyself!

I find it very odd that Blogger's spell checker doesn't recognize the words "Blogger" or "Blog." I assume they use a standard dictionary, but you'd think they'd at least add their company name and that of their product to it. I mean hey, Microsoft does it!

Why you should escape your ampersands

Molly's recent Searching for Standards, mentions that AOL's search engine doesn't validate due to unescaped ampersands. I've personally seen a lot of this happening and I thought I'd relate a little experience I had a few years ago while working for my previous employer where I learned the hard way that I should escape my ampersands.

The project called for a set of parameters to be passed through the querystring, one of which was named "sect" which was short for the word "section." The final URI looked something like this:

<a href="http://www.domain.com/page.asp?param=1&sect=2">My Link</a>

Much to my surprise, the link didn't work. Instead it would render something like this:

<a href="http://www.domain.com/page.asp?param=1§=2">My Link</a>

A little investigation and I discovered that &sect (or more properly §) was actually the character entity for the section sign. So when the browser came across my anchor it took the contents of the href attribute and did what it was supposed to do. It parsed its contents, found character entities and rendered them. Of course, by rendering the &sect portion of my querystring, it broke my anchor.

Now, that's one real world example of how not escaping your ampersands can cause you trouble. Though you may be thinking "yeah, but what if I don't use the word sect in my querystrings?" Well consider this. There are many more character entities that can pose a danger to your code. What if you were passing currency information using any of the following entities: ¢, ¥ or £? Or what if you wanted to use something like: ¬?

The bottom line is, if you don't escape your ampersands, you could end up with broken code.

Gimme a little base

Recently I've found myself in situations where I need to mess around with HTML documents for sites that I haven't previously worked on. This means that I don't have any of the document's dependancies locally. Plus, some of these pages are dynamically generated, requiring that I install the appropriate environment on my machine in order to work with the file.

If you just want to play around with the HTML and you don't want to go through all the hassle of setting up environments and copying over files here's what you do:

1. Copy the source of the page you want to edit into a local .html file.
   
2. Insert the <base href="" /> tag into the document <head> with the original domain in the href attribute.

That's it. Now when you view the local HTML file, all of the images, CSS links and so on will work.

Beware of bad estimates

How many times has this happened to you: you're assigned a new project, or you sit with a new client and everything goes well until you get to the time estimate. More often than not, at least it's been my experience, that those for whom you work just don't understand how long it actually takes to do the work. It's normal, they're not web developers. But we are, and recently it seems to me that bad estimates are prevalent in our industry. From freelancers who don't respect the worth of their own time, to companies who sign contracts without consulting those who'll be doing the building first.

I'll give you an example. A junior member on my team this past week was given two tasks, both which were badly estimated. The first was for a couple of promo pages for a fairly large client. The deadline was looming, the project was near completion and with only a few days left they dumped these pages on him with an estimate of four hours to complete them. The second task was the integration of a blog template in Typepad, estimate: five hours.

Now that may seem reasonable at face value until you consider what's involved. First off, the guy's never worked with Typepad. Second, he's got to apply a design that someone else created (in the form of a Photoshop .PSD) to markup that he didn't write. Third, it's got to work on all modern browsers without any browser sniffing. And lastly, he's still learning so he can get snagged in bugs from time to time.

My rule of thumb on estimation is: a minimum of one day per page and maybe more depending on complexity.

My rule of thumb is a minimum of 1 day per page. Taking into account the fact that 1 day translates into 7.5 hours (where I'm currently employed), it tends to go by pretty quickly. Especially if you run into bugs, have questions about the design and experience delays because even 1 page usually involves 3 to 4 people. Yes, that's right, you've got the producer who interfaces with the client, graphic artist who came up with the concept, the web developer who makes it a web page and possibly the programmer who's got to tie it into the back end. All of these aspects can affect your work. Sometimes, in mid course you need to check with the graphic designer about something, or you need to ask the producer something about the behaviour or a certain element and so on, and so forth. Of course if you're a one man show you won't have all those thumbs in the soup. But in your case it's even more important to remember that all that work still needs to get done, and now it's all up to you. One person who can't just focus on one task. You're responsible for it all. Thus, you need to add even more time to your estimate.

Why stress over impossible deadlines. Whenever possible, overestimate! Then that way, you can be the hero if you deliver early.

Edit any page on the web right in IE

Edit any page on the web right in IE! Ever visit a site and feel an overwhelming urge to mess around with the content? You know, just replace a name with your own, or move a picture somewhere other than where it is? How about rewriting the copy of a story just because you’re bored and don’t have anything better to do? No? Well, just because you never wanted to doesn’t mean you couldn’t have.

Just type javascript:alert(document.body.contentEditable=true) into the IE address bar and away you go. Have fun, enjoy, and be careful, ‘cuz we all know that WYSIWYG is harmful to your health.

Thanks to Andrew Stevenson for the tip.

The new Gap.com: A peak under the hood

Well, I haven't even had a chance to work much on my template and I've already got something to post about!

I went to the Gap.com and got this message saying that I was one of the few who was being allowed to see their new site. Apparently it's been down for a little while now undergoing renovations. Unfortunately I don't have a screen cap of the message (it won't come up any more for me). If you're interested in seeing the site for yourself, just keep trying, it seems to let you in if you're persistent. In fact it seems to have gotten easier to get into since the first time I got in.

Anyhow, after spending a little time skimming over the site and peeking under the hood, I have to give the team who worked on it a definite "A" for effort. For starters, it's built using Web Standards. It doesn't validate, but it's mainly due to unescaped ampersands and a couple of tags that are in the wrong place. Plus I noticed a meta tag that wasn't closed. But I guess it's probably because they've got a fairly large team working on it and not everyone is on the same wavelength.


One of the first things you notice when you navigate the site is the mouse-over button that appears over the products that allows you to view its details. I think that the product information is delivered through an AJAX-esque setup since there are three IFrames that follow you throughout the site who are contained in a div aptly named "dataLoaderIFrames".

Unfortunately, even though they made an effort at using Web Standards, they didn't implement Unobtrusive JavaScript as you can't view the site without JavaScript enabled.


All in all, even though there's room for improvement (we can all nitpick) I'd say that the site is nicely done. Good going guys!

First things first

So here's my latest attempt at a blog about web development & design. But before I begin, I think I'll work on the template a little. So without further ado... Oh and did I mention that this'll be a live work in progress? ;-)