The Cost of Developing Rich Interfaces
At Cloudera (where I work now) we’ve been hard at work for the last month on the product we’re launching today. (Side note: I’m not going to link you to it because you’ll just go there and play with it and screw up all our numbers when we see all these JavaScript people show up and click the forward, back, forward, submit, add, delete, etc. buttons just to see what they do and we’ll be wondering what we’ve done wrong to make the interface so confusing…)
Anyway, today’s launch is basically a 6 step form. It’s built on Django’s form wizard which, in many respects, does all the work for you. Making the experience interactive, helpful, and even kind of fun to use is my task, and it’s made me consider the cost of adding such (arguably non-critical) features.
Let’s face it. As much as we like to talk about how JavaScript has finally kind of arrived (what with all the “Web 2.0″ commentary) and, well, it really has kind of arrived when you think about what you can do with the technology, but as much as we tout that, it’s still expensive.
Developing a simple 6 step form takes probably, oh, a day to do with a framework with Django. Less even. A few hours. If you were practiced at it and knew exactly what you wanted, maybe not even an hour. But then we start thinking about Ajax, client side form validation, tool tips, interactive components that help you construct more complex data sets that otherwise might be a pain to do by hand (like, say, typing in a date), etc. etc. And the next thing you know, there’s 90K of JavaScript on the page. Oh, and it doesn’t work quite right in Chrome or Safari 4 because those browsers aren’t in your testing suite, and then there’s IE6, which you’d rather just not support.
It seems that, just as we’ve gotten to the point where we can just bang out something as simple as a 5 step form, we’ve managed to complicate it ten times over so it still costs a ton of time and money to make it work. Is it worth it?
I’d like to think so. I like having rich interfaces that look nice. I want a web app that I build to feel like it’s going the extra mile to make the user’s life a little easier and the task in front of them a little fun. Playful even.
I’ll give you another example. I made a login box for this app. It’s a username/password box floating dead center in the page. It fetches the server response to the user’s login attempt via ajax and if the user types in the wrong credentials, it shakes at them and puts a little red “!” next to the password field. It’s not that fancy, but it makes everyone who sees it want to type in a bad password. But doing this meant a bunch of photoshop and css to make it look slick, a new extension to MooTools’ Fx that took a bit of effort, plus a bit of hacking in the Django authentication code which isn’t quite designed for this style authentication.
It’s made me think more about my programming to patterns concepts. It’s more important than ever to focus on inheritance and derived functionality. Building a base layer of functionality and abstraction makes it possible to create a system of rich interfaces. The cost up front is somewhat daunting, because you basically have to approach everything in a generic way. Sure, you’re working on the login box, but to just make the thing jiggle you have to revisit the authentication model of your app and author a new Fx plugin which involves figuring out the math for a sinusoidal transition… Ack!
But it’s worth it when you get further into it. It’s what makes Apple products so rewarding. All you have to do is look at all the phones that came before the iPhone and know that there’s value in going that extra mile. Functionality paves the roads and makes the engines work, but the details in the design make the difference between a Ferrari and a Hyundai.
The task that we have before us, I think, is to figure out how to make the system that we use to add those fine details as cost effective as Django, Ruby on Rails, and other such frameworks have made the MVC pattern. For MooTools I can see that pathway (and to be fair, we’re behind other frameworks on this score – but MooTools More is the first step on that path), but ultimately it requires a lot of people contributing who are solving very different problems to create such a system. It’s always cheaper to do something for one time use if you are never going to reuse it.
So the task I have before me, personally, is to abstract as much of my own work away from my current goals so that others can use it. And your task is to do the same. And our task as a group is to contribute our use cases, knowledge and effort into finding the commonalities between these things and make life a little better for each other. If we spent the next 2 months, 6 months, and year doing that, we’d be in such good shape. In a way that’s what we’ve been doing with MooTools this whole time (and the same can be said of all the frameworks, which borrow from each other constantly). So when I write about why you should release your code this is one of the bigger reasons. Yeah, there are a lot of shorter, tactile reasons for doing it despite the effort it takes. But the big reason is that we’re all busy reinventing the wheel. We should be doing that, but after we’ve all invented the wheel, we should compare notes, and collaborate. Then the next time we need a wheel there’s nothing to think about, and the only thing left to do is to see what cool things we’ve all done with them. Ferraris indeed.
Follow @clientcide on twitter to get notified of new posts.
To follow me personally on twitter, follow @anutron.
March 16th, 2009 at 12:04 am
Looks cool. Especially forward-back navigation ;-)
March 16th, 2009 at 2:19 am
Great post! I’ve been reinventing the wheel when it came to rich ui components — I have my own version of a lightbox, form validation, etc — I really like the jQuery UI effort. Maybe MooTools more could grow into something like that (you guys have been talking about it for a while now).
And yes, I do believe that the cost of a rich ui is worth it. It took me getting a Mac to fully understand the importance of appearance and consistency within your application.
I dont know if I have done anything that is ‘More worthy yet, but if I do, it will definitely be added to the que.
March 16th, 2009 at 4:57 am
At my job we create web-apps for pharmaceutical companies. They get pretty intense, even when the idea is so simple. So I know what you mean when scripts get really large.
This past week we’ve been designing a page that allows users to create data extracts, in a dynamic way. They can pick what to extract, what columns, pick criteria etc. It acts as a wizard. And each step is contained in a block that is the width of the main page container. And when the user clicks ‘continue’ or ‘back’ the container scrolls (horizontally).
The idea was simple, but the implementation is another story. Took a lot of time and effort. But when you put your mind to it you really can do just about anything. And I’m happy to say that it works in just about every browser (even IE!).
Oh, and we use MooTools. I never used it until I got this job. Now I love it. I used to use Prototype which has its perks. But MooTools is better, in my opinion. And MooTools More RC1 is great! I can’t wait for more, and for a Core RC. Keeps getting better.
March 16th, 2009 at 5:57 am
What we’re talking about now are very simple applications. On the flip side of this, more complex applications can be made alot simpler using client-side technology.
For example I did the entire backend interface for a product management system that handles over 5000 products in 1000 categories in 5 countries using just 2000 lines of code. And I was using YUI back then!
What really made the difference was that otherwise complex issues like translations, crosslinking and handling hierarchies could be made really simple using drag and drop operations.
There isn’t really much benefit in to gain on simple forms. Infact, it’s probably even an unnecessary expence. But if you can save each employee one work hour a day in a multi-national company because of a new interface… That’s some serious gains.
March 16th, 2009 at 10:47 am
As I started reading, I immediately thought of the iPhone (and then you mentioned it.). Since the iPhone, there’s been other phones that come out with Touch Screen interfaces. So the iPhone isn’t alone in that regard. But why is the iPhone still better?
It’s fun to use. And that’s actually one of the things I tell people why I like the CMS I work on most. Sure, it’s powerful, and hopefully easy to use, but for me, the way we made it work, I enjoy editing my site and other clients’ sites.
Fun to use. Worth the investment.
March 17th, 2009 at 1:51 pm
I fully agree with your final thought on contributing to next-level / higher-level tools. And I think a lot of people share your utopic visions. I have myself written quite a series of reusable extensions and classes that could have helped lots of people.
However, there is currently no community portal for sharing and communicating about these contributions… this is the biggest show-stopper at the moment! Any thoughts on that?
March 17th, 2009 at 1:58 pm
While it’s true that there isn’t a portal for MooTools scripts (we are slowly working on it…) we do have several options to help people release their own code. Github and Google Code both allow for hosted code and I’ve offered previously here on Clientcide to host download pages for projects and to share the tools used to generate the download builder and docs and whatnot. While a portal for scripts is ideal, there’s nothing stopping you from releasing code today.
March 17th, 2009 at 7:10 pm
Thanks for the kick up the butt! I’ve got a growing collection of classes to solve different problems that have arisen in our day to day studio work and really should start posting them. The only thing I’m concerned about is releasing classes that aren’t bulletproof and causing people problems when they try to dump them in and go. In my eyes I guess they’ll never be done though!
March 17th, 2009 at 7:46 pm
@Dan, you’d be surprised. When you release code, yes, people find your bugs, but that’s a good thing. And sometimes they even help you fix them.
March 18th, 2009 at 12:23 am
@Aaron, indeed there are enough ways to release code, I am starting to do this myself. However, a central repository or listing would make a big difference: an overview with full coverage of everything available, version managed, standardized documentation & examples and registered dependencies are things that make the difference between amateur and professional. You mention you are slowly working on this, I am willing to help.
March 18th, 2009 at 7:21 am
You’ll need to reach out to Digitarald. Here’s the codebase (http://www.redracer.org/).
March 19th, 2009 at 3:36 am
I’m a really lazy guy and I hate it to reinvent the wheel, however I believe MooTools currently isn’t as far as to be reused easily by anyone.
It’s still too complicated finding out what plugin needs what files (js, css, images…)
And if you have a Layout for a Plugin how can you easily change it (if css only changes are not enough) without recreating the functionality.
I think that’s pretty important “for me” as I don’t want to think during development about all those things…
And I guess most of the people out there just include the full core and more code during development because it’s the only way you can develop without suddenly getting a not defined error… :p
don’t get me wrong – I love MooTools and I’m trying to adopt it to my needs… I’m currently heaving my basic UI class you can see at: http://www.delusionworld.com/mootools/general-mootools-ui/
I’m also trying to create a manager for locally installed plugins but there is still some work to do before it’s usable by “others”.
March 19th, 2009 at 9:08 am
@Thomas, I would argue that the things you complain of are all manageable if you design your code differently. Certainly I’ve illustrated here at Clientcide that releasing lots of code is possible, even when that code includes image assets and whatnot. Dependency management is something we’ve already solved (with our scripts.json maps and build scripts that resolve dependencies).
March 20th, 2009 at 1:11 am
@aaron, yeah sorry maybe it’s just my lazy code style. That’s the reason I said it’s important for me. And I (again just me and my crazy style… :p) believe that there could be a better solution than the scripts.json…
If you write your dependence information in an separate file that has nothing to do with the actual plugin I guess it’s like putting the price tag of a car not on the car but on a list that’s hanging in the headquarter lobby of your company. Now you stand in front of the car and you what to know it’s price – you would have to got to the headquarter lobby and check it there. And what if your not at the headquarter but in some remote outpost? I guess It would be easier to just add the price tag to the car… I mean what’s happen if you are not allowed to update the list – your just allowed to bring a car…
Man that was a strange comparison – don’t wanna offend anyone but that’s how I’m experiencing it. Jet again it doesn’t really matter as I’m working on a solution to my problems you don’t need to listen I’m just blabbering… :p
March 20th, 2009 at 8:05 am
The reason for scripts.json is so that other things than browsers can read the dependency list and do things with it (like build tools, docs engines, etc). If you declared it in the JS file itself, then the only thing that could read it would be a javascript parser or one you wrote yourself. By having the map in a json file, anything that can read json (i.e. nearly everything) can take that file and do things with it. It’s a JavaScript problem, and MooTools solution.
April 3rd, 2009 at 11:26 am
I have come to love Mootools. Most of my issues are not with Mootoo, but management’s view of JavaScript. With the new JavaScript frameworks, it does clean up many of the common issue and give us web developer more functionality to create new things. I have found that most managers, like many developers did in the past, don’t see the amount of effort it takes to make a rich HTML/CSS/JavaScript UI. This makes it hard to develop rich environments with unreasonable deadlines/budgets. Managers still see JavaScript as a limited/simplistic/easy language. Also it hard for them to understand that you have lots of rendering engines you have to worry about. To make matter worse, the most common browser is also the flakiest. So QA time/costs are high too.
April 3rd, 2009 at 12:36 pm
Good stuff Ben. In my mind, all those barriers you describe only highlight the importance of developing abstract patterns for greater code reuse. If you know your SlideShow class works in all browsers, it’s one less thing you have to test. The other thing is that it illustrates the importance of “selling” your work after the fact. I.e. once the product is launched, give a talk to your coworkers and explain the product enhancements you added with clientside technology, what that entailed, the technical challenges it represented, etc.