dan-menard.com

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:

   context.drawImage(img,0,0,img.width,img.height);
   

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(
    clickX,clickY,HIGHLIGHT_SIZE,HIGHLIGHT_SIZE).data;

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 — 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!

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.

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!

(sorry)

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.

HackOTT

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!

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 dan@dan-menard.com!

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.

(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?

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?

…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?)

A prediction: In the near future, browsers will no longer have stop and refresh buttons.

Think about it. When the internet first started out, pages actually took a human-measurable amount of time to load. And with finicky dial-up connections, it wasn’t uncommon for a connection to completely drop in the middle of a page load. It made a lot of sense to have a refresh button, in case you just lost your connection and have now reset it. Stop made sense too; if you saw a page loading tons of images, maybe it wasn’t worth loading at all.

Now fast-forward to today. Pages load instantly, and connections are almost always persistent. No more need for refresh, no more need for stop. The buttons are obsolete.

Testing the Theory

Looking at what buttons in my toolbar I actually use (I’m running Firefox), There are really only four:

• Address Bar
• Search Bar
• Back
• Forward

The buttons I don’t use are:

• Stop
• Refresh
• Home

So to see if I really don’t use them, I removed them from my toolbar about a week ago. And you know what? I haven’t missed them one bit. They don’t fit into any of my use-cases anymore. We simply don’t need stop/refresh as much as we used to, and even home is less necessary than it was in the days of online portals.

In fact, I’m really starting to appreciate my minimalist toolbar. Back/forward on the left, then address bar filling up most of the screen, and a search bar off to the right. Nothing I don’t use every single day. It’s bliss.

A Note for Web Developers

Web development is one case where refresh — as an action — is still necessary. I still maintain that a refresh button is not needed in this case. Web developers are always power-users, and we simply don’t use buttons for actions like refresh; we use hotkeys.

If you’re a web developer, you probably at least use ctrl+R or F5 to refresh a test page. Better yet, you probably use ctrl+shift+R or ctrl+shift+del and some menu work to clear the cache before a refresh (and if you don’t, you should). Standard refresh buttons aren’t ideal for us anyway.

Browser “Support”

Obviously not everyone will be willing to part with legacy buttons right away. One interesting solution to this problem is customizable toolbars, such as the one used by Firefox. Here, the user has full control over what buttons appear in the interface. This is in fact the only browser I tested that allows the stop/refresh buttons to be removed.

There are also a couple of major browsers that have started to deemphasize the stop/refresh buttons. Chrome, for example, combines them into a single button, and Safari goes one further by merging this single control into the address bar.

Predictably, Internet Explorer is still a step behind. Microsoft’s browser’s UI is generally recognized as the weakest of the four, though it looks like they are catching up with IE9.

I didn’t spend much time digging into more niche browsers. If anyone uses one, I’d be interested to know how the UI stacks up against “the big four”.

What do you think? Am I out in left field here, or are we about to see a neat evolution in the web browser interface?

The other day my boss walked up to my desk and asked me to choose a number between one and ten. I said four. He handed me an HTC Surround, a new handset running Windows Phone 7, and told me to try it out for the day.

It was awesome.

This is the first serious iPhone-competitor I’ve seen so far. Sure, it doesn’t have Android’s openness or Palm’s lovable WebOS, but it has it’s own user experience that isn’t just a knockoff of what Apple came up with almost four years ago. Here are some thoughts from my day of usage:

I’m in love with the interface.

The new hub-scrolling paradigm is a fresh and welcome change to how content is organized on a small screen. Instead of always breaking different information into distinct views, like you would see on an iPhone or Android phone, applications for WP7 are organized as one giant view that you sort of scroll around on. It’s a bit tricky to visualize, but once you’ve used it, you get it. It’s that simple.

And then there’s the transitions! They’re incredible. Anytime you do anything on the phone, it’s accompanied by a fancy-but-not-quite-distracting animation. The way one view flips to another is gorgeous. The loading screen is clean and fun to watch. The whole thing is like one giant production, and it’s really well done.

Lastly, many of the applications I downloaded already use these new UI elements very well. The Facebook app (which admittedly was made by MS) is easy to use and well-organized. Though it’s completely different from the iPhone Facebook app, which I’m a huge fan of, it’s just as good. I was blown away. Twitter was another great example, and this was actually made by the guys at Twitter. They grasped how to use the new graphical features and made an absolutely stellar app out of it — again, totally on par with Twitter’s official iPhone app.

The hardware is good, but not great.

The Surround in particular had a slide-out speaker, and a built-in stand. While this is probably standard fare for Android users, as an iPhone-enthusiast I’m not used to my phone having weird hardware. I probably wouldn’t use the speaker/stand much, but it might be interesting to see what other kinds of hardware are added in future third-party devices.

Of course, the standard components were done pretty well. The camera quality (5 MX stills, 720p video) is the same as that of the iPhone 4 (and puts my 3G to shame), though there’s no flash and no front-facing camera on this particular handset. The screen quality was very crisp, though I didn’t have an iPhone 4 on hand to compare it to.

It could be interesting to see how the hardware powering future WP7 devices will stack up to the iPhone 4 and whatever new iteration of the iPhone that Apple releases in 2011. For now, the iPhone still comes out on top, at least from the stock of WP7 devices available in Canada.

Some other misc things I liked:

The soft-keyboard is pretty awesome. The shape of the keys are different from the iPhone, and I found I was making less mistakes while typing. That said, the auto-complete may be a step down. Instead of filling in new words by default, like the iPhone, WP7 tries to guess what you’re typing as you go, and you have to manually select it when it shows up at the bottom of the screen. This is decidedly more work on my part; not only do I need an extra tap to auto-complete, I also have to constantly peek down at the bottom of the screen to find it.

Finally, I need to mention the home screen. I like it. Having applications update their icons automatically with new information is very useful, and grouping content by subject rather than by application has a lot of potential. The People tab, for example, lists all of your contacts, and integrates Twitter/Facebook information if applicable. I didn’t really have enough time to get a good feel for how useful this really is, but it’s an innovative concept nonetheless, and I’m anxious to see what third-party developers will do with it.

I kind of want one of these phones!

The overall impression I got from the Surround was quite positive. My current carrier-contract expires in July 2011, which should be right after Apple’s next iPhone iteration. I’m excited to see how WP7 stacks up at that point, because it looks like I might have a difficult decision on my hands — and that’s a good problem to have.

For this week’s post, I decided I would play around with the Internet Explorer 9 beta and post some initial thoughts. I’m a bit of a browser geek, and as I mentioned back in April, I’m excited about IE9. I imagined I’d have a great time exploring the support for HTML5 and CSS3, and playing around with new features like SVG and GPU-acceleration.

As it turns out, I didn’t get that far. Why, you ask? Two reasons:

Reason #1: It has never taken me as long to download a browser as it took me to download IE9.

Seriously. I opened a text file to log my initial impressions, and thought it would be fun to start taking notes right from my search to download the beta. I ended up saving my text file, happy with my outline, after only completing the install. Briefly, here’s what I noted:

Downloading the installer feels like work. The top hit on Google for Internet Explorer 9 is the old platform preview page from April, still with the same title. I initially skipped over it, thinking that I already have the preview and that’s not what I’m looking for. The next few results were all sketchy, unofficial mirrors. Eventually I crawled back to the preview page, which had a link to “Get the Beta”.

This led to a completely different-looking page (neither were particularly well designed, they were both quite startling in their mediocrity). Here I immediately saw a link called “Get it Now”, which I followed to a third page, that had not one but almost forty buttons labeled “Download”.

Yes, forty.

This is because Microsoft decided to list all languages IE9 is available in, each with its own download link. And to choose your preferred language, you don’t click on the language or a checkbox or anything, you highlight your OS version from the accompanying drop-down list. Are you kidding me? Who designed this? That’s five clicks now, for those of you who are counting, across three pages, with two different types of controls, and I had to parse my language out of a giant list.

Downloading a browser shouldn’t feel like a chore!

Think about the last browser you downloaded. Was it Chrome? Then you probably don’t remember downloading it at all, because it takes about 10 seconds. The download page can be found in an instant, and you click one button to download the installer. ONE. From one page, that you found really easily.

Maybe your last download was Firefox. In that case you probably remember it a little better. The procedure was smooth and enjoyable; branding was consistent and the sequence of clicks and navigation was concise and straightforward. You probably noticed how beautifully designed Mozilla’s website is.

If Microsoft is expecting IE9 to compete with the other major players in the browser market, they have to streamline the downloading process. Google and Mozilla go out of their way to make sure their browsers are easy to find, and simple/enjoyable to download. Finding and downloading IE9 is currently a hassle.

Reason #2: Installing IE9 is about as modern as debugging IE6.

I’m serious. The installer for IE9 looks and feels like it was built in about 1997. It’s a standard dialog box with a progress bar. No decoration of any kind, and no branding. No “Thanks for participating in our beta!” or “Here are some of our new features…”. Just the bare minimum; something no other browser maker would dare do these days.

And how long it took! I’m pretty sure I could have installed FF, Chrome, Safari and Opera in less than the amount of time it took to run the installer for IE9. Of course, Microsoft was kind enough to provide me with a couple of helpful progress messages explaining what was taking so long:

• “Installing required updates.”
• “Installing.”

That’s it. Two extremely vague statements with no way to gain further information. And just when I thought it couldn’t possibly get any worse, I completed the install only to find a pop-up telling me to restart my PC. I almost fainted. Why on earth would installing a browser require a system restart? This is unheard of.

Is this really the best Microsoft could do?

Where were the interaction experts that put together the interface for Windows Phone 7 or Windows Live? When will Microsoft figure out that it’s no longer acceptable to phone in their UX? That it’s not okay for even trivial interactions with a new product to be poorly designed?

The web crowd is not known for its patience, and I wonder how much longer it will persevere.

I spent yesterday in Montreal at Make Web not War. It was a really fun time, and I learned a lot of neat things and met some interesting people. I was tweeting about it a fair bit, as were many others, (#webnotwar was actually the top-trending topic in Canada for much of the day) but for the benefit of those of you that don’t follow me on Twitter, I thought I’d sum up the experiences I had while I was there.

The keynote was a good start.

Joel Perras gave a great opening speech that really set the tone for the day. There were a lot of thoughtful tidbits about how closed-source platforms and open-source platforms can interact with one another, but by far the most-quoted phrase from this introduction was the following:

Interoperability isn’t a feature. It’s a requirement.

This simple sentiment sums up exactly what Make Web not War is about. Different platforms must interact with one another to be part of the modern web.

Next I saw a crazy-looking WordPress development process.

Morten Rand-Hendriksen develops WordPress applications, but he does things a little more radically than most people. He uses Expression Web to make presentational changes through a GUI, rather than editing CSS himself, and the speed of results was pretty remarkable. This was a really thought-provoking presentation, and lucky for you, some of the content is available on Morten’s blog.

Morten also shared a bit of interesting WordPress knowledge. Did you know that WordPress 3 (which is currently in Beta 2) will support custom CMS-style menus? The interface for it is very slick; select what you want, and drag/drop to set the order (no more HTML-level changes). Secondly, he found a really neat hack for creating custom template pages per-category: simple add a page called categoryName-categoryId.php and it will be used by WordPress for that category’s landing page. Lots of potential here!

Then there was a really interesting panel about communities.

The panel set-up was very informal, and provided a great atmosphere that really made it feel like we, the audience, were simply listening in on a conversation between the panelists. It’s hard to describe what I liked so much about this particular panel, but from what I remember, the take-aways were something like this:

• In the world of web development, the community is your best friend.
• In order for the community to grow and remain healthy, people have to participate.
• Waiting for the “big” meet-ups that happen every four or five months isn’t good enough.
• All big cities have a variety of technologically-inclined groups that meet up much more often than that.
• The meet-ups don’t even have to be techie; a karaoke group or patio night is just as productive.

So the message overall was pretty loud and clear: get out there and spend some time with others in the web development world, doing anything from talking about new technologies to trading bacon-themed recipes.

After that, there were some five-minute web-app demos.

The one in particular that caught my eye was the not-very-carefully-named Flockoo. This is a service that allows you to log in with your Twitter account and enter a location, and then returns a list of all the users you follow from that location. Very useful for conferences, for example.

My favourite panel of the day was actually about SEO.

Man, was I shocked. I went into this one thinking it would be a drag (I have a relatively low opinion of self-proclaimed SEO-experts) but it turned out to be absolutely full of practical, useful information. The speaker promised that the slides would eventually be available via SlideShare, and I’m anxious to give them a re-read. They filled in quite a few gaps in my SEO knowledge, and I’m sure they’ll help you too.

Next was another panel, this one about cloud computing.

I’m not much of a cloud-guy yet, so I didn’t really gain much from this session. The only thing I distinctly remember was one of the panelists describing the current state of your average cloud-based service as a “cloudsterfluck”, which is a term I’m sure I’ll re-use for months to come.

Then I was pretty disappointed with the HTML5 session.

This is a topic I know a lot about, and I was really looking forward to seeing some interesting demos or cool new techniques. Unfortunately the speaker spent most of his allocated time rambling about spec changes, something that I (a) could have learned about myself in about half that time, and (b) was already intimately familiar with.

He did mention HTML5 Doctor, though, which is a fantastic resource for all things HTML5, and I made a point to share this awesome HTML5 demo with the other attendees via Twitter, as it’s my favourite HTML5 application to date.

The CSS3/jQuery session wasn’t much better.

The material wasn’t quite so dry, and the presenter was much more animated, but there still wasn’t anything really new or interesting.

Finally, there were the Coding Competition finals.

This is where the very best of two-dozen-or-so web-apps were shown off by their developers and voted on by their peers (the other attendees). The criteria for these submissions was that they used PHP, open data, and/or Microsoft Azure.

The entry I voted for was TaxiCity, a really creative game that uses geographical data from Vancouver to overlay a 2-dimensional game world on top of the Bing maps for Vancouver where you, the cab driver, drive around the city picking up and dropping off fares. The execution was very well done, and the distributed team clearly worked very hard to put a lot of polish into their product — an A+ in my book.

The idea that won, however, was an application with a lot of potential called Find a Home. This is a real-estate-type tool that lists homes in the Edmonton area and ranks them by novel criteria such as family-friendliness (based on proximity to schools and parks) and safety (based on proximity to Fire and Police departments). It’s certainly a good use of open data and new technologies, but I felt it wasn’t quite “finished” yet, even by alpha standards.

All in all, Make Web not War was a great time.

The food was delicious and plentiful, the venue was gorgeous, and the staff were fantastic. I’ll definitely go back next year.