barnsworthburning.net
- What this site is
- Colophon
- Contact me
- Shortlist of interesting spaces
- Behind the scenes
Most likely to succeed in defining Japanese aesthetics is a net of associations composed of listings or jottings, connected intuitively, that fills in a background and renders the subject visible.
For a person just getting started in some area of natural history, and unabashed focus on list-chasing is a good thing, at least for a while. The trick is knowing when to stop.
Cover art for Alan Fletcher's wonderfully expansive commonplace book.
The idea of “evergreen” content naturally contrasts with its opposite. I am going to call that non-evergreen content “deciduous” because I wasn’t bullied enough as a child.
Once you see that an answer is not serving its question properly anymore, it should be tossed away. It's just their natural life cycle.
They usually kick and scream, raising one hell of a ruckus when we ask them to leave. Especially when they have been with us for a long time.
You see, too many actions have been based on those answers. Too much work and energy invested on them. They feel so important, so full of themselves. They will answer to no one. Not even to their initial question!
Something interesting about the design of Twitter is that it doesn’t have much of a way of rewarding curation, only authorship.
...I’m inclined to think that the mechanisms of distribution of information are very important, and I think figuring out ways to reward good curation is probably an important thing.
...I don’t really know what the solution is here, but I do think that finding and curating good links and bits of information is useful, and something that should be rewarded more than it currently is.
Collect the Web,
Express Yourself.Collect what truly matters to you from the web. It's who you are. Like-minded people will find and learn from you.
Glasp is a social highlighting app that allows you to highlight and tag what you think is important while reading articles or watching videos on the web.
Cataloguing the underrated creativity of menus from around the world.
Assemblages are passional, they are compositions of desire. There is no desire but assembling, assembled desire.
Throughout his career, Wilson often answered fan mail and outside requests for his time with this form postcard:
Edmund Wilson regrets that it is impossible for him to: Read manuscripts, write books and articles to order, write forewords or introductions, make statements for publicity purposes, do any kind of editorial work, judge literary contests, give interviews, conduct educational courses, deliver lectures, give talks or make speeches, broadcast or appear on television, take part in writers' congresses, answer questionnaires, contribute to or take part in symposiums or 'panels' of any kind, contribute manuscripts for sales, donate copies of his books to libraries, autograph books for strangers, allow his name to be used on letterheads, supply personal information about himself, supply photographs of himself, supply opinions on literary or other subjects.
- Think like a gardener, not an architect: design beginnings, not endings
- Unfinished = fertile
- Artists are to cities what worms are to soil.
- A city’s waste should be on public display.
- Make places that are easy for people to change and adapt (wood and plaster, as opposed to steel and concrete.)
- Places which accommodate the very young and the very old are loved by everybody else too.
- Low rent = high life
- Make places for people to look at each other, to show off to each other.
- Shared public space is the crucible of community.
- A really smart city is the one that harnesses the intelligence and creativity of its inhabitants.
- The best way to improve software UX is regular direct observation, by everybody on the team, of the work done.
- Have some personality.
- Minimalism is garbage.
- Metaphors are fantastic.
- Naming things is fantastic.
- Try to write HTML that would make sense and be usable without the CSS.
- The buyer is quite often wrong. That fact never changes their mind.
- Working on a functioning app’s codebase does more to increase its quality than adding features.
- A good manager will debate you, and that’s awesome.
- The term ‘project’ is a poor metaphor for the horticultural activity that is software development.
Laurel’s birthday: March 15. [These are] a few of her favorite things.
I like words, and I note down ones that catch my eye as we cross paths.
Sometimes I read over the list, random access style, just to remind myself of forgotten thoughts. Each word is a bookmark into a little cascade of concepts in my brain.
So because I’d like to keep these words somewhere I can find them in the future, I’m putting them here.
Storm Doris Mimecom Cloudbleed Athleisure Cromwell H7N9 Trappist-1 ... (+448)
It’s frustrating to have done something really important and later realize that you didn’t get rewarded for it just because the people making the decision didn’t understand or remember what you did.
The tactic is pretty simple! Instead of trying to remember everything you did with your brain, maintain a “brag document” that lists everything so you can refer to it when you get to performance review season!
Things I‘ve read, people I‘ve tried to learn from, and things I‘ve done to become a better designer. This is an idiosyncratic list reflecting what has helped me along the way, rather than an exhaustive list of design classics.
Though the list leans toward theory — principles are more durable than technique — I offer a few ideas further down about how to practice design. It also leans toward information design, because the task of presenting rich, dense information in an accessible way is ultimately the task of any digital product.
A curated list of sites with an extra bit of fun.
- What sort of person will the use of this technology make of me?
- What will the use of this technology encourage me to notice?
- Does the use of this technology bring me joy?
- What limits does the use of this technology impose upon me?
- Upon what systems, technical or human, does my use of this technology depend? Are these systems just?
I've been fortunate enough to meet some of my heroes, but I still have a long way to go.
This is a list of people I'd like to high five IRL.
- A formal design process model is needed, to help organize design work, to aid communication in and about projects, and for teaching.
- Having a visual, geometric representation of a design process model is crucial, for designers are spatial thinkers. They will most easily learn, think about, share, and talk in terms of a model with a clear geometric picture.
- The Rational Model of design occurs naturally to engineers.
- The linear, step-by-step Rational Model is highly misleading. It does not reflect what real designers do, or what the best design thinkers identify as the essence of the design process.
- The bad model matters. It has led to the too-early binding of requirements, leading in turn to bloated products and schedule/budget/performance disasters.
- The Rational Model has persisted in practice despite its inadequacies and plenty of cogent critiques. This is because of its seductive logical simplicity, and because builders and clients needs “contracts."
- Several alternative models have been proposed. I find Boehm’s Spiral Model the most promising. We need to keep developing it.
The spiral shape certainly suggests progress. It associates successive repetitions of the same activity. The geometric shape is easily understood and memorable. The model emphasizes prototyping, starting with user-interface prototypes and user testing long before an operational prototype is possible.
Since a development model is principally used by developers, I believe having it designer-centered is entirely appropriate. With Boehm and against Denning and Dragon, I advocate frequent but not continuous interaction with representative users, with successive prototypes as the vehicles.
I strongly believe that way forward is to embrace and develop the Spiral Model.
Who advocates in the requirements process for the product itself—its conceptual integrity, its efficiency, its economy, it’s robustness? Often, no one. As often, an architect or engineer who can offer only opinion based on taste and instinct, unbuttressed as yet by facts. For in a classical Waterfall Model product process, requirements are set before design is begun.
The result, of course, is a grossly obese set of requirements, the union of many wish lists, assembled without constraints. Usually, the list is neither prioritized nor weighted. The social forces in the committee forbid the painful conflicts occasioned by even weighting, much less prioritizing.
Any attempt to formulate all possible requirements at the start of a project will fail and would cause considerable delays. — Pahl and Beitz, Engineering Design
As Project Manager, I had to reject the requirements document as totally impractical, and have a quite small team of architects, marketers, and implementers extract the essence.
Requirements proliferation must be fought, by both birth control and infanticide.
It is the necessity for contracts, whether within an organization or between organizations, that forces the too-early binding of goals, requirements, constraints. The pressure for a complete and agreed-upon set of requirements run into the hard fact, that it is essentially impossible to specify any complete and accurate set of requirements for any complex system except in iterative interaction with the design process.
How have the centuries-old building design disciplines handled this perplexity? Fundamentally, by a quite different contracting model.
- The client develops a program, not a specification, for the building.
- He contracts with an architect, usually on an hourly or percentage basis, for services, not for a specified product.
- The architect elicits from the client, the users, and other stakeholders a more complete program, which does not pretend to be a rigid contractable product specification.
- The architect does a conceptual design that approximates the reconciliation of program and the constraints of budget, schedule, and code. This serves as a first prototype, to be conceptually tested by the stakeholders.
- After iteration, the architect performs design development, often producing more detailed drawings, a 3-D scale model, mockups, and so on. After stakeholder iteration, the architect produces construction drawings and specifications.
- The client uses these drawings and specifications to enter into a fixed-price contract for the product.
Notice how this long-evolved model separates the contract for design from the contract for construction. Even when both are performed by the same organization, this separation clarifies many things.
Engineers seem to have a clear, if usually implicit, model of the process of design. It is usually an orderly model of an orderly process as the engineer conceives it.
The notion that the design process should be modeled as a systematic step-by-step process seems to have first developed in the German mechanical engineering community.
Herbert Simon independently argues for design as a search process in The Sciences of the Artificial. He was motivated to lay out a strictly rational model of design precisely because such a model was a necessary precursor to automating design. His model remains influential even if today we recognize the "wicked problem" of original design as one of the least promising candidates for AI.
In software engineering, Winston Royce independently introduced a seven-step Waterfall Model to bring order to the process. In fact, Royce introduced his waterfall as a straw man that he then argued against, but many people have cited and followed the straw man rather than his more sophisticated models. Even if ironically, Royce's seven-step model must be considered one of the foundational statements of the Rational Model of Design.
Any systematization of the design process is a great step forward compared to "Let's just start coding, or building." It:
- Provides clear steps for planning a design project
- Furnishes clearly definable milestones
- Suggests project organization and staffing
- Helps communication within the design team
- Is readily teachable to novices, and tells novices facing their first design assignments where to begin.
The Rational Model in particular brings yet more advantages. The early explicit statement of goals, secondary desiderata, and constraints helps a team avoid wandering, and it breeds team unification on purposes. Planning the whole design process before starting coding or formal drawings avoids many troubles and much wasted effort. Casting the process as a systematic search of a design space broadens the horizon of the individual designers and lifts their eyes far beyond their previous personal experiences.
But the rational model is much too simplistic, even in Simon's richly developed version.
The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. It it easy to give corresponding salaries to corresponding rungs, but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.
Why does the dual ladder need special attention? Perhaps because managers, being human, are inherently inclined to consider their own tasks more difficult and important than design and need to deliberately assess what makes creativity and innovation happen.
As the architecture design progressed, I observed what at first seemed quite strange. For the architecture team, the real System/360 was the Design Concept itself, a Platonic ideal computer. Those physical and electrical Model 50, Model 60, Model 70, and Model 90 things under construction out on the engineering floors were but Plato’s shadows of the real System/360. The real System/360’s most complete and faithful embodiment was not in silicon, copper, and steel, but in the prose and diagrams of IBM System/360 Principles of Operation, the programmer’s machine language manual.
I had a similar experience with the View/360 beach house. Its Design Concept came to be real long before any construction began. It persisted through many versions of drawings and cardboard models.
Is there positive value to recognizing an invisible Design Concept as a real entity in design conversations? I think so.
First, great designs have conceptual integrity—unity, economy, clarity. They not only work, they delight, as Vitruvius first articulated. We use terms such as elegant, clean, beautiful to talk about bridges, sonatas, circuits, bicycles, computers, and iPhones. Recognizing the Design Concept as an entity helps us to seek its integrity in our own solo designs, to work together for it in team designs, and to teach it to our youth.
Second, talking frequently about the Design Concept as such vastly aids communication within a design team. Unity of concept is the goal; it is achieved only by much conversation.
Thus, moviemakers use storyboards to keep their design conversations focused on the Design Concept, rather than on implementation details.
The design is thus the mental formulation, which Sayers calls “the Idea,” and it can be complete before any realization is begun. Mozart’s response to his father’s inquiry about an opera due to the duke in three weeks both stuns us and clarifies the concept.
For most human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out,” are essential disciplines for the theoretician.
In retrospect, many of the case studies have a striking common attribute: the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome. These bold decisions were made due sometimes to vision, sometimes to desperation. They were always gambles, requiring extra investment in hopes of getting a much better result.
Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?