COMMENTS
Actually our message is that less is less. It's not less is more because that implies more is better. Less is less and we believe less is just enough for most folks.
"Less features" doesn't make any sense. "Fewer features" makes sense.
First things first:
Nice site you have here, I've recently added it to my feeds, and I'm impressed at the quality of the writing. Keep up the good work.
As for this post, although I'll concede that you may have a point overall, I think you're misunderstanding the specific example you use.
The power in letting people solve their own problems is that they will undoubtedly solve them in their own ways, sometimes in ways that simply cannot be anticipated by the designer/developer.
For example, I recently heard of a university campus that was designed and built from the ground up. The designers completed all the buildings, and conveniently "forgot" to build any sidewalks between structures.
Why would they do this? Because once the campus had been used for a semester, where the sidewalks need to be was crystal clear - the users had decided that for them!
I take 37s advice the same way. If you view a piece of software as adaptable and open to change, sometimes it's best to let the users themselves show you where you build paths, and where not to.
Several points:
1) "Less is less and we believe less is just enough for most folks."- Looking at the word processor example, are you prescribing that students, doctors, journalists, and lawyers aren't a significant portion of the population (one could argue there are a number of other professions that require some features such as footnotes, formatting, etc.). Now there are some great examples that aren't as applicable to a wide population (mathematical formula formatting such as the niceties in TeX).
2) "For example, I recently heard of a university campus that was designed and built from the ground up. The designers completed all the buildings, and conveniently "forgot" to build any sidewalks between structures." - A number of the older "state colleges" were actually built this way. I know Michigan State was and I believe Penn State was as well.
3) "I take 37s advice the same way. If you view a piece of software as adaptable and open to change, sometimes it's best to let the users themselves show you where you build paths, and where not to." - With decently established problem domains what is the point of re-establishing some of the known issues? Again, look at the word processor example. There's a world of difference between a text editor and a word processor. I believe in using the proper tools for the proper job. It's not to say one can't get creative and get around 80 - 95% of the issues by using a similar tool.
It gets to the point Jason / folks bring up about the build half a product vs. a half - ass product. There are certain areas where "simple" doesn't cut it, as artificial complexity exists. Another good example would be tax software. Tax code is totally complex and sucky. Are there ways things can be simplified on the interface end to make it easier to get taxes done? Of course. But there are so many rules and conditions that one can not "simply" build something for it.
The todo list software is a taster for a paid, hosted project management and time tracking package called Basecamp.
I haven't used Ta-da List in a while, but from what I remember it was two parts Basecamp ad, one part Rails tech demo.
Why not create three different Words for various sets of users? It's sometimes easy to hurt yourself with a pocket-knife.
"Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. "
Yes that's right... you make $1 solving the simple problems, the guy who solves the nasty problems makes $1million.
Anyone heard of the term "Barrier to Entry?"
"Yes that's right... you make $1 solving the simple problems, the guy who solves the nasty problems makes $1million."
It's partially a question of scale and market though. If you can sell something for 20 or 30 bucks a pop to a million people vs. something for a million bucks a pop to 5 corporations...
37S is taking the old Unix approach: a single application for a single task.
This works when your applications have a small or limited scope (eg: del.icio.us, Ta-da, Flickr) but doesn't when you're editing images, creating a spreadsheet, or doing 3D modeling.
So while 37S isn't making a false assertion, they are making a misleading one; it only applies under a strict set of circumstances and therefore becomes much less useful on any sort of reflection.
PS: Why not have different versions of MS Word for each market? That's a development, resource, marketing, and QA nightmare. Just look at Vista.
i agree.
you might find some of the things I've written on this topic of interest:
Sketching on Simplicity As Qualitative Perceptual Concept
http://explorerstreet.blogspot.com/2005/11/sketching-on-simplicity-as-qualitative.html
Notes on What Qualitative Perceptual Concepts Are
http://explorerstreet.blogspot.com/2005/11/notes-on-what-qualitative-perceptual.html
Complexity as Qualitative Perceptual Concept
http://explorerstreet.blogspot.com/2005/12/complexity-as-qualitative-perceptual.html
Quick Drafting on Tradeoffs Between Local and Global Simplicity/Complexity
http://explorerstreet.blogspot.com/2006/03/quick-drafting-on-tradeoffs-between.html
Factors in Tool Complexity/Simplicity: Viewing Value as Additive
http://explorerstreet.blogspot.com/2006/03/factors-in-tool-complexitysimplicity.html
Factors in Tool Complexity/Simplicity: Vertical- and Horizontal- Features
http://explorerstreet.blogspot.com/2006/03/factors-in-tool-complexitysimplicity_31.html
Initial- and Standing- Simplicity/Complexity
http://explorerstreet.blogspot.com/2006/03/initial-and-standing.html
You might also be interested to see this comment by Linus Torvalds on this matter of oversimplification:
http://lists.osdl.org/pipermail/desktop_architects/2005-December/000390.html
Thanks to everyone (especially Jason) for taking the time to comment. Will read through them and plan on a follow-up post.
Don't want to try and respond via comments as this will sound like I'm being defensive.
Good discussion.
Fields definitely asked for in a task/todo listing interface by ALL of our customers.
Date Due
Assigned To
Task
Priority
Anything less than that and it'd have little or no value to them. Just my 2¢
Poignant article. Thanks!
Bert
I just want to say that I fully believed "less was more" until my lab reports started to demand tables and graphs ...
I agree with you so does this guy. Also I for one would like to see you defend your position.
http://www.doc.ic.ac.uk/~mml/feast2/papers/pdf/556.pdf
summarized below
I - Continuing Change
An E-type program that is used must be continually adapted else it becomes progressively less
satisfactory.
II - Increasing Complexity:
As a program is evolved its complexity increases unless work is done to maintain or reduce it.
III Self Regulation
The program evolution process is self regulating with close to normal distribution of
measures of product and process attributes.
IV - Conservation of Organisational Stability (invariant work rate)
The average effective global activity rate on an evolving system is invariant over the product
life time.
V-Conservation of Familiarity
During the active life of an evolving program, the content of successive releases is
statistically invariant.
VI - Continuing Growth
Functional content of a program must be continually increased to maintain user satisfaction
over its lifetime.
VII - Declining Quality
E-type programs will be perceived as of declining quality unless rigorously maintained and
adapted to a changing operational environment.
VIII - Feedback System
E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must
be treated as such to be successfully modified or improved
I would agree with you Dharmesh. Overall, I'm a fan of the work that 37S do, but what grates with me is that they think that everyone can work their way - ergo, everyone else works the wrong way.
Their tools, and way they work, works for them *in their specific problem domain*. This works fine for a bunch of guys hacking out code, satisfying 80% of people. Heck, I bet they're making a good living out of it. But for those of us that have to satisfy 100% of our customer's needs, many Getting Real concepts fall down.
I'm all for keeping things simple - it's the backbone of how I work, but sometimes, 'less' just means a p*ssed off customer. I wish I had the liberty to pcik and choose my customers as freely as 37s, but alas, I don't. Still, I manage to make a good living too.
I can understand both viewpoints. I like simplicity but applications that lack certain functionality are also very frustrating.
For example, I use a particular text editor because of its interface and it has some handy features that I haven't found in any other editor. However, it's find and replace is terrible complicated and I haven't been able to use it reliably. SO, I have a different editor with a simpler find and replace that I use specifically for that purpose. That's pretty lame. When all the other features are so well executed, is a decent find and replace too much to ask?
As far as Word goes. I find it overly complicated for what I use it for. I also dislike its auto-formatting habits. Anyhow, I can understand that different groups may have totally different uses for that product and require totally different features. Why not show/hide menus/features based on user types.
Some Macromedia products such as Dreamweaver do this when you first install them. I'm assuming they researched this ahead of time but they divided their user base up into camps such as developers, graphic designers, etc. When you install, they ask you to choose a specific purpose that then customizes menus/features for that use. At any time you can go back and change your prefence but it simplifies menus into those tasks that they deem most useful to each group.
How hard would it be for other applications to follow their lead?
Looking solely at the complexity of a program is not a good way to measure how good it is.
First, complexity can be hidden from the user, which reduces (initial) user-shock, but makes the program unnecessarily difficult to use at an advanced level.
Second, there is such a thing as inescapable complexity and at a certain point a line must be drawn for minimum competency. If that line is drawn too soon, the program will not be powerful enough to solve the inescapable complexity.
Therefore, the best programs are those with an interface that approaches a 1:1 relationship with the complexity of the problem domain. The biggest challenge for a good developer is to not accidentally (or carelessly) butcher the hierarchy of the domain. If the hierarchy is properly preserved, the user will know what must be done without reading a manual.
"It's partially a question of scale and market though. If you can sell something for 20 or 30 bucks a pop to a million people vs. something for a million bucks a pop to 5 corporations..."
Perhaps you misunderstood me. I was referring to total revenue of $1 vs. $1mil.
Consider the barrier to entry concept. If the idea and the implementation are simple enough for anyone to copy... then your less really amounts to less $ in your pocket.
Apologies. I misunderstood the point of your original post.
"Consider the barrier to entry concept. If the idea and the implementation are simple enough for anyone to copy... then your less really amounts to less $ in your pocket."
Well...then it becomes a question of market share, commoditization, etc. (typical Porter fare). By your argument, no one should be making / selling commodities as other people do as well.
I agree. Ta-Da list is a good example. It's the most worthless app that I have ever seen even though I love 37signals approach to web development.
The message I am taking from the book is this:
Focus on a niche. Focus on what you are good at and
Do it well... really well.
Don't try to do everything and diffuse your focus.
The key is to be THE BEST and the truth is that
you CANNOT be the BEST at everything.
This philosophy should apply not only to the applications we write but also to our lives.
You can always expand and grow once you have established yourself.
Best wishes,
Hari
That's a great point. Having a niche is essential to getting off the ground. It's much easier to get (and show) "traction" in a niche.
Guy Kawasaki would agree with you completely. His term for it is "Niche Thyself".
I am a big believer in focusing on a niche market (see earlier post called "Risks of The Mega Market". I am not suggesting that companies try to do "more" in the sense that they focus on larger markets -- quite the opposite.
This article is intended to address something different: After you have picked a niche, it is important to deliver the functionality that customers want/expect and to grow the product within that niche.
There is a tactical sales element to all of this. What makes sales work for software products (particularly those sold to an enterprise-level market) is that the product or service solves a problem that is critical to the customer. This is true for markets/niches/customers of any size. If your product doesn't meet this test, it will be seen as nice to have or interesting technology, but not as an absolutely necessary purchase. In today's market, nice to haves and interesting technology aren't competitive beyond the visionary customer stage. It may be that 37signals meets this test in their target market - if so, no argument from me.
Build Opinionated software:
Do a small thing really well. Not too many things poor. There should be atleast 2-3 reasons for including a feature. If it is a word application, give a plugin for customizability. Someone else is probably better equipped to handle customizability for journalists. Someone else for mathematicians.
Examples of poor features on this site:
* posting comment on this blog needs email. Why?
* URL doesnt show up as link in the comment. So why ask for it at all?
* On Firefox, right click on Article Navigator doesnt work as expected. Why build an another thing, for which simple solutions exist?
Amit,
Good points. Will take a look at the issues and make the appropriate changes in the next version.
Thanks for pointing them out. You're experiencing a "work in progress", so apologies for the issues.
Make sure you judge the Get Real book for what it is: a manifesto for the web applications development.
Here is my take:
http://blog.startup.gr/blog/_archives/2006/5/5/1934407.html
Of course less is more. But we are talking more about the focus beyond that of a single tangible "thing".
Think of a horror movie, where you see the monster and are able to see it's just a guy in a suit. Boring!
Now think of a horror movie where you see fleeting glances of the monster, you get to fear it.
Less is more - of an experience. Experience is life, not a feature. Any dolt who's been anywhere near a design class knows less is more, form follows function, etc. Unfortunately egotistical developers developers developers who get treated like rock stars start believing they are rock stars and pump out complete shit and demanding riders.
Why re-invent the wheel? Why try to hijack the meaning of the design classic "less is more"? Go to art school, or leave design to the designers.
Excellent article. The recurring problem is that when engineers add power (capability) to software they usually burden the user with increased complexity. ("oh, you want to schedule your FTP uploads? I have time to create the feature but not to make the *interface* as simple as possible).
Therefore, users often associate "increased capability" with "increased complexity of the interface".
As MS's head reasearcher ( Nathan Meyrhold?) said "it take a lot of effor to make things simple").
So, when the user asks for "simplicity" they rarely mean "less capability" but, rather, "make it easier to use". It's all the little things that help that: I'm using FogBugz right now and when I open a new Case and report the version # where the problem was found and then open another Case, it fills in the previously used version number. That's extra capability that makes the software EASIER to use.
It IS possible to add capability while making the software eaiser to use. But that is, as the mathematicians say, " a non trivial problem". But that's what usability is all about.
I have used a 37signals product as a paying customer as well. An inspiring user experience but I quickly found some limits or rather found myself looking for features that weren't there.
Photoshop is feature-rich, has a learning curve, and it doesn't try to think for you. No instant gratification here. Just long-term utility and value.
I believe there's a happy medium somewhere between the "less is more" trend of lightweight, agile-but-specific SAASs and the utility of something that provides almost innumerable common, non-specific functions to create long-term application value the way Photoshop has for me as a designer.
I definitely believe in less is more.
Here's why: http://www.devamigo.com/?p=8
37S are targeting a niche market...there are a lot of users out there who have had enough of using the convoluted systems and 37S's apps are basically a breath of fresh air in the clutter. You do not have to become the next Facebook or Google to be successful...targeting a niche market and managing your customers' expectations would make you successful as well and that is what I believe 37S are doing...and doing it well.
Ironically I quoted the same passage today in my blog about opinionated software, AND included an example of
how Facebook is needlessly complicating a particular piece of UI in the minifeed.
Complicated UI invariably makes a programmer feel good about their accomplishments, but the same can't be said for how useful the software is.
Good design is about making smart decisions for the user so you DON'T have to make choices. Amount of choice correlates positively with functionality and complexity. So ultimately, 37signals is taking away choice but increasing value.