Screwing with people considered harmful

Posted by on . No comments.

Apologies about the rude title, but I couldn’t find another word that fit.

I was opening a business bank account the other month. The process goes as follows:

  • Ask friends and coworkers what banks they recommend.
  • Make a list of banks, including fees, minimum deposits, locations, and other restrictions.
  • (List reviews but give up when every bank has 2 star ratings)
  • Go to bank and ask questions to reveal hidden fees; get 20 page Disclosure of Legalese (this is customary at every bank; if you don’t get one, it’s still there)
  • Pretend to read, sign 15 forms; ask for copy of form you signed and get a “we don’t usually give out that form”
  • Get any forms of ID/checks/missing that you didn’t know you needed the first time; acquire debit card/checkbook

After this process, two interesting and opposite observations emerge: 1) Our protagonist is clearly more pedantic than most mere mortals, and 2) Despite all the efforts of due diligence on his part, does anyone really doubt he’ll be hit with some sort of fee at some point?

US banks belong to a special class of institutions, shared with mobile carriers, cable companies and used car salesmen. What’s interesting about these places is not the degree of hatred they inspire (bad bosses and politicians on the other side–substituting your personal other–are also), but rather the kind. A proper analogy might be a well-kept house with bad flooring. Someone unsuspecting might choose to play foursquare in the living room, but those in the know shake their heads at these youngsters and test every step they make.

The true cost society pays for this isn’t just fixing the floors, but rather being unable to run. Patching up the single parent who gets hit with an overdraft, or being forced to call the cable company every 12 months to get the same rates we started out with is bad enough; learning to mistrust the institutions we work with every day is another thing entirely.

A lot of advice on picking a bank says “it’s not the bank, it’s the banker.” Now, the real reason to do this is likely to make it easier to get a line of credit, not avoid dickish fees; but this line of thinking – the mantra of “find a person, because the process itself isn’t good enough” – reminded me of another, more soviet set of institutions. I think it would be unreasonable to say hidden fees are like a Gulag; I’m not making that comparison. However, every time someone needs to double check their form filling out of paranoia, or review yet another contract with a magnifying glass, under the expectation of mistrust, that brings us closer to countries and bureaucracies where the process is really and truly broken, countries that we generally call corrupt.

As a more positive example, imagine the process we go through to buy books at a bookstore. Whole regions of our minds dedicated to things like “will this book poison me?” and “do I give up my right to sue when I buy this book?” and “will I pay a special extra fee if I try to read this book in a roaming area?” just…don’t exist. Whole sections of cortex are liberated to think about things like characters and plot. It’s enough to bring out an involuntary grin.

If dickish institutions were designed in such a way that it was transparently clear what we were getting, even if it was expensive, that would be more than a good deal for society – would it perhaps be a relief?

Never pile stuff on top of a container

Posted by on . No comments.

The moment you put something on a box with a lid, you’re going to have to shuffle things around every time you want anything inside the box.

And most likely, the stuff inside the box is important, but not important enough that you’ll bother going inside the box if you have to work at it. So now you’ll never go inside the box.

Working with Terrible Code, Part One: Writing a CKEditor plugin

Posted by on . No comments.

Understanding Terrible Code, Part One:

Writing a CKEditor Plugin

Exposition: Why should you care about a random text editor?

Modding CKEditor is a well-designed exercise in self-flagellation.

CKEditor is a text editor plugin that works with rich text (bold, italics, tables, links, etc.). If you’ve ever used Gmail or Hotmail, you’ve used something similar.  CKEditor is relatively easy to use, powerful and has lots of features, and it’s used everywhere. But while the code is well written and well documented, at a macro level there are terrible design things going on, and if you want to modify it, you’ll be glad you never did end up getting that gun license after all…

Since I’ve been wrestling with it for quite a while now, I wanted to share my thoughts:

  • In case you happen to be forced to alter CKEditor as well. Hopefully this will be a useful breadcrumb trail.
  • To convince myself I’m not faking it. CKEditor has well written source, in the sense of comments and indents and other things they do well, so someone could argue “maybe they’re doing it well and you just don’t get it.”
    This is a perfectly valid counterargument. The best way to figure out if I’m faking it is to actually try and explain why it’s bad, and see if this post turns into “CKEditor is an architectural marvel” in the process.
  • Complaining is whining unless you can explain why, and how to make things better.
  • I need to understand this stuff myself, and nothing helps with understanding like trying to explain.
  • Because I’ve been staring at this for days and need to say something.

Act One: Parallel Universe APIs

Half of CKEditor code essentially replicates JavaScript DOM APIs and jQuery. Let’s use the most radical example of CKEditor manipulation – the dialog architecture.

CKEditor dialogs are used for special properties. If you want to add a link, you would create a dialog to set the URL.

What language do you think dialogs would be designed in? Presumably a language that is used to lay things out in a web browser. Hmmm…what language do we use for that…HT nope, you’re right, it’s JavaScript:

The new dialog system in CKEditor is to be written from scratch. One of the key things in CKEditor is that it doesn’t rely on HTML pages to run. Everything is created on the fly in JavaScript. In this way, we avoid limitations about cross domain serving of the editor code, like CDN solutions, and enhance the editor performance.

http://docs.cksource.com/FCKeditor_3.x/Design_and_Architecture/Dialog_System#Dialog_Definition

We’ll get back to the benefits CKEditor claims later, but let’s think about this. You’re laying out a mini-web page. You’re a web developer and probably lay out web pages all the time. You read A List Apart obsessively; you understand the difference between content (HTML), presentation (CSS), and behavior (JavaScript), and the benefits of separating them.

And then you see this:

(This is actual dialog code that CKEditor uses to show a link dialog.)

Is that HTML? Yup – it looks like a <select> – there’s a list of options (items), and an id, and even a label.
Is that JavaScript? Yup – it’s got an onChange, a setup, and a commit, whatever that is.

This confuzzlement is compounded by the fact that there are about 1000 (literally, see for yourself) lines of this JavaScript/HTML hybrid. If you separated this into HTML and JavaScript, it would be easy to read, not indented six ten tabs in, and it wouldn’t take you an hour of sorting to figure out what a dialog that’s basically a handful of selects and some text fields is doing.

By the way, there’s CSS too:

		var basicCss =
			'background:url(' + CKEDITOR.getUrl( this.path + 'images/anchor.gif' ) + ') no-repeat ' + side + ' center;' +
			'border:1px dotted #00f;';

Let’s establish some of the downsides of this mixed-content architecture:

  • Wading a thousand four-hundred line morass of mixed behavior and content every time you want to change things
  • No way to test the layout of your dialog without loading all of CKEditor (as opposed to HTML, which can be tested by anyone with a web browser)
  • You have to relearn all your HTML/JavaScript/CSS ninja skills in a weird JS hybrid
  • Oh and if you miss a brace, it’s not like missing an angle bracket – everything dies. JS is brittle. Did I mention you have to reload all of CKEditor to test your fixes?

So how about the benefits? The CKEditor docs claim that you can do cross domain* loading (for content delivery networks, etc.). While there are plenty of things wrong with the solution, the CDN problem is serious and it would be irresponsible to ignore it. Is there another way we can allow CDN loading without replacing all of our HTML with JavaScript?

One option: Write HTML for the dialogs, but convert it into escaped JavaScript internally. Escaped HTML is ugly, but if we compile it, we needn’t use it except in production.

Another option: Don’t use a 1-1 HTML counterpart, but use a simplified meta-language.

This rant is just barely getting started. Every time I work on CKEditor I’ll make sure to add more.

“When you have enough data, sometimes, you don’t have to be too clever”

Posted by on . One comment.

Peter Norvig, famed AI researcher and one of the creators of the Stanford AI online class:

Past, Present, Future Vision of AI – Google and AAAI 2011

“And it was fun looking at the comments, because you’d see things like ‘well, I’m throwing in this naive Bayes now, but I’m gonna come back and fix it it up and come up with something better later.’  And the comment would be from 2006. [laughter] And I think what that says is, when you have enough data, sometimes, you don’t have to be too clever about coming up with the best algorithm.”

(Peter’s speaking about search algorithms, but what if you applied this to running a startup? Or life in general?)