All software really should statisfy these characteristics.
It might be a bit pretentious but I’m not talking about us or how Soocial will be. Ok, I do hope Soocial will live up to this title, but I just came across a number of articles that made me think about how software should aim for these goals.
How often do you have the feeling when software breaks that it was your fault? That you just didn’t use it right? As developers most of us are NOT stupid, still often software leaves us in the dark. So often I hear people apologize for taking an action a software UI doesn’t get. A user thinking he is stupid is looking at it backwards.
Program code done right combines the beauty and expression of mathematics with aesthetics in (UI and program) design with a practical goal to provide real value to it’s eventual consumers.
There are so many levels of design (information architecture, interaction, data & database, Graphics & UI etc.), often it’s hard for a developer to jump between the various levels of abstraction to get the design right. However if we get the approach right, understand the complexity of our tools and work hard to make things simpler the end result can be very elegant. Usually this takes much thought, refactoring and patience.
All software really should statisfy these characteristics.
It might be a bit pretentious but I’m not talking about us or how Soocial will be. Ok, I do hope Soocial will live up to this title, but I just came across a number of articles that made me think about how software should aim for these goals.
How often do you have the feeling when software breaks that it was your fault? That you just didn’t use it right? As developers most of us are NOT stupid, still often software leaves us in the dark. So often I hear people apologize for taking an action a software UI doesn’t get. A user thinking he is stupid is looking at it backwards.
Program code done right combines the beauty and expression of mathematics with aesthetics in (UI and program) design with a practical goal to provide real value to it’s eventual consumers.
There are so many levels of design (information architecture, interaction, data & database, Graphics & UI etc.), often it’s hard for a developer to jump between the various levels of abstraction to get the design right. However if we get the approach right, understand the complexity of our tools and work hard to make things simpler the end result can be very elegant. Usually this takes much thought, refactoring and patience.
As Bjarne Stroustrup mentions:
“Elegance is essential, but how do you measure elegance? The lowest number of characters to express the solution to a problem? I think we should look for elegance in the applications built, rather than in the languages themselves. It would be a stretch to call a carpenter’s complicated set of tools (many quite dangerous) elegant. On the other hand, my dining-room table and chairs are elegant–beautiful, really. That said, it would of course be best if the language itself was a beautiful work of art.”
No pain no gain
A friend recently mentioned that if we as developers can relieve our users of pain we should be prepared to pay the price, even if that means we must refactor for twice as long, have to delve into AI tactics or get a third party involved. Of course the end result will always determine if we have succeeded but we need to try if we even want to have a chance at succeeding. As Johan Cruyff says: “To score you must shoot at the goal, to shoot at the goal you must have the ball, to have to ball you must run to get it”. (or something similar, but you get the point).
As far as relieving pain goes, one philosophy I like is to avoid preferences as much as possible. It means we as developers must take on our responsibilities, by not sticking every (program) design choice in a preferences or user settings. We must have the guts to choose ourselves, that’s called designing, it’s our job. Read this book for more on killing preference, its genius. The less a user has to think about using your software the better it is. Let them ‘just use it’. Our grand master has some things to say about the new UI paradigm used in MS Office 12:
The next version of Microsoft Office will be based on a new interaction paradigm called the results-oriented user interface. As the demos show, the most obvious departure from the past is that menus and toolbars are all but wiped out. The focus is now on letting users specify the results they want, rather than focusing on the primitive operations required to reach their goals.
So the simplicity of this approach is to only show relevant UI elements to the user.
No guts, no glory
This takes guts because when users sees a limited set of functionalities, we think they’ll think “Is this all it can do?”. In reality they think: “Oh wow, is it that simple. I must be smart.” And that is a good thing.
