This all started with looking at the WordPress site presentation deck Brian Lamb used for a talk last week at Conventry University. There’s a lot more to Brian’s talks than this, but few people title them as well as Ed Tech Isn’t Dead, It Just Smells Funny nor finds the wackiest GIFs.
But I’m not here to talk about the presentation. It was the launch point to think about how in many ways of “creating”, and especially presentation decks, we create by destroying what we did before. We regularly pave over our creative process paths.
Or, taking it maybe another way, if we are creating in a mode of considering the versions of our work, it’s usually looking backwards often as a means of reverting. What if we used a version “mindset” in moving things forward?
But why presentations? It was just a trigger.
This “WordPress as a Presentation Deck” was something we did first a little over a year ago for a talk Brian and I did for Open Education Week. The fun thing, and it probably should be a SPLOT of some sorts, is that this is a stock free WordPress Theme, Intergalactic, that we had made available on the trubox multisite I worked on while at TRU last year.
By adding a little custom CSS to hide stuff in the footer, and turn the “next posts” navigation into just an arrow AND using a plugin to manual control the order of posts, we got a nifty template. Want the details? Wow, there is a blog post that explains it.
The first WordPress / Presentation Stack thing…
But there is more- because we were making use of the Multisite NS Cloner tool, we could make a copy for a new presentation, and then customize for the new deck. So that first presentation begat another and another, and another… and so forth. I exported it to our work on the UDG Agora for some talks at the 2015 Open Education conference and at the University of Guadalajara… I then exported a copy to my own domain to have a “presentation” maker multisite with 1 2 3 separate presentations.
But here is the thing that got me thinking; because we kept cloning, the copies carried along the entire media library of what cam before, so in some case I am using a 7th generation copy, I see the images Brian and I used in the first one.
It’s not like a full version history, but I was intrigues that in this process there are relicts of what came before, often not even related to a current work, sitting there inside the box.
While we may have some familiarity with versioning features in Word, or Google Docs, and even WordPress itself, for the most part, this feature is not used as a way of pushing content in the future. It is used to go back in time, to revert to a version before we messed it up or before someone wrote something inappropriate.
James Somers shows not only a timeline history of work, but it’s position within the Work. Woah, Neo.
One exception I can think of is what is perhaps one of the most fascinating stories– James Somers’ reverse engineering a way to play back a Google Doc’s entire history (now available as a the Draftback Chrome Extension. Another is the classic Heavy Metal Umlaut screencast by Jon Udell that demonstrates viscerally how a Wikipedia page evolves. There might be some other creative uses of document versioning, but I bet they are far and few between.
These exceptions show the time-flow of a creative process, and while looking backward, they might be seen as propelling forward??
It’s in the realm of software / code development that such lavish attention is given to content versioning, it’s practically a field of its own — and pretty much inscrutable to anyone else.
But it’s in the scope of interest in my new Creative Commons project, and just general interest, to probe farther in my own understanding of git-ness.
There is a pulse of interest in ideas for using the features of the GitHub environment in ways outside of software. See John Johnston’s “Gitzone” post and responses. There is GitBook as a front end for doing publishing projects. Adam Croom recently shared what looks like an awesome OLCInnovate presentation on using GitHub — see Fork U! (great title) (great stuff).
And thinking this way is a bit of a head adjustment from the way we typically think of “making” stuff. It’s thinking about it’s evolution as a branching map, it’s considering how contributions can either split and go a way, or return their adventuring to the source.
flickr photo shared by lisibo under a Creative Commons ( BY-SA ) license
It can hurt the head.
I’m still trying to get someone beyond Tom Woodward to try an itty bitty forking experiment. I dare you to fork it. I triple dog dare ya.
I am slowly finding out, that in some ways, GitHub is kind of like blogging on WordPress.com – it’s simple, and much is done for you. Understanding git– the foundation that runs beneath GitHub, is like diving into the PHP code of WordPress, understanding the nuances of hooks/filters, or the ideas of the template hierarchy.
It looks more complex, and bizarre, but… with great programming knowledge, Peter Parker, comes ….
It’s been a bit of an awakening that I really did not get much of the principles operating within GitHub. I pretty much relied on the desktop version. I even got a bit confused when I started doing things with the gh-pages “branch” (the version of your github site that can be a public facing web page).
When you toggled between the main branch and gh-pages, the stuff you were working in disappeared! Is ti gone (no it’s all stored in hidden sub directories, and stuff is shuffled to and from your working directory). This if course, again, is super basic (and laughable to command line git jockeys), but its counter intuitive to how we think about files on our computers.
But worse, when I was working on some changes in my WordPress projects, I would dabble with my local files, run some tests on a dev server, and if stuff was okay, I would sync the changes back to GitHub. So I always was tinkering with the main branch.
Well duh, this is dumb. What I do now, and the way it works is, if I am developing a new feature or functionality, I make a branch for my work, develop from that, and once its working, I merge the changes into the repo. To the GitHub source, the different is nil, but it’s a better way to work.
One of the sources helping me get to that deeper understanding was recommended by John Johnston — Ry’s Git Tutorial. Once concept that has kept echoing is the idea of thinking about working on feature branches.
Again, a branch is a copy of the current stable code/content, and a safe place to experiment with something new. If it does not work or is just undoable, it’s a dead end. If it is a successful experiment, we can merge it to the stable code/content.
Now that I think about it, it is a beautiful embodiment of Hora’s watch making mode described by Mike Caulfield:
The point here is not about multitasking, but about evolution. We tend to see emergent complexity as the accumulation small deviations leading to new forms of life, thought, or practice….
Instead, evolution must proceed through a series of stable, intermediate forms, via a pattern Simon calls “aggregation of subassemblies.” You can’t get from nothing to the human eye unless there are stable and useful states between nothing and the eye as we know it, and the structure of your eye is as determined by those intermediate states as by anything else. We’ll be stuck forever with a blind spot in our field of vision because there’s no desirable set of intermediate states that would result in a new blind-spot free system.
But back to Ry’s tutorial on branching. He outlines a “crazy” change in the working files–
The crazy branch is a longer-running type of topic branch called a feature branch. This is fitting, as it was created with the intention of developing a specific feature. It’s also a term that makes Git’s contribution to the development workflow readily apparent: branches enable you to focus on developing one clearly defined feature at a time.
This brings us to my rule-of-thumb for using Git branches:
- Create a new branch for each major addition to your project.
- Don’t create a branch if you can’t give it a specific name.
Following these simple guidelines will have a dramatic impact on your programming efficiency.
Again, going back to Mike’s framing of changes and watchmaking — branches enable you to focus on developing one clearly defined feature at a time.
For the most part, in writing a paper, in whacking away at JavaScript code, in putting together a presentation, we do not make this clear a focus. I sure do not; I hold all the maps, ideas in my head.
And this works while we are focused on the “thing” but when we come back days, weeks, years later– this organization is, well, fuzzy at best.
I have no idea if this is a way of working that can apply to things outside of programming. Maybe not wholesale. But this idea of thinking about creating as a series of iterative steps, experiments, pushes ahead, we know intuitively. But that’s how we always work.
flickr photo shared by cogdogblog under a Creative Commons ( BY ) license
What would it mean to use the branch mentality to go forward with versions of what we work on?
This is really just mumbling out loud…
I am writing this before I even write this post, and I only have a fuzzy idea how to weave together a strand of seemingly disconnect4d ideas. That’s that happens when writing what you are thinking, rather than writing what has already been thought.
My idea was to find an image at the end of the results rather the start. My first search in Google Images / licensed for reuse on “versions” got an interesting hodgepodge of results, photos of packaging, and cartoon characters, but nothing clicked. I changed it to version history, and glanced at the icon for what looked like a flow chart. Better yet, it’s from a YouTube video, where the person who posted is explaining the different between git and subversion:
I just scrubbed to an interesting visual part, so I have no idea who Steve is! The video is licencsed Creative Commons and is identified as “an instructional video for CS196 at the University of Illinois.”
I’m moving toward this model for tracking changes in lambTracker http://nvie.com/posts/a-successful-git-branching-model/
Thanks Oogie, this is really helpful, as I try to get better with a flow. I just branch, fiddle, and merge back to main when done, but this idea of keeping a parallel develop one is logical.
This is a really neat idea. A branching approach gives you a place to park your “someday, maybe” ideas – even if you don’t know yet if they fit or how, at least it’s a way to keep track of some of those ideas and develop them for later use. It seems like bringing back some of the useful features of note cards and marginalia which didn’t quite make the leap into the digital age for many people.
Branching might also help you do one thing at a time. I’m reminded of a comment I heard from a couple of senior faculty members about papers in the word processor age. They claimed that the first page of student papers had become very good – because it was edited every time the file was opened. The second page was almost as good, because it had been edited N-1 times. The third page, not quite as good, with N-2 edits, et cetera, until you get to the conclusion which was written heartbeats before it was sent to the printer.
There’s some glorification of the good old days in there, but the result would point to a work style that’s not focused on one task at a time. I think some people (like me) could be served well by a more structured workflow, and a branch metaphor could provide it.