start-simple: Difference between revisions
| Line 2: | Line 2: | ||
One of several [[microformats]] [[principles]]. | One of several [[microformats]] [[principles]]. | ||
short url: ''' http:// | short url: '''http://tr.im/simple/''' | ||
== solve simpler problems first == | == solve simpler problems first == | ||
| Line 13: | Line 13: | ||
* '''specific problem.''' Look for a problem to solve in a specific real world domain, rather than a broad set of domains. | * '''specific problem.''' Look for a problem to solve in a specific real world domain, rather than a broad set of domains. | ||
* '''immediate problem.''' Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem. | * '''immediate problem.''' Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem. | ||
* '''80%''' of [[examples]] of behavior (not syntax). And even then, look at solving perhaps the 80% of instances of real world (see related principle: [[humans-first]]) uses of that specific problem rather than trying to solve 100% of such use-cases. | * '''80%''' of [[examples]] of behavior (not syntax). And even then, look at solving perhaps the 80% of instances of real world (see related principle: [[humans-first]]) uses of that specific problem rather than trying to solve 100% of such use-cases. | ||
== start with a simpler solution == | == start with a simpler solution == | ||
Revision as of 13:31, 17 September 2013
start as simple as possible
One of several microformats principles.
short url: http://tr.im/simple/
solve simpler problems first
Large problems can often be difficult to solve and seemingly require complex solutions. Instead start with:
- simpler problems. The first step to creating a simple solution is starting with simpler problems.
- parts of problems. Try to solve part of a larger problem rather than the entire problem.
- specific problem. Look for a problem to solve in a specific real world domain, rather than a broad set of domains.
- immediate problem. Prefer addressing an immediate problem over a (often simply hypothetically perceived) longer term problem.
- 80% of examples of behavior (not syntax). And even then, look at solving perhaps the 80% of instances of real world (see related principle: humans-first) uses of that specific problem rather than trying to solve 100% of such use-cases.
start with a simpler solution
Start with a simple solution with few features, rather than a complex solution with many features.
Often, the simplest possible solution turns out to be the most effective solution. No more work is needed.
When given the choice of two solutions to a problems, start with a simpler option, which can be accomplished effectively and immediately, and find any actual shortcomings from experience. Avoid starting with a more complex option which may a priori deem to solve conceptual or theoretical chimeras; possibilities that might have a general impact when implementing the solution, but then again might not.
minimal vocabulary
One way of keeping a solution simple is to minimize the vocabulary that the solution uses, and certainly of those, minimize any new vocabulary that are introduced.
Minimizing the vocabulary used for properties (and values) of a microformat helps keep the microformat easier to understand.
Minimizing the introduction of new vocabulary is particularly important. Doing so:
- Keeps microformats as a whole easier to understand (the smaller the total vocabulary of all microformats).
- Reduces confusion with the re-use of existing technologies. See minimal-vocabulary for more.
make evolutionary improvements
When any solution is designed and implemented, it is inevitable that some shortcomings will be found in practice.
It is better to find a few shortcomings, which can be addressed through iterative improvements, than find out that you have spent time designing features which few if anyone uses in practice (but may have already cost developers time to implement, nevermind the hours/days/weeks of design-time debate).
Microformats should remain as simple as possible for as long as possible, collecting additional element semantics only when a significant practical need has been demonstrated for such additions.
When such shortcomings/needs are found in practice, they should be documented, along with the practical instances.
If there are sufficient instances (say, near ~80% as mentioned previously), then add improvements that address the specific shortcoming (avoid the temptation to add more generic improvements unless a need is demonstrated for such a broader improvement), and iterate as necessary.
case study hAtom
- Atom specific person/author constructs were replaced by simple reuse of the existing hCard microformat
- hAtom 0.1 omitted anything dealing with feed level metadata, leaving such information to the web page context.
The Start Simple consultancy service, presumably makes use of the pre-existing and broader generic principle of "start simple" which can be found referenced on numerous websites.