News apps tell stories. They’ve got much of the same structure as any news story. They’ve got the graphical equivalent of ledes and nut grafs. At their best, they help a reader to find their personal stories in a large data set and to understand the story you’ve reported using the example of themselves and their own community. A great news application lets a reader understand new concepts by relating them to their own experiences.
One of my friends shared this wonderful link about Simplicity on his Facebook profile. Here are the ten laws of simplicity by John Maeda.
- Reduce – The simplest way to achieve simplicity is through thoughtful reduction
- Organize – Organization makes a system of many appear fewer
- Saving Time – Savings in time feel like simplicity
- Learning – Knowledge makes everything simpler
- Differences – Simplicity and Complexity need each other
- Context – What lies in the periphery of simplicity is definitely not peripheral
- Emotions – More emotions are better than less
- Trust – In simplicity we trust
- Failure – Somethings can never be made simpler
- The One – Simplicity is about subtracting the obvious and adding the meaningful
- I do not understand 7. How can more emotions be better? Does this law contradict laws 1 and 10? This one certainly bears more thinking.
- In fact Edward De Bono, has an entire book on Simplicity. At the end of that book, I found that simplicity is not really simple to achieve. Achieving simplicity is a complex process. YOu need to strive hard for it.
Are these laws contextual? Do they apply only to design or to other problems as well? I guess I need to read the book to find out. Some thing tells me that I need to get back to this subject in more detail later.
In the Next Programming Skill You Should Learn, Scott Hackett talks about the ability to communicate well, especially in writing. I totally agree. The post is certainly worth a read.
An unexpected bonus in this post is Scott’s tips on the golden rule of documenting software design.
The golden rule of documenting software design
Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:
Describe your design to others as you would have others describe their design to you.
When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.
One of the experiments I am conducting with a set of interns is to make them write a LearnLog and ProjectLog – just a few bullets or short sentences. We do this in a wiki so that every one in the project has access to it. It is also one of the easiest and most effective ways to communicate asynchronously with the team.
In the Project Log, they are supposed to write the following:
- Design decisions
- Decision to use libraries/tools and why
- Problem areas and stumbling blocks and how they solved it
- A list of links to the resources they used
It is still an uphill battle but we are getting better gradually.