An interesting project that will research and document the language used across different design systems to name similar components.
This is a great how-to from Darius Kazemi!
The main reason to run a small social network site is that you can create an online environment tailored to the needs of your community in a way that a big corporation like Facebook or Twitter never could. Yes, you can always start a Facebook Group for your community and moderate that how you like, but only within certain bounds set by Facebook. If you (or your community) run the whole site, then you are ultimately the boss of what goes on. It is harder work than letting Facebook or Twitter or Slack or Basecamp or whoever else take care of everything, but I believe it’s worth it.
There’s a lot of good advice for community management and the whole thing is a lesson in writing excellent documentation.
The slides from Carolyn’s talk at Beyond Tellerrand. The presentation is ostensibly about writing documentation, but I think it’s packed with good advice for writing in general.
200 discarded objects from a dump in San Francisco, meticulously catalogued, researched, and documented by Jenny Odell. The result is something more revealing than most pre-planned time capsule projects …although this project may be somewhat short-lived as it’s hosted on Tumblr.
Ah, what a wonderful treasure trove this is! PDF scans of Apollo era press kits from a range of American companies.
- Official NASA
- Lunar Module
There’s something so fascinating about the mundane details of Isolation/Quarantine Foods for Apollo 11 Astronauts from Stouffer’s.
Running an experiment for 500 years is hard enough. Then there’s the documentation…
The hard part is ensuring someone will continue doing this on schedule well into the future. The team left a USB stick with instructions, which Möller realizes is far from adequate, given how quickly digital technology becomes obsolete. They also left a hard copy, on paper. “But think about 500-year-old paper,” he says, how it would yellow and crumble. “Should we carve it in stone? Do we have to carve it in a metal plate?” But what if someone who cannot read the writing comes along and decides to take the metal plate as a cool, shiny relic, as tomb raiders once did when looting ancient tombs?
No strategy is likely to be completely foolproof 500 years later. So the team asks that researchers at each 25-year time point copy the instructions so that they remain linguistically and technologically up to date.
Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.
It’s really heartwarming to see this idea resonating.
There’s something quite Bridlesque about these lovely books that Brendan is generating from git commits.
Great advice on writing sensible comments in your code.
Alla looks at ways of documenting animations into a pattern library. I tell ya, her book is going to be unmissable!
Once again, we can learn from Christoper Alexander’s A Pattern Language when it comes to create digital design systems, especially this part (which reminds me of one of the panes you can view in Fractal’s default interface):
- Each pattern’s documentation is preceded with a list of other patterns that employ the upcoming pattern
- Each pattern’s documentation is followed by a list of other patterns that are required for this pattern
A nicely-documented styleguide from Atlassian. It’s not a component library, though—there’s no code here.
An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.
It’s good to see that the examples have some thought given to fallback content.
There’s also a corresponding tutorial on custom elements