As part of a new course I’m working on, the course team has been making use of shared Google docs for working up the course proposal and “D0” (zero’th draft; key topics to be covered in each of the weekly sessions). Although the course production hasn’t been approved yet, we’ve started drafting the actual course materials, with an agreement to share them for comment via Google docs.
The approach I’ve taken is to created a shared folder with the rest of the course teams, and set up documents for each of the weekly sessions I’ve taken the lead on.
The documents in this folder are all available to other members of the course team – for reference and /or comment – at any time, and represent the “live”/most current version of each document I’m working on. I suspect that others in the course team may take a more cautious approach, only sharing a doc when it’s in a suitable state for handover – or at least, comment – but that’s fine too. My docs can of course be used that way as well – no-one has to look at them until I do “hand them over” for full comment at the end of the first draft stage.
But what if others, such as the course team chair or course manager, do want to keep check on progress over the coming weeks?
The file listing shown above doesn’t give a lot away about the stare of each document, not even a file size, only when it was last worked on. So it struck me that it might be useful to have a visual indicator (such as a horizontal progress bar) about the progress on each document so that someone looking at the listing would know whether there was any point opening a document to have a look inside at all…
..because at the current time, a lot of the docs are just stubs, identifying tasks to be done.
Progress could be measured by proxy indicators, such as file size, “page count” equivalent, or line count. In these cases, the progress meter could be updated automatically. Additional insight could be provided by associating a target line count or page length metadata element, providing additional feedback to the author about progress with respect to that target. If a document exceeds the planned length, the progress meter should carry on going, possibly with a different colour denoting the overrun.
There are a couple of problems at least with this approach – documents that are being worked on may blend scruffy working notes along with actual “finished” text; several versions of the same paragraph may exist as authors try out different approaches, all adding to the line count. Long copied chunks from other sources may be in the text as working references, and so on.
So how about an additional piece of metadata for docs additionally tagged as “task” type in which a user can set a quick progress percentage estimate (a slider widget would make this easy to update) that is displayed in a bar on the file listing. Anyone checking the folder could then – at a glance – see which docs were worth looking at based on progress within the document-as-task. (Of course, having metadata available also opens up the possibility of additional mission creeping features, rulesets for generating alerts when a doc hits a particular percentage completion, for example.)
I’m not looking for more project management tools to take time away from a task, but in this case think the simple addition of a “progress” metadata element could weave an element of project management support into this sort of workflow? (changing the title of the doc would be another way – eg adding (20% done) to the title…
Thinks: hmm, I procrastinating, aren’t I? I should really be working on one of those docs…;-)
OUseful.Info, the blog... 
The problem with automatic measures of progress is that its a bit like using “number of code lines” to measure progress in programming. I remember realising that some of my most productive days as a programmer where the ones where I mainly deleted code.
But perhaps you could script the docs to ask the authors for “% complete?” when they close them, and collate the responses in a spreadsheet?
Of course, an alternative would be to use a task manager, like Asana. That would also cover tasks that go across documents.
btw, Is this a course in python?
@Yishay
Yes, but, on the lines of code. OU has nominal mappings on words/pages-hour for planning student workload. Also, as a doc author, I know if I’ve only written one of ten planned sections in a doc, whether I’ve finished 3, sketched two and not started 4, etc. Which is why I tried to suggest that auto measures are a bit rubbish.
The main idea is that the author sets some sort of flag so that folk know whether there is any point having a look at a particular doc without opening it. Also, the measure may be useful guide to the author about work still to be done.
As to the course being in Python – yes, plan is to use IPython notebook running with various databases on an OU supplied VM config.