I'm honored to have been selected to present at the first-ever DrupalCamp Michigan. The local Drupal community is super strong: they opened registration for 50 people and it sold out so quickly they expanded to 100. Not being a good public speaker at all, you'd think this might be daunting. However, a combination of under-preparedness and lack of sleep really put me in the right mindset. So, without further ado, here are the slides and a video of the presentation:
Notes
You've got the wrong guy
I originally proposed this session not because I have a ton of experience on the topic and all the answers, but because I wanted to use presenting as an excuse to learn about git.
If you've been using git for a long time and/or have memorized large portions of the Drupal APIs, chances are you won't be able to learn much from me.
WTF is a git!?
The word git was first a British slang word for an annoying or stupid person. The software was named self-deprecatingly from that word. I like to think git stands for something else though: good shit.
Git is a fast, distributed version control system.
It was originally developed by Linus Torvalds in 2005 to be used for developing the Linux kernel
If you've used another version control system, you might wonder what sets git apart.
From what I've gathered, the most important differences between git and other systems are:
Git is distributed — this is important, because having a local copy of a repo lets you access the version history easily, commit whenever it makes sense, and push it to one or more repositories, or remotes, based on the structure of your project
Git reduces the pain of merging, which means that you can make lots of branches without worry
Other systems, like CVS, subversion, and others, are also considered slow for accomplishing certain tasks. While I don't have a great means of comparison, git seems pretty quick to do most everything.
Phase 1 was a git mirror, so that people could test and develop in git without affecting the project
Phase 2 is a centralized model based entirely in git
Phase 3 will be a decentralized, GitHub-like model that will change the Drupal.org contribution workflow. Details are still being hashed out on that front
Local Tools
Locally, there are a few tools that can make routine tasks fast and can integrate with the tools you already use.
I'm a visual, GUI guy, especially for menial tasks. So I like TortoiseGit on Windows, along with a Git plugin for Notepad++. TortoiseGit makes pushing changes a job of a few clicks. The Notepad++ plugin lets me press Ctrl+Alt+C, type a commit message, and click a button to commit changes to one or more files. If you think vi is a pain in the butt, tools like these are for you.
Remote Tools
It's probably not just you doing development. Even if it is, there's a compelling reason to have at least one central place for your repositories, which I'll explain later.
But a side reason to have bare remote repositories is that you can use tools intended for remotes, like redmine. Tools like this add another layer for project management. You can do project planning, bug tracking, wiki documentation, and other such tasks from a web interface, letting either you or your team keep track of things. And if your project is out in the open, you can leverage a much larger community using sites like GitHub, Google Code, or SourceForge.
Your First Repo
Let's say you have a directory of files that you want to put under version control at that path. You'd go there in your terminal, then initiate a new repository. Next you'd add all the files. Those files are queued up and ready for the first commit, which you then perform.
If you don't use the 'm' option to add a commit message, the commit command will show the log entry for the commit in vi, and you put the commit message at the top. It's at this point that I'd like to reiterate that vi is a pain in the butt.
So that's how you create a new repo from bash
Commands
These are the git commands you might use in day-to-day work
*Point at commands and explain what they do*
^ Learn what the commands do
These commands are used less frequently (in general), but it's good to know about them
bisect lets you determine where a bug began in the revision history, using a binary search to split the possibilities in half each time.
These are also git commands, though you might not use them very often or ever.
stash is commit for wusses
Workflow
So let's talk workflow.
At my job I've got two Drupal sites: "Beta," which isn't really the right name for it, since at times it's a dev box and at others it's a beta-slash-QA machine.
And the live site.
The design and development parts of my job revolve around creating modules and themes to add functionality and enhance the design of just those two properties.
I'm guessing that's NOT what your jobs are like. I'm guessing you make lots of sites. And those sites in various states exist in multiple places, like your local dev machine, an internal server for testing, and external hosting that you don't necessarily control. I don't envy you.
Wherein I Tell You Not To Hack the Core
A site is Drupal core, plus contrib, plus the data in your database.
Since Drupal is modular and nearly everything can be changed via hooks, it's really pretty rare that you have to change anything in core. And if you do, I've found from experience that it's usually for temporary debugging rather than for permanent changes.
Do not hack core.
Avoiding Temptation
So from Do Not Hack Core we can take away that all the things on the left are things you shouldn't mess with, and the thing on the right is the only place that customizations go (unless you have a weird multisite setup, which is cool, but your workflow's going to be different).
A repo at the whole site level is redundant, and reinforces the opposite of the number 1 best practice of the Drupal site-building community.
Drilling Down
What about at the 'sites' level?
This is workable, but you might notice something immediately.
Look at the sites/all/modules directory.
You're probably not going to be hacking contrib either! All of those modules are version tracked in git on the drupal.org site. The vast majority of those modules require zero coding to work exactly as expected. Putting them under version control doesn't accomplish much.
Then there's sites/default
sites/default/files contains uploaded and attached files. Those files are site-specific and are subject to database dependencies. The files also tend to be images and other files that are unlikely to change. There are a number of reasons why version controlling those files is impractical.
On the other hand, sites/default/settings.php is a good candidate for revision control individually, as it's something that you have to work on in the development process, and some of the settings will likely have to change depending on where the site lives. The branching model of git could be really useful for this purpose.
.gitignore Files
One way to wrangle sites/default/files and streamline the process is with .gitignore files. With a well-made, well-placed .gitignore file or two, you can continue using git add . and git commit -a without adding stuff you don't want to your project.
.gitignore files let you choose files to omit from the versioning index, based on wildcard notation. So instead of omitting /sites/default/files wholesale, for instance, you could just selectively ignore boring images and junk while preserving the directory structure wherever the repo might end up.
What You're Controlling
Conceptually, the two components that you're likely to work on that can most benefit from version control are:
Customizing the theme to the client's needs
Developing custom modules or modifying one or more contrib modules
If you start with a working theme, like Zen, you can clone down a repo from Drupal.org and use the history of that particular part of the project if you need it. You can create your own branch for your theme and develop from there.
If you code up a custom module, it might only be useful for a single site a single time. But maybe the functionality you add is something that other clients might want, or that can be contributed back to the Drupal community. Modules are reusable pieces, so structuring your repository environment to make them accessible for all sorts of projects is a plus.
Hypothetical Model
Here's an example of what repositories on a central server might look like.
I made the directory structure here very flat, putting core, modules, themes, and the site_projects repositories all within a single folder. This would work well if you always use the same base theme along with a limited number of custom modules. This particular setup plays nice with management software like redmine, which is one reason a flat structure is attractive.
If you're going to have lots of distinct themes and modules, it might be helpful to create big repos called modules and themes, then use git's submodules functionality to manage the individual drupal modules contained within. Thanks Ben for the submodules tip!
Now that we have a central place for all the things we're working on related to building our sites, we can optimize our workflow to play nice with version control.
Leveraging Synergy
One way to do that is to set up pushing and pulling.
If you don't already have ssh keys set up between your development box and your repository server, setting that up will make it a lot quicker to push and pull from git. If you want to deploy via git from the repo server to other machines like your site testing server or even live web server, you'll also want to set up ssh keys between the those boxes.
On your local dev box, use the clone command to make a local version of the repo on your server. When you do that, the source repo becomes a 'remote' called origin.
Make some changes to the local copy (you can branch if you want to, you can leave master behind). When you're done making changes and they're ready for other people in your shop to see/use them, use the push command to send them back to the origin.
Drush Make and Install Profiles
Once the changes are on the server, you can pull them to your deployment boxes, or...
You can get fancy.
It's a common use case: you end up using the same base theme, modules, configurations, and other tweaks on most of your projects. You might already have an "install profile" informally; Drupal with all the stuff you use all in one place.
The "drush make" command lets you generate makefiles that turn your informal install profiles into the real deal. In Drupal 7 it's easier to make profiles that configure things on install, but technically it should be possible in D6 too. Some combination of the features, strongarm, context, and other helper modules could let you automate some impressive stuff — like pre-built views.
Hint: it might be manual coding work, but if you install a whole bunch of similar sites, writing a [profile name].install file could be a time-saver in the long run. Especially if you swipe one from an existing public profile and suit it to your needs.
You can use the drush make command to import all the dependencies for your profile wherever you need them. Then just run the installer (which if you're super fancy you could get working with drush site-install) to have a functional site in the time it takes to make a pot of coffee because your junior dev doesn't know proper coffee machine etiquette.
The makefiles are really flexible, so you can choose particular version numbers of modules for compatibility, apply patch files to change modules or core code, or grab external libraries from tarballs.
Nailing down a "holy grail" workflow for this sort of development takes time and effort, and I certainly don't have all the answers.
Over the next few weeks, Alex Fisher and I will be working on drush make and workflows, and will report useful findings to our respective blogs.
You may also ask about how to go from local dev to testing to quality assurance to live, all while easily managing your databases. You may ask that, but I don't have an answer. Sorry.
Pay it Forward
If you'd like to become a core developer or get involved in a contrib project, a working knowledge of git will help.
I'm fighting the urge to give nitty-gritty details here, as the instructions are both technical and well-documented. If you're not a project maintainer, contributing code involves creating patch files based on numbers from the issue queue. If you are a project maintainer, you can interact directly with the remote repo (albeit while following the guidelines).
One reason I'm avoiding an in-depth explanation is that the Phase 3 git migration could very well change how things get developed on Drupal.org.
But here's how to create a patch file, just in case.
Just one commit is the easiest for contributing back patches.
The Version Control tab on project pages gives really good instructions for grabbing source repos and other contibution tasks, including the specific clone command you need to grab a local copy of the repository.
So now that you're a git expert, go out there and contribute back to the Drupal community!
Thanks for putting up with me!
My apartment is covered in dry erase boards. I like to use them. Here are some examples:
This tendency has led to me using them for my slide presentations. I've had two in the hopper that I presented at the Michigan Library Association's Tech Escape workshop in May. As is always the case with my presos, be forewarned that they contain a lot of salty language:
If you have any dry erase board art requests, please leave them in the comments and I will try my best.
It was one year ago today that I first posted about transliteracy. A few days earlier, I had complained on twitter that transliteracy was "a bullshit made-up term for the same old stuff." Since it's always been my policy on this blog to offer solutions whenever I identify a problem, it took a few days of thought before I posted the beginnings of the language model.
Over the last year, I've done some other transliteracy-related stuff that might interest you:
Starting out, and despite my first tweet calling transliteracy bullshit, I was conciliatory and downright friendly. After putting some positive work out there and being ignored, I chose to approach the topic differently and talk about the controversy. The L&T librarians told me that I had gone too far, so before publishing Redefining Transliteracy I scaled back and was only semi-controversial (if you consider pedantically listing problems with a definition controversial).
Thing is, that post was probably the most popular of the whole lot. It was even the subject of an assignment for a Digital Media Communication class at Rider University (co-instructed by the truly inspirational John LeMasney). I hope most of the post's appeal was that it offered a compelling case for the adoption of a model for transliteracy that people find useful. I suspect that part of the appeal was the oh-no-you-didn't out-calling of the PART definition. So screw it, this stuff's been bugging me...
PART of the Problem
If the original "working definition" of transliteracy were claimed to be proprietary, it wouldn't be a big deal that my criticisms (let's call them "bug reports") and suggested improvements ('patches') have fallen on deaf ears. But the seminal First Monday paper on transliteracy refers to it as open source thinking. Professor Thomas calls transliteracy an open source concept in a well-circulated video:
We see it as an open source concept, and we offer it up for you to think about, develop, write about, go to Wikipedia and argue about the definition...
One immediate problem is that Wikipedia is a bad place to argue about the definition, since it's a place for things notable outside of itself, not original research or discussion leading to development of new ideas. While it might be acceptable to have a discussion of wording on an article's talk page to some extent, arguing about the definition using Wikipedia as the sounding board will generally lead to NOR, NPOV, and/or CoI issues. It's precisely why I haven't personally made any edits to the transliteracy page. If you don't already have your hat in the ring, I encourage you to edit on the language model's behalf.
Calling transliteracy open source is really quite hollow. Is the transliteracy blog really all the source? Where's a clear explanation of licensure for applicable source, besides a CC icon on the First Monday article? Where's the mechanism for reporting bugs and submitting patches? The fact of the matter is that there is very little open source about PART's work on transliteracy. It's a buzzword in a sea of buzzwords.
Call to Action
PART, if you do not wish to explicitly put the transliteracy concept under an open source or open creative license, release source material in the same manner, and ideally explain the mechanismby which the community can contribute to the project, you should publicly clarify that transliteracy is actually a proprietary concept.
Neither PART nor Libraries and Transliteracy have posted about the language model. Since I'm certain that prominent posters of both those blogs have read Redefining Transliteracy, it's curious to me that they haven't talked at all about the language model on their respective blogs. To me that's a lie of omission, or worse yet a faith-based lapse of intellectual honesty. After all, they've been presented with evidence to the contrary of their claims:
The things listed in the definition (signing, orality, handwriting, etc.) aren't established to be platforms, tools, or media either individually or as a group
The property of platforms, tools, and media that allows a literate person to go across or between them is not explained (and I contend, cannot be explained – a single unit is necessary for comparison)
All other criticisms aside, the order of the list is nonsensical, yet easy enough to change to chronological, alphabetical, or to delete altogether
Interaction is just a series of reading and writing acts as it applies to literacies, so including it is redundant
Talking about literacy as a function of platforms, tools, and media is akin to telling an auto mechanic over the phone that your car is yellow. Sure, color is an important attribute of a car, but the mechanic is more concerned with the make, model, and mechanical attributes of the vehicle. Literacy is about reading/writing stuff (ie. messages in languages), not where the stuff's written (ie. medium)
Unless there is some means of reconciliation to which I've not been made privy, believing transliteracy can operate under the PART definition requires faith: belief in the absence of [or in the face of contradictory] evidence. That's not a leap I'm willing to make. I've proposed a patch for a definition based instead on language (with thorough explanation of what language means in that context) that eliminates all 5 of those problems. Of course, if there were problems with the language model, I'd be interested in exploring those as well.
Maybe the silence on those blogs is because of personality conflicts with me. But that only goes so far; at some point pointing at me and saying I'm being arrogant or condescending just ends up being a distracting Argumentum ad hominem. If you think I'm an asshole and don't want to subject your readers to my douchitude, just don't mention me by name or link to my blog. I don't care – all I care about is furthering the discussion of transliteracy by putting ideas out there. If you're unwilling to tell your readers about ideas because they conflict with your pre-formed assumptions, who's the real asshole?
One thorny problem, though, is over-riding the style of certain elements that use the width of the screen liberally by default. One such element is the venerable data table.
Coyier's solution is great in that each table cell is labeled. However, doing this requires either writing CSS manually for every data table on the site (which is near-impossible for large sites) or having the same thing done with scripting on either the server or client side:
I propose a generalized solution that requires no scripting whatsoever. The drawback of this method, though, is that the cells are not individually labeled. The example is also more compact, but this aspect can be tweaked by marrying the two methods:
@media screen and (max-width:720px){
table{display:block;}
td,thead th{border-color:#444;border-style:solid;border-width:0 2px 0 0;display:inline;float:left;}
td:last-child,th:last-child{border-right:0 none;}
thead th{background:transparent;font-size:1.1em;}
tr{display:block;float:left;clear:left;padding:6px 0;width:100%;}
thead tr{border-bottom:4px solid #444;margin:0 0 .3em 0;padding:0 0 .2em 0;}
tbody tr:nth-child(even){background:#ddd;}
td:nth-child(5n+1),th:nth-child(5n+1){background:#FFD8D8;}
td:nth-child(5n+2),th:nth-child(5n+2){background:#FFE8D8;}
td:nth-child(5n+3),th:nth-child(5n+3){background:#FFF8D8;}
td:nth-child(5n+4),th:nth-child(5n+4){background:#D8FFD8;}
td:nth-child(5n+5),th:nth-child(5n+5){background:#D8D8FF;}
}
Open the working demo and resize your window to under 720 pixels wide to see the effect. I call this approach the "Rainbow Tables" method
For 2011, my New Year's resolution was three words: exploration, patience, transparency. It's been a goal of mine to assess the documents in my Google Docs, share as appropriate, and disseminate the information once available.
It's with that goal in mind that I'm releasing these 65+ documents. This release makes up only a fraction of the electronic documents that could tentatively be shared, but it's a start. There's some good stuff in there; also, some pretty useless stuff.
I look forward to continuing this exercise as the year goes on.
At the end of last year, my library school classmate Lane Wilkinson and I had this great email conversation. I had just posted Redefining Transliteracy, and he and I discussed the various implications of it. What I found most awesome were Lane's questions regarding definitions of words used in the language-based transliteracy definition: "What do you mean by language?", "What does encoding and decoding mean in this context?", etc.
Given that turnabout is fair play, and that Lane specifically requested feedback, I have a definition-based question regarding his recent post:
What definition of medium is used in this context?
Mean Medium? Mode?
To me, a medium is a go-between over time and space used to convey information:
An artist's medium might be oil on canvas
A telegraph's medium is electricity over wire
At the endpoint of a telegraph (or phone, or radio) is another medium — waves of sound over air
Medium can inform us about a lot of things. It can also confuse the issue. The reason I've pushed so hard for literacies to be defined as language skills is that many languages are relatively medium-agnostic. A letter written in ink on paper and one written in marker on posterboard are different in many ways, including both medium and aspects of visual language; but if the textual content of both is the same, the written language of both is equivalent. If that same text is on a computer screen or a television or a tattoo, the written language portion remains congruent.
In usage, people also tend to conflate medium with mode (semiotic modality). Modality is nearly a sensory means of categorization. Except it's not.
Whether medium or modality, questions arise:
Is there any difference between watching a video on television or on YouTube? Is it the video that's different? The screen? Or is it the non-video stuff that surrounds a YouTube video?
What about a watching a film on an old CRT and a new HD LCD? Different literacies?
Isn't print literacy a visual literacy? If medium or mode is important, what is the necessity of the distinction?
If someone reads text on a computer, is it print literacy or computer literacy or both? Why?
If both the medium and the mode of spoken word and of music is the same, in a medium-or-mode-literacy world can they be considered the same literacy?
Languages
Language requires a medium. Communicating (over time and space) constitutes information being encoded into signs and symbols and sent over a channel, then decoded by the receiver(s) to be interpreted. Often, though, changing the channel has little effect on the integrity of the semiotics. McLuhan's stickiest mind-virus, "the medium is the message," is widely misunderstood, and is dead wrong much more often than it is right.
Since literacies are abilities for a sender to write and a receiver to read a message, rather than abilities of either party to grok a medium, it makes more sense from a literacy taxonomy standpoint to define and categorize literacies by linguistic properties rather than media.
Also, I think the literacy ecosystem would be a lot cleaner if we could agree that, whether "information literacy" is actually a literacy or literacies or not, its name is a really crappy mistake.
Otherwise, the diagram is fantastic. It's especially astute because it shows how literacies named and in common use can be grouped, even if those named literacies are themselves problematic. Literacy sucks indeed.
I'd like to touch briefly on a widely-circulated LJ post by Aaron Schmidt entitled Resist That Redesign. It is generally good advice – using iterative website design rather than relying on complete redesigns. However, I think the advice needs better context.
For one thing, most library websites are really outdated and bad. Comparing the design/development workflows of Apple and Google (nice!) or Amazon and Netflix (not exactly gems of design) to how libraries maintain their sites is apples-to-oranges. If a library has a flat-file website (Not a straw man: this is common in libraries!), performing a complete redesign/redevelopment is probably advisable. A "slowly evolved" CMS developed in-house at a library is likely to be slapdash, and there are tons of available CMSes that are well-designed, secure, free, and supported.
What's not mentioned in the original post is that redesigns don't have to be long, painstaking processes. Bad redesign processes are that way, but a sufficiently-experienced and talented designer can ease those woes. The solution for doing a good redesign is to have a good designer.
Likewise, iterative design isn't always a breezy process, and it often isn't design. Design needs control; website creative control is often lacking in library environments. What often ends up happening under the guise of "iterative design" is actually a patchwork; sometimes from having too many cooks in the kitchen, sometimes from having one crummy cook. We've all seen these websites; they start out clean and freshly-designed. Then someone pastes in a widget and it clashes with the design. Then comes more widgets ad nauseum until the site looks and works awful. As such, the solution for doing good iterative design is to have a good designer.
Library folks: don't resist redesigns. If a well-designed website is important to you, hire a good web designer. Trust their judgment to decide whether the best course of action is to iteratively improve your site or to do a full redesign.
Last week, David Rothman posted Commensurable Nonsense (Transliteracy), a post critical of transliteracy from an Information Literacy perspective. David’s arguments were plausible-sounding fallacies, leading to some serious confusion.
tl;dr
Information Literacy is a bad name for really good concepts. Let’s change the name (again!) to avoid confusion.
Plausible Fallacies
Rothman’s post starts with the two most common definitions of literacy:
an ability to read and write
knowledge of a specific subject
Nothing wrong there. However, it’s implied that for the purposes of transliteracy the second definition is the important one. I don’t see how one would reach that conclusion, given that the definition of transliteracy quoted later in the post starts “Transliteracy is the ability to read, write and interact...,” pointing to the first definition rather than the second. Transliteracy is about reading and writing (or their equivalents in other senses/contexts); working from some different assumption is a straw man.
The second problem is that Information Literacy is not a literacy per his own criteria. If a literacy is an ability to read and write or knowledge of a particular subject, where does “Information Literacy is the set of skills needed to find, retrieve, analyze, and use information” fit? The common definitions of IL as critical skills are incompatible with the extended-but-conventional literacies of transliteracy. As such, comparing IL to transliteracy in such a manner has no bearing.
The second problem I mentioned — that Information Literacy isn’t a literacy — underlies the growing misconception. IL requires conventional literacies, but is not encompassing of them by definition. IL advocates apparently consider IL to be all-encompassing, but that’s a difficult-to-defend position. As such, the topics important to transliteracy, at least before last week, are distinct from IL.
The ensuing discussion has led to confusion over the practical boundaries of these terms. For instance, it isn’t clear how big transliteracy’s domain is per this newly-thin-air-pulled definition. In Why Transliteracy?, Lane insinuates transliteracy encompasses the Venn diagram of IL:
For me, transliteracy is the bridge between isolated spheres of information literacy,...
I'm only using transliteracy as a catch-all for one particular slice of information literacy that I haven't seen before.
This leads me to wonder: is transliteracy an umbrella over Information Literacy and other literacies as most everyone seemed to agree prior to last week, or just some small sliver of IL?
Call to Deprecate
It’s neither, of course! Information Literacy is the notable exception to the transliteracy umbrella. I hinted at this in my Redefining Transliteracy post and a smidge on twitter; here are the charges against IL’s compatibility with transliteracy:
Transliteracy is an ability to read and write across things (which I frame as languages, while others prefer platforms, tools, and media for some unknown reason), whereas IL is an ability to find and critique information
From a reading/writing lens, or any lens for that matter, all literacies are information literacies. IL as a term is redundant and overly-broad
However an information literate entity interacts with information, that interaction is indirect, as information does not exist in any raw form. IL as a term is non-specific to the point of triviality
I cite these charges as more than just a reason not to compare Information Literacy and transliteracy directly; I also contend that it’s reason to deprecate Information Literacy and call its skills something else.
We’ve done this before. As a field of study, Library and Information Science effectively deprecated the term “Bibliographic Instruction” in favor of “Information Literacy.” The reasons behind this switch, it appears to me, were fourfold:
Proponents of Bibliographic Instruction became entrenched in out-moded concepts and techniques, and were unwilling to adapt BI to new technologies and methods
The word ‘Bibliographic’ itself implies books. Library-ish instruction is about much more than books
Information Literacy as a term focuses on the skills of the learner, whereas Bibliographic Instruction as a term was about teaching those skills
Here’s what I’m proposing: From some point in the near future on, people talking about the useful, respectable principles currently referred to erroneously as “Information Literacy” should instead use the term [insert term here]. Previous references to Bibliographic Instruction, Information Literacy, and other less-than-ideal terms should be considered [insert term here] by implication.
Conclusion
I think transliteracy and Information Literacy are like peanut butter and jelly. You can have one without the other, but they’re usually better together. If we can remove the myth that IL is a literacy of comparison (through deprecation or social agreement), we can more effectively work to develop a helpful instructional ecosystem for our patrons. We can look at transliteracy for all the different ways people encode and decode information, and Information Literacy for the critical skills associated with that information parsing.
At the end of May I quoted Voltaire in my first transliteracy-related post: "Define your terms, you will permit me again to say, or we shall never understand one another." It's been a long process, but I feel I've defined a language model of transliteracy to a satisfactory extent. So before I demolish IL in the Information Literacy vs. transliteracy debate, I figured it would be fun to offer a practical example of the language model.
One thing came to mind when thinking of examples: Brian Hulsey's Everyday Transliteracy video. It's known as the "blueberry smoothie" video to many; it shows how someone might communicate the same message (a blueberry smoothie recipe) using different websites and other forms of communication, and all in a concise, friendly manner.
Let's look at the examples through a linguistic lens.
Written Language
Most examples involve some form of written language. In many cases, though, communication via a particular website or other form requires subtle changes of dialect or language variant.
Email
In many ways, the language used in email is most like that of a written letter from perhaps a century ago. If a writer wished to ignore clear, concise business style, he or she could write an email of flowery prose or any other style you might otherwise encounter in written language. To me, the written language of an email is something of a baseline for comparison to other language usage.
Twitter
Linguistically, twitter is an interesting variant. Where you might devote a whole paragraph in an email for a stand-alone idea, the standard on twitter is for one tweet (at 140 characters or fewer) to do the same. As such, someone familiar with the letter/email baseline might develop a workflow for converting their verbose ideas to tweet-appropriate length:
Write a sentence or two. See that it's a number of characters over the limit
Shorten any URLs (more on that later) to preserve space
Use common abbreviations
Go over entire text looking for places to re-word, perhaps with chat/SMS lingo
Start removing things like pronouns and the vowels from certain words
Remove punctuation that isn't absolutely necessary
Begin to question whether the idea(s) might require multiple tweets
There's more to it, such as @replies, but the above workflow is the gist. It's interesting, anecdotally at least, that tweets and text messages diverge somewhat in linguistic usage, despite their similarity in imposed length restrictions. Whereas it's common to use instant message-type lingo (lol, brb, stfu, etc.) in an SMS message, it's at least somewhat less common on twitter. It's also more accepted to go over the character limit in text messaging, while quite impractical on twitter.
Facebook
Facebook doesn't formally impose stringent length limits like twitter. A savvy facebook user, however, knows that a long status update will get cut off at a certain length; and the cut off text is only viewable after clicking a "read more" link. This leads to a subtly different usage than twitter. Facebook users are more likely to use full words in full sentences.
The combination of "read more" links and quoting the first three or so words of comments on profile pages means that effective facebook users avoid "burying the lead." Such users communicate in pithy, concise posts, with their thesis statement within the first few words.
Facebook users may sometimes forgo leading personal pronouns since their name is displayed before their status. This is a less-likely occurrence on twitter, where users are represented by short usernames rather than their actual names.
Blog
Blogs are similar to emails from a written language perspective. There are nuances, of course, but it's long-form writing with the optional addition of hypertext elements, just like rich email.
Telephone (or face-to-face)
Talking on the phone obviously isn't written language. However, I think it's a great basic example of transliteracy. Brian, in the video, reads the necessary amount of orange juice aloud off the screen. This is him reading (decoding) written language and speaking (writing, encoding) the same message into oral language. This is a basic transliteracy that many of us possess that we often take for granted.
A Post-It Note
Similar to long-form written language. For a message longer than originally intended, someone writing a post-it message might employ chat lingo and abbreviations, or might start writing smaller near the end of the message.
Other Languages
URLs
URLs are a written language construct all their own. I learned what URLs looked like, how they worked, and the intricacies of their syntax and semantics from using them, rather than by any formal instruction. However, an internet user can gain a lot from being instructed in URLs.
For instance, Brian was 100% correct to shorten the URL for the recipe before posting it to twitter, as that's common practice. On the other hand, he didn't show how he used the full URL for the resource in facebook. It's knowing usage rules like these that make URLs an important language literacy.
Hypertext
Written language is a special subset of visual language. Hypertext is where, on the web, written language and what we usually consider visual language intersect. Hypertext elements have default styles per user agent stylesheets in the browser, making them visual elements. They are also semantically-defined markup elements per their SGML syntax. So bold text or italic text or a link or a heading appear different from text not wrapped with any markup; the elements' semantics precede their appearance.
A web user who doesn't know how to identify the common appearance and function of hypertext elements would be at a great disadvantage. Often the appearance of form elements, for instance, are derived from similar UI elements from the base operating system's toolkit. However, sites will often style or re-implement elements like buttons, so the essence of button-like symbols is a useful and transferable visual language skill.
Note that in the video, Gmail, twitter, facebook, and WordPress all have similar, but at least somewhat-different, representations of buttons, text fields, text areas, rich text boxes, etc. I think it's in the subtleties of hypertext visual language that it's most practical to use the language model instead of the platforms/tools/media model.
Visual Language
Each site uses layout conventions involving columns, proportion, color, contrast, and other precepts of visual language. How they are similar and different is a teachable thing for those we might instruct. Knowing basic visual language of websites is a transferable skill.
Besides site layout, another interesting form of visual language are symbols, often used as icons. The Noun Project is a cool resource for exploring this aspect of visual language.
Conclusion
I've written a lot about a little, and have still managed to leave out a lot! The literacies at play when doing seemingly-simple things are often complex and varied.
What I wanted to demonstrate more than anything else is that the language model allows us to talk about all the same transliteracy things, but in a way that actually gets to the core literacies.
I think these language literacies allow us to work from a common set of terminology. They let us proceed quicker to developing more-universal and more useful curricula for instruction.
A point to ponder: Brian's video, many (myself included) contend, is a wonderful example of transliteracy. It does not, however, focus in any way on the critical abilities normally associated with Information Literacy.
A cool-looking box arrived unannounced at my apartment two days ago. It was Google's Cr-48 notebook for the Chrome OS Pilot Program. It was a pleasant surprise, and I've been happy trying to crash it for the last 48 hours. Here's an analysis of this gift horse's mouth:
Trackpad
A lot has been made of the Cr-48's keyboard's lack of a caps lock. To me, though, the trackpad is the interface device that has caused the most trouble so far.
On my [aluminum] MacBook, I'd configured the trackpad to right-click when the pad is clicked from the right region and left-click for the left region. This helps out in the OS quite a bit, but is most handy in the browser for "Open Link in new tab," I use that context menu item in reddit, Google Reader, facebook, and for 'shopping' in incognito mode; in other words, for the sites I visit most on the web. I could connect a mouse and click the scrollwheel and get back a lot of lost link-opening productivity, but I want to note that it would be a departure from my previous expectation of laptop trackpads. The "two finger click" right-click gesture on the Cr-48 is terribly-inconsistent and annoyingly-different from previous experiences.
I'm also personally used to a three-finger swipe on the trackpad to go back and forward. Having to use function keys, shortcuts, or move the mouse pointer and click are all super slow in comparison. It won't be fun to browse the web without these features.
Keyboard
I like the function keys a lot. They're: back, forward, reload, full screen, toggle windows, brightness down, brightness up, mute, volume down, volume up.
The search key replacing the caps lock is novel. However, when I accidentally hit the caps lock on any other computer, what I type continues to print to screen, albeit in all caps. On Chrome OS, a new tab pops open and what I type shows up in the omnibox. It hasn't happened yet, but I anticipate it'll cause me some annoyance. Since I use ctrl+t constantly and consistently to open a new tab, I don't really get a huge benefit from the replacement key.
The arrow keys are all scrunched. Meh.
What the keyboard needs desperately is a backlight. It's an all-black machine with a lowercase keyboard (a nice UI touch in my book, since the default letters that appear when you press the keys are lowercase), so it's hard to see what key you're pressing. Perhaps this will be less of a concern when I get used to the slightly-different layout. Also, it's testing hardware, so production mileage will vary. One thing that's occurred to me is that a backlit keyboard might make some of the trackpad issues more bearable.
Performance
Startup is snappy. In fact, it was a breezy process to get the notebook on the internet after unboxing it.
I've found that there's a slight delay in establishing connectivity after opening the lid, but it's not bad at all.
The OS would feel snappier and be more usable if the new tab page loaded faster. For me, it's a race between the URL coming up in the omnibox and the app link appearing on the new tab page. Since the tab page looks cool, I like when it wins the race sometimes.
The big performance problem is flash. I'm not sure if it's the hardware or flash itself or the sandboxing model or some combination of all those things, but watching video on this thing is just the worst. Since I'm a hulu junkie, keeping to my promise to use this as my primary machine is going to suck unless flash performance improves significantly. To be honest, I've already sort of gotten used to watching hulu all jumpy-like in just the last two days. Work with what you're given, I guess.
OS
It's Chrome. I like Chrome.
I think there's a legitimacy to the complaints that you can't really produce content effectively without a robust filesystem and using only web apps. However, I see these as solvable problems that will only get better with time. For instance, I'm confident in my present ability to produce documents in Google Docs (as I have for 3 years now), edit photos and make vector graphics in Aviary, and do other limited media production using web apps.
In order to do this more effectively, though, access to files on peripheral devices has to be better-supported. I've found the core file system satisfactory so far, but can envision it would be better if the various prompts were more unified and the keyboard shortcuts more memorable. I think it'd be cool if downloads piggybacked to my Google Docs storage asynchronously. If local files appeared in a Google Docs List-like interface with the ability to quickly search those files, I think it would be a knock out of the park.
Fun Stuff
ctrl+alt+t brings up the Chrome Shell, or crosh for short. It has a very limited list of commands. I was able to use ssh, so that's cool.
If you click "About Chrome OS" in the wrench menu and select "more info," you can switch between the beta and dev channels.
This note isn't just about Chrome OS, but about the web app store in general. Google specs a 128x128 icon for apps and extensions, but asks that they be 96 pixels square, centered, with padding. This makes the icon ecosystem inconsistent, since developers sometimes glaze over the part about the padding. For instance, Aviary's icon is huge compared to the Google icons.
Conclusion
There are some things I don't like that are probably easy fixes; or they won't apply to consumer hardware. Once the OS gets those fixes or I get used to living without them, this will be a great machine for surfing the web and for occasionally producing stuff.
I'm optimistic that the web is moving forward, and that the few remaining things I rely upon desktop apps for will have viable cloud-based equivalents soon. I'm also confident that Chrome OS will have a novel, simple, usable solution for handling peripheral storage devices and for the necessary interaction with some sort of file system.
It's been fun these past two days, and I look forward to testing this machine a lot more.
