start-simple: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Reverted edits by RolroRolva (Talk) to last version by Brian)
(rewrite)
Line 1: Line 1:
= Simple Start (Draft) =
= start as simple as possible =
One of several [[microformats]] [[principles]].


Note: Name Change, "Start Simple" is a Trademark in the Technology Sector (usability).
== solve simpler problems first ==
{{main|solve-simpler-problems-first}}


<em>Starting simple</em> means solving a specific, immediate problem with your efforts. Often, the simplest possible solution turns out to be the most effective solution. No more work is needed.
Large problems can often be difficult to solve and seemingly require complex solutions. Instead start with:


The Microformats [[process]] emphasises [[reuse | reusing]] previous efforts as much as possible, enabling greater efficacy in existing standards and their semantics. Starting simple keeps the focus on what can be accomplished effectively and immediately, rather than spending additional time chasing conceptual or theoretical chimeras; possibilities that <em>might</em> have a general impact when implementing the standard, but then again <em>might not</em>.
* '''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 <em>might</em> have a general impact when implementing the solution, but then again <em>might not</em>.
 
=== minimal vocabulary ===
{{main|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 that you spend time designing features which few if anyone uses in practice (but may have already cost developers time to implement).


Microformats should remain as simple as possible for as long as possible, collecting additional element semantics <em>only</em> when a significant practical need has been demonstrated for such additions.
Microformats should remain as simple as possible for as long as possible, collecting additional element semantics <em>only</em> when a significant practical need has been demonstrated for such additions.


=== Case Study - hAtom ===
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.
 
== similar and related principles ==
* [[humans-first]]
* [[reuse]]
* [[minimal-vocabulary]]
* [[naming-principles]]
* [http://en.wikipedia.org/wiki/Occam's_razor Occam's razor]
 
== 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.


* Removing Atom specific person/author constructs in favour of hCards
== loosely related at best ==
* Not dealing with feed level metadata - leave this to the web page context
The [http://www.startsimple.com/ Start Simple consultancy service], presumably makes use of the pre-existing and broader generic principle of "start simple" which can be [http://www.google.com/search?q=%22Start+Simple%22&start=10 found referenced on numerous websites].

Revision as of 21:16, 1 June 2009

start as simple as possible

One of several microformats principles.

solve simpler problems first

Main article: 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

Main article: 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 that you spend time designing features which few if anyone uses in practice (but may have already cost developers time to implement).

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.

similar and related principles

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.

loosely related at best

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.