A 14-Point Framework for Evaluating Programming Libraries & APIs (Part 1)

Libraries, network-services, virtual machines, platforms and frameworks, all qualify under the umbrella term "API". Some are simply things to be lived with — if we develop Windows applications, if we write Android or iOS applications, then we're blessed or cursed with certain platform-level givens, and there's not a great deal we can do about them apart from, perhaps, wrapping them behind a facade layer that feels a bit "nicer" — that makes life a little easier for us as developers by providing abstractions that more closely match the abstractions defined in our own applications and hiding layers of complexity that must necessarily be handled, but are uninteresting or distracting from the goals for our own development.

Aside from those "givens" we are faced (almost daily) with choosing other utility libraries and services to make our own development faster, simpler, more reliable, more performant and less repetitive.

This then, brings us to the heart of my topic: What exactly is it that makes one programming interface "nicer" than another? What makes one library "better" than another? Is it the expressive power? How would we go about measuring that? Is it how quickly we can churn out useful code, working correctly? Does popularity and coolness matter? There has to be a better way to measure — if only in a fuzzy and inexact way — whether one library or REST service is better suited to our needs and wants than another, and whether using a particular library might be better or worse than writing our own.

In case it is not already clear, let me emphasize: There is no One True Best API for any given task. Every problem lives in a context — a set of forces pushing and pulling on the boundaries of the solution space, warping the texture of the implementation landscape. Costs, time, expertise and past experience, functional requirements, timing and reliability constraints and, not least, developers' penchant for playing with the newest, shiny technologies — their desire to learn and extend their mastery. So: each and every API we choose to employ (as opposed to those that are forced upon us whether we will or no) must be tested against the problems we are trying to solve and the constraints and forces acting upon us and our application. A particular library may be the "right" answer for one project, but be quite inappropriate for the next one. Our desire for "good architecture"[1] suggests that we should, at least, make those choices consciously and deliberately rather than blindly or reflexively.

In what follows, I suggest some ways we might pick apart the various dimensions we might choose to use in evaluating various competing APIs, identifying 14 dimensions that you might want to consider as evaluation metrics in choosing (or avoiding) an API.

I should emphasize that I consider APIs (along with programming languages, platforms and codebase-hygiene) as primarily a UX problem. These things are all first and foremost user-interfaces for us, as tool-manufacturing humans to use, misuse or abuse. The principal question is, "How likely is it that this tool (API) will lead us astray and into the murky swamp of technical-despair?" versus "To what degree will this tool allow us to write less code, more reliable code, more readable (comprehensible, therefore maintainable) code?"

[1] I refrain from trying to nail down just what constitutes "good architecture" and rely, here, on your own intuition and experience. Suffice to say that it extends well beyond the merely technical concerns and encompasses the human, social and business spheres, too.

1. Surface Area

How many types, methods, configuration items do you have to learn in order to use this thing?

This is not unrelated to the ideas of Function Points as a way to "size" software — it attempts to measure the number of inputs and outputs (since that's what types and configuration items are) and use-cases for those moving parts. The absolute number is not important, since different APIs address problems of many sizes and a wide range of complexity, but it can be useful in comparing APIs that purport to solve the same or similar problem-spaces.

2. Coverage

How much of the topic-area does an API address? Is that what you need?

Does the API do all that you expect it to do? Does it do way more than you need? If the API is functionally incomplete, you will find yourself writing supplementary code to make up its deficiencies. That may be acceptable, but it may spell trouble if the API in question is supposed to be solving some complex or difficult problem (e.g. crypto) but is not sufficiently complete.

The case where an API covers way more territory than we really need is a little more subtle. Given appropriate tooling (not always available in all toolchains or environments) this is not primarily a technical problem (of linking too much object code into an application codebase, resulting in codebase bloat) but a cognition problem. Every part of an API wants to put little hooks into our brains. They call out to us, crying, "Me, me. Pay attention to me!" and we truly cannot afford to give them that time or mental space. Take the Google Guava library (for Java.) I use it on almost every Java project I am part of. But I only make really heavy use of maybe two chunks of what it does — the Preconditions and some annotations (for adding contract-like guarantees to classes) and the Collections (particularly Immutable collections) classes. The rest of the library is mostly surplus cognitive baggage most of the time. I'd be better off with it being in a separate library to be pulled in only when truly needed. Indeed, I have seen projects that end up with as many as three separate definitions of methods like isNullOrEmpty(aString) and checkNotNull(anObject) simply because developers did not want to pull in all of the Guava library in the early stages of their project, then acquired another instance of those methods because some other third-party library made those definitions, and, at the end of the day, they ended up using the Guava library anyway for other reasons. What a mess.

3. Composability

How well does this API play with other libraries and tools?

If an API works in terms of platform-compatible types, it is much more likely to play well with other APIs. If it insists upon introducing and using only its own types, it will be much more difficult for us to force it to play well with the other libraries in our armory — we are sure to find ourselves writing endless boilerplate code converting between custom datatypes. And unit tests for that code. Or not, so hurting our code coverage metrics and creating emotions of despondency and discouragement because clearly we suck at doing The Right Stuff.

4. Modularity

How easily can we break this library into pieces so that we can use just the bits we need?

This is (again) about reducing cognitive load. Does a library allow us to just pick and choose the bits that suit us well, leaving the remainder strictly alone, or does it force us to schlepp in all sorts of sundry other parts of the library that do not touch on the problem we're solving. Some frameworks tend to be really bad at this.

5. Openness

How much is this API a black-box?

Can you tweak the under-the-hood stuff if when you need to without delving into the twisty, slippery innards of the implementation? This is simply the Open-Closed Principle in its essence.

6. Opacity

How well does an API hide the details and complexities of the problem-space? A well-thought-out API will shield us (to an appropriate degree) from the concepts and particularities of the underlying domain it deals with, allowing us to work with concepts the ought to be much closer to our own, more familiar application domain. The types and operations exposed at the surface of the API should reflect something more amenable to adaptation to our own conceptual framework than the underlying problem that it hides and manages.

If a library is not making stuff simpler for us, why bother using it? Does it provide a facade that makes sense in the context of the problem your application is attempting to solve?

7. Accessibility

Can you learn just a little bit of the library and be useful (Vertx), or do you need to learn the whole damn thing before you can (safely) use any of it? (Git)

Accessibility is one of the more important dimensions for thinking about APIs because it means we can tackle the (sometimes daunting) task of learning to use a library truly effectively in little bites, and each little bite that we can chew and swallow gives us an ever-increasing confidence in the library, and an ever-increasing confidence in our own abilities to put it to good use.

---

I shall continue with the remaining seven dimensions in a follow-up post in a couple of days. This thing is already too long for Internet-attention-spans as it is.

Web-design HowNotTo

Seen recently on a mailing-list I receive:

> These guys stock 29mm Crown Caps http://www.africancork.co.za

Went off to take a look at their website...

"You have to be logged in to view our products"

They have to be joking! I can only assume that they actively hate it when people want to buy their stuff. Needless to say, I bounced.

Do people really still misunderstand the nature of the web that badly when we're already more than 10% of the way through the 21st Century?

Work Wanted

This is a small call for help. I am looking for work, and need your help.

Contract or permanent. Preferably (but not exclusively or even at all) telecommute. I can code, design, architect software, consult in any of these (and dev process/team issues) and teach a variety of Java, OO Design and web development topics, and would be happy to do any/all of these. I additionally have some experience doing system administration work. I work in Linux/Unix environments and know next-to-nothing about Windows.

I've done web stuff, and loads of backend "heavy lifting" coding where reliability, scalability, etc. are important. I am not good at quick'n'dirty. Skeptical of the value of buzzwords and big-arse frameworks.

Check out my "business" website for more details about me and what I've done in the past.

R (as they say) "highly neg".

If you have anything suitable, or know of anything that fits, please drop me a line.

I will be in Cape Town and environs next week, so an ideal time to get together and chat about possibilities and opportunities.

Design using Other Peoples' APIs

Where you are dependant upon somebody else's API, decouple from that API at the earliest possible opportunity so that the remainder of your system works in terms of your own abstractions rather than that somebody else's. This shields you from the random, spurious, and often unwarned changes they may make. It also enables you to place guards against the various stupidities they may likely perpetrate in the name of fashion or unthinkingness, and ensures that you are - as much as possible - forced to deal only with your own stupidities and unthinkingess.

This injunction includes decoupling from your own APIs where those are non-core to the subsystem under design.

Measuring Progress in Software Development

Background

I am about to take on the leadership of a new, still-in-formation developer team, on a project - the first of several - of critical importance to the client. This means that everything is up for negotiation: team structure, development methodology, coding styles, frameworks to be used,... everything!

Initially my role was confined to that of Consulting Architect, but, by force of circumstance, has evolved to Architect and Team Leader pro tem for a few months while the client gets their dev team properly resourced and settled-in. Naturally I'm trying to help that along as best I can.

Methodology

The client initially planned to use a BDUF (Big Design Up Front), waterfall approach to the project. The requirement is extremely well-known and quantified, in a very well understood business domain.

I have never believed in my tummy that BDUF is in any sense realistically or practically achievable, though, even long before the Agile Movement tore the idea to shreds. It is impossible to foresee every detailed design element, no matter how hard you work at it. On the other hand, some Agile proponents seem to say that no up-front design is necessary... Perhaps my hearing is playing tricks with me. I cannot agree with them, either.

So call me a proponent of SDUF: Some Design Up Front.

And on the Process front, I don't think there's a lot to argue about when we contrast a waterfall/sequential process with an agile/incremental process. For me the critical difference lies in how we report and feed-back progress and how frequently we do this. And what we do about the feedback we receive - how flexibly we accommodate direction changes from customers, business sponsors, unit-tests,... to change the still-in-the-pipeline development and requirements without completely trashing the budget and time-to-market constraints. An also-essential aspect of agile development is "to reflect on what has gone before, and to adjust what we do to make
things better." [Ron Jeffries]

Waterfall possibly still does have a place in some circumstances. I can't honestly say that I've ever actually been party to such circumstances, though I've certainly been on projects where some of our business partners thought they needed hard, contractual milestones with no going back. (In reality we always "went back" anyway, when necessary, after some amount of renegotiation.)

Metrics

A very greenfield situation, this, which some people would immediately call a "wonderful opportunity", but which I very much see as a "two-edged weapon"...

The question that has been most on my mind is, "What should we measure?"

I am a very firm believer in the old saw, "Tell me how you Measure me, and I'll tell you how I Behave."

Measure a sales-person by the number of sales, and you'll get a high order volume of the easiest-to-sell products, regardless of whether they represent the best margins or quality-of-business for the company. Measure the same sales-person by margin-value of product, and you'd best hope that your high-margin products are ones that lots of people want to buy. Measure them by the number of sales calls they make and you'll have lots of calls that don't result in sales.

Here is where I believe that some Scrum proponents are going wrong... We take Features and break them up into Tasks - the developers' unit-of-work. And they measure Task completions using a burn-down chart of Tasks completed versus time. This can easily result in a situation where many Tasks are being completed, but not so many Features. A situation where Features reach an 80%-complete state, and then get stuck, for any of a variety of reasons, all of which amount to "Nobody wants to complete those Tasks" because they're boring,... or they're "just" test Tasks,... or they're difficult (because not well understood), or...

The solution is really simple. Just measure Feature completion instead of Task completion. Then the team only gets rewarded when Features or User Stories get completed. We only get beer and Pizza when the Business gets value.

But is this enough? Can we go further? Is there a way to tie developer reward directly to delivered Business Value?

In the situation I'm headed into, Business Value should be pretty easy to quantify: The product to be built is one that will directly generate revenue for the company, so we can very easily quantify how much Business Value the software is generating. (Successful completion of the product will also deliver a huge  strategic Business Value by enabling new revenue streams, but that's also quite easy to quantify, and, indeed, is the prime reason the client is taking on this quite substantial investment in the first place...)

Are there ways to close the loop? To feed-back to the dev team on how much business-value their efforts are generating without making money too much of an up-front issue? Then, too, I have a reservation: Developers can have notoriously short memories, and the sort of value we're talking about here is only delivered on longer time-scales... Maybe it's good to have both long-time-loop feedbacks as long as we also have the short-timespan feedback in place as well... Waterfall's failures are largely a result of too little feedback taking too much time for us to correct project course when we need to.

My instinct is that moving towards a continuous deployment process (the step beyond continuous integration) might help to shorten this feedback loop, which is completely the point of "agile" thinking, but I'm still not really clear on how we might implement it.

Cogito Ergo Wiki

For your entertainment and delectation, I offer up a small write-up in which I muse about complexity and simplicity in the tools we choose to inflict upon our project partners.

A short excerpt:

I think that WikiMedia is a relatively terrible thing to inflict upon unsuspecting project partners who are already stressed out by the weird idea that they should contribute documentation to your project, that they might actually be asked to actually write something

Wiki Wondering: Share and enjoy.

Invalid Field Feedback Failure

Random musing on UI misdesign

A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.

Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)

Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.

Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.

So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.

[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]

User Interface Redesigns

I love this quote by E. A. Vander Veer in "Why Does Facebook Keep Redesigning?"

typically users aren't considered at all when it comes to software redesigns. I wouldn't have believed this if I hadn't seen it in action on countless projects in several different companies! The attitude is, "We're the experts, we know what you want and need, our redesign is making it better, and it won't take more than a few minutes for you to get up to speed."

This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.¹

Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.

Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.

Like those who thought that adding autoboxing and varargs to the Java language was a value-add...

---

[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!

Software Design

"System Design, is one that as a profession we talk about less than I believe we should. It is, in many ways, the most important and most difficult thing that we engineers attempt to do. I believe that we avoid talking about it because it is hard, and seems somehow “unscientific.” There are clearly some designs that are good and others that are not. But the judgment of how good a design is often seems subjective or based on aesthetic principles rather than on the cold hard facts that we are engineers who pride ourselves on forming the basis for all that we do. I hope that this essay convinces some readers that the dichotomy between science and art or engineering and aesthetics is not clear, required, or even desirable. What we do must be grounded in fact, but it also needs to be grounded in taste. We should revel in that rather than trying to cover it up. It makes what we do more difficult, but also much more interesting."

-- Jim Waldo

I've been thinking a lot again, lately, about software design and how to teach it... and about how little there is out there to guide the design of good software architecture...

All part of my Quest After The Heart Of Design for the last 15 years. And maybe (just maybe!) I think I have a useful angle on it that might illuminate a path forward.

I'll say more as I develop the concept.

(And, BTW, Jim Waldo is, in my humble opinion, one of the preeminent thinkers on design alive, and one of the most interesting people I've had the privilege to meet.)

Word processors

If Word Processors are to Words as Food Processors are to Food.... no wonder they're so bloody awful to use!

Code as Exploration of Unknown Territory

I have come to view coding as the act of exploring and charting unknown territory -- the wilderness of our cognitive space.

If we let it, as we go along, our code illuminates the crevices and crags of our understanding, and shapes as it goes, our ideas of where to go next.

Version-control is the key mapping tool.

---

I've just reached a point in the development of the mikroblogging tool where I (finally!) believe I understand what's needed; what might work as something new-ish and interesting-ish in the conversations we have over this Internet thingie...

It's not a conventional website like Twitter or Blogger. It's not a standalone desktop/PC-installed system doing some sort of smart p2p stuff. It's not a conversation follower nor a search tool nor a Bayesian-interest-detector. More something hybrid from all of these.

Let's see where the code will take me next...

Courseware: The Next Step

Just received my Instructor's Manual (only a week late!) for Sun's SL-425 "Architecting and Designing J2EE Applications"¹ and I'm very happy to see that it is basically the same course as the old "Architecture and Design" course I taught several times lo' those many years ago when I was so frequently on my feet as "Herr Instructor".

This is easily the best² course I ever "taught"! It is aimed a senior, experienced designers and developers³, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!

It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!

So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)

Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.

I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
----
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.


[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!


[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!


[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal⁵ stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."


[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)

UI Design Encourages Mistakes, Boosts Profits

Having just finished my banking and tax admin for the month, I fire up the bank's online system to fork the money over to the various landsharks, fatcats and leeches.

To make the various tax payments I first have to select which of my accounts to use for paying.  Then I select who I want to pay.  (For some value of "want".) The system insists that you click the "Search" button to check that you have entered the corect payee account details, but, of course, it only tells you this after you navigate away to the next page, and, when you return to the payment details form, it throws away all the details you have already captured.

I also have to enter a 19-digit reference number and, guess what, if I get it wrong (as I am likely to do with such a long number) it only tells me on the next page, and, again, throws away all the work I have done to fill in the form, forcing me to redo it from scratch.  Including forcing me to redo the payee "Search", despite the fact that my browser has captured the field details perfectly.

The real kicker is that it also ditches the account-number from which I want to make payment, substituting the "default" account (which happens to be my personal account and not the business account)  Of course, the account number is metres away up at the top of the web-page, so I don't notice that I'm making payment from the wrong account.

As a result I pay business taxes out of my personal account.  When I eventually discover my mistake, I have to transfer the money over from my business account to fix things.  And I am going to get hit with the withdrawal fees again.  To add insult to injury, the payment pushes my personal account into overdraft.  Bam!  Overdraft fees!

This UI is so wrong, in so many way, you would think that the bank  would have "inspired" and "motivated" to fix this monstrosity years ago.  Do you wonder why Standard Bank can't be "bothered" to fix their broken user-interface?  Do you wonder why they make incredible profits?

Did you think the two facts are unrelated?

Invisible Work

Here's a great quote from Jim Waldo, courtesy of Dan Creswell's Blitz blog:

…Even worse than not being visible to the customer, work done on designing the system is not visible to the management of the company that is developing the system. Even though managers will pay lip service to the teaching of The Mythical Man Month, there is still the worry that engineers who aren’t producing code are not doing anything useful. While there are few companies that explicitly measure productivity in lines-of-code per week, there is still pressure to produce something that can be seen. The notion that design can take weeks or months and that during that time little or no code will be written is hard to sell to managers. Harder still is selling the notion that any code that does get written will be thrown away, which often appears to be regression rather than progress.

Never a truer word!

Quotable

"The Ark was built by one man.

The Titanic was built by a team of professionals."

User-interface Reboot

This article by Mr Mirchandani gets it exactly right: UI again ...don't pretty up, destroy!

I have never forgotten the experience of early last year. Our car had been stolen, and we were jumping through the licensing department's hoops to get the old car de-registered, and our new car registered.  Well, 10-year-old, 2nd-hand car, since that's all we could afford with what the insurance company deigned to pay out -- another saga for another day.

First we could not de-register the old car, because it was flagged on the licensing system as "stolen", so no changes to its details are permitted.  WTF?  We could not unflag it, since that would require the police to mark the car as recovered, complete with verification of engine, chassis, VIN and registration numbers.  Eventually we left the matter in the hands of one supervisor who took pity on us as I crumpled in the face of this actively-hostile "information" system.  She solved the impasse by going outside the system: phone calls to a special contact in Pretoria -- "high friends in low places."

Then we had to register the new car.  The details had to get captured no less than 5 times!  Twice, manually by myself, the remainder by the clerk punching a terminal.  And two of those instance involved recapturing the vehicle details from a form still-hot from their system's laser printer.  The system already had the details, yet they still had to be manually recaptured.  This is insane!  Weren't computers supposed to save us work?

5 Trust Points for Website Usability

For a while now I've been working (slowly) on a new web application; the details are unimportant; I'll talk about the specifics in a couple of months when I'm ready to show something.  I have about 60% of the backend written, and am just starting in on the web frontend.

I am far from being a good "web designer", having the graphic-design and artistic skills of a newt.  The best I can hope for is creative imitation.  It worked for the Japanese car manufacturers, didn't it?  Consequently, I am paying close attention to what works and what irks on other websites, particularly the flow around initial engagement and user sign-up.  Here are the most irritating and unnecessary five things I've figured out.  These are all prompted by stuff I see over, and over, and over again on website after website.  It's getting old.

1. Don't Make Me Jump Through Premature Hoops

Allow me to explore the website. I am entitled to poke about and get some reasonable idea of what the site does, the why and how, before you ask me (or require me) to create an account.

I grant its really not a big deal creating an account, especially since most/all of the details I'll give you initially will be bogus because I have no reason to trust you at first. IBM still, about ten years after filling in a webform on their site, send junk mail (the paper kind) to "Lord Mike" :-)  But there's still some small effort involved in entering a Login-ID, email address and whatever other bits and pieces you require me to fabricate before you allow me into your walled garden.

If I cannot fathom enough detail about the site, if it does not help me to figure out the value proposition it offers me, I will just walk (well, click) away to somewhere else.  The Web is, for all intents and purposes, infinite.  For me to have stumbled across your tiny patch of virtuality was nearly a miracle in the first instance.  Don't block me from finding out whether I want to actually give you my time and attention.

2.  Don't Assume a Trust You Haven't Earned Yet

When I actually do sign up for an account, don't ask me for my whole life history, food preferences, sexual orientation and DNA samples.  I'll just lie, anyway.  I don't really trust you yet.  I only think that your site may have something I want.  This ties into the previous point: The more information I am able to glean before signing-up, the less likely I am to lie to you about myself, the more trust you will have created between us.

For the site I am building, I will be asking for:

1. Your choice of Login ID
2. Your email address.

Nothing else.  I don't need to know anything more about you yet; why would I assume that you're willing to give me any more?  I will generate a password and send it to you; I need to confirm that your email address works anyway, and, since I want to be able to send you email, I need you to confirm that you're OK with that, so I may as well send you a password at the same time.  You can always change it to that standard password you use everywhere later, if your browser doesn't remember it for you, anyway.

Incidentally, I just made the sign-up process as quick and painless as it can possibly get, didn't I?  There's only one way to make the process shorter.  Do you really, really need people to sign-up?  I know its an attractive proposition to a certain mindset, but is it really, truly necessary?

As I gain confidence in the site, I may go back to my profile page and fill in missing details, and correct some of the more egregious inventions.  This may take months or even years.  This brings me to my next point:

3. I Am Human, Ergo I Forget.


OK, so you don't burden me by asking for too many personal preferences and details early on.  Well done!  On the downside of that, I will repay your consideration by almost instantly forgetting that I left out details, lied about my birthdate or typed jarblewarblefarble into that form-field.  I know that you can actually make your site more useful and usable to me if I do give you those details, I just was not ready yet.

I suggest that you remind me occasionally.  Perhaps every second or third time I sign in, put a little reminder message on my landing-page, and ask me to fill in one specific piece of missing data.  And make it dead easy for me to do so, either by linking to my profile-management page, or by placing a relevant edit-field right there on the page.  Don't get tiresome by nagging me every time.

And while we're talking about reminders, if you're running any kind of email service, do remind me that I am subscribed, together with my subscription details and your unsub-algorithm periodically -- not more than once a month, but not less than quarterly.  Perhaps in the form of a newsletter.  (You did get my explicit permission to send me email, didn't you?)

4.  Don't Make Me Sign In Again

I'm talking about the phase immediately after initial-sign-up.  I've made the emotional commitment (however small!) to sign-up with your site.  Don't immediately demand that I do more work by signing-in.  I've just told you all that stuff -- login-id, password (twice, no doubt) -- don't make me type it all in again.  You're just being tiresome.

What?  Did you think somebody may have hijacked my IP address in the intervening two second?  That some malware may have sucked your session cookie out of my browser for nefarious unpredictable purposes?  Get over it: you already know who I am (for some value of "know".)

And then, once I am "signed in", don't forget it. (Hello, Feedburner!)

5. Reciprocate My Trust


Having

1. signed-up for an account, possibly
2. jumping through the confirmation email hoop, and then
3. signed-in to that new account

Don't pretend you don't know me!  Don't present me with a page that says

Get an Account with Us!
Here is how:
Step #1: Create an account at Flibertigibbet.com
Step #2: Blah, blah, blah.
Step #3: Blah, blah, blah.

That's it!! What are you waiting for? Get major benefits, make money, win friends, influence millions! Create your account now!

Didn't I just do this?  Who are these idiots?
You just trashed my tentative trust in you.  Goodbye.

Great Tools, Great Times

Just as much as some software is a pain in the arse to work with (even though it may be totally essential) on the other side of the coin we discover things like the CSS editor in the Firefox/Web-Developer Toolbar!

Working on a significant look&feel upgrade for the farm website, I tripped across this thing today.  "Oh!" says Jason, "I've known about it for ages -- can't work without it.  I thought you knew..."  Well, call me Mr Slow...

Despite its few quirks and oddities, the ability to fiddle with CSS -- especially the somewhat complex CSS I'm working with, where there is a cascade of CSS files, each one overriding another -- and see the results as you type...

That rocks!

Software That Makes You Angry

Isn't it peculiar?  Some pieces of software are actually an almost physical pleasure to use.  Others make one actively angry.  Or is that just me?

I will refrain from mentioning a specific piece of software, here -- it would just be a distraction.  The software in question has been pissing me off the whole afternoon.  All I want is to make a simple change to some templates.  But it turns into a huge bloody performance: hoop jumping, contortions, hystrionics and hysterics, all resulting in a Resort to Strong Drink.

The software itself is not such a terrible piece of work.  In some places it is excellent, and the rest of it certainly gets the job done.  But the thing taken as a whole just makes me angry.  Microsoft Windows has much the same effect on me.

On the other side of the fence are pieces of software that just slide effortlessly into your life.  When you stop and bother to notice them, they're just... effortlessly there for you.  No muss, no fuss.  They just get out of your way and work.

So what's the key?  I would certainly only like to write the latter kind of software and avoid foisting the former on the world.  I think it boils down to "Do things my way or else" vs. "Let me serve you; here's what I do... I'll stay out of your face, now."

What software pisses you off?  What software do you love?

Vista Sound

Zoli has an entertaining little anecdote over on his blog about how users cannot disable the startup sound in the current (beta) release of Microsoft's Vista OS.

Funny, back in the days when I still had a Windows machine (around 5 years ago), I never could be bothered to figure my way through their twisty-little-maze of configuration dialogues-for-the-brain-dead to switch off the startup noise.  I used to just jump in and delete the damn media file.

So I guess there is a way to turn it off after all...