Defining “simple” really depends on your target audience. What is simple to me might not be simple to my mother, or my friends. Also, when I create something, it’s always relatively “simple” to me, because I understand it inside and out. But to somebody who’s never seen it before, it might be very complicated.
This is why in VCI I put a big, obvious section of documentation near the top called “New To VCI?” And then it contains some simple, obvious steps to take. It’s written as if the reader knows nothing about VCI, because if you’re new to something, you probably don’t know anything about it.
I see way too many software projects mess this up. You go to read the documentation, and you’re presented with a huge mass of links and no direction. This is simple to the long-time developer of the project, because a page with lots of links lets that developer quickly go to the part they’re looking for. But for the new person, it’s complicated. On the other hand, for the long-time developer, adding a page with big, simple buttons and eliminating that list of links would add to the complexity of his task, because he’s just trying to find a very specific thing very fast in the documentation.
The only thing worse than complex documentation is no documentation, where you’re just expected to figure it out for yourself or “already know.” To the developer, the way his program works is obvious, but to the new user, it’s totally unknown.
With software, there are all sorts of different viewpoints. Just a few would be: Programmer, QA Engineer, Manager, Support Technician, User, Power User–to all of these people, “simple” will be different.
Context has a lot to do with this too. For example, in the context of a program, object-oriented architectures usually lead to simplicity, if done right. But imagine displaying that structure directly on a web page as the only interface to your program! That wouldn’t be that simple in that context, even if you were the developer!
You can be a little less bad than that, and still be complex. Some programmers design their user interfaces in a way that’s very closely tied to the backend architecture of the program. There’s three fields in the database, so they display three fields on the page, even if, for the user, one field containing three values would be simpler. This is “simple” to the developer, because (a) it’s easy to write and (b) it closely maps to how he or she imagines the program working internally. But when you go and try to actually use the program, it would be simpler for everybody if it was all just one field instead of three. (A classic example of this is how we display “status” and “resolution” as separate fields in Bugzilla’s user interface, when users couldn’t care less that they’re separate fields.)
Also, sometimes what seems complex is actually simple in the right context. On a billboard by the side of the road, a lot of explanatory text would be very complex! There’s just no time to read all that text, it would be stupid to put it there. But in a manual for a computer program, lots of text would probably be a lot simpler than just a one-sentence description of something. That’s why people don’t just write one-line blogs. It wouldn’t really be all that simple to just say something and then not give any description of it.
So…man! All these different viewpoints and contexts! Does this mean that simplicity is impossible, and that everything is hopeless? No! Not at all. 🙂 There are specific target audiences for everything, and the context of any indvidual thing you’re doing is usually pretty limited. The problem is always solvable. It’s just important to take these things into account, so that when your work comes out the other end and it’s actually being used by somebody, it really is simple for that person.