I've moved to http://arapehlivanian.com

Well, I did it. I have my own site: http://arapehlivanian.com. Right now it's just a stock install of WordPress until I figure out how to make it do what I want it to do. So please be patient with me. I'm going to try and keep writing during the setting up process. This blog will remain for the indefinite future. I'm not sure if I'm going to move any of the posts from here to the new site. We'll see.

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.