Hiltmon

On walkabout in life and technology

Learn to Automate

It’s been almost six months since the Codecademy launched learn to code in 2012, headlined by Mayor Bloomberg. Lots of people pledged, lots signed up.

And I’ll be flabbergasted if any of them are still doing it.

I’m not going to go into why having everybody learn to code is a bad thing in detail, Jeff Attwood nails that in Please Don’t Learn to Code. Short version, it puts the method before the problem, programmers like to solve problems and create solutions, and the tool they mostly use is code. We need problems solved and solutions, not more code.

But I was on a client site the other day and was shocked to see the amount of manual work performed by one member of the staff on their computer. Every day, without fail, they spend half an hour dragging and dropping files that are delivered electronically into one folder to other folders, where they are then used by other systems and staff. If they fail to drag and drop these files, the entire business process fails. If they are sick, no-one knows where each file needs to go, so this poor employee has to work every day to keep the business running (or login remotely).

I could not stand for this, I believe in the Hiltmonism - Automate or Die!. So I stepped in and wrote a few ruby scripts in a few minutes that are scheduled to run on his PC every day and do this work for him. The scripts are less than 10 LOC (lines of code) each, and Windows Scheduled Tasks takes care of the rest (this user just leaves his PC on). With a few lines of scripted code, I just saved this person hours of drudge a week and documented where each file needs to go in code. And they can go on vacation knowing the work will still get done.

Wouldn’t it be nice if this user could create their own automations? If they could do this themselves. If they learned to code, they probably could do it. If they could even identify the problem and formulate a solution. If they could then logically write the script. If they could test it and set it up as a scheduled task. If, if, if!

But coding is too hard. Critical problem solving is hard. Logic is hard. Applying process is hard. Just getting something done is easy. And probably provides some kind of comfort and job security.

Maybe something like Apple’s Automator would work for this person. It’s a great idea, a visual way to script, but it’s not available on Windows. And most users don’t know that this exists anyway.

So, instead of using your geek friends to fix your printer or tell you what next PC to buy (which is why they hate you), pay them a few hours to watch you at work. Give them a problem to solve, what can be automated in your job. That’s why we are programmers, we love the challenge of solving real world problems. We may find nothing, we may be able to script a portion of it quickly, or we may need more time to create a full-blown application. You have nothing to lose by seeing if some of your work can be automated, but man-years of your life to get back if some of it can.

There is no need to learn to code, but there is a need to automate. Either learn how to do that yourself, or hire someone to make it happen. Automation scripts are easy for us geeks to write, they are reliable, flexible, cheap, document institutional knowledge, and free people up to work on what they should be working on. And they do what computers are good at, drudge work without complaints or sick days.

Markdown Metadata

As you all know, I write everything in Markdown, see my The Markdown Mindset. It would be nice, though, to also save metadata - information about the document - in the document, to make it searchable, but not to have it appear in the final output.

Turns out, MultiMarkdown (and other new Markdown processors) do support this. It’s easy.

Simply add the metadata to the top of a markdown file as follows:

1
2
3
4
5
6
7
8
9
Title:       |  
Subtitle:    |  
Project:     |  
Author:      Hilton Lipschitz  
Affiliation: Noverse LLC  
Web:         http://www.noverse.com  
Date:        June 18, 2012  

Your first paragraph starts here

The metadata is just a set of key-value pairs, where the key is before the : and the value after. The keys can be anything you want them to be, although Fletcher Penney, creator of MultiMarkdown, has recommended some standard ones here. From what I can tell, adding your own makes no difference. So I do.

Also:

  • It is recommended to end each line of the metadata with two spaces before the newline, so that older Markdown processors do not turn the metadata into a single line.
  • The metadata block ends with the first blank line.
  • You can have more than one value for a key on a new line, e.g. in my Call Note metadata header:
1
2
3
4
5
6
7
8
9
10
11
Called:         Donald  
In Conference:  Huey
                Duey
                Louis  
Project:        Fake Disney App
Author:         Hilton Lipschitz  
Affiliation:    Noverse LLC  
Web:            http://www.noverse.com  
Date:           June 11, 2012 16:48

Call notes start here

A search for called donald huey will find this document easily, even if Huey was quiet for the whole call and does not appear in the notes. Yet if I format this document for HTML or PDF using Marked, the metadata disappears. Just the way I want it.

I use this so much, I have TextExpander snippets that generate metadata block, fill in the dates for me, and place the cursor at the title line. Just New Document, type ;mmt (for MultiMarkdown Title) or ;mmc (for MultiMarkdown Call) and I have a new markdown document with the metadata block all set up and ready to go.

Unrepairable

Last week, Apple launched the new retina Macbook Pro. Which, of course, was immediately followed by a brouhaha (Definition: A noisy and overexcited critical response, display of interest, or trail of publicity.)

Kyle Wiens, who runs a web site called iFixit which creates videos for people who want to fix things, posted an article in Wired entitled The New MacBook Pro: Unfixable, Unhackable, Untenable claiming that the new laptop is unfixable by the general public, and that this is, of course, obviously “a very bad thing” and part of a trend that will destroy the tech industry as we know it.

Really? Destroy the tech industry? I totally disagree.

In of itself, it’s a good opinion story, although one should note that the expressor of the opinion is in the business of doing that which the laptop is not designed for. But what happened next was the the FUD (Fear, Uncertainty and Doubt) campaign was kicked off by others, (not worth reading):

So what’s this all about?

All this has happened before. All this will happen again.

Pythia Battlestar Galactica

Friends, this is a non-issue. All this has happened before in other product lines, even in this product market. And we have better, smaller, lighter, more reliable products as a result.

Let’s look at motor cars (or automobiles or horseless carriages). You could repair a car made in the 1960’s and even a few from the 1970’s. I even had the repair manual for my Datsun 1100, and did, in fact, perform several repairs on it. Cars of the day were mostly mechanical beasts held together with nuts and bolts. They were also noisy, rattled a lot, belched smoke and broke down every Thursday.

Modern cars have fuel injection, computers, hundreds of sensors, sealed engine compartments and warranties longer than the rust-free life of a 1960’s Datsun. They are like this because we consumers prefer reliable, safer, smarter, more fuel efficient, easier to drive cars. Which requires manufacturers to use higher tolerances and lots of computing power to achieve. And so the Sunday oil change and the Thursday tow-truck call joins buggy whips in the annals of history.

The same applies for any other home appliances, even dishwashers and clothes dryers are more computer than mechanical these days. Commonly repairable items from the past such as radios, video recorders and toasters are now microchip based. And even if we wanted to, these products are now too complex for us to understand, nevermind repair. They break, you get a new one, or you get a pro to repair it. But our TV’s and toasters work better, use less energy and last longer. Surely this is “a really good thing”.

99.9999% of people who had repairable items still used professional repair ships to do the work anyway. No-one likes the time when the thing is in the shop and unavailable for use. No, we want reliability, and sleekness, and lightness and all of these things in our commodity products. Which means that manufacturers need to use tighter tolerances, stronger fasteners, robotic soldering, flush mounted components and sealed compartments to achieve these goals. And home repairability goes by the wayside.

One could argue that repairability, or even upgradeability, may be something that a manufacturer wants to include in their product to satisfy the 0.0001% of people who like to tinker. But to do so, they need to introduce pluggable components, mounting screws, access panels and to create repair connection points between components. Each of these creates more points of failure, thereby reducing reliability, and increases the cost to manufacture and the size of the product (human fingers are huge). Which makes the product more expensive and less reliable. Not what we consumers want.

And this is not the first Apple product to be this way either. The iPod, the iPhone, the iPad, the Macbook Air, the Apple TV, the new iMacs, Time Capsule, and the latest Mac Mini’s are all the same. Sure, you can get replaceable parts from MacSales/OWC, but they had to reverse-engineer Apple’s design and build a whole set of tools to do it.

And how many non-geeks to you know that ever repaired their own laptop anyway. Or even upgraded the thing. I have purchased five laptops since 1998, and only once did I add RAM to one of them, and I’m a huge geek!

But the news and the pundits turned this non-issue into a big deal. “You should not buy the new laptop because it’s not repairable”, they scream. Sure, then you should not buy that new BMW, TV, fridge, toaster, phone, watch or any other appliance for the same reason. Sigh.

We have the most reliable, sleekest, most awesome products on the market today, and we should be happy to own them and enjoy them.

The Care and Feeding of Software Engineers

Nicholas C. Zakas (@slicknet), writing in NCZOnline in The care and feeding of software engineers (or, why engineers are grumpy), writes:

And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.

Anyone who has anything to do with software development should read this.

I Love My Lawyers

As an experienced indie running my own business, there are things I know I am good at, things I know I am passable at and things that I simply cannot do. And one thing I will not do is enter into an engagement without a good contract. And I cannot do contracts. So one of the first things I did when I set up Noverse was to find and engage the best lawyers I could find to take care of this for me.

I love my Contract

Before talking about the lawyers, I need to talk about why the contract is so important to my business.

Maybe there was a time when a steely gaze and a handshake was good enough to do business. But things are more complex now. We no longer live in the same village, the world is our village. We no longer have to deal with individuals, but with large groups of people called companies. And the law is no longer just the word of elders, it’s a complex and confusing morass of words.

It’s relatively easy to decide what needs to be done in an engagement, and who will do it, and who will pay what. These discussions start business deals. If all goes well, and all parties agree it went well, you could argue that a contract is not necessary. And you would be completely and utterly wrong!

I don’t really know what the legal definition is, but to me, the contract defines the relationships between and responsibilities of each party and what to do if anything goes wrong. From my side, the supplier, it defines what I will do, when I will do it, and what happens if I fail to deliver. From the client side, it defines what they will do, when they will do it, how much they will pay, when they will pay, and what happens if they do not live up to their end of the agreement.

In short, and in my opinion, a great contract is one which is easy to read, clearly describes what each party will do, defines how the business will work when all is well, and what to do when things go wrong. It’s all in the contract.

The realities of business, people, companies, software and change is that “No campaign plan survives first contact with the enemy” (Carl von Clausewitz). Maybe the supplier, me, cannot write the program needed, or the program does not work, or the program fails after a few weeks. What happens then? It’s in the contract. Maybe the client does not have the data needed, or their business needs change, or they wish to abandon the project. What happens then? Do I still get paid? It’s in the contract.

What I needed when I started my business was one of these magical contracts so that I could do my business. One that I can understand, one my clients can enjoy, one to be proud of.

Finding and engaging my Lawyers

So off to find a lawyer. Well, it’s not easy. You cannot walk into a store and compare them. You do not get a 30-day trial period. They do not come in a box with an instruction manual and a features comparison chart. And Yellow Pages ads are useless.

The best way to find a good lawyer is to use your network of business associates and friends to find people who use similar lawyers and gain their insights. If the same name starts popping up with positive reviews, then you’re on the right track. I found my tax guy that way, and he’s brilliant. Talk to other people who provide you services and get their recommendations. My tax guy recommended my lawyers.

The next step is to interview them. In my case, it was over the phone. You are going to get into a long term business relationship with your lawyers, it’s worth everybody’s time to have a good first discussion. What I really wanted out of this were answers to only two questions: can you write me a great contract (i.e. do you know what you are doing) and more importantly, can I trust you?

As to the first question, a good lawyer will explain the basics of contract law and relate some of the unique issues relating to software and consulting engagements (my kind of needs). They will patiently answer your questions. You may not understand all they say, I did not, but even a layperson can get a feel for bullshit vs brains, whether they are making a sales pitch or genuinely understanding the issues. My lawyer opened my eyes, question one answered.

The second one is important, the trust issue. Your lawyers are going to know all your business secrets, your client base, your payment schedules as well as your personal secrets, your strengths and weaknesses. You have to be able to comfortably share with them all these things and be confident that they will not breach that trust. Yes, I know all about the client confidentiality stuff based on TV law shows, but I think it’s important to trust them as people too. Another reason for the trust is that they are going to advise you and in some cases represent you and argue on your behalf (and boy do I need that). You need to trust that they will have your best interests at heart, both in advising you what is best to do and what is best not to do, and in representing you when needed. My lawyers did that.

Based on that first conversation, I realized that my lawyers knew exactly what I needed, both in terms of the contract, but also in terms of running my business and other related topics. Their other clients are like me, indies, creatives, software folks. This is what they do, and the passion for doing it right came across. And they took the time to talk with me, and it was a long talk.

So I engaged them. Over the phone and email. Most lawyers ask for payment up front, a retainer, and I sent it. I like that they were up-front about the cost, and about what services would be provided. I would worry if my lawyer ever told me they would do the work and bill me later, I’d fear that sticker shock. The retainer sets bounds, and the agreement that came with it was clear and understandable. Just great.

I love my Lawyers

So why do I love my lawyers?

Firstly, they made a great contract. I can read it and understand it. My clients have no problems doing the same and signing it. And the contract itself protects me and my clients properly and fairly. I can do business with it without fear.

Secondly, they give good advice, and they don’t let me make mistakes. I did a deal recently where, had I gone with the deal as originally presented, not so good for me. It was a good engagement, but the agreement was not so fair and balanced. My lawyers advised me on how to negotiate to fix and balance the agreement, and explained to me why these innocuous clauses in the original were bad for me. I even pushed back, I wanted the deal, and was prepared to unknowingly compromize my business. My lawyers did not allow that. They stood up and protected me, both from the bad deal and from myself.

And thirdly, there was a lawyer to lawyer discussion that needed to be held on another deal. A negotiation of sorts. One which I am completely unskilled at handling. I trusted them to do it and to do it right, for both me and the client. And they did it.

They write good contracts, they give good advice and they protect me. That’s what every indie business needs and that’s what I got. But I got a whole bunch more. They looked outside my direct needs and pointed out issues and areas that I needed to take care of that I did not know about. It’s that extra mile that they do not need to walk that puts them over the top.

One needs good lawyers to do business, lawyers you can communicate with, lawyers you can trust, lawyers who create the best agreements for you and lawyers who will back you up and go into battle for you when needed. If you don’t have them, find them and engage them today.

And all through this, I had not yet met my lawyers. Even though their offices are in walking distance, communication was always by phone or email. In fact, when I finally did meet them for the first time face-to-face, I did not recognize them, then I gave my lawyers hugs. It would be the understatement of the decade to say they were surprised, what kind of madman hugs their lawyers, but then they hugged me back.

In my case, my lawyers also happen to be amazingly nice people. FTW.

My WWDC 2012 Scorecard

I published my WWDC 2012 Keynote Predictions a few days ago, lets see how well I did:

  • Sales: [0/1] Instead of the boring “we sold a lot”, they went emotional, “we helped a lot”. Nice, but not worth the 10 minutes as it made them hurry the laptop announcements.
  • Hardware updates [2/4]
    • No Mac Pro updates (Correction, they did bump the Mac Pro, just silently, but not to the new E5 CPU’s)
    • Lovely Macbook Pro updates
    • Lovely Air updates
    • And the new Retina Macbook Pro (I was so wrong there)
  • OS X 10.8 Mountain Lion: [3/3] As expected, we got a release date, no radical new features (except dictation and power nap), and we did get Facebook.
  • iOS 6: [¾] Beta, check, new maps, check, updated Siri, check. Did not expect the nice updates to the phone app and the new passbook app, but these do seem incremental.
  • iCloud: [½] Expected more features and got them, shared photostream and cloud tabs stand out. But not all of MobileMe has been replaced.
  • Apple TV: [1/1] No mention, as expected
  • Apple applications: [2/3] Expected iCloud updates for iLife and iWork (actually was expecting new versions, but the updates are OK). Did not expect any Pro updates like Aperture.
  • Steve Jobs: [0/1] No mention
  • No “one more thing”: [1/1] Check

And on the meta:

  • Liveblogs: [0/1] Expected failure, they worked great.
  • Missing magical features: [1/1] Check, lots of complaints about no retina on the Air, no iPhones (duh!), no Siri SDK, no Apple TV.
  • Share Price Drops: [1/1] Check
  • Not as good as a Stevenote: [0/1] Crickets, phew, glad to be wrong about that one.

So all in all, out of a possible 24 points, I got 15 right. Pretty average for a set of uninformed keynote predictions.

The winning announcements:

  • The new retina MacBook Pro, I want one.
  • Retina versions of Photoshop and Aperture, just wow
  • Mountain Lion next month
  • iOS 6 maps look just lovely

Sandboxing and Productivity Utilities

Apple’s recent requirement for all App Store applications to be sandboxed has led to a problem for us pro users, many of our magical productivity utilities will no longer work. And if you think that’s a problem for us, imagine how the developers feel.

Er, Sandboxing?

Sandboxing is a computer security term for separating running programs so that they can only access a limited set of files and resources on your computer and not interfere with other programs and files. The idea is that each program requests access to only those things it needs to do, and the operating system ensures that the program cannot access anything else. So a sandboxed application may not have access to the network, or it can only access it’s own files.

If a sandboxed app gets hacked, you, the user are safe. The worst a hacked sandboxed app can do is access its own stuff, leaving the rest of your computer and data safe.

Sounds good, so what’s the problem?

The key problems with Apple’s implementation of Sandboxing are the lack of any option to enable interconnect with other applications, and a ban on cross application scripting.

Lets look at each.

I use Moom to help manage and arrange my windows because I am still a spatial user. Moom works by adding a menu to the green “traffic light” button on each window, offering the user a menu to resize the window. But Moom also allows me to press a key combination, and rearrange a set of windows. In order to work, Moom needs to integrate with all running windows to move and resize them. This behavior is not allowed by sandboxing, nor is there any ‘permission’ available to get this to work. Moom cannot be sandboxed.

In the case of scripting, well, I use a combination of Keyboard Maestro macros and Alfred scripts to automate many common actions that save me a lot of time every day. Since sandboxed applications cannot script the behavior of other applications, neither of these can be sandboxed either.

From App Store to direct

This does not mean that Moom, Keyboard Maestro and Alfred are going away, just that their App Store versions may. The problem is, how does one convert from an App Store version of an application to a direct version, without having to pay for the application again?

The ManyTricks team have come up with a very elegant solution for Moom 3. If you have Moom 2 from the App Store, just directly download and install Moom 3 and it detects that you used to have the App Store version, and licenses itself. What a brilliant idea. And if anyone in the future buys the old version on the App Store, on first launch, it tells you how to upgrade. The only negative is that these App Store users remain anonymous. I just went and bought another license directly, because I want them to know I am a happy customer.

Alfred takes a different tack. The core product, available on the App Store, can work under sandboxing for search and opening files. But the scripting support is unavailable. They offer a powerpack which requires a direct download, and replaces the App Store version. Since this is a direct copy, it’s not sandboxed and scripting works.

How bad is it

It’s not that bad. For the majority of users, especially non-pro users, sandboxing is a good thing. Apps cannot get malicious on them. And they do not really use these productivity tools anyway.

For us pro’s, we can get what we need directly, so that’s not an issue. The only thing we miss out on at the moment is iCloud synching (but Dropbox does a good enough job). Who knows what we may miss out on in the future though.

But right now, I commend the makers of my favorite productivity utilities for their ingenious solutions to finding ways to migrate anonymous App Store users into direct users without paying again.

My WWDC 2012 Predictions

After writing Annual Apple WWDC Disappointment, several people have asked me what I do expect at the WWDC 2012 keynote, ignoring the rumors. So here it is, my WWDC 2012 keynote predictions, what I think in my opinion, without rumor or factual basis, will be covered at the WWDC 2012 keynote on Monday:

  • Sales: Apple has had its best year ever, and Tim Cook will enjoy sharing the numbers. And he should!
  • OS X 10.8 Mountain Lion: We’ll get a clearer release date and a top 10 new feature demo. At least 8 will be features we already know, and one will be a lot more on the Messages app. Maybe a new developer beta, but it’s not ready yet.
  • iOS 6: The next iOS will be announced, without a release date (so that they can do it with the next iPhone), but us developers can get started developing for it. I do expect new maps, new background process options, and a new version of Siri. But after the US 4G marketing bungle, I expect the next iOS and iPhone to be a more world phone than a US one and so the next iOS update will be incremental software, not radically new.
  • iCloud: It was announced last year, it will get more features this year. Now that MobileMe is gone, I expect iCloud to take on some of its features, such as photo galleries and maybe personal web hosting. But more, I expect that iCloud synching will just work better.
  • Apple TV: Nothing new here, it was updated recently.
  • Apple applications: I expect new versions of the iLife and iWork suites. Neither has been updated in ages (iWork was in January ‘09), and all would work better with iCloud (Their iOS versions already do). I do not expect any of the Pro applications to be updated, they’ll save that for another event.
  • Hardware updates: I expect Mac Pro updates as we developers love our Mac Pro’s (see my The Last of the Workstations). And probably a 15" MacBook Pro update. But no laptop retina displays (or it’s going to cost me!).
  • Steve Jobs: It’s been 9 months, and I think Apple will spend a small amount of WWDC keynote time just remembering him. And this will be the last time they bring Steve Jobs up in public.
  • No “one more thing”: That’s it, no new product lines, no TV, just good old operating system and developer updates.

I also predict:

  • Having a hard time following the liveblogs as the event’s networks fail. And watching the event video Monday evening to see what I missed.
  • A large number of articles to be written on how disappointed people are in Apple’s announcements because they did not release insert magical made up feature here. Or that this insert same magical made up feature here was pulled at the last moment because it was not ready, so the made up sources did not lie.
  • The share price to drop, because it always does.
  • A bunch of blowhards saying how Steve Jobs did a much better keynote than Tim Cook, ignoring the fact that the last few keynotes were the Scott Forstall and Phil Schiller show as well, with Jobs as MC.

In the mean time, I’ll be ensconced in front of all my monitors from 1PM EST on Monday hanging on to every liveblog and tweet. Don’t call, don’t write.

And maybe, just maybe, Apple does have a surprise or two up their secretive sleeves. Wouldn’t that be fun.

Hiltmonism - No More Than Five

We’ve all seen those interfaces: Internet Explorer windows with racks upon racks of toolbars, forms with hundreds of fields to fill in or applications with menus that run off the bottom of the screen, or worse, have unending levels of sub-menus. They are confusing, messy, hard to use and even harder to navigate.

This Hiltmonism is simple. One, there shall be no more than five things on an interface element. Ever! No more than five fields in a form section, no more than 5 menu items in a menu section, no more than five things in a toolbar segment, no more than 5 tabs on screen.

Two, there shall be no more than five elements. No more than 5 sections on a form, no more than 5 menu blocks, no more than 5 segments on a toolbar.

And three, there shall be no more than five of anything. If you application is complex, break it down into no more than 5 main areas, break those into no more than 5 sub-areas, and then separate them visually.

And if in doubt, or impossible to remain at five, you can grow to a maximum of seven. But no more. I will come to your house if you do.

Why 5 with a maximum of 7?

It really starts with a seminal psychology paper by George A. Miller of Harvard University, written in 1956 and originally published in Psychological Review in 1963, entitled “The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information”. (References: The article or Wikipedia).

In short, Miller’s experiments proved that the average person can hold 7 plus or minus 2 objects in working memory at one time.

The outcome of his research and those that followed (especially about the magical number 4 in “The magical number 4 in short-term memory: A reconsideration of mental storage capacity”, Cowan and Nelson, Behavioral and Brain Sciences) can be seen everywhere in everyday life. Phone numbers in the USA are seven digits because of this. And when area codes were added and became too long, parentheses and hyphens were added to break them up into several objects as they are easier to read and remember. (212) 555-1212 are three objects to remember instead of 2 1 2 5 5 5 1 2 1 2, a stream of 10 digit objects. The same applies to license plates, social security numbers and credit card numbers.

And in software? It’s the same. Users cannot remember how to use software when there are hundreds of buttons to push and hundreds of menus to click. So they don’t use all the features of the product, or worse, workaround the features of the product that exist but are too hard to find. No matter how good your documentation and training is, the cognitive overload wins, people forget or cannot find functionality.

If you want to make a product that is easy to learn, easy to use and delivers a great experience, you need to reduce the cognitive load. No more than five. Users can remember and navigate five to seven menus, users are happy with a few pertinent buttons or toolbar items, and users can easily understand the purpose of small forms.

If you follow this Hiltmonism, you will create simple, focussed and very functional applications.

But that’s not possible!

Ahh, but what about massive ERP (Enterprise Resource Planning) systems like SAP, or complex professional graphics programs like Photoshop, or something that has a lot of features like Excel? It’s not possible to do this?

Actually it is, and SAP, Adobe and Microsoft have done amazing things to try to get to a “no more than five” rule, often getting it down to seven or eight, but they still have a long way to go. The ribbon interface is a good start, replacing too many toolbars, but still to busy. SAP’s module breakdown and navigation systems have been cut to the bone, and Photoshop’s menu madness is slowly coming under control. But these are professional grade applications for professional grade people, people who are prepared to deal with complexity.

For regular folks, there are products just as functional with far simpler interfaces. Compare Excel (top) to Numbers (bottom), Excel has a heap of buttons on the toolbar, Numbers only has a few, it’s simpler, more focussed and easier to use:

Or compare Photoshop (dark window chrome) to Acorn (light windows chrome), Acorn has a far more compact and simple interface, yet can do a lot of what the complex Photoshop interface does and with a lot less effort:

Some rules to help

If it can be done, then how can it be done? Here are a few rules to help you get to the “no more than five” rule:

  • Create what is needed, and no more. Build software that meets the needs of your clients, and forget the rest. Don’t add features and functions because they want - but will never use - them. Don’t add features just in case a future feature may be needed.
  • Show the frequently-used stuff, hide the rest. Figure out the things that will be clicked on the most and make them prominent, and hide the rest. Professional users who need these other features will find them and remember them, but most of your users will stick to the common stuff.
  • Make decisions and prioritize for your users. Decide what and how things need to be done, don’t make users decide each time. And if there are different flows, enable them in preferences so the default flow happens automatically. Then prioritize the data needed, placing the highest priority functions and data fields at the top of screens. Hide the low priority stuff, or even better, place it elsewhere or get rid of it.
  • Break things up into logical components, and then fence them in. Editing and formatting a document are two different things, which is why most operating systems separate the edit and format menus. In your application, break it up into components, and then, when a user is interacting with one of these components, only show them the functions for that component. They can navigate to another component if they want.
  • Actions go with data, and nowhere else. Display the things a user can do with a piece of data, ways to navigate to other areas in the system and nothing else. When working with data, show the user what they can do with that data and only that data. Let them navigate to other data if they want, and see the other data’s actions, do not clutter the interface with actions on other data.
  • Prune the tree. Business changes, needs change, and your application should change with it. When a function is no longer being used, or no longer a priority, move it, hide it or prune it. Be ruthless. You used to need a field and now you don’t, hide it. If you need to go back in time, the data is still in the database.

And the benefits?

So why follow this advice? Well:

  • Navigation is easier. Users can choose the area they need to work in, and go there first. We’re all very good at navigating a simple landscape with a few landmarks and we’re all good at working on a task by task basis. We’re not good at making up a workflow as we go in a featureless landscape.
  • People can work faster. Smaller forms, limited actions and focus means that users make fewer decisions while using the software, and fewer decisions mean that they can be more productive with it.
  • Easier to learn. A simpler navigation structure and focussed actions means user can pick up and “get” the software in less time. It’s less imposing if there are only a few things on the screen to do.
  • Better clarity, reduced click fear. With fewer things on the screen, you can make those few things more clear, even more verbose, to help users understand what is happening or will happen when they click. No more needs for your own home-grown abbreviations or terminology to squeeze yet another field in, when good plain english will do. When people understand what is going on, they find it easier to use, they have less click fear - the fear of clicking on the wrong thing and messing things up.

Really, there’s no excuse

A lot of applications, especially internally developed corporate systems, are a confusing mess of buttons, menus and large complex forms. Their users are unhappy, befuddled, and unproductive. The most common excuse for this is that there is no time for IT to “fix” it, so they just add another menu, field, button or report name and move on, increasing the messiness of the system.

That excuse is lame and lazy. It takes no time at all to break a complex form up into sections. It takes no time at all to see which fields are never filled in and to hide them. And it takes no time at all to start cleaning the mess up.

The second most common excuse is that there is no architect to manage the structure of the system and to decide what goes where, what gets split and what gets pruned. Sure there is, every time. These people are called “managers” and it’s their job. They need to know what is used and what is not, they already decide what gets changed, ipso facto, they manage the structure of the system. Make them responsible for this.

No more than five

So next time you develop an application, or change your current one, start by counting the on screen elements. If there are more than five, then redesign, break things up or prune. It makes the application simpler, clearer, more focussed and easier to use. And your users will love it a whole lot more.