Archive for December, 2010

Fitting that on the last day of 2010, I have a few loose ends to wrap up.

There were publicly-set goals that expire today, and ideas and targets that are currently in limbo. So let’s address all that:

One Post Per Week

A few days shy of a year ago, I decided to start posting on a regular, weekly schedule. There was a big announcement, and then off I went, not knowing if I would be able to stick to it or not.

To date, this was probably the best decision I’ve made for this blog.

Forcing myself to post every Monday has made me a much better blogger. Having a weekly opportunity to try something new or hone my writing skills has been fun, and I’m going to keep doing it. For the curious, here’s how my posting schedule looked in 2010:

There were 52 Mondays in 2010.

I successfully posted a “real” post on 44 of those Mondays (not bad, but not great).

The only time I missed more than one consecutive week was when I missed three back in August/September (yuck).

Overall, I posted 61 times this year (slightly more than expected).

The Karma Experiment

This idea, which I posted about last month, was something I was really excited to try. Unfortunately, it never got off the ground.

December was a busy month for me, and I was starting to burn out a little (not a lot, and I’m getting better). It turns out that being pressed for time and lacking energy really aren’t optimal circumstances for writing heartfelt messages to fellow bloggers. In the end, I didn’t send a single message (though I wrote and discarded more than I care to count).

I really liked the idea (I still do), and I really wanted to do it well, but that wasn’t possible this month, and I didn’t want to half-ass it. Going forward, I’m going to put this on hold for a bit and get back to it when I’m capable of doing it right. So if you were holding your breath waiting to see how this turned out, start inhaling again and I’ll get back to you in a few months, k?

OCRI Updates

The original plan was to post these every two weeks. That sort of fell through when the schedule shifted a bit from what was originally planned, but I’m still one solid post behind. I’ll get that up soon, and after that the updates will be more sporadic (but I’ll try to keep them on Fridays).

Going Forward

I’m still going to post every Monday. I’m still going to use Fridays for smaller posts or additional content, and probably still the rare Wednesday when necessary. I’m still going to experiment. I’m still going to set goals and then try to hit them, and I’m still going to fail every now and then. In short, I’m still going to learn.

I have plenty of fun ideas in store for 2011, so thanks for joining me in 2010 and I’ll see you in the new year!

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:

I can do nothing, and put up with the fact that one in four tweets I read will be nothing but a nuisance.

I can unfollow everyone that talks about basketball, then follow them back later, and hope I don’t forget anyone.

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

I’m currently implementing a web front-end that has to work in a very secure environment. One of the things we can’t count on is that users will have JavaScript enabled, simply because it’s often a vector of attack on the web. While this has been a great learning experience overall, last Tuesday I learned a bit more than I’d planned on:

Apparently before I’d left the office Monday evening, I was doing some testing with JavaScript disabled. I’d also forgotten to turn JavaScript back on. And how long did it take me to realize this error the following morning?

Two hours.

Because apparently somewhere between CSS 1 and web 2.0, everybody forgot about <noscript>.

And I don’t just mean people like you and me — we’re talking big names here. Do you know what Google Reader looks like with JavaScript turned off? Try it. It’s just a logo that says Google Reader and a blank white page. It looks like a server issue.

My task management software didn’t fare much better. It simply sat there on its loading icon, perpetually promising me my todo-list, yet never delivering. How many times did I hit F5 thinking it was “just a slow server”? Tons.

Then there’s Yammer, probable the worst offender of the bunch. It managed to load everything except my timeline, the only bit that matters. What good is navigation if I can’t navigate to anything?

Finally, Grooveshark got it right. The recently HTML-ified music-streaming app displayed a prominent message alerting me of my ineptitude, triggering a sudden light bulb and all that jazz. But this raised an interesting question:

Who’s responsibility is it to tell users when they have JavaScript disabled?

Obviously the easy one is to blame is the user. If I turned off JavaScript support, I probably did it on purpose and it’s my responsibility to remember to turn it back on. But let’s say I forgot, or I did it by accident with some bizarre hotkey incantation. What then? There are two entities that can help me:

As in my recent case, web applications can use <noscript> to give me a heads up that I can’t enjoy their content given my current browser settings. Big names like Google should especially do this. They could even go the extra mile and detect my browser version, and as long as I’m not running something horribly old (Netscape 1?), or something excessively insecure (cheap shot at IE6! Yes!), provide me with a kind reminder that I probably did this myself, oh and here’s how to fix it in whatever browser my user-agent suggests I’m using.

And that brings me to my second point, and the bigger one in my eyes. Where was Firefox on this one? Let’s look at the various data points Firefox had but didn’t manage to connect:

That webapp sure does have a lot of JavaScript in its headers/mime-types/mark-up.

Hey, this is one of Dan’s bookmarks; it’s all over his browsing history.

Dan always has JavaScipt enabled, except the other day when he was mostly hitting localhost.

There was plenty of information there that Firefox could have used to deduce that I probably wanted to run JavaScript. A friendly reminder would have done just fine: “Hey, this site that you visit all the time uses a lot of JavaScript; if you want to run it, click here.” Is that expecting too much?

I think I’ll write more about this soon.

I really am learning quite a bit about taking JavaScript-less users into account in complex web applications. And next time I’ll be sure to share something more productive, instead of just bashing a few of my favourite things.

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?