Why Not?

User experience is one of the most important parts when developing a project. Users should never have to think or fight with your product if you wish for it to succeed. If you look at most of the successful web applications today, the simplicity of the user experience if prevalent.  Gmail and Google Calendar are the two applications that immediately jump to mind when I think about this.  The user can know how to interact with the complicated software within a couple minutes. Unfortunately, this beautiful simplicity does not exist often enough in development frameworks and SDKs.

SDKs and frameworks are complicated behemoths that are hard to learn.  In my mind, when I have to learn a new framework, it is almost like learning a new programming language.  Actually, it may be even more difficult to learn a new framework because concepts don’t translate from one framework to another. I don’t know how many hours I’ve lost when learning a new SDK and just trying to wrap my mind around how each piece of code talks with each other or getting the correct security key to access a web app’s API.  How much time have you invested in debugging Windows SDK errors rather than actually creating code? These problems are barely the tip of the ice berg in SDK usability. As such, I believe that a better way to look at frameworks, especially if you are interested in large adoption, is to see them as a piece of production level software rather than a tool to solve a problem.

We can take this thought by looking at the difference in popularity between two well known javascript frameworks, jQuery and dojo. These two libraries deal with very different problems in the javascript space, but are still compared by their respective users since they cross many paths. As such, jQuery is known by many proficient web developers and designers, while dojo is more popular with advanced developers. This is a result of how the two libraries throw the users into the code to start playing around..

jQuery makes a lot of sense for developers that have only used core javascript and CSS when creating website. The fundamental way to develop with jQuery is to use CSS selectors with everything you do. For example:

   1:  $("a").click(function(event){

   2:      alert("a link was clicked!");

   3:  });

I believe the above code, in my opinion, makes sense to new developers once they read the intro jQuery docs:

- $(“a”) creates an array of all anchor nodes on the page

-when a user clicks on any link on the page, an alert box will appear

On the dojo end of things, the CSS selection system is not a core fundamental to development.  They have a system much like jQuery’s (it’s called dojo.query() ), but dojo aims to solve many of javascript’s shortcomings by introducing a module system, widgets, data layer, xhr, and much more.  As such, dojo has a higher bar of entry, it isn’t too difficult, but users must learn how to interact with the dojo code loading system and make sure the web page dependencies are all correct. To recreate the same type of onclick event in dojo, we can do the following:

   1:  dojo.query("A").connect( "onclick", function(event){

   2:      alert("a link was clicked");

   3:  });

It isn’t too much more, but I feel that the above syntax might confuse some users. What is dojo.query? What does “connect” do? Why should i do this instead of dojo.query().onclick?

What I am trying to get across with the above examples, without getting into a dojo vs. jQuery argument, is that jQuery is so much more popular than dojo because it has a much lower bar for users to pick up and start making simple programs with. jQuery is even one of the first libraries that web development classes teach their students. Jeffrey Brown, in an interview with CSS-Tricks captured how students pick up jQuery so fast:

I find Javascript is a bear to teach. Imagine you were them, so far they have learned Digital Design Production (fairly straight forward, you tell a program what to do and you see your changes instantly), HTML (extremely straight forward, you write it and it shows up), and CSS (you change it and it changes on the screen). Then all of a sudden here is this beast that is capable of complicated thought, you can’t always see the changes you make in your site, and if you type a single character incorrectly it could break it. Not to mention its syntax is unlike anything they have seen thus far. It is a big jump and often we (web professionals) are too quick to lump JS with HTML and CSS. It falls in the same category but it doesn’t teach or learn the same way.

I make them stick it out with JS for a solid month or two, then just when they think they can’t process any more JS I show them JQuery. They always say the same thing, “Why didn’t you show us this first?” and I always say the same thing, “Because you need to know how to write JS on your own and not rely on a third party library.” They still hate me, but at least they know the basics of Javascript. Jquery works for them, as with many of us, because of the use of the familiar CSS selectors.

The process Brown seems to take here when teaching students is HTML > CSS > Javascript > jQuery because the library solves so many problems and makes simple sense for people that just learned CSS.

We can even extend this topic into how popular some web application APIs are, more specifically, Twitter. Twitter’s web site is the most unpopular way to interact with the service, more people are using mobile or desktop clients to talk with their friends and followers. This is because Twitter’s API is so simple to use. If you are a web developer, you will understand that all you need to do is make an AJAX call to the Twitter and you can grab the data from a user account, their search service, etc.

Let me repeat that.

To get twitter data, you give an AJAX call the URL and you get all the data you are interested in back.

No difficult security validation. (ok, some if you are worried more than just the search API)

No crazy programming model of objects, methods, etc.

Just a single URL and a function to handle the data returned.

It honestly can’t get simpler than that.

How many tech news stories do you read that has something about a new twitter client a day? a lot?

How much news do you read about new Flickr/Google Maps/Yahoo Pipes/whatever applications and clients?

Twitter’s consumer product is not it’s website.

Twitter’s consumer product is the API.

When creating your frameworks with the intention of large developer adoption, ask your self these questions:

-How long is it between downloading the SDK to writing hello world?

-How much documentation does the user need to read to understand our model of development? Can the user figure out what is going on just from looking at the packaging of the example files?

-How much example code do you give the user to copy and past into their application to start hacking away with?

-How easily accessible is the documentation for the user?

-How easy is it for users to discover new features and aspects of our SDK?

Hopefully with these thoughts in my mind, you never hear a user say “I spend more time fighting with the APIs than actually developing my code!”

For the best example of a failure to make a simple framework, Joel Spolsky captures it best in his classic article, How Microsoft Lost the API War