The other day I discovered #800×80, an art project by @arc4g and @lochieaxon, and since then I’ve been having so much fun goofing-off and creating and sharing animated gifs in a “weird resolution” with some supremely talented and amazingly skilled like-minded people on Twitter – we need more weird resolution art, right?
Cycling in the wet at night is fun.
For a while I’ve been thinking about how adopt a different approach to tooling in our team, beyond nameless and obtuse groups of tools built on google sheets that record and reveal information about our projects.
I think there’s value in considering these tools more like colleagues and team members with position descriptions and real roles to perform. I also think there’s value in extending the metaphor to the point of giving these team members names, for fun and function.
Meet the team
Introducing Wanda, Dennis, Terry, Justin, Gordon, Velma, Valerie, Bruce and Pam – as google sheets and valued colleagues, their job is capture logistical information such as hours on task, courses scheduled, course and production information etc. Super helpful, but I think there’s something more we can add to their position descriptions.
I often need to provide a quantitative update on a project e.g., hours used, progress etc but I try to add a qualitative element to add meaning and context to the reporting.
Right now, I capture this in a centre sanctioned meeting log for each project, but it’s overly formatted google doc and divorced from other tools and project contexts we use to capture and share information about a project – it’s hard to maintain, access and isn’t as helpful as it could be.
Exposition and inspiration for another skillsetIn the UK, the National Health Service uses patient diaries with critically ill patients – they may also be used here in Australia and other jurisdictions, but I heard about the UK variant so that’s my inspo.
“Patient diaries can be used to help patients understand and come to terms with what has happened to them whilst they have been critically ill. Diaries provide a factual account of what has happened in Critical Care so filling gaps in memory. They provide a context for memories that exist and can help dispel inaccurate and delusional beliefs.”
Because rehabilitation is recommended
“following critical illness starts as soon as possible and addresses psychological as well as physical symptoms. Equipping patients with a better understanding of what has happened to them in Critical Care may help to set realistic goals for recovery and minimise the risk of adverse long term problems”
The patient diary is accessible by family and friends and should not contain information confidential to the patient or to close relatives only.”
Patient diaries need to be
“easily accessible and started promptly for any patient who may benefit.”
What to write? It’s a good a question and the
“simple rule is that anything you are prepared to tell the patient, and that the patient is willing to share with family and friends, you can write down.”
“All staff in the multi-disciplinary team should be encouraged to contribute to the diary to give it added depth and meaning. Factual detail on the patient’s condition and observation of their behaviour and environment can all be helpful.”
“It is helpful to note the date and time of events and to write the diary, when possible, in sequential order. Jargon and abbreviations should be avoided, as they should be with any communication with patients and relatives. Similarly, avoid information confidential to the patient as others will read the diary.”
Bringing it back to our context
Our projects are patients, and although I don’t believe our projects are critically ill, they do require a high level of care throughout their journey from inception to delivery. Reporting on the projects journey needs to be quantitative and qualitative and easily available to everyone at any time.
Here’s what I’m thinking.
I don’t believe we need to create another colleague just to capture each diary entry because we have Wanda and Dennis and they already communicate really well, and I want this feature to be super-quick to be developed and to be carried out throughout our work shifts.
What about adding another work type to Wanda e.g., 10. Reflection and then another column to the right of “Notes” called Diary. Each entry is an observation.
BTW, I’m not wedded to a new work type but I wanted to allocate time to reflection, which is a separate activity and different from development – notes feature isn’t reflection.
For Dennis, add a column e.g., Diary and then pull in all dates and diary entries related to that project, much like he does for total team time (hours) and person.
What do you reckon – yeah or nah?
Building on the momentum of making my way through my very, very first noise displacement tutorial, I had a go at Polyhop’s instancing geometry in TouchDesigner tutorial.
Again, you literally start with a ‘blank canvas’ and then slowly build up a network that results in a fun and visually interesting output.
My key takeaways
- It’s possible to assemble 3D forms from various geometry with a merge SOP.
- You can use Python expressions to access parameters e.g., scale and height of spheres at the end of the tube – super cool and efficient!
- Split the screen to create a clear and uncluttered workspace e.g., TOP viewer, and then Display modal window, and uncheck background CHOPs.
- Because Nulls act like a conduit, they’re great for creating space and increasing flexibility in a network – easier to swap out or experiment with inputs in a given network.
- Polyhop’s expression “moving a SOP to CHOP land” – love it!
Super-stoked about taking my very first steps with the visual coding software TouchDesigner by making my way through Polyhop’s Noise Displacement Tutorial – it’s a fun tutorial with just the right amount of detail designed especially for first timers like me.
You literally start with a ‘blank canvas’ and then over time slowly build up to something something visually interesting and fun to play with – I’m most likely going to adopt this workflow while I’m still finding my feet with TouchDesigner.
My key takeaways
- Learning how to chain together Noise TOPs
- Using Nulls to connect nodes
- Polyhop’s expression “toot the parameters” – love it!
Today I spoke to the team about how we might explore the use of a tool/service that allows us to easily store, manage and share regularly used content and/or code snippets.
I was really interested in hearing from them if exploring the use of tools/service is something worth doing? Remembering this is not so much about creating cookie-cutter courses (because they’re all individual and unique), but more about creating readily reusable code that forms the foundation.
An example – while the set of Arts translation and interpreting courses are based on a template for their structure, there’s still a large number of frequently used elements (call-out boxes, buttons, accordions etc) that would benefit from their code, CSS and event instructional copy being stored in a readily available single source.
What we do now
I think we currently store our HTML and CSS in a variety of places e.g., google docs, google sheets and homebrew tools e.g., Velma, Wanda, Dennis, Terry, Justin, Gordon, Valerie, Bruce or Pam. We store our instructional copy in our storyboards because it’s usually heavily intertwined with the content (and is developed at different stages of the production pipeline and features contributions from outside the team) – I’m being careful not to conflate the two.
Doing this isn’t necessarily a problem but is it the most efficient way? How might we use more tools like:
Dreamweaver (and it’s snippets feature to reuse code chunks across “sites” i.e., courses) – this software is available to us through our Monash Creative Cloud subscription – using Dreamweaver means we can also make use of the visual tools to generate/edit HTML if you didn’t want to do it by hand with a text editor/.
A private repo on GitHub – how might we all have access to the single source and most current code chunks by storing these elements on a private repo – we have access to this with our yearly subscription to GitHub (this is where all of the course content for the data science microcredential is stored).
We could use Dreamweaver in tandem with Github, or not at all – we could continue to code all HTML and CSS by hand then store on Github. Snippets of instructional copy could also be managed in this way – I can’t be the only person that has frequently used phrases or FUPs as I sometimes like to call them, right?
Another approach is creating our own BEAST (like the team from the Faculty of Education), an online code generator like the team in Arts have – how might that help?
Is it possible to create a library of assets/elements in Moodle Workplace that we can then import/load in individually as required in a course?
Why do this?
My reasoning behind this is that there must be ways for us to increase efficiency of writing (instructional copy) and authoring our courses (using HTML, CSS and instructional copy) in the platform (Moodle), particularly those that are a set of courses with an established styles e.g., Arts T&I, or even the Business Exec Courses – repurposing these elements may be one way of achieving this, maybe.
What do you think – yeah, nah?