While not all of these are actually one-liners, Una Kravets’s Ten modern layouts in one line of CSS has some neat tricks I hadn’t seen before. (I’m realizing I really need to brush up on modern CSS. It’s been a few years and lots of things have changed in that time.)
I recently came across Maggie Appleton’s article on digital gardens. Oh my goodness, this is delightful. I’m sure some small part of it is just nostalgia for the old days of the web, but the idea seems good and solid nonetheless. I love digital gardens. (See Mike Caulfield’s The Garden and the Stream and Swyx’s Digital Garden Terms of Service for more in this vein.)
Exploring some of these gardens led me to the idea of learning in public (also see Gift Egwuenu’s Learning in Public talk). Very closely related to digital gardens, of course, but a different angle to look at it from. It also nicely parallels the working in public idea I posted about recently.
I’m looking forward to adopting more of these practices myself. Not sure yet exactly what form that will take, but at the moment I’m thinking it’ll probably be the notes system I mentioned. While that would be doable with the website engine I have now, it wouldn’t be very ergonomic, so I’m probably going to retool. (And by probably I mean almost certainly, because I am an inveterate toolmaker at heart. I’ve written out plans for a new version of Slash, my blog engine, that will easily support notes as well as blog posts and web pages. More on that soon.)
Just came across Frank Chimero’s essay Everything Easy Is Hard Again, on the rapid state of change on the web, technology-wise. It’s really good. While I don’t completely agree with everything he says, I do think there’s unnecessary complexity that could be pared down a bit.
Ever since seeing the IPython notebook, I’ve been thinking about how its notebook idea would be great for genealogical research. So I put together a (very rough) proof of concept:
A text-based query interface (the queries are in purple) to get information from a database. I don’t know that the best query language would be natural language like this — it’s more just to get the idea across — but the important thing is being able to easily do these types of queries against the genealogical information you’ve stored, enabling all sorts of analysis. “Who in my tree is born more than nine months after their father died?” “Who got married when they were younger than 12 years old?” “Who are all the children who died when they were younger than eight years old?” And so on.
Interleaving queries, their results, and other text (using Markdown, of course). This is the core notebook idea. Or you can look at it as an annotated transcript of a query session. Rather than just having a list of queries and their results, you sort of embed them in between your writing about the research. (Similar to literate programming.) For me, writing things out helps me to see what I think and wrap my head around the research.
There’s a lot of room for data visualization here. I’ve only shown pedigree charts and some basic tables, but it’d be easy enough to have a query return any other type of chart — bar, pie, fan, you name it. Including interactive things like the family analysis tool.
I didn’t include this in the mockup (because I, uh, just barely thought of it), but you could extend the query language to support hypotheticals. “Show me what William Crowder’s family would look like if he and Sarah got married in 1820” or “From now on, pretend Samuel Shinn was born in 1860.” And then following queries would act as if that were true. It’s nice to be able to establish a few suppositions and then see what the ramifications would be, whether they’re plausible, etc. Or to compare two different hypotheses.
Which brings us to the purpose of all this: to have a good place to do the rough, messy side of genealogical research. Thinking through things, seeing what comes of it, and keeping a record of the journey, basically.
Since the information in the database would be subject to change (as you do more research), it would probably be good to cache the results. Or maybe highlight the queries whose results have changed when you reload a notebook. Personally, I lean more towards caching, so that the notebook accurately represents the database at the time it was written (making it a valuable historical record of your research), but you could also look at it as a living document that updates automatically when the background data is updated.
Anyway, the proof of concept is just a static HTML page. I’m not planning to do anything more with it, but I wanted to get the idea out there.