saturday, july 12, 2014
I’ve had a lot of fun helping developers in my community (who build extensions for jailbroken iOS) improve our developer documentation wiki over the past year, so in May I gave a talk about it at Write The Docs in Portland. This conference was exciting; I don’t often meet other people who actually care about technical writing, and there were a couple hundred of us and many good conversations. There are 29 talk videos online!
The following is my talk, in video and text. I hope it’s helpful for other people who work with volunteers and documentation. You can jump to about 6:26 if you prefer to skip introductions and context.
Hi everybody, sorry about that [setting up the slides went weird], I’m Britta, and this is what I’ve learned from reviving my community’s volunteer developer documentation wiki. I’ll explain how I ended up as a contributor, despite not being a developer at all, and then I’ll share my strategies for encouraging volunteers to help with it — with a little bit of social engineering and a lot of friendliness. Pretty much all documentation projects could use some more enthusiasm, and I wanted to share what I’ve learned so far, because hopefully this will help you with your projects too. And there’s an under construction gif [on the intro slide], because under construction gifs are pretty cool.
So for a few years, our wiki looked like this:
It looks like a MediaWiki install — OK, whatever. But it was somewhat cryptic.
It started with an outdated tagline, and then it had a list of “ideas on what to add to this wiki”, as if the wiki didn’t have anything yet. It did have a lot of good pages, they were just buried. But at least it was honest — it also said “it is a real challenge for a beginner — where to start?”
This is what it looks like now:
Still looks like a MediaWiki install, pretty standard. But it’s so much more exciting now!
There’s a up to date statement of goals, there are lists of the best articles and the newest articles, there’s a picture with an in-joke just for fun, there’s a big “Getting Started” section, it’s alive!
So what happened here? There are a lot of volunteer editors who have helped make this happen. They are pretty awesome, so I listed some of them here.
But before I explain, it’s probably helpful if you know what this community is — where do these people come from, and why do they care about it?
I work for the tiny three-person company that makes Cydia, which is the alternative to the App Store for jailbroken iPhones and other iOS devices. This is documentation for writing software for jailbroken iOS. Apple is not going to document how to use their private APIs, so we have to do it!
What is jailbreaking though? Let’s say you have an iPhone and you want to write some software that shows up on the lockscreen instead of being a normal self-contained app. That’s crazy. You can’t do that. Apple just doesn’t give you a way to do that. But wait a minute…
This is a lockscreen running custom software. [Credit: Typo5 Lockscreen by Patrick Muff, using Cydget by saurik.] You can use a specialized security exploit available for free — you can download it from the internet and put it on your phone — which removes Apple’s restrictions on the operating system. Then you can write crazy new software that adds new features and customizations to any part of iOS, and people distribute and sell this software in our alternative to the App Store. These developers mostly write this stuff for fun, and they might make some money on their products, but they don’t work for us; they’re not our employees. They’re volunteers when they’re writing on the wiki.
How do you get started writing these kinds of customizations? You’d probably want to learn about the tools and libraries that people have written for doing this, such as by reading some documentation. That’s usually a good start.
But for a long time we didn’t have much documentation. You had to figure out a lot of it on your own, and maybe ask some questions on IRC. When I started working for this company as a community manager, I was just working on user support forums and that kind of thing, because I’m not a developer. What do I know about developer documentation?
Occasionally I would poke developers and say “Oh, the wiki is looking a little neglected, maybe you should do something about that” — and they said “OK, I guess so. Sure.”
That didn’t work.
A new perspective
Here’s a story. Last year, just for fun, I started contributing to an open source project called OpenHatch, which teaches people how to contribute to open source projects. I’m a support person at heart, so I helped out by answering questions from developers about contributing. I answered questions about how to read a bug tracker, how to submit a patch, how to find the right documentation for the project they wanted to work on…that kind of thing.
But wait a minute, I’m helping developers with development questions. It turns out I know something about helping developers? OK, maybe I should actually join the developer IRC channels in my work community and see what I can do there too.
And that developer wiki — I actually know a lot about building wikis. I’ve been a Wikipedia contributor for twelve or thirteen years. I don’t know why I wasn’t feeling qualified to edit a wiki. OK, it was time to log in, click “edit”, and start fixing up that homepage.
This is what started my fight against inertia on my wiki. Contributing to open source projects can give you a new perspective on your work and new skills, and you can practice them in a low-pressure environment where people will often help you, because they want you to volunteer on their project. It’s also really fun. So, as an OpenHatch volunteer, if you have questions about being a new open source contributor, you can ask me! That’s my plug.
Now I’m going to go through a big list of strategies that I’ve learned while working on this wiki. Some of these will resonate for you and some won’t, so I’m going to throw a bunch out there.
0) Have somebody who cares hang out where the developers are.
My first step was to show up and hang out with the developers. For me, this meant joining the IRC channels (developer chat rooms). If your community has an IRC channel, that’s probably where the developers are. But this could be a mailing list, Twitter, forums, meetups, the engineer lunch table, whatever it is in your community or at your company.
1) Talk to newcomers and beginners.
You might start by asking the experienced developers to write things, since they know a lot, and if that works, that’s great. But usually they’re busy, or they don’t know what to write, or sometimes they ignore you, because well, who are you anyway?
But enthusiastic beginners are solid gold. They want documentation, they’re looking for it, they’ll read it if it exists (if they can find it), and they ask questions that reveal what’s missing. They ask redundant questions that show that something is hard to find, which is also useful to know. You can ask “What was the search path that you used?” to help you fix why they weren’t finding it.
You can ask these beginners to write things down as they learn, because they look up to you as a more established person in the community, even if you’re really new too. They don’t know better! As they get more experienced, if you’re lucky, they’ll keep on contributing. You can have a nice pipeline going on.
1a) Help identify useful info to write down.
I started by noticing useful conversations in these developer chatrooms and very, very gently asking “Would this be useful to put on the wiki?”
It turned out that people had forgotten about the wiki. It was kind of outdated and stale, and it didn’t seem useful to them, so they weren’t using it. That meant they didn’t know what was documented and what wasn’t. It didn’t occur to them that they could actually fix it.
So I started reminding people that maybe this specific useful bit of information (that people keep asking about) would be useful to write down. A few of them started saying “OK, I can do that.”
1b) Ask encouraging questions to counter anti- documentation concerns.
But important in this is that I don’t tell people what to do. I ask very innocent, gentle questions. Here are examples of questions I’ve used when people have the impulse to not write documentation, which happened a lot at the beginning.
I would hear “If people can’t learn this part on their own, they probably can’t build successful projects, because this is difficult, so we really shouldn’t write it down.” OK, but that gives nothing to beginners who want to learn. So I asked “Can you write a ‘prerequisites’ list of what people should know before they start exploring on their own?” Somehow that didn’t feel like it would give everything away, and people started writing that.
When people said “Nobody pays attention to the docs, so we shouldn’t bother writing them”, I said that people would pay attention if we used the right teaching strategy. I asked these volunteers “What problems do people run into if they don’t read the docs? Let’s write down advice for these people too, so that when they show up on IRC and clearly did not read anything before they got started — very ‘exploratory’ learners — then we have a page for them, oriented toward people who tried something that didn’t work.”
Or I’d suggest to somebody to write something down, and they’d say “I don’t know enough to write this”, so I’d say “Can you add a ‘this is missing’ note to the right place in the wiki?” — and then often, magically, in the next few days somebody would fill out that spot. Having somebody point out that something is missing turns out to be valuable.
2) Think of it as a marketing problem. Make the homepage enticing to click!
As I was working on this, I realized…this is a marketing problem. Marketing is not a bad word. I’m trying to: identify the value of this documentation and communicate that value to people who need it, in order to get them to use it and contribute to it for other people. That’s the definition of marketing. The value of documentation is not obvious to everyone. Sometimes you have to figure out how to sell it!
Part of this was to make the homepage really enticing to click. Put the best articles way up front! Write a really grand tagline with a great statement of goals. I put a picture on the front page so that it had some kind of “visual identity”. Try to make it something to be proud of.
2a) More marketing: build new articles that attract more visitors.
Another part of marketing was that I helped build articles people wanted and then promoted those articles. For example, I helped with this giant table of open source projects that people can look at as example code. This made developers feel great since their projects were mentioned on the wiki, and this list felt valuable to people since it was a huge list of resources…so they kept sharing it on Twitter. Huh. This list was also really easy for people to contribute to, since all they had to do was log in and add their project, which meant lots of people signed up for wiki accounts (yesss).
This list was outside the normal scope of our documentation wiki, but that was OK. It attracted people to the wiki, and when people hear about it, some of them are going to want to start contributing.
3) Make writing more fun: show that people read it.
Many developers don’t ordinarily find it fun to work on documentation. Writing code is fun for them! They like discovering new things, and very importantly, they’re releasing them to an audience who wants them — an audience who says “Yes! Please give me more features! And here are all my support problems…” OK, maybe support isn’t that fun. But generally, releasing software is fun. You have this really good feedback loop with people who are using your work.
Contributing to the wiki felt lonely. Even if three people read your article that afternoon, you had no idea. Nobody said thanks — because they’d have to log into the wiki and click “edit”, and people don’t know how to edit, and they don’t know how to write on talk pages — so nobody was thanking anyone for working on the wiki.
So I wanted to show them that people are reading their work!
3a) Make it more fun by copyediting new stuff.
Whenever anyone added anything, I went in and copyedited it or added some formatting. This was an immediately visible way to prove to writers that somebody read their work. It added some feedback loop to the wiki process.
This also helped people feel more confident in contributing. A lot of these developers speak English as their third or fourth language, or writing just isn’t their main skill. And a lot of them are about fifteen — they don’t necessarily have a lot of technical writing experience yet. They appreciated getting some friendly feedback on their writing, and I added syntax highlighting to their code snippets, so it looked great. People like that!
3b) Make it more fun by making it look active.
Nobody likes hanging out in a ghost town. (OK, some people like hanging out in ghost towns, but they’re kind of weird. They’re cool, but they’re weird.) On a wiki, if there have been no edits for the past month, you’re going to think that nobody looks at the wiki, so why bother throwing your words into the void? I make sure that the “Recent Changes” page always has something on it, something in the past few days — even just some copyedits.
We list new articles on the homepage. It’s great if the homepage keeps changing with new stuff, so that it always feels fresh and active — something people feel they should check on. They know that if they add something, it’ll get featured on the homepage too.
c) Make it more fun by thanking people.
And we make it more fun by thanking people! If you write an article, and nobody says thank you, that is the definition of a thankless task.
Readers aren’t necessarily going to write thanks, even if they appreciate something, so this is something that I do. I write thanks to writers on their wiki talk pages, on IRC, on Twitter, everywhere. Writing thanks publicly on my work Twitter account shows that this is a priority for the community, and what’s funny is that by writing stuff on Twitter…who knew, you’re promoting the wiki again!
To write thanks effectively: do it right away, be really specific about what they did that was awesome, and say it publicly. [Credit: as discussed on the OpenHatch mailing list.] It makes people feel good, and it’s super easy. It’s the best.
4) Be there to give people permission.
Some of the people in my community felt like they needed permission to contribute to the wiki. These are often the very best people, because they’re very polite, and they’re very careful, and they don’t want to mess it up. Or they don’t feel like they’re qualified to write, a little bit of impostor syndrome.
So I’m there on IRC to be a person they can ask whether adding something would be a good idea. Of course, I’m always saying “Yes, go ahead! It’s OK if it’s not perfect, we’ll fix it!”
5) The docs system needs docs.
Here’s something that surprised me recently: the docs system needs docs! We had a jailbreaking conference last month, and I ran a little workshop for working on our wiki. Even though these volunteers are amazingly brilliant developers who can read assembly code, reverse engineer iOS, and write really complicated programs, they were asking me questions about MediaWiki editing syntax.
Because MediaWiki is a little frustrating and confusing for everyone, no matter how amazing they are. You need cheatsheet links and explanations of how to edit the wiki, even if your community is absolutely brilliant.
6) Leave rough edges for others to smooth out.
This part is a classic bit of wiki social engineering — you leave around a few obvious mistakes and easy tasks, like typos somewhere in the wiki, because that will entice new people to click “edit” and start contributing. They’re thinking “Oh that’s easy, I can fix that!” Once you get them to log in and make an account, that’s the first step — it’s good.
You can also make a list of easy “bite-sized” tasks for new editors, such as contributing to that list of open source projects. I put this in an obvious place on the homepage to help people get started.
6a) Write bad first drafts as motivation.
Another funny social engineering trick: writing bad first drafts as motivation for people to fix stuff. One of the best developers I know told me this recently: that if I want him to help with the wiki, I should write some really terrible documentation myself, even about something I don’t fully understand, and then show him what I did, because he’s going to be like “oh my god” and go fix it. That’s how to motivate him. It’s great advice.
This is, again, why beginners are solid gold. Experienced developers often have no idea what needs to be written — they need a draft, or an outline, or something else to get started with that isn’t a blank page. Beginners are perfect for writing this. Like me, as a beginner in a funny way since I’m not a developer.
Then I start wondering if this is going to end up with me becoming a developer too. What if I learned some Objective-C so that I could skip all of this work and just write documentation by myself? That starts to sound easier… This is one strategy I haven’t tried yet. It would be kind of hilarious. We’ll see.
Thanks! If you also have volunteers and you try to motivate them, I want to know what you do and learn about your strategies too.
In response to this talk, I got a nice email from a person who noted that for his team’s wiki, it was helpful to install a MediaWiki extension that automatically displays credit to article contributors. I like this idea and might try to convince our dev wiki maintainer to add it.
thursday, march 06, 2014
In August, I gave a talk at JailbreakCon, an annual conference that gathers together fans of jailbreaking and people who help make jailbreaking happen. This is a large and complex community: security researchers who develop the jailbreaks themselves, developers who make software for jailbroken iOS, designers who make themes for jailbroken iOS, repository managers (who host those software packages and themes), documentation and support forum helpers, bloggers and video makers, the three of us who work on Cydia as SaurikIT, and others. It’s pretty great to see each other in person, and to meet lots of other people who are into jailbreaking. (If this sounds interesting, JailbreakCon 2014 will be April 12-13 in the Bay Area.)
Instead of doing a typical JailbreakCon talk explaining something about security research or software development, I decided to look at the reasons why we care about those technical parts. Why have tens of millions of people figured out how to jailbreak their iOS devices and use Cydia, and why have hundreds of people spent money on planes and cars to talk to each other about these things in person? This is fascinating and exciting to me, and I’d like to convince you to be fascinated and excited too.
Here’s a video and a slightly-edited transcript for people who prefer reading. But the video might be entertaining; I’m pretty enthusiastic in it.
What I think is interesting to talk about is: why did you jailbreak your phone? Oh, I should introduce myself first; I work for saurik on community and support for Cydia. A lot of the time I stay a bit behind the scenes, but I moderate forums like JailbreakQA and /r/jailbreak (the subreddit), and I write some of the information inside Cydia.
So. Why did you jailbreak your phone? It’s sort of an obvious question. Usually people answer it with something like “I wanted to delete Newsstand”, or “I wanted quick-reply for text messages”, or “I wanted to toggle WiFi and 3G on and off more quickly, because Apple’s way of doing that is really lame”. These are very reasonable answers. But if you asked people a few years ago, they would have said: “I wanted to customize my wallpaper because Apple won’t let me”, or “I wanted to put apps in folders”, or “I wanted to record video”.
But these sound like entirely different reasons to jailbreak; there’s not much in common since the old reasons are part of iOS now. So, what’s going on with that? Do these reasons change all the time? Every time a new iOS version gets ready to be released, a bunch of tech blogs publish articles like this one:
They say, “Is jailbreaking dead? Is there any reason to jailbreak anymore, because all of the old cool features are now part of iOS?” But each jailbreak is more popular than the last one: evasi0n was even bigger than Absinthe, which was bigger than the ones before that. So something else is going on here, something strange.
My hypothesis is that even though you think the reason you jailbroke your phone was to get Five Icon Dock or WinterBoard — instead there was a more durable reason that hides in the background. I think this reason, at least for me, is to get access to this rich, complicated, hybridized primordial soup of software features. They’re not just the features and decisions that one company in California made, but this cornucopia of product decisions made by lots of people, such as the people in this room — with lots of conflicting and different ideas, like four or five different kinds of app switchers — which is awesome.
Something that I like, that most of you probably aren’t into, is fanfiction: where you take a TV show, or in this case an operating system, and you build new stories or new features on top of it, unauthorized. The quality of these stories and features may vary widely, and they may have conflicting plotlines — you have one TV show with sixteen fan stories that go off in different directions, or you have sixteen different features built on the same operating system with different ideas of how something should work.
And it’s really fun. People have these different visions of what software can be like. It’s creative, and it’s playful, and it generates a lot of good stuff along with the stuff that’s not so good. One company can’t cover everything that somebody wants out of a device. They can get to maybe 90% if they’re Apple, but there’s that last 10% of something that bugs you, or something that could be cooler, and jailbreakers are great at filling up that last 10% with awesome stuff.
We can take their pretty good operating system and write our own stories with their characters. We can fill in the missing scenes in Notification Center or the lockscreen, even if Apple wants to be the only person telling stories with this interface. Some of these features may be implemented by Apple someday, but there will always be new ones that we’ll make up, because you don’t run out of stories. A lot of them Apple will just never add, because they require extra battery or memory, or they’re confusing for ordinary people, or they’re just kind of goofy. Like this one, which is one of my favorites, called NyanSliders, where the sliders are Nyan Cats:
This should be animated; they do the little running dance as you change your volume. That’s cool! Jailbreaking is this big prototyping lab where we can experiment with what software interfaces can do, and how we can make them more fun. Instead of coming up with a concept in Photoshop, and everybody just thinks “that’s a cool way to do keyboards”, you can implement that feature right away. You don’t have to wait for Apple to maybe see your blog post, and maybe decide that it’s OK for them to implement it. You can do it right now, and see how it works. Like SwipeSelection, an alternate way to use your keyboard, which sounds kind of cool and kind of weird, and then you use it, and it’s interesting. It’s maybe not perfect, but it’s valuable to have this experimental attitude and experience.
That’s one reason to jailbreak! There are more reasons. I won’t list all of them, because I’ll be here all day. But one thing, that I think doesn’t get enough appreciation, is being able to turn off features in iOS. I maintain the featured packages list in Cydia, and one day we realized that we should have a special list of packages that start with “no”:
That’s NoCoverFlow, NoNewsIsGoodNews, NoPasscodeBlock, and NoStoreButton, and if you search Cydia for “no”, you’ll see a lot more of these tweaks that turn off annoying features that Apple doesn’t provide options to disable. Like “shake to undo” — a lot of people just find that feature irritating. And you can fix Apple’s default features that favor their own apps instead of App Store apps, such as BrowserChanger if you like Chrome, or MapsOpener if you like Google Maps, which makes a more level playing field. So that’s one set of reasons: you can add features and you can take them away, which is useful.
There’s a second reason that I find interesting, which is that you jailbreak because you can, because you should be able to jailbreak your device. To be able to use your phone as a general-computing device instead of a limited device, and to have the capability to do research on the software to verify that it does what Apple says it does, that’s cool.
It goes along with a third reason that is important to me: jailbreaking is a way to learn something, to explore a technical subject even for a lot of people who have no experience. These people can be frustrating — you have a lot of new people who ask…seemingly-dumb questions. But let’s say you’re a kid who doesn’t have your own computer, but you’re playing around with jailbreaking your iPod touch and asking questions about it, and you are on your way to learning something technical that you might not have had a chance to learn otherwise. This is great.
You end up learning this whole new vocabulary: what is a bootrom? What is a kernel? What are SHSH blobs? SHSH blobs are this complicated cryptography-related concept that millions of people are now dealing with on a regular basis — that’s amazing. When you open up iFile, the whole iOS filesystem is right there. Even a desktop computer will try to hide parts of the filesystem from you because it doesn’t think you can handle that. But in iFile, it’s there for exploring. You can even SSH into your phone and learn how to use the command line.
And if you mess up your phone, you can restore it. If you mess up your desktop computer, or your mom’s desktop computer, that is going to be a massive hassle, and it’s going to take you more than half an hour to fix that. If you restore your phone after deleting a system file, it’ll take you half an hour, and it’s kind of a hassle since you lost your jailbreak, but it won’t ruin your day. Well, maybe. But it won’t ruin your mom’s day, which can be important!
This educational reason might not be the first thing that occurs to people when you ask them why they jailbroke their phone. Nobody is going to say “I wanted to learn more about SHSH blobs”, but learning new things is a hidden and powerful reason that keeps people in the jailbreaking community. They can even start writing code without asking Apple for permission or paying Apple, which is great.
I see this on the forums that I moderate. Somebody comes in asking a “dumb” question, and a few months later you see them pop up again, answering a question about how to downgrade a baseband. You might be like “Whoa! Where did that come from?” — but that person has been learning and reading the whole time. It warms my little heart, and it’s a big part of why I work on this stuff. I like to imagine we’re training a whole secret generation of people who actually know how to tinker with computers.
So if somebody asks you why you jailbroke your phone, it’s probably still best to say “oh, I have this cool theme”, because if you try to explain all this, they might get confused and bored — but hopefully it’ll linger in the back of your mind that there are these deeper, more important reasons why we do this stuff and spend time with it.
I also convinced a few of the newer developers attending the conference to get up in front of everyone and give a series of two-minute talks after mine! Here we are among the other speakers:
saturday, july 20, 2013
Last month I went to AdaCamp and learned a ton partly because the Ada Initiative runs it both as a place to discuss solving problems and as a testbed for better ways to hold conferences. Lots of conferences try to encourage a diverse group of participants and speakers, but making conferences better is specifically part of the Ada Initiative’s mission, and this was especially fun because a bunch of the participants were community organizers/managers/coordinators like me. Among topics such as running real-life meetups for open source projects and the ramifications of using gender-neutral usernames, we talked a lot about AdaCamp itself!
I’m in Portland for Community Leadership Summit this weekend, I’ll be at Defcon soon, and I’m going to XOXO in September, so I’ve been thinking about things AdaCamp did that I’d like to see more conference organizers consider. Of course I like the idea of making tech events better for women, but this stuff is especially interesting to me because worthwhile efforts to make a tech event more welcoming to women also make the event more welcoming to other non-majority types of people (for example, including women means not just including able-bodied women). It’s the magic of intersectionality! Some of these ideas are conveniently compiled on the page of resources for conference organizers on the Geek Feminism Wiki, but here’s my list too:
- If you have an application process, like AdaCamp and XOXO do, it’s great for the application to be as encouraging and inclusive as possible, with detail about how the conference is aiming for a crowd that is diverse in x and y and z ways. This is because an application process can discourage people who tend toward “impostor syndrome”: the feeling that you’re not cool enough for that conference, even if you’re actually the perfect attendee. At AdaCamp we talked about how this type of self-doubt is common in women who work in technical fields, and I imagine it’s also common among other kinds of non-majority people (or even simply people with anxiety issues). A conference missing those people would not be the best possible conference!
- Before the conference, providing a list of nearby low-cost hostels and hotels. I’ve seen some conferences listing nearby hotels, but a lot of AdaCamp attendees appreciated seeing the lowest-cost hostel options as well as the usual options.
- Giving people a choice of badge lanyards: green meaning “photographs always ok”, yellow meaning “ask before photographing”, and red meaning “photographs never ok”. This can help people feel more comfortable, especially if they’re concerned about photos getting online with nasty comments attached to them. Defcon recently switched from “no photos” to “photos OK”; I don’t know whether switching to color-coded lanyards would be respected or mocked there, but I wonder if the organizers have considered it.
- Laying blue tape on the floor to mark access paths where people shouldn’t stand or put chairs/bags; you can label them “walk and roll” (ha ha). This is especially useful for people using wheelchairs and other tools to move around, but it’s also great for people who don’t like being stuck in crowds (pretty much everyone).
- Being explicitly inclusive of people of all gender identities, including considering labeling all-gender bathrooms along with men-only bathrooms and women-only bathrooms. The AdaCamp organizers emailed the attendee group with a proposal: since the venue provided two sets of women’s bathrooms and two sets of men’s bathrooms, and the conference would have 200 women and 20 men, and some people prefer single-gender bathrooms and some prefer all-gender bathrooms, how about re-labeling one set of men’s bathrooms as all-gender bathrooms (with a sign asking people not to use the urinals)? People agreed, and it worked well. I’d also be happy with organizers asking attendees for permission to re-label some women’s bathrooms as all-gender at conferences that generate long lines for men’s bathrooms (nobody likes long lines).
- Setting up a dedicated “quiet room” with a rule against talking in that room; people can use the space to nap or work/relax quietly. This is helpful for anyone who wants a moment to escape from the relentless socializing of conferences, since not everyone always has a nearby hotel room. (And not a “chillout” lounge like DefCon has, which is supposed to be low-key but isn’t very relaxing — music mixing with the sounds of people trying to hire each other, bad efforts at flirting, and groans of sleep deprivation.)
- Having a series of 90 second (1 slide) lightning talks - I thought 90 seconds sounded impossibly short compared to normal 5 minute lightning talks, but it turned out to be great. It’s fun to see tiny windows into what people find important enough to share, and it almost feels like watching a game that tests people’s sense of timing. The rules excluded doing recruiting pitches or ads for commercial products, which helped keep things interesting. 90 seconds is also short enough that even inexperienced speakers can plan something without a lot of preparation, giving them confidence for future speaking. (I told AdaCamp how playing Nethack as a kid gave me a sense of familiar territory when I later encountered the command line, and I was delighted that people enjoyed my tiny speech.)
- For evening meals: creating a spreadsheet on Google Docs with a list of nearby restaurants, and inviting people to type in their names to create small groups for dining out. There can also be a spot for naming a theme for the group (such as “open source community building” or “feminist nonprofits”), to help people find a group to join. At AdaCamp, this was a pleasant way for even shy people to opt into meeting new friends; the spreadsheet limited each group to ten people to keep things reasonable.
I haven’t been to WisCon, but its “Universal Design” accessibility policies and details go into more depth than I learned about at AdaCamp…a mind-boggling level of depth.
thursday, june 28, 2012
I grew up in Los Angeles where there are a lot of oil wells, usually somewhere out along a freeway. (I always liked the wells you can see on the way to LAX, ones that look like dinosaurs eating from the ground.) In Santa Barbara, our oil wells are out in the ocean, and the university-owned nature preserve leases some space to an oil company to store crude oil drained from the ocean floor. This nature preserve is next to the neighborhoods around the university, and you can just walk out into the fields and look at the tanks with their coded markings and geodesic dome tops.
Nobody really tells you that the tanks are there, since most people either don’t find them particularly spectacular or haven’t been to the nature preserve. You hear about them when you acquire a boyfriend who lives next to them; he shows them to you because you both like infrastructure. (From his apartment we listened together to trains whistling, the coastal fog horn, and airplanes headed to and from the little airport next to the university.) We found out about a historic gas station down the road, built as a showcase by one of the oil companies in the 1920s, now picturesquely defunct and a favorite of everybody in town with a fancy camera. On a few Saturdays we took long driving trips to visit other oil fields — he’d tell me we were going on an adventure, and a couple hours later I’d look out to see more oil pumps than I’d ever seen in one place before.
The native Chumash people used the natural tar on the beaches here to caulk their canoes, and the tar still comes up and caulks the bottoms of your feet if you’re not careful while walking on the sand. There was even an asphalt mine for a couple years in the late 1800s where the Art Department building is now; there are a few surprising pictures of very grimy-looking men hauling things around the campus lagoon.
I’ve read that the oil company’s lease on this nature preserve land ends in 2016 and the university doesn’t plan to let them renew it, which makes sense, but I like living in a place where its history is so close to the surface. By looking you can find clues that this land was once a slough, then ranches, then explored for oil, then a small WWII marine base, then a university nature preserve. It’s not heavily developed enough yet to obscure the origins of the place, unlike where I grew up in LA — where old underground oil developments sometimes come back to bite people in the form of gas explosions, and where the remaining active oil wells are carefully hidden.
thursday, february 03, 2011
I like learning geometry and topology terms that make you notice and describe patterns out in the wild:
The wires hanging between those pylons form catenary curves, which describe what happens when you hang an ideal string between two points. The word is also used for catenary wires (which power trains).
These shiny light shapes are caustics generated by a spotlight shining on a curved piece of plastic (Untitled, 1967, Giovanni Anselmo, Museum of Modern Art). You can see a typical caustic by taking a mug of tea into the sunlight and looking at the curvy, pointy light on the tea surface. This is also what you call the light patterns in the shadow of a glass and wavering at the bottom of a pool.
These wiggly lines are a reaction-diffusion system of air bubbles between two panes of glass in a layered piece of art by Dustin Yellin. This type of wiggly pattern also happens in places like bird feathers, rabbitfish scales, and shriveled paint.
Angle of repose
The dirt in this pile is showing off its angle of repose: the slope that a pile of granules forms when it is “at rest”. You can watch for the angle of repose when you shovel snow and throw it in a pile, or when you build sandcastles, depending on where you happen to live right now.
Non-geometry-related things to find and name: bollards, wall ties, ghost signs, perforated screen walls, former Fotomats, benchmarks (find some near you), manicules, telephone exchange buildings, skeuomorphs in general. And obsolete technologies that are still in use or still visible: sidewalk prisms, Quonset huts, civil defense air sirens, glass insulators, old-style phone numbers.