Archive for January, 2011

Ottawa Google Hackathon Wrap-up

Monday, January 31st, 2011

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!

The Golden Rule of Web Design Implementation, Part 2

Wednesday, January 26th, 2011

This is part two of The Golden Rule of Web Design Implementation. In part one, we learned that pages aren’t views, and that thinking in terms of views is much more beneficial. Today we’ll wrap up our analysis by looking into development.

As you may recall from Monday’s post, the Golden Rule is:

The time it takes to implement a web design will always average out to one view per day.

Our first corollary was related to views. The second is about development. Or more specifically, developers.

There’s a reason I put that always in there. It’s to remind myself (and you) that this rule can stand up to a lot of variables. As I’ve mentioned already, the technologies being used and the platforms being targeted are irrelevant. Plenty of other things are too. But what I found most interesting was this:

The developer’s skill level doesn’t matter.

This is counter-intuitive. If a weak developer needs an average of one day to implement each view, then shouldn’t a more experienced developer be able to get those same views done faster? The answer is no. In fact, it will take a strong front-end developer and a weak front-end developer about the same amount of time to implement any given design. We’ll get to why in a moment, but first let’s clear up some definitions:

  • By weak front-end developer, I mean someone that knows the basics of front-end development in the technologies being used. That statement above is obviously false for someone with zero experience.
  • By strong front-end developer, I mean a real ace. Someone that can put “HTML/CSS Expert” or “Adobe Certified Flex Expert” on their resumé without exaggerating.

All set? So how is it that a below-average developer and a bonafide expert will require the same amount of time to implement the same design? It all comes down to the perceived level of what constitutes a correct implementation. In other words:

Better developers don’t code faster, they code better.

Picture a standard HTML/CSS implementation. The design is there, and you hand it off to your weak developer and your strong developer, and tell them each to get to work. After X days (where X is the number of views, of course), you get both implementations back. Here’s what you can expect:

The weak developer will have done exactly what you asked. The pages will look just like the mock-ups, pixel for pixel, and work as intended. There will be nothing wrong with the design from a typical user’s point of view.

The strong developer will deliver an implementation that looks about the same. Surprised? Don’t be. That’s all these two implementations will have in common. Let’s look at some things the guru probably did that our weak developer didn’t even consider:

  • The HTML and CSS both validate, with no errors.
  • Each page has a proper doctype.
  • There is a clear separation of structure and presentation.
  • Accessibility has been accounted for wherever possible.
  • The HTML is semantically clear, and would be easy to restyle.
  • The CSS is beautifully minimal, and optimized for maintainability.
  • There are <noscript> blocks for users that don’t have javascript enabled.

Do you see the difference here? On the surface, it’s barely noticeable. But just beneath that surface is a trove of quality that goes far and beyond what was asked. To the guru, this isn’t even extra work. This is just how HTML and CSS are used.

Don’t blame the developer.

You may be thinking: “The guru shouldn’t waste time doing what wasn’t asked of him; he should be able to translate that extra time into finishing the implementation faster.”

Please don’t ever ask this of your developers.

Would you ask a master carpenter to build a simple chair as quickly as possible, and not “waste” time without worrying about quality, durability, ethics, or craftsmanship? Of course you wouldn’t. That’s simply not how experts work.

The solution to this problem is simple: choose the best developer for the job. If you don’t care about the internals of a deliverable, assign a developer that has lots of room to learn. If the project requires some baseline level of quality, consider a developer that is better versed in the fine art of building interfaces. Only call in the guru when the project requires an unmatched level of care.

And remember that no matter how hard you push, and no matter which developer you choose, you’ll never beat one view per day.

The Golden Rule of Web Design Implementation, Part 1

Monday, January 24th, 2011

Hi folks! Today’s post was so full of awesome that I had to split it in two. This is part one, about views. Part two is about development.

Estimating is hard, and I hate doing it. But I have a trick.

Specifically, I’m going to talk about how to estimate the implementation of a web front-end project. Maybe it’s a UI refresh for an existing web site, maybe it’s a new take on e-commerce, maybe it’s one of those new-fangled web-apps… it doesn’t matter. As long as you’re implementing a relatively well-spec’d-out design, this rule will work every time.

Oh, and the technology doesn’t matter either. It can be HTML/CSS, with or without JavaScript. It can be Flex, it can be JSP or ASP or anything else. As long as you’re not doing any significant back-end work, this truth still holds.

This is really important so I’m going to write it in a really big font:

The time it takes to implement a web design will always average out to one view per day.

So if the design has 16 views, the implementation will take 16 days.

There are two interesting facets to this rule. Today we’re going to talk about the first one, the significance of the term “view”.

Views != Pages

This is an important distinction: it’s not about pages anymore. We’re past that. We have bigger monitors, and that means we can have more elaborate pages. In fact, we often put several views on the same page, just because we can.

Imagine you have a page in a standard two-column layout. The main content is one view, that’s obvious. What about the sidebar? These days, if it’s anything other than nav, it’s probably also an independent view. Even the main content can be more than one view, if it separates logically and especially if part of it will be re-used on another page.

Of course, not all views are created equal. Maybe the sidebar view in our example is a lot less work than the main content view. That’s bound to happen, and it’s fine. The rule states that this will average out, and believe me, it will. For every super-easy “only took an hour and a half” view you find, you’ll get stuck with one that takes nearly twice as long as it should because you hit some silly browser compatibility issue.

Get used to thinking in terms of views.

There’s another reason for looking at the design in terms of views: That’s how implementation works. You start with the overall page architecture, build out a grid or column structure, and then tackle each distinct view one at a time. The developer’s standard divide-and-conquer approach.

Doesn’t it make sense to estimate the same way? By considering the design in terms of views at scheduling time, you’re estimating the same chunks you’ll be implementing. This will lead to more accurate estimates.

It will also make your estimates easier to defend if they seem too high. Write out a list of all the views in the design, and say “this is a breakdown of the implementation in one-day chunks”. If there are 12 chunks, that’s 12 days. You don’t even have to use the term “view”.

By throwing away the pages metaphor and instead thinking in terms of views, you’ll get better estimates that are more accurate and easier to track, and easier to explain to others.

There’s still more to learn!

We’ve only looked at the first interesting corollary from the Golden Rule. In part two, we dig even further to reveal the secrets of development.

“Newspapers Have No Future”

Monday, January 17th, 2011

A tweet caught my eye this afternoon:

I knew there was a fire nearby work this morning… Check out the video. http://bit.ly/gJY60rless than a minute ago via web

Open the link and watch the video. Cars on fire are pretty cool, right? But do you know what amazed me even more?

That video was shot by some office employee, standing around in the company lounge. And now it’s on this major newspaper’s website, part of an entire city’s local news. That level of cooperation between news organization and regular person is awesome. The news company wasn’t there when it happened, but that guy was. So one of them reached out to the other and now that video can be shared with everyone. No egos, no red tape, just people helping each other out.

And look how fast it went up! That post went live shortly after 2pm. The fire happened at 9am, only five hours earlier. Rather than waiting until tomorrow, the newspaper got to work pushing that update right away. The days of delivering the news first thing in the morning, or even in the evening, are long gone. We want the news as it happens, especially when it’s local news.

Ignoring the video for a moment, look at the post accompanying the story. Is it full of ads? Does it span six pages? Of course not — it’s short and sweet. Only the details we care about, and nothing more. The content is concise because the newspaper understands what internet users want. We have no attention span; just give us what we care about, and maybe some pretty pictures (or in this case, an awesome video).

Oh, and did I mention that this same newspaper just released an iPad app? And that it’s gorgeous, and free, and I use it all the time?

§

For all the clambering about how newspapers and other print media don’t have a future, here’s one that seems to be doing just fine.

Contact Forms are Totally Lame

Monday, January 10th, 2011

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 !

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:


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?

Great Advice about New Year’s Resolutions

Friday, January 7th, 2011

I didn’t want to do a post about resolutions this year because I wrote a great one that I still feel strongly about back in April 2010 called Make Every Day New Year’s Eve. But this is still a time when a lot of people do the introspection thing and come up with some goals for the new year, and I’ve read quite a bit about it in my RSS the past week or so.

As a quick thought going into the weekend, here is my favourite quote on resolutions out of everything I’ve read all week, from the mentally incontinent Joe the Peacock:

Here’s a helpful hint: Make your yearly to-do list a bunch of verbs. “Run every day.” “Write a book.”

This is exceptionally good advice. It’s easy to follow, easy to verify, and it will absolutely lead to healthier goals.

For my part, the closest thing I have to a resolution this year is to cut down my poutine intake to once per month. The statement itself isn’t quite dead-simple, but it is still verb-focused. How do your resolutions stack up against this rule?

Should You Support Classic Features or Should You Innovate?

Monday, January 3rd, 2011

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?