Writing “Scaleable” JQuery – Shu

Recently, I’ve been thinking a lot about what it means to do really great front end development (HTML, Javascript, CSS). And, one of the key issues things I keep hitting upon is writing “scaleable” front end code. I use the word scaleable in a couple ways:

  1. Writing code well in a way that you could keep adding developers and they could each increase productivity linearly.
  2. Writing code that will work for increasingly larger sites.
  3. Writing code that is maintainable, testable, and extendable.

I know others have thought about this, some people call it “best practices”, some people call it frameworks, Yahoo even went as far as to create the YUI family of libraries. I think deep down, most people were trying to think about how to “scale” whatever it was they were doing.  This entry is the first in a series of writing jQuery code that “scales”.

Another thing I probably need to address before we get started is “Shu”. It comes from the Japanese phrase “Shuhari“, which I learned from Alistair Cockburn and is common in the Agile circles, and “describes the stages of learning to mastery”. Once you’re aware that there are certain levels of mastery of something, you start asking yourself which level you’re at and what level others are.

JQuery is awesome, and I love it. For along time, I treated javascript as a 2nd class citizen, but I’ve recently been really digging into it and making it “scaleable”.

In Dan Cederholm’s recent book, he introduces some jQuery that I’m lumping into the “Shu” box (ba-da ching!).

$(document).ready(function(){
$("#loc-adv a").click(function(){
$("#map").slideToggle("slow");
return false;
});
});

Now don’t get me wrong, this code is perfectly acceptable, especially for the situation it’s presented in (a small, static site, built by 1-2 developers). I’m all for not complicating things if they don’t need to be. This code is the simplest thing that could possibly work, and that’s awesome. However, we’re talking about scaling javascript up to larger sites, more developers, and maintainable in legacy applications, and there are some things about this code which don’t make it very scaleable.

First, it’s not really re-useable. Sure, you could include it in any page that has the `#loc-adv` a link and a map, and it’s going to work, but what if  you needed multiple maps in one page or had multiple links. All of a sudden, you’re going to need to repeat yourself, and we don’t do that.

Second, if you put this right in your page, as it’s presented in the book, you can’t use it on other pages without repeating yourself. Maintaining this code could be painful if you put it in more than one page.

Third, the only way this code is going to fire is if you click the link. There’s no way to call it from other code, or test it, and you’ll have to attach it to multiple elements if you add another link or some other element that needs to reveal the map.

What if you want to link to the page with the map open? This code won’t account for that.

I’m not going to address all these issues in this post. I’m going to leave that up for the “Ha” and “Ri” posts. Look for them in a couple days.

UX Fail: Colorblindness

According to wikipedia as much as 10% of males (~15 million people in the US) have red-green color blindness.  Why is that important? Well, for me personally, it’s important because I’m in that 10%. For a designer, it’s important because that’s probably more than the number of people who use, say, Safari and Chrome to browser your site. Do you care if your site works in Safari and Chrome? Do you care if it’s useable to people with color blindness?

I was reminded of this when I checked out Google Wave recently. When I signed in, I had 1 contact: the person that invited me. Their presence was shown by either a red or a green dot. Not an icon, but a dot. Not a large dot, a small dot.

So here’s the problem: I have no clue, litterally none, whether that person is there or not, because I can’t tell if that’s red or if that’s green.

Now, I’ve had this conversation so many times I can tell you what you’re thinking. You want to ask me, “What color is it?”. I can’t tell you. They are either green or red, but I don’t know. In fact, I can’t even tell if they are the same or different colors. Both of the dots look green, unless I think they are red, then they look red. I know, it doesn’t make sense. I literally can’t tell what color they are. I’m actually red-green-brown color blind, so they could be brown and I’d have no idea. All I know is: Google, you’re doing it wrong.

Facebook on the other hand, did it mostly ok. The blue moon is great for away. A green dot for available? That’s just lazy (and 2 different metaphors).

Update:

Here’s an example of a red/green combo I can differentiate and one I can’t.

Twitter Claim Chowder

Today both Microsoft and Google announced partnerships with Twitter for including tweets in their search results. If I had to guess, I would think they were paying for this data. In other words, Twitter just figured out how to make some money.

Remember when Jason Calacanis said he’d pay $250k to be a “suggested” follow and TechCrunch said this was how twitter would make money:

If other companies feel the same way, sellingthese slots could be a lucrative side business for Twitter. At $120,000 a pop, 20 slots would generate $2.4 million in revenues the first year.

And then there was Sam Gustin on Wired.com on 8/04/08 lamenting that waiting to make money was going to hurt them:

Stone’s hesitance to “monetize” Twitter echoes that of other major Web 2.0 companies, such asFacebook and YouTube, whose founders have said they’d build their audience first and find revenue streams later. But those giants have shown that converting eyeballs into money hasn’t exactly been easy; Facebook has yet to start generating meaningful profit, and Google has said on a number of occasions that it has yet to find the right business model for monetizing YouTube’s considerable traffic. Twitter, despite some plans Stone has up his sleeve, may very well find itself in the same position.

Remember when Fred Wilson said that Twitter would make money the same way Facebook would:

I think you have to look no farther than facebook to see where all of this is headed. They are the Google of social media. They are going to figure it out When they do something that works (becoming a platform for third party apps) others will follow in their wake. When they make a mistake (beacon version one) others will learn from that mistake. I am not saying that twitter is going to monetize exactly the way facebook is going, but I think that’s a good place to look for inspiration right now.

Remember when Bernard Lunn (10/15/2008) was complaining because Twitter wouldn’t tell us how they planned to make money? Oh noes:

Twitter is the poster child for the ‘scale first, don’t even think about revenue at launch, monetize much, much later’ model of startup. In the current climate, ventures like that probably won’t get funded. Which is a shame. Twitter is addictive and fun and even occasionally useful. If anybody can pull this business model off, it will be Twitter. It has scale, seem to be moving mainstream and they’ve even fixed their reliability issues.

But Twitter won’t survive if it doesn’t find a great revenue model. This matters to all of us.

So, what now that they know how they are going to make monies?

Minimalism & The Simplest Thing That Could Possibly Work

One of the core tenants of Agile/XP/TDD/Getting Real/Lean (etc) is doing the simplest thing that could possibly work. TDD says you should write a test and then only write enough code to make it pass. Lean says you should think about “minimal marketable features”. Paul Graham says you should launch just as soon as you have 1 feature that anyone would care about (here and here). Why is this so important? The fact of the matter is that 80% of your users use 20% of your app. That is to say, most people don’t care about most of what you have built. So why build it?

It turns out it’s really hard to know what people want before you make it. There are certainly ways to mitigate it, user observation testing, paper prototyping, but sometimes these things end up taking more time than just doing the simplest thing that could possibly work. In the end, you just need to build it, get it out there and see if anyone cares.

Well, the other side of this coin is that it’s also really hard to limit yourself to doing the simplest thing that could possibly work. You have to say “no” to many things and many people, including yourself, and people just aren’t good at that. No one wants to be the guy that always “puts down others ideas”.

Helvetification

Helvetireader

I’m very happy to be seeing a new trend in web apps, minimalism. I can only hope, that it continues to pervade all corners of software, both web based and desktop based. The tip of the spear seems to be the “helvetification” of popular apps. Some examples:

So what is so interesting about some new skins for some web apps? Is it just that I really like Helvetica? Well, I do like Helvetica, but the really interesting thing about these skins is not that they change the fonts and colors, it’s that they actually hide or remove significant parts of the apps. I’ve been using Helvetireader for probably over a year now, and I can’t stand to use google reader without it. I *hate* what GReader has become. It’s got tons of stuff I could care less about (probably say, 80% of it’s functionality). Starred Items? I use delicious. Trends? Really? And my favorite “Browse for stuff”. Uh, what? Isn’t that what using the internet is? What if Google Reader was the simplest thing that could possibly work? I think it would look like Helvetireader.

But Wait, There’s more!

So how does a couple skins for a couple web apps me that this is a trend? Well my friends, I didn’t think it did until I saw this:

lite.facebook.com

What is this? It looks like facebook, but they’ve gotten rid of all the crap I don’t care about. Lite.Facebook.com is supposed to be a version for “low bandwidth users”, but boy it sure does look like a minimal version of Facebook to me, and I like it. Compare it to say, myspace, and we’re talking Donald Judd levels of minimalism. And have you seen an Amazon Kindle? What about Readability from Arc90 (which happens to be really popular)? All of a sudden, we’re starting to get into trend categories, and I haven’t even mentioned how minimalism is the entire strategy of Apple, 37Signals, Twitter, and Tumblr.

But Features Are Good!

Gist Dashboard

Well, features can be good, but they can also be terrible. Recently, an interesting sounding website called “Gist” launched. What does Gist do? “Gist is designed to help the professional email user who often opens up their inbox only to feel like it’s helplessly out of control” (via ReadWriteWeb).  When I think of designing a site that is supposed to “take control” of something which is in chaos, I think of clean, minimal, organization. I would think that this tool would help me get to inbox zero, where there’s nothing in my email inbox but whitespace and the freedom to actually get my work done. So when I see screen shots like the one to the right, I can’t but help to think, “Is this really the simplest thing that could possibly work?”  This is a site that’s coming out of beta today. Not something that has been around for a decade. How would anyone know where to look, or what any of those boxes do?

Minimalism != the simplest thing that could possibly work

I could give you a bunch of definitions from famous artists and architects about minimalism, but I’m going to just say that minimalism isn’t the simplest thing that could possibly work, it’s when you optimize tsttcpw. The important point here is that it’s important here is that if you do more than tsttcpw, then you’re much less likely to rip out the parts that no one cares about. And I hope it’s apparent that, people want you to remove this crap. They don’t want more features, they want better experiences. They want that 20% of your application to be 100% of your focus, and they want the 20% to get better, not slowly become 18%, then 12%, then 10% because you keep adding crap they don’t care about. Minimalism, whether it’s in design, or any thing else, is taking that 20% and making it 100%.

NoSQL isn’t a movement

Today there’s been a tweet going around that says:

@programmingjoy: Help pick a better name for NoSQL Movement at NoSQL East Conference #programming http://bit.ly/18H0o7

This tweet really drives me nuts. In fact, I tweeted back:

@robotdeathsquad: NoSQL isn’t a movement, and when people say stuff like that, it makes them sound like idiots and I laugh at them.

So what’s so wrong with this tweet? It’s not the “NoSQL” part of it. I’m perfectly fine calling all the key/value, document oriented, and column centric DBs “NoSQL” as a short hand. That’s perfectly fine by me. My whole problem is with the “movement” part of this. Lets look at the definition of “movement”:

A group of people with a common ideology who try together to achieve certain general goals. (via http://en.wiktionary.org/wiki/Movement)

What exactly is a “NoSQL movement”? What is the common ideology? That you hate relational dbs? Hopefully that’s not it because that makes you sound like a child. Who hates software? Certainly not professionals. A professional doesn’t arbitrarily hate something, they apply the appropriate technique at the appropriate time.

What exactly is the goal of a NoSQL movement? To rid the world of SQL? Really? Really?

If it is to work together to build some great databases that perform much better in certain situations, then why not come up with a name that means that. I’m not sure that meets the definition of a “movement”.

Just as I mentioned in my post NoSQL: If only it were that easy, having new and different databases, which have new and different uses cases is great, but they are just one technique. Another tool in the shed, if you must. Trying to hype them, and elevate them some sort of “movement” status, is juvenile at best, and certainly misplaced.

NoSQL: If Only It Was That Easy

The biggest thing in web apps since “rails can’t scale” is this idea that “your rdbms doesn’t scale.” This has gone so far as to be dubbed the coming of age for “nosql” with lots of blog posts and even a meetup. Indeed, there are many promising key-value stores, distributed key-value stores, document oriented dbs, and column oriented db projects on the radar. This is *definitely* a great thing for the web application scene and this level of variety will definitely open doors for organizations large and small in the near and long term.

However, along with these great tools, an attitude that “the rdbms is dead” has popped up, and while that may be true in the long run, in the short term, it’s definitely premature.

Continue…

Rails App Template

I start a lot of projects. More than I’d like to admit. I finish and deploy very few, but I like cranking out the first iteration of an app in a weekend. Sometimes I do it just to learn some new feature, or try out an architecture idea. I don’t like to do this in the context of whatever existing app I’m working on, because I don’t want any baggage of whatever I was thinking last week. Last week is too long ago.

Continue…