Web Technology

Is Firefox Past its Prime?

A few weeks ago, in a post about why Google+ is going to succeed, I noted that Google Chrome has been on an upward trend of about .5–1% per month since it launched nearly two years ago.

While I didn’t mention it at the time, Firefox has an interesting usage graph as well. If you follow that link, you’ll see that Firefox’s curve hovered a little over 30% for the tail end of 2009 and the better part of 2010, but has started to drop over the past twelve months.

If these trends continue, Chrome will be more popular than Firefox by the end of next year.

What does this mean for everyone’s favourite open-source browser?

From Phoenix to Providence.

Back around 2003, the ‘net was desperate for something new. Sure there were other browsers around, but nobody could hold a candle to the market-dominating behemoth that was Internet Explorer (source). Innovation was non-existent, and the web as we knew it was suffocating.

Enter Mozilla. The release of Firefox 1.0 in 2004 was a breath of fresh air for the online community. Suddenly there was an open-source, standards-compliant competitor gaining momentum. We were thrust from the shackles of monopoly into an arms race that culminated in the second browser war.

Mozilla was a critical piece of the puzzle. It was a veritable flagship of new, exciting features. Better CSS support. A clean, tabbed interface. The prevalence and importance of add-ons could be its own post; countless extensions have become standard features across the board of popular browsers.

By the time Firefox 3 was released, in June 2008, Mozilla could do no wrong. Everything was on the up-and-up.

Then, the landscape changed.

Is Firefox still necessary?

With Microsoft innovating again (see IE9), Apple’s devices gaining popularity (and Safari with them), and Google bursting into the browser space with Chrome, competition was hot in 2009/2010.

Firefox still played a key role at this time: it was the yardstick against which all other browsers were held. Sure Safari and Chrome have built-in development tools, but are they as good as Firebug? How does WebKit’s HTML5 support compare to Gecko’s? And isn’t IE still laughably behind?

But this role has run its course. The major players are now well-established. Most users are aware of alternatives to their operating systems’ default browsers.

This can’t be a long-term position for Firefox. It won’t last.

The competition is no longer resting on its laurels. Chrome is closing in. Internet Explorer is finally in a position to reverse its eight-year downward trend, and WebKit is absolutely dominating this year’s explosive rise in mobile browsing.

Extensions are everywhere. Support for standards has never been better. Firefox is quietly becoming less and less relevant with each passing update.

So I ask again:

Does the golden age for Firefox lie in its past?

Web Technology

Why Google+ is Going to Succeed

It’s official, I’m making a call: Google+ is going to work out just fine.

I know there are plenty of skeptics out there, so let’s go ahead and address the most common concerns:

Common Concern #1: Google+ can’t compete with Facebook.

The idea: Facebook is too popular, and a new network like Google+ won’t gain enough traction to reach critical mass.

Why that’s dead wrong: Google knows a thing or two about taking on massively-successful competitors. If it can hold its own against Apple and Mozilla, it can hold its own against Facebook.

The long answer:

Google doesn’t try to gain market share in one overwhelming blow. Google prefers slow, steady growth.

Look at Android. When it launched in Q4 of 2008, Apple had already sold nearly 10 million iPhones — and Steve & co. were getting started. Google didn’t try to win these users over immediately; they gradually earned market share one user at a time. Now Android is more popular than iOS, and all signs point to continued, step-by-step growth.

Need more proof? Let’s talk Chrome. At launch in 2008, Google’s browser started out with roughly 1% of the world’s internet users. Since then, Chrome has slowly crawled along, picking up half a percent of the market every month or so (stats). It now owns a whopping 20% of the browsing market, and there’s no reason to believe it’s going anywhere but up. Half a percent at a time.

Google+ isn’t out to crush Facebook all in one go. It’s going to slowly pick up users, little by little, until it’s a force to be reckoned with in the social media space.

Common Concern #2: Google+ is going to end up just like Google Wave.

The idea: Google’s last major product launch failed. Why should Google+ be any different?

Why that’s dead wrong: Google learns from mistakes. It’s a wildly successful company full of incredibly smart people. If anything, Wave’s failure will help the Google+ team overcome similar challenges.

The long answer:

Google Wave failed for a lot of reasons. It was difficult to explain to others, its success relied too much on developers, and invites were a mess. Google+ has fixed all of these problems.

“It’s just like Facebook” is an adequate description of Google+. Everyone knows Facebook, and that begs questions like “well, what is different?”. These conversations show what Google+ is really about: polish. It doesn’t have a bunch of killer new features, it just has a slightly-better version of the features common to most social media tools.

The invite system is much improved as well. Google Wave fed users a meagre handful of invites on an ad-hoc schedule. This meant carefully choosing who to invite, any only inviting a few friends at a time. The invite system for Google+ is more like a valve; when the servers can handle more users, the valve opens, and everyone can invite as many people as they want. When capacity fills, the valve closes, and we take a short break until the next tide.

Google+ isn’t Wave. It’s not just a different product, it’s a better product. Run by a better team, with a better plan going forward. Why expect anything less from an internet powerhouse with a proven track record?

Even if I’m wrong, I still win.

You know what the best part is about Android vs iOS and Chrome vs Firefox?

Of course you do. Competition.

High-profile technology wars bring major innovation to the market, and that’s always a win for users. Just look at how much smartphones and browsers have advanced in the past three years or so. All of it thanks to increased competition.

Ultimately, it doesn’t matter if Google+ succeeds. The real value is the threat — Facebook, Twitter, LinkedIn, Yammer… they all have to up their game to stay competitive. As a user of these networking tools, we’re certain to benefit for the foreseeable future.

What do you think?

This post also appears on the Macadamian blog.

Web Technology

Browser Innovation Occurs in Cycles

Who are the most innovative browser-makers right now?

  • If you’re hip and trendy, you’ll probably say Google (and you’re right).
  • If you’re a bit of a techie, I bet you’ll say Mozilla (also a good choice).
  • And if you’re an honest web developer, you’ll say Microsoft (equally correct).

I’m sure there’s enough flamebait in that list to start a dynamic discussion, but I’ve got another question first:

Who were the most innovative browser-makers ten years ago?

The list looks something like this:

  • Apple (back when they were unpopular).
  • Mozilla (pre-Firefox).
  • Opera (obviously).
  • A whole raft of independent developers.

Notice anything?

The current wave of browser innovation is driven by the big players.

You can complain all you want about the travesties Microsoft has wrought upon the development community, but they pioneered in-browser GPU-acceleration with IE9.

Chrome and Firefox hardly need justification. The number of features they’ve introduced that are now must-haves is staggering. (Pinned tabs, tabs-on-top, private browsing, and built-in debugging tools, just to name a few.)

But it wasn’t always this way.

The previous wave of browser innovation was all about the little guys.

Before the days of iPods and Macbooks, Apple was struggling to keep OSX afloat. Many called their decision to make a browser a mistake, but Safari 1.0 was a boon for the web’s widening world. That’s where webkit got its roots, and we’ve been blessed with the fruits of its labour ever since.

Mozilla was making a browser by its own name, with platform-specific spin-offs like Camino and K-Meleon. The trials and tribulations of the heavyset gecko platform encouraged a culture of ruthless javascript performance improvement — a culture which still thrives to this day.

Opera was the de facto non-Microsoft choice at the time, and did wonders for open standards. As much as we like to take this for granted, there was a very real time in the early 2000s where every website had to be written twice; once specifically for IE, and once for all other browsers.

Then there were the independents. The Shiiras and the Avants. The stepping stones that lead to the giants we surf the web with today. Each contributed to a better web. A stronger web! And we wouldn’t be where we are today without them.

But how did we get there in the first place?

The rise of small-time browsers was driven by a number of forces:

  • The late 90s were ruled by then-juggernauts Netscape and Microsoft.
  • Internet Explorer began devouring market share, and users wanted alternatives.
  • When Netscape folded, it (thankfully) left behind a rich, open-source codebase.

Then, as the browser evolved from geeky toy to application that everyone needs, the costs associated with developing and maintaining a modern, working codebase soared. Suddenly the hodgepodge teams working out of basement apartments couldn’t compete, and the rest is history.

So the cycle so far has looked something like this:

Big Juggernauts → Low-budget Developers → Major Companies

What can we expect to see going forward?

I don’t see an indy-browser renaissance on the horizon. Lately it’s been the opposite: we’ve lost Flock, Opera is flailing, and the myriad of mobile browsers haven’t mustered but a whimper against their built-in counterparts — a far cry from the independent revolution discussed above.

The competition between the current super-powers is more than enough to keep us in an innovative state, and I don’t see that changing anytime soon.


What will the next wave of browsers look like? How will they gain traction? Where will the innovation come from?

Web Technology

The Playbook is being Marketed to Fail

I don’t think this iteration of the BlackBerry Playbook will do very well, and I blame RIM’s marketing team.

If you’re not sure what the Playbook is, let me explain — and thank you for proving my point. The BlackBerry Playbook is a tablet computer released last week by Research In Motion, the company behind BlackBerry phones. It’s chief competitor in the tablet space is the iPad, followed by the handful of Android tablets that are currently available.

It’s a great device. The hardware is plenty powerful, and the software is certainly good enough for a 1.0 release. It supports native apps written in several languages, and web apps that can take advantage of HTML5 and Adobe Flash.

The Playbook has a lot going for it, but the one thing it’s sorely lacking is a marketing strategy. Without this, it will fail.

People need to know you have a product before they can buy it.

I spend a lot of time on this Internet thing. I read too many blogs, I stalk people on Twitter, I waste time on Facebook. As a tech-savvy 20-something year old, you’d think I would be the target market for a sexy new tablet. But alas! Everything I know about the Playbook, I learned from friends that work at RIM. Is that how the marketing team was expecting to reach me?

What’s their plan for everyone else? Let potential customers hear about it through word of mouth — weeks or months after launch — if at all?

That doesn’t work anymore. If you’re going to compete with someone like Apple, you have to be loud about what you’re doing.

And that brings us to an even bigger problem with RIM’s silent strategy:

When you don’t make your product sound great, your customers don’t either.

iPad users don’t need to think to explain why they love their iPads. They need only recite whatever Steve Jobs and the rest of the Apple Marketing Messiahs have told them about it.

What are potential Playbook users going to say when they talk to their iOS brethren?

“It has Flash”?


Specs don’t sell products. Potential users want to know which tablet will improve their day-to-day life, not which one has more RAM. And that’s marketing’s job.

We’ve seen this before.

If RIM isn’t convinced that a lack of marketing will kill their product, maybe Google can sway them.

Remember when Google Wave launched? It was going to replace email, and add awesome features, and be everything to everyone!

Not a single person I knew could explain what it was in one sentence. What followed was confusion, lacklustre adoption, and ultimately, termination.

I loved Google Wave. It was a fantastic product that was constantly misunderstood because there was no marketing message to support it.

And as I read article after article, I can’t shake the feeling that I know where the Playbook is headed…

This post also appears on the Macadamian blog.

Software Development Web Technology

How to Make a Colour Selector with HTML5 Canvas

Over the weekend, I attended HackOTT, a hackathon here in Ottawa that encouraged everyone to play around with some neat third-party APIs. It was a lot of fun seeing the awesome apps everyone came up with, and even though we didn’t get to demo, I’m happy with how much I learned.

My team was comprised of myself, my softball captain/ex-coworker @jyboudreau, and our fearless leader @davefp. The idea was that we would create an HTML5 application that allowed users to upload an image of a room, select a few colours from that image, and get back a list of products sold through Shopify that match the room. We were pretty excited, and so were some of the API guys we talked to.

Dave and JY grabbed the TinEye and Shopify APIs, so that left me with the UI. While we didn’t quite manage to get everything working in time to demo, we did make a lot of progress, and I thought I’d share part of my contribution, a Canvas-based app that lets the user pull colour swatches out of an image.

Let’s look at how it works!

Basic Setup

The layout is pretty simple. The empty blocks on either side are just divs that will hold our colour swatches, and that image in the middle is actually a canvas. In fact, it’s two canvases, overlayed on top of each other using some absolute positioning.

We used two canvases to make the drawing easier. The backmost canvas holds our image, and that’s it. The frontmost canvas, which is completely transparent, is where the swatch outlines are drawn. This makes it less expensive to redraw swatch outlines, because we don’t have to reload the image each time, and allows two swatch outlines overlap without having them affect one another’s colour.

Now, let’s have a look at the drawing code.

Loading the Image

Loading an image into a canvas is relatively straightforward. Check out the javascript file, and in particular note the addUserImage function. The mechanics of loading an image are simple:

  1. Create a new logical image:
    var img = new Image();
  2. Make sure the image’s onload function ends by drawing the image:
  3. Trigger onload by setting the image’s src property:
    img.src = TEST_IMG;

There are a couple of gotchas, though:

First, you may have noticed that in the image’s onload lamba, we’re adjusting the dimensions of both canvases and their container. This resizes our canvases and the surrounding layout to match the size of the image. We also set the canvases to display block because they are hidden by default (this avoids an ugly resizing-flash right after the page loads).

Second, the image src can’t be just any image. For canvas to load it properly, it must be an image contained within your own domain. This means you can’t just give it a url you found online, or even load it from a file using localhost. We deployed our app using App Engine, but any container should do the job just fine.

That’s all there is to loading an image, let’s move on to swatches.

Drawing the Swatch Outlines

There are three user events we care about for our canvas: mousedown, mousemove, and mouseup. To handle these events, there are three functions: handleCanvasClick, handleCanvasMouseMove, and handleCanvasMouseUp. Let’s look at these a little more in-depth.

First, you’ll notice that each function uses some simple math to get the coordinates of the mouse click:

var clickX = event.pageX - canvas.offsetLeft;
var clickY = event.pageY - canvas.offsetTop;

We get the coordinates from the page via event.pageX, then subtract the top-left corner of the canvas so that we’re left with the distance of the click from the canvas’s top-left corner. Conveniently, the origin for canvas is located in the top-left corner, so we’re already in the right coordinate space and our x/y positions are ready to use.

Next let’s talk about getSwatchIndex(). This is a convenience function that parses the id of the currently-highlighted div to give us a numerical representation. Why is this important? Because we want to maintain an array that represents the current position of each swatch outline, and we use these numbers to index it.

By storing the positions of the swatch outlines in an array, we’re free to clear the swatch-outline canvas and redraw it completely on each pass. This might seem like overkill, but it’s necessary for situations where two swatch outlines overlap, and at a code level, it’s less work than repainting a transparent box over a swatch outline before the swatch outline is painted again it in its new position.

Once we’ve updated our array, it’s off to our redrawSwatches function to actually draw them. The algorithm here is what you would expect, we loop over the array of swatch outline positions, and draw each one with a semi-transparent background and a solid border. We’re also watching for the currently selected swatch index to come up, because we want to highlight that border with a brighter colour so that the user knows which swatch outline is active.

Handling Dragging

We wanted the user to be able to drag a swatch outline around to make sure it’s placed in exactly the right spot. This ended up being easier than we thought. You may have noticed the dragEnabled variable in our mouse event functions. This is a global boolean that we set on mousedown and clear on mouseup. That way, when mousemove fires, we can check it and redraw if a drag is occurring. Simple!

Extracting Colour Information

Let’s head back to handleCanvasMouseUp and look at the colour extraction (which should probably be in its own function).

The important step is this one:

var imageData = context.getImageData(

Here we’re telling the canvas to give us the image data for a square positioned where the user clicked, and the size of our swatch outline (that I for some reason called a highlight this time &#151 we were in a rush). That returns canvas’s own ImageData object, which probably does all kinds of neat things, but we just wanted the pixels, so we called .data to grab them.

Pixel data in canvas is stored as a giant rgba array. So if you have a 10×10 canvas, then the array will be of size 400 (10x10x4) and will be formatted as [r1, g1, b1, a1, r2, g2, b2, a2, etc]. We want the rgb values only (we skip straight over the alpha values in this case), so we sum up all of the reds, blues and greens individually.

Finally, we average out each colour by dividing it by the number of pixels, floor the totals to get integer values, and voilà! We have an average colour we can show in the swatch.

It was fun spending the day playing around with canvas. Hopefully next time we’ll get something we can demo!

Uncategorized Web Technology

Just Browsing

I’m kind of picky about my browsers.

Alright, that might be an understatement…

I’m a browser whore.

I use three different browsers every day at work, and several others at home. Two of them are beta versions. Even though I use Firefox at home and at work, I have completely different addons for each install. And I use different browsers on my iPhone and my iPad.

I’ve probably used about two dozen unique browsers in my life to date.

That’s not even the worst of it.

I’m also a browserphile.

I’ve memorized the market share of all major browsers, just because I hear the numbers so often. I’ve been following the progress of the HTML5 spec for about six years. I’ve installed (and used) nightlies.

I can tell you exactly which CSS attributes and selectors are supported by every version of Internet Explorer since IE4.

How did I get like this?

I blame my condition on a few factors.

First and foremost, I was a Mac user for much of my learning-about-computers days. This was long before Safari was an A-list browser. You just got to know about the Shiiras and the Caminos. The features varied so wildly that it really encouraged experimentation. That part just stuck with me.

Then there’s the internet/computer synonymy. I don’t really remember what computers were like before the internet, because I was in grade school when the web started to take off. To me, a browser has always been an essential part of a computer.

Finally, I do a lot of web development. Knowing what each major browser can handle is practically a job requirement for me, and if I have to have them all installed for testing anyway, I’m going to find things I like that are unique to each one.

Here’s what I use at work.

My primary browser is Firefox. I need this for Firebug, and a handful of other useful web-development extensions (Fireshot, Tamper Data, Window Resizer, and FireQuery, which is actually an extension for Firebug). I’m also a huge fan of app tabs, because Chrome got me enthralled with that feature, and I’ve experimented with some tab-bar modifications here and there, but not found a working combination that I like just yet.

The half-dozen pages I keep open all the time are app-tabbed, and other than that Firefox is used for relatively-persistent browsing; stuff I’ll want to keep open for a little while.

Chrome is my secondary browser, and I use it for more instantaneous needs — like when I can’t remember jquery syntax, or looking up spelling, or when I need to grab a url for an obligatory xkcd reference. This is because Chrome is extremely fast, especially compared to Firefox with 18 tabs open, half of which are running AJAX in the background. Chrome fires up instantly, I punch in whatever query I have, and moments later I have my result and close the window.

I also use Internet Explorer at work, because our archaic timesheet software only renders properly in IE (I know, right?). Right now I’m running the IE9 beta, so that I have an excuse to play with SVG in all its GPU-accelerated glory.

At home is a different story.

I’m actually pretty good about sticking to one browser on my desktop machine. It’s been Firefox for quite a while now, ever since the novelty of Chrome wore off, and I’m currently running the latest FF4 beta release. Unfortunately, that disables most of my plugins, but with built-in app tab support I’m not too broken up about it. Also, when I experiment with Opera/Flock/anything else, this is the machine I use.

In the mobile world, I’m still using Safari for iPhone. I find that with the screen being so small, there’s not much room for fancy features, and they’re all webkit anyway so there’s little reason to stray from the default.

My iPad is a different story, though. One of the first apps I downloaded was Life, a browser with some neat multi-tab features. It’s non-free ($3), but I like it quite a bit. Besides, how many people do you know that have actually paid for a browser?

Why am I telling you all this?

Honestly? I don’t have an answer. Some days you just feel like writing about what you love, and you’re not going to let the fact that it’s a total rant that doesn’t really go anywhere stop you.

Am I the only self-confessed browser-nut out there? Or are you passionate about something completely different?

I’m here to listen, too.

Web Technology

Ottawa Google Hackathon Wrap-up

I spent my Saturday with some awesome people, hacking together an HTML5 webapp.

We were at the Ottawa Google Hackathon; a Google-sponsored event held at the University of Ottawa. Here’s a run-down of how it went from my perspective:

Free Bagels!

This was the first thing I (everyone) saw when they walked in: a table full of about a dozen kinds of bagels, with a dozen different cream cheeses. It was heaven. I instantly forgot that it was barely past 8am on a Saturday.

And it was delicious! Serious kudos to the organizers for deciding that this was a good idea, because it absolutely was.

Lightning Talks

Not everyone at the hackathon had the same level of experience with HTML5. The organizers had sent out a survey ahead of time to gauge what the least-known technologies were, and prepared a few quick and simple demonstrations of each.

Here’s what was covered:

  • Web workers
  • Canvas
  • Web sockets

I’ve always found talks or blog posts about canvas to be especially boring because there’s really nothing to learn. It’s a canvas. You can draw on it. You’re going to have to look up the API to do any real work with it anyway, a Hello World in canvas isn’t going to teach you anything. But alas, it’s what the people demanded.

That’s not to say it was a bad talk. The speaker (someone from Google) was very entertaining. In fact, all three presentations were easy to absorb and fun to watch. The highlight was when one Google employee was explaining what to do if you get stuck on an HTML5 problem: Just do a Bing-search, he said. We all had a good laugh.

Not much Twitter action.

I always tell people that conferences are about the only time that I become an average Twitter user. I’m not around much most of the time, but at any sort of large techie gathering, I’m all over the event’s hashtag.

This time around, though, it seemed like only a handful of us had Twitter accounts. I’m not sure if that’s due to the demographic (hardcore programmers are too anti-social media?) or simply because everyone was super-busy trying to bring their apps to fruition (we’ll get to that in a sec). Anyway, just something I wanted to see more of.

Take Tetris, and turn it on its side.

After the lightning talks, everyone kind of broke up into groups and started talking about ideas for a fun app. That heading up there was my pitch; I wanted to make a Tetris game where pieces come from the left and right, and two players have to work together to build lines in the middle of the screen.

Sounds pretty awesome, right? Yeah. It does. But “we” decided to make a LightCycle game instead. Not that I was bitter, it was still a fun idea.

The premise for our LightCycle game was that there’s no real reason why it must be restricted to two players, and no reason why the players can only move in straight lines. We decided to make the board a circle, and have the left/right arrows control rotation, so the cycles travel in curves. Neat, eh?

Anyway, the fancy HTML5 technologies we needed here were web sockets for the multiplayer, and canvas for the drawing. We also needed a lightweight server (we chose NodeJS) and some basic HTML/CSS/Javascript to tie it all together.

Time to git us some source control!


About half the table was in love with git, and the other half had never used it before. I was pretty adamant about git, because I was one of the git-versions git-virgins, and I wanted to see the light. So our team spent a solid 45 minutes unlocking it’s gitsteries.

You know… Mysteries. Regarding git.

Yeah, I’ll stop.

Ad-hoc Organization

Have you ever seen seven developers with little-to-no management experience self-organize on a seven-hour project? That’s one developer for each hour in the project schedule. Clearly, we had no time to waste on overhead.

Since we were all sitting at the same table, discussions were held aloud with participants drifting in and out as needed. We also had a Google Doc set up for things that were hard to remember, or things that we copy/pasted a lot. And I think at one point we drew something on an actual sheet of paper, so that was cool too.

This worked remarkably well. We were all very focused, and at no point did I ever feel like the tools at our disposal were insufficient or in the way. It was nothing short of ideal collaboration.

Final Products

I’m sad to say that our game didn’t quite make it to the finish line. We had some trouble with our web sockets; the connection would arbitrarily drop every now and then, but far too often to ignore. This seriously hampered our efforts, but we all resolved to continue the project after the fact. So we’ll see how that goes.

Most of the other groups were at about the same point we were: an hour or two away from being able to demo. A couple of teams did make it to the final stage, though, the most notable being this awesome HTML5 pong implementation.

There was also an Angry Birds parody. Apparently we all made games.

Oh, and the swag!

No sponsored event is complete without a bunch of awesome free stuff.

The coolest thing we all got was a pad of absolutely epic graph paper, marked as 768 pixels wide and with a little Chrome browser heading. It even came with a ruler that measured in pixels!

They also gave away some books during a brief trivia period (I forget which one/s, something about HTML5 and CSS3) and a few shirts (I got one!) and some remarkable posters (we scored one for the office).

All in all, it was a really fun day. A huge thanks to the volunteers, especially event organizer extraordinaire @mohamedmansour for actually referring to me as a VIP while we were in line. And of course my team, working with whom was the highlight of the event.

LightCycle forever! And all that jazz.


If this all sounded very appealing to you, you’re in luck: there will be a similar event in town in February. HackOTT promises to be “an awesome gathering of the very best of Ottawa’s technology hackers and developers”. I’ll be there, and so will a lot of other really cool people!

Web Security Web Technology

Contact Forms are Totally Lame

Remember the mid-to-late 90’s?

Music was awesome, there were less browsers to support, and people got spammed to death if they posted their email address online.

Having your email address posted online was the worst thing that could happen to you. We didn’t have spam filters back then. You would get so much unmanageable spam that you would have to change your email address. It was that bad. You had to tell everyone you knew about your new email address, then just kiss the old one goodbye. It was ok, though, because normal people just didn’t post their email addresses online.

Ah, but the bloggers…

That’s right, those pesky bloggers with their please-contact-me egos. They had to find ways to post their email addresses on their websites. What did they do?

First, they did nothing. And got spammed. It sucked.

Contact me at!

Then, obfuscation kind of caught on. So instead of writing your email address in plain HTML, you would write some basic JavaScript that would dynamically insert your email address into your mark-up. This worked pretty well, until the spammers got wise and updated their tools to match.

Contact me at !

You have JavaScript disabled, so you can’t see the JavaScript example.

Next, everyone settled on this idea that instead of linking your email address automatically, you could hint at what your email address is and let the users figure it out — and manually punch it into their email clients.

This worked well against spammers, because it made it look like there was no email address. But it also worked against users, burdening them with added responsibility. It was annoying then, but understandable. When people do it now, it’s just plain annoying.

Contact me at my first name at dan-menard dot com!

Finally, serious bloggers settled on the contact form. Instead of posting an email address online, these bloggers would post a form that asks you to enter your name, the subject, and the content of your email. When the user submits the form, some back-end server somewhere fills in the email address, far and away from anything spammers can see or touch.

Enter your name:

Enter your email address:

Enter the email subject:

Enter your message:

(That form doesn’t actually do anything, especially when you have JavaScript disabled.)

This was a foolproof anti-spam system, and held up well until Gmail came along and I never saw another spam message ever again. Wait, that’s worth repeating on its own line:

Then Gmail came along and I never saw another spam message ever again.

Seriously. I have three email accounts that I use daily, all of them running on Gmail. Do you know how often I see a spam message in my inbox? Maybe a few times a year. And I post those addresses online as much as I please. I don’t even think about it anymore.

And this is where we get to the point I’m trying to make:

Why are people still using contact forms?

Contact forms are unfriendly. Have you ever tried to write a heartfelt, meaningful message in one of those things? It’s impossible! They remind me that I’m monotonously typing into a machine when I should feel like I’m composing a message to a real person. I cringe whenever I see one.

They’re just not necessary anymore. We have spam filters! They work! You can post your email address online and you won’t get spammed. I promise!

And it’s pervasive! Blogs that I know and love still use them. Forcing me to shoehorn my beautiful prose into their stale, no-longer-necessary and mildly-annoying form.

I don’t get it.

I just want to use my own email client to write them an email on my own terms. Why are they making this so difficult?

Software Development Web Technology

Should You Support Classic Features or Should You Innovate?

A few months ago, the Internet Explorer team did a Q&A about IE9 via Reddit. While there were a few interesting items discussed, I almost did a spit-take when I saw this one:

Why doesn’t IE have a built-in spellchecker?

Are you kidding me? IE9 is going to ship without spellcheck? Ludicrous!

I immediately thought of all the typing I do in my browser every day, and how awful it would be to do it all sans spellcheck. I write my blog posts in WordPress. I comment on blogs. I consider proper spelling a necessity in my writing, and I simply can’t achieve it without a little help from my browser.

And it’s not just me.

Regular users are writing important emails, posting thoughts on Facebook, filling in online forms… How can anyone survive without spellcheck? What was the Internet Explorer team thinking?

I was really disappointed. Then I read the reply from the IE team:

Like any software project, developing IE is a trade off between features, quality and schedule. A built-in spellchecker would be a great feature that simply didn’t make the cut this time in favor of other things like <CANVAS>, <SVG> and other platform features.

Suddenly, I’m conflicted.

The SVG support coming in IE9 is a truly cutting-edge feature that really pushes what we can do inside a modern browser. And Canvas is no small feat either; people like me have scolded the IE team left and right for over a decade for not supporting open standards. These new features really are important to me both as a web developer, and as a browser-technology enthusiast.

So which is more important?

On the one hand, I really don’t think I can use a browser day-to-day that doesn’t have built-in spellcheck. On the other, I’m ecstatic that the Internet Explorer team is finally choosing to innovate and support new standards. I’m really not sure which side to take on this debate.

What do you think? Is it more important to support old, tried and truly-important features, or is it better to spend that time pushing the envelope and coming up with something new?

Web Technology

All I Want for Christmas is a Mute Button

…for Twitter.

Look, it’s not you. I like reading your updates, I always open your links, and I care about your coffee habits and your drive in this morning (I really do). But sometimes I just wish I could turn down the volume of messages that are flooding my stream, you know? Not all of them — I’m not saying I need a button to keep me away from Twitter — I just need some way to selectively parse out the noise.

How Things are Now

Suppose there’s a high-profile basketball game on, and I don’t really care for basketball. What do I do when a quarter of the tweets coming down the pipe are from passionate basketball fans? Well, I have three lame options:

  1. I can do nothing, and put up with the fact that one in four tweets I read will be nothing but a nuisance.
  2. I can unfollow everyone that talks about basketball, then follow them back later, and hope I don’t forget anyone.
  3. I can turn off Twitter.

Which of those solutions is best? Well, they all kind of suck. Doing nothing is the most annoying of the bunch. How useful is Twitter when the noise-to-signal is that high? Not very. I don’t want to have to work to see those tweets.

Number two would solve my problem somewhat elegantly, if I could script it and if those that tweeted about basketball were consistent. But of course they rarely are: sometimes their tweets will be about basketball, and sometimes they’ll be about incredible statistics. Ideally, I want to keep the awesome videos and lose the stuff about point-guards.

Our third option requires the least effort. Which do you think I choose most often?

How Things Could Be

I want mute options. Lots of them. I want to be able to mute people I follow, I want to be able to mute by hashtag, and even by keyword. I want to be able to toggle mutes as I please, mute for specific amounts of time, and save my common mutes in a mute-friendly screen. For muture mutings.

Let’s get back to our basketball example. If I know some blogger I adore is a Cavs fan, I want to be able to mute him for a couple of hours when the Heat roll into town. Furthermore, I want to mute a few keywords, so that I don’t get hassled by anything containing the words “Lebron James”. And maybe also a few tags; #miamiheat, #basketball, that sort of thing. Basically, I want to define a few basic conditions to filter my stream so that it has more meaning to me.

How We can Get There

While it would be great to see Twitter implement this functionality, who knows what their priorities are like. The good news is that third-party clients can handle this themselves. And how hard can it really be? Before displaying a tweet, check it against a few simple conditions. I could probably hack that together myself. In fact, I wouldn’t be at all surprised if there’s already a client out there that allows me this privilege (is there?).

(And if not, maybe there will be soon? Please?)