robertogreco + toolmaking   12

Alan Kay's answer to What made Xerox PARC special? Who else today is like them? - Quora
[I noted on Twitter that "1 through 5 easily adaptable for education. For example: teach students, not subjects."]

"A good book (pretty much the only good book) to read about the research community that Parc was a part of is “The Dream Machine” by Mitchell Waldrop. There you will find out about the ARPA (before the “D”) IPTO (Information Processing Techniques Office) set up in 1962 by the visionary JCR Licklider, who created a research community of 15 or 16 “projects”, mostly at universities, but also a few at places like RAND Corp, Lincoln Labs, Mitre, BBN, SDC, etc.

There was a vision: “The destiny of computers is to become interactive intellectual amplifiers for everyone in the world pervasively networked worldwide”.

A few principles:

1. Visions not goals

2. Fund people not projects — the scientists find the problems not the funders. So, for many reasons, you have to have the best researchers.

3. Problem Finding — not just Problem Solving

4. Milestones not deadlines

5. It’s “baseball” not “golf” — batting .350 is very good in a high aspiration high risk area. Not getting a hit is not an error but the overhead for getting hits. (As in baseball, “error” is failing to pull off something that is technically feasible.)

6. It’s about shaping “computer stuff” to human ends per the vision. Much of the time this required the researchers to design and build pretty much everything, including much of the hardware — including a variety of mainframes — and virtually all of the software needed (including OSs and programming languages, etc.). Many of the ARPA researchers were quite fluent in both HW and SW (though usually better at one than the other). This made for a pretty homogeneous computing culture and great synergy in most projects.

7. The above goes against the commonsense idea that “computer people should not try to make their own tools (because of the infinite Turing Tarpit that results)”. The ARPA idea was a second order notion: “if you can make your own tools, HW and SW, then you must!”. The idea was that if you are going to take on big important and new problems then you just have to develop the chops to pull off all needed tools, partly because of what “new” really means, and partly because trying to do workarounds of vendor stuff that is in the wrong paradigm will kill the research thinking.

8. An important part of the research results are researchers. This extends the “baseball” idea to human development. The grad schools, especially, generally admitted people who “seemed interesting” and judgements weren’t made until a few years down the road. Many of the researchers who ultimately solved most of the many problems of personal computing and networking were created by the ARPA community.

Parc was the last of these “ARPA Projects” to be created, and because of funding changes from the Vietnam war, got its funding from a corporation rather than from ARPA-IPTO. But pretty much all of the computer people at Parc had grown up in ARPA projects in the 60s, and Bob Taylor, who set up the computing research at Parc, had been the 3rd director of ARPA-IPTO.

Bob’s goal was to “Realize The ARPA Dream”.

Parc was highly concentrated with regard to wealth of talents, abilities, vision, confidence, and cooperation. There was no real management structure, so things were organized to allow researchers to “suggest” and “commit” and “decommit” in a more or less orderly fashion.

Quite a lot of the inventions Parc is most known for were done in the first 5 years by a rather small pool of researchers (Butler Lampson estimates about 25 people, and that seems about right).

One of the most interesting ideas at Parc was: “every invention has to be engineered for 100 users”. So if you do a programming language or a DTP word processor, etc, it has to be documented for and usable by 100 people. If you make a personal computer, you have to be able to make 100 of them. If an Ethernet, it has to connect to 100 devices, etc.

There was no software religion. Everyone made the languages and OSs and apps, etc that they felt would advance their research.

Hardware was trickier because of the time and costs needed for replication and doing and making new designs. In practice this worked out pretty easily most of the time — via not too many meetings — and the powers of HW geniuses like Chuck Thacker. A few things — like the disk sectors and simple Ethernet protocols, etc. — were agreed on, mainly to allow more important things to be done more idiosyncratically. In practice, Parc designed and put in the field a variety of Alto designs (about 2000 Altos were built), MAXCs, Dolphins, Dorados, NoteTakers, Dandelions, etc over a period of about 10 years — i.e. quite a lot.

There were key figures. For example, Parc would not have succeeded without Bob Taylor, Butler Lampson, Chuck Thacker, and a few others.

I would call the first 5 years “effectively idyllic”. And the second 5 years “very productive but gradually erosive” (the latter due to Xerox’s many changes of management, and not being able to grapple with either the future, or a possible grand destiny for the company)."
alankay  zeroxparc  2017  vision  goals  funding  milestones  deadlines  errors  tools  toolmaking  education  learning  innovation  creativity  arpa  sfsh  teaching  howweteach  howwelearn  openstudioproject  lcproject  problemsolving  problemfinding 
april 2017 by robertogreco
Eyeo 2016 – Sarah Hendren on Vimeo
"Design for Know-Nothings, Dilettantes, and Melancholy Interlopers – Translators, impresarios, believers, and the heartbroken—this is a talk about design outside of authorship and ownership, IP or copyright, and even outside of research and collaboration. When and where do ideas come to life? What counts as design? Sara talks about some of her own "not a real designer" work, but mostly she talks about the creative work of others: in marine biology, architecture, politics, education. Lots of nerdy history, folks."
sarahendren  eyeo2016  2016  eyeo  dilettantes  interlopers  translation  ownership  copyright  collaboration  education  marinebiology  architecture  design  research  learning  howwelearn  authorship  socialengagement  criticaldesign  thehow  thewhy  traction  meaning  place  placefulness  interconnectedness  cause  purpose  jacquescousteau  invention  dabbling  amateurs  amateurism  exploration  thinking  filmmaking  toolmaking  conviviality  convivialtools  ivanillich  impresarios  titles  names  naming  language  edges  liminalspaces  outsiders  insiders  dabblers  janeaddams  technology  interdependence  community  hullhouse  generalists  radicalgeneralists  audrelorde  vaclavhavel  expertise  pointofview  disability  adaptability  caseygollan  caitrinlynch  ingenuity  hacks  alinceshepherd  inclinedplanes  dance  pedagogy  liminality  toolsforconviviality  disabilities  interconnected  interconnectivity 
august 2016 by robertogreco
The Hypercard Legacy — Medium
"This type of plain-language programming makes sense, particularly in an application that was designed specifically for non-programmers. I have been teaching programming to designers and artists for nearly a decade, and I find the largest concern for learners to be not with the conceptual hurdles involved in writing a program, but with obscure and confusing syntax requirements. I would love to be able to teach HyperTalk to my students, as a smooth on-road to more complex languages like JavaScript, Java or C++.

HyperTalk wasn’t just easy, it was also fairly powerful. Complex object structures could be built to handle complicated tasks, and the base language could be expanded by a variety of available externdal commands and functions (XCMDs and XFCNs, respectively), which were precursors to the modern plug-in.

This combination of ease of use and power resonated with the HyperCard user base, who developed and shared thousands of unique stacks (all in a time before the web). A visit to a BBS in the late 80s and early 90s could give a modem-owner access to thousands of unique, often home-made tools and applications. Stacks were made to record basketball statistics, to teach music theory, and to build complex databases. The revolutionary non-linear game Myst first appeared as a HyperCard stack, and the Beatles even got into the scene, with an official stack for A Hard Days Night."



"In new media, practitioners are often identified with the specific tools that they use. I started out as a ‘Flash guy’ and over the last few years have been connected more and more with the open source software project Processing. Though I originally came to Processing to escape the Flash Player’s then sluggish performance, I value the platform as much for its ease of use and its teachability as I do for its ability to quickly add floating point numbers. Lately, I’ve been asked the same question, over and over again:

‘Why don’t you move to OpenFrameworks? It’s much faster!’

It is true that projects built in OF run faster than those built in Processing. This question, though, seems to be missing a key point: faster does not always equal better. Does every pianist want to play the pipe organ because it has more keys? Is a car better than a bicycle?

In my case, choosing a platform to work with involves as much consideration to simplicity as it does to complexity. I am an educator, and when I work on a project I am always thinking about how the things that are learned in the process can be packaged and shared with my students and with the public.

Which brings us to the broader concept of accessibility. HyperCard effectively disappeared a decade a go, making way for supposedly bigger and better things. But in my mind, the end of HyperCard left a huge gap that desperately needs to be filled – a space for an easy to use, intuitive tool that will once again let average computer users make their own tools. Such a project would have huge benefits for all of us, wether we are artists, educators, entrepreneurs, or enthusiasts."



"I could imagine a new version of HyperCard being built from the ground up around its core functional properties: HyperTalk, easy to use UI elements, and a framework for extensions. It’s the kind of open source project that could happen, but with so much investment already existing in other initiatives such as Processing and OpenFrameworks, it might not be the best use of resources. So, let’s forget for now about a resurrection. Instead of thinking bigger, let’s think smaller.

HyperCard for the iPhone?
It might not be as crazy as you think. Imagine having a single, meta app that could be used to make smaller ones. This ‘App-Builder App’, like HyperCard, could combine easy to use, draggable user interface elements with an intuitive, plain language scripting language. As a quick visit to the App Store will show you, many or most of the apps available today could be built without complex coding. You don’t need Objective C to make a stock ticker, or a unit converter, or a fart machine. These home-made apps could be shared and adapted, cross-bred and mutated to create generation after generation of useful (and not so useful programs).

By putting the tools of creation into the hands of the broader userbase, we would allow for the creation of ultra-specific personalized apps that, aside from a few exceptions, don’t exist today. We’d also get access to a vastly larger creative pool. There are undoubtedly many excellent and innovative ideas out there, in the heads of people who don’t (yet) have the programming skills to realize them. The next Myst is waiting to be built, along with countless other novel tools and applications.

With the developer restrictions and extreme proprietism of the iPhone App Store, it’s hard to remember the Apple of the 80s. Steve Jobs, Bill Atkinson and their team had a vision to not only bring computers to the people, but also to bring computer programming to the public – to make makers out of the masses. At Apple, this philosophy, along with HyperCard seems to have mostly been lost. In the open source community, though, this ideal is alive and well – it may be that by reviving some ideas from the past we might be able to create a HyperCard for the future."
jerthorp  2009  2014  hypercard  apple  history  programming  toolmaking  billatkinson  myst  accessibility  tilestack  hypertalk  coding 
november 2014 by robertogreco
Buzz Andersen — I suppose I understand the perspective of these...
I suppose I understand the perspective of these engineers, though I don’t think their fear is of abstraction. It is a fear of improper abstraction, which is often the product of trying to create an abstraction before you even understand the problem; you know sit around and talk aimlessly for a couple of hours driven development. Good abstractions start very simple and evolve overtime to become useful mental models for a particular problem.

—Abstraction - A Tool For Collective Thought [Merrick Christensen https://dayone.me/8WwzfO ]

"I’ve been wanting for awhile now to write a post about programmatic abstractions that would be very much along these lines. I think this is a really important insight that separates great abstractions that hold up over time from lousy ones that are fashionable for a season until people start to understand their limitations. Good abstractions start simply—often close to the minimal solution possible—and evolve over time in a way that is always informed by specific use cases encountered in the wild. Abstractions that start out as monolithic, seamless, end-all-be-all solutions tend to break down very quickly when exposed to anything but the textbook use cases their creators anticipated, whereas more humble efforts, judiciously managed, tend to grow more organically into true general purpose tools with real staying power."
buzzanderson  tools  abstraction  2014  small  scale  simple  simplicity  problemsolving  toolmaking  lms  purpose 
april 2014 by robertogreco
Tools | LettError
"Once an alert designer has become familiar with the software, it is to be hoped that questions will arise which the software is incapable of solving. This can be frustrating. You think of an image or a solution that requires a specific combination of functions, and then it turns out not to exist. Or you want to repeat an action a large number of times, while the program does not offer any way of doing it automatically. The toolhorizon comes into view. Should you begin to have doubts about yourself as a designer? On the contrary. It simply means that the people who devised the program did not take your idea into account, so it is a relatively new idea. And it is no bad thing for a designer to have new ideas. All the same, good advice is a rare commodity when you run up against the limits of the tool-kit in the middle of the thinking process. Should designers slow down and adjust their ideas to what the computer can handle? As we know, to design is to make images within given limitations. But not all limitations are the same. Limitations and demands imposed by a client are easier to accept than the arbitrary limitations of your digital tools."



"The critical outsider will note that this method also has its disadvantages. After all, sometimes designing proceeds faster and more securely if nothing is left to chance, if work starts straight away as on the computer with a precision of a hundredth of a millimeter (‘exactly one cm’ is also possible). Is it really handy to generate the layout of a calendar with a program that can shift parameters endlessly? You have to write a program like that first, and that takes a lot of time. Of course not, will be the answer, the first time naturally takes more time and trouble, but that is what makes it so much fun. Design is hardly a challenge any more, but programming is. The paradox of designing like Just and Erik is that a lot of individually written tools are only efficient (in the sense of saving time) if the same sort of design is repeated a large number of times; but that is a very rare occurrence. Explorers, and that is what they are, do not want to do the same thing twice. They prefer to leave that up to ordinary designers, and studios. Which brings us to the second paradox: such designers may never get around to programming. They hope that the scripts and programs of LettError will simply be available on the internet one day. Ready to use."
design  type  computers  toolmaking  making  digitaltoolkit  onlinetoolkit  janmiddendorp  2000  via:tealtan  tools 
december 2013 by robertogreco
An Ill-Advised Personal Note about "Media for Thinking the Unthinkable"
"Right now, today, we can't see the thing, at all, that's going to be the most important 100 years from now.

We cannot see the thing. At all. But whatever that thing is -- people will have to think it. And we can, right now, today, prepare powerful ways of thinking for these people. We can build the tools that make it possible to think that thing.

We cannot see the thing. At all. My job is to make sure our children can."

[See also:https://vimeo.com/67076984 ]
thinking  future  tools  toolsforthinking  systems  bretvictor  2013  systemsthinking  computing  programming  circuits  signalprocessing  representation  howwethink  toolmaking  visualization  coding  carvermead  software  engineering  time 
june 2013 by robertogreco
Wired 7.01: The Revenge of the Intuitive
"The trouble begins with a design philosophy that equates "more options" with "greater freedom." Designers struggle endlessly with a problem that is almost nonexistent for users: "How do we pack the maximum number of options into the minimum space and price?" In my experience, the instruments and tools that endure (because they are loved by their users) have limited options.

Software options proliferate extremely easily, too easily in fact, because too many options create tools that can't ever be used intuitively. Intuitive actions confine the detail work to a dedicated part of the brain, leaving the rest of one's mind free to respond with attention and sensitivity to the changing texture of the moment. With tools, we crave intimacy. This appetite for emotional resonance explains why users - when given a choice - prefer deep rapport over endless options. You can't have a relationship with a device whose limits are unknown to you, because without limits it keeps becoming something else.

Indeed familiarity breeds content. When you use familiar tools, you draw upon a long cultural conversation - a whole shared history of usage - as your backdrop, as the canvas to juxtapose your work. The deeper and more widely shared the conversation, the more subtle its inflections can be.

This is the revenge of traditional media. Even the "weaknesses" or the limits of these tools become part of the vocabulary of culture. I'm thinking of such stuff as Marshall guitar amps and black-and-white film - what was once thought most undesirable about these tools became their cherished trademark."

"Since so much of our experience is mediated in some way or another, we have deep sensitivities to the signatures of different media. Artists play with these sensitivities, digesting the new and shifting the old. In the end, the characteristic forms of a tool's or medium's distortion, of its weakness and limitations, become sources of emotional meaning and intimacy.

Although designers continue to dream of "transparency" - technologies that just do their job without making their presence felt - both creators and audiences actually like technologies with "personality." A personality is something with which you can have a relationship. Which is why people return to pencils, violins, and the same three guitar chords."
howwework  thetoolsweuse  intuition  intuitive  via:vruba  1999  familiarity  limitations  mediation  experience  toolmaking  features  featurecreep  options  freedom  seams  distortion  software  design  creativity  technology  culture  tools  constraints  tradition  art  intimacy  brianeno  music  seamlessness  from delicious
november 2012 by robertogreco
Eyeo2012 - Jonathan Harris on Vimeo
"Jonathan talks about some major turning points in his life — things he used to believe that he no longer believes, painful moments that ended up being doorways into something else, highs and lows, and other ways in which life’s topography determines one's art. He relates all this against the backdrop of a desire to humanize the Web and evolve the art of storytelling, touching on insights and principles picked up along the way."
travel  change  painting  landscape  art  web  stories  narrative  datacollection  data  visualization  datavisualization  storytelling  bhutan  life  owls  meaningmaking  meaning  experience  jonathanharris  2012  eyeo2012  eyeo  tools  toolmaking  facebook  twitter  carljung  software  behavior  cowbird  purpose  healers  dealers  from delicious
july 2012 by robertogreco
Tellart | Experience Design & Engineering
"People don’t interact with computers or devices, they interact with each other and the world around them; a world in which the borders between natural, material and virtual have blurred.

Tellart builds where these borders blur.

As we come to understand that the network isn’t in computers but inside everything we touch, we learn that “form” isn’t what we see, it’s what we use. Every day there’s a new surface to interact with. But, underneath these surfaces lie familiar human needs, desires, habits and hopes.

Emerging technologies aren’t built with the same tools or the same talents we know from the past. We are Tellart: we’re inventors and explorers. We believe the best way to explore an idea is to make it real. We don’t just dream and sketch, we prototype and manufacture. We are in the business of making things real.

For twelve years, Tellart has been building interactive objects and environments that connect to the web.

Twelve years of marketing stunts, building control systems, museum exhibitions, games for health, consumer electronics, and medical simulations. Technologies emerge, and we’ve set out to give them culturally and economically relevant form.

In a small factory in New England, we’ve been housing the brains, hands, and hearts of industrial designers, electrical engineers, graphic designers and software architects. We’ve built our own tools and we use them every day.

We are proud of our clients and partners and the work we’ve done together. Sometimes our work starts with workshops to reveal needs and goals, or to identify potential strategies and tactics. Sometimes we create long-term agreements over years to build out innovative lines of business. But we always share the same goals as our partners: to actually make things that change the way the world thinks and acts.

Tellart starts where you start: with a hunch, an idea, a stray piece of technology, a carefully articulated demand, a broad sense that something is possible if addressed with courage, care, attention, and commitment."

[via: http://twitter.com/moleitau/statuses/225703421397831680 ]
manufacturing  sketching  internetofthings  form  toolmaking  tools  uk  studios  interactive  design  interaction  webdesign  agency  technology  usability  prototyping  making  tellart  iot  webdev 
july 2012 by robertogreco
Toolkit for Today | Canadian Centre for Architecture (CCA)
"Toolkit for Today: Concepts for Contemporary Architecture"

"Concepts can become powerful tools to analyze reality and to develop new practices, confronted with the necessities of the contemporary world. In the notorious juxtaposition between the “bricoleur” and the “engineer”, developed by Claude Lévi-Strauss, the first uses a limited number of tools and materials to perform multiple tasks, reassembling things together in creative ways, while the second invents specific tools for the solution of each new problem that arises.

The objective of the first CCA summer school for graduate students is to critically read a series of concepts developed by theorists and designers to understand their potential as tools for reflection, for the development of new strategies and for the creation of novel assemblages within contemporary architecture and urbanism."
edwardsoja  mohsenmostafavi  reinholdmartin  nancylevinson  momoyokaijima  davidgissen  stanallen  renatasentkiewicz  iñakiábalos  urban  urbanism  toolsforreflection  reflection  reassembly  materials  toolkits  2012  assemblage  toolmaking  tools  engineering  design  cca  toread  books  architecture  claudelevi-strauss  bricoleur  bricolage  from delicious
july 2012 by robertogreco
AU 2011: Otherlab's Saul Griffith, Part 1 - Pneubotics Yields Soft Robots on Vimeo
"At Autodesk University 2011, Saul Griffith, founder of Otherlab, discusses his pioneering work in Pneubotics. Otherlab is working on soft, fabric-based robots that are actuated by compressed air."

"At Autodesk University 2011, Saul Griffith, founder of Otherlab, talks about inventing and the type of follow-up required to see that invention go out into the world." [ http://vimeo.com/33131553 ]

"Part 3 of our video chat with Saul Griffith, co-founder of Otherlab, at Autodesk University 2011. Griffith answers questions about Theory vs. Making Stuff in education, advice for design students, and how to enable yourself to make truly unique things." [ http://vimeo.com/33131913 ]

[Later: "Solve for X: Saul Griffith on inflatable robots" http://www.youtube.com/watch?v=tqP3IpEqkk4# ]
design  tools  toolmaking  saulgriffith  education  projectbasedlearning  2011  core77  glvo  making  doing  learning  learningbydoing  advice  robots  invention  failure  howwework  howwelearn  pneubotics  otherlab  pbl 
december 2011 by robertogreco
Buckminster Fuller - Wikipedia
"He attended Froebelian Kindergarten. Spending much of his youth on Bear Island, in Penobscot Bay off the coast of Maine, he had trouble with geometry, being unable to understand the abstraction necessary to imagine that a chalk dot on the blackboard represented a mathematical point, or that an imperfectly drawn line with an arrow on the end was meant to stretch off to infinity. He often made items from materials he brought home from the woods, and sometimes made his own tools. He experimented with designing a new apparatus for human propulsion of small boats.

Years later, he decided that this sort of experience had provided him with not only an interest in design, but also a habit of being familiar with and knowledgeable about the materials that his later projects would require. Fuller earned a machinist's certification, and knew how to use the press brake, stretch press, and other tools and equipment used in the sheet metal trade."
design  technology  art  architecture  future  buckminsterfuller  childhood  froebel  kindergarten  learning  materials  systemsthinking  biography  maine  bearisland  penobscotbay  geometry  math  mathematics  toolmaking  designthinking  friedrichfroebel  from delicious
june 2011 by robertogreco

related tags

abstraction  accessibility  adaptability  advice  agency  alankay  alinceshepherd  amateurism  amateurs  apple  architecture  arpa  art  assemblage  audrelorde  authorship  bearisland  behavior  bhutan  billatkinson  biography  books  bretvictor  brianeno  bricolage  bricoleur  buckminsterfuller  buzzanderson  caitrinlynch  carljung  carvermead  caseygollan  cause  cca  change  childhood  circuits  claudelevi-strauss  coding  collaboration  community  computers  computing  constraints  conviviality  convivialtools  copyright  core77  cowbird  creativity  criticaldesign  culture  dabblers  dabbling  dance  data  datacollection  datavisualization  davidgissen  deadlines  dealers  design  designthinking  digitaltoolkit  dilettantes  disabilities  disability  distortion  doing  edges  education  edwardsoja  engineering  errors  experience  expertise  exploration  eyeo  eyeo2012  eyeo2016  facebook  failure  familiarity  featurecreep  features  filmmaking  form  freedom  friedrichfroebel  froebel  funding  future  generalists  geometry  glvo  goals  hacks  healers  history  howwelearn  howweteach  howwethink  howwework  hullhouse  hypercard  hypertalk  impresarios  inclinedplanes  ingenuity  innovation  insiders  interaction  interactive  interconnected  interconnectedness  interconnectivity  interdependence  interlopers  internetofthings  intimacy  intuition  intuitive  invention  iot  ivanillich  iñakiábalos  jacquescousteau  janeaddams  janmiddendorp  jerthorp  jonathanharris  kindergarten  landscape  language  lcproject  learning  learningbydoing  life  liminality  liminalspaces  limitations  lms  maine  making  manufacturing  marinebiology  materials  math  mathematics  meaning  meaningmaking  mediation  milestones  mohsenmostafavi  momoyokaijima  music  myst  names  naming  nancylevinson  narrative  onlinetoolkit  openstudioproject  options  otherlab  outsiders  owls  ownership  painting  pbl  pedagogy  penobscotbay  place  placefulness  pneubotics  pointofview  problemfinding  problemsolving  programming  projectbasedlearning  prototyping  purpose  radicalgeneralists  reassembly  reflection  reinholdmartin  renatasentkiewicz  representation  research  robots  sarahendren  saulgriffith  scale  seamlessness  seams  sfsh  signalprocessing  simple  simplicity  sketching  small  socialengagement  software  stanallen  stories  storytelling  studios  systems  systemsthinking  teaching  technology  tellart  thehow  thetoolsweuse  thewhy  thinking  tilestack  time  titles  toolkits  toolmaking  tools  toolsforconviviality  toolsforreflection  toolsforthinking  toread  traction  tradition  translation  travel  twitter  type  uk  urban  urbanism  usability  vaclavhavel  via:tealtan  via:vruba  vision  visualization  web  webdesign  webdev  zeroxparc 

Copy this bookmark:



description:


tags: