Instructables is a website brought to you by the partners at www.squid-labs.com. We make a lot of stuff, for business, and for pleasure. We've been looking for a long time for a convenient system for documenting our how-to projects, and the things we make, but it simply didn't exist. We decided we'd have to develop it ourself, and here it is, it will evolve as we grow to meet our own rigorous demands, and those of our users. Principal in our demands is convenience - it should take less time to document a project than it did to build it.
We have been thinking and working in this space indirectly for more than 5 years, following the developments in Open Source Software, blogs, wikis, and version control systems. The largest influence motivating us on this project is the 1945 Atlantic Monthly essay of Vannevar Bush "As we may think" which has been widely accredited as a huge influence on the internet. Two sections of that article particularly engage us:
In 2000-2001 Saul Griffith and collaborators at MIT launched www.thinkcycle.org a collaboration system for people interested in aiding technology development for developing countries. That community has grown to a large user base and has had many successful offshoots including www.designthatmatters.org. The idea was that invention and innovation would benefit from the distributed processor approach - put enough eyes on a project, and someone will have a neat idea on how to improve it.
Also around that time Saul Griffith, Eric Wilhelm and a handful of others played with www.zeroprestige.org - using a blog interface to augment yahoogroups as a method for documenting how-to projects, particularly focussed around kites and things powered by kites. Over a number of years hundreds of people have built kites and contributed new ideas and plans to that community. Thousands more have used the information at the site to learn more about how to use their kites safely or to augment their knowledge in kite aerodynamics.
These experiences as well as the involvement of other Squid-Labbers Dan Goldwater, Colin Bulthaup, and Ryan McKinley in both the open source software movement and hardware hacking led us to a new perspective on physical objects, hobbyists, DIY-ers, and people who want to share their knowledge on how (and often why) they did something. We have taken the lessons from these projects and other's in the same area on board as we've set out to create a convenient set of tools for documenting what you've made, finding what other people have made, or just to inspire people of the range of human creativity and the cool things people make and the way they make it.
In late 2004 we released something called iFabricate. It was an early pass at what we are now calling instructables. Again we incorporated the lessons of iFabricate into our new instructables tool set.
A key insight behind instructables is that humans are constrained to working in linear time - ie you do things sequentially and are generally not in two places at once. This gives us the overall framework for instructables, a way of documenting the sequence of steps that are undertaken to make any particular thing or do any task. Many of the sub-sequences will be re-useable. Why have everyone document how to drill a hole repetitively? These sorts of things should be seen as share-able sub-routines in the library of how to do things. Add to that the power of a large community filtering sub-routines for best practice and you get an expanding library of human knowledge, craftsmanship, and best practice for making just about anything.
We learnt in previous projects that well motivated communities are capable of solving the CAD conversion problem for themselves, and that out there are thousands of really smart people who know how to solve most of the little problems that arise when building something. Give these people the forums to discuss these points and they'll solve the problems. The problem to date though is that the format of these forums hasn't been conducive to retaining that information for the long haul, and continually improving the information to create the library of best practices.
We like to think about the physical world as something that is programmable. We like to think of objects or stuff you make as 'code'. In other words, we are approaching the physical world as something that is describable and replicable. CAD files are obviously part of this. The CAD file I use to design and cut out my bicycle parts is the same file that you can use to cut similar bicycle parts. However this is not everything, CAD descriptions alone don't fully describe heating schedules, or filing methods... the art involved in certain processes of making things. To extend the open source software analogy, hardware doesn't have a compiler that is the same for everyone. The code might be the same, but the compiler for hardware is the art and the skills, and the small details that are ususally left out of project descriptions. We are trying to think about the 'art' or 'skills' required to actually build things as defineable, sequential sub-routines that can be well illustrated with words and pictures. Cooking is an excellent example, processes like sauteeing, frying, filleting, and mashing are generic subroutines that have specific instances which require other detail for different meats. If you are writing a recipe, why not call upon the generic sauteeing subroutine and just add the unique details specific to your recipe.
We are using these types of approaches to think more deeply about how people share what they do and how they do it so that we can build a system that is easy and intuitive to use, and that will save you time in sharing what you've done.
Welcome to instructables, provide us good feedback and we'll provide you a better service.
Squid Labs.

All Steps Viewing
View all steps of an Instructable on the same page when you're a Pro Member.