Rollin' with Rollyo
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.
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.
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.
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.
BLEACH is the new AJAX
Yes, of course I'm kidding. Yes, you may leave a comment with your own witty acronym.
Invalid markup: does it matter?
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 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"?
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.
- 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
Image tag vs. Image replacement
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?
Depending on your answer, you've got three possible options:
When trying to decide whether to use an image tag or not, ask yourself: "what does this image represent?"
- 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-imageCSS 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.
AJAX: What's in a name?
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.
Ultimately, once you come up with an acronym, you set boundaries (however ethereal) on something that's capable of doing so much more.