Workshop Cheats - coda Doctorate 3Q22

Explore

coda Maker Cheats

Document Design Considerations
Document Design Considerations

This link can't be embedded.⁠

⁠

As this doc is being created as part of the coda Doctorate (3Q22 Cohort), there were many question to be acted and answered about the reasons why (the famous Eigenquestion), as well as consideration about how to implement. Some of the answers are recorded here, others can be found in the discussions supporting the

Moderator Data⁠

, the

Content Data Structures⁠

, as well as in the [[not yet properly documented]] implementation detail of both the

The Display Workspace⁠

and

The Creative Workspace⁠

And yes! These notes were written before implementation began. Any revisions or additions are clearly marked as P.S..

Purpose and Premise
⁠

What problem would you like to solve?

Support for the development, discussion and extension of a Business Model Canvas.

For whom?

Those involved in the Business Model Canvas development and discussion process, either as contributors or as moderators. Those interested in improved workshop quality and deliverables.

What are the top features of the doc?

⁠

Cheat Sheet content - high quality content to drive the discussion, to set the appropriate flight level and to establish quality standards

⁠

Display Workspace - a space to facilitate discussion of the Cheat Sheet content or other versions of the Business Model Canvas

⁠

Creative Workspace - a space to dissect, discuss, extend and enhance the content detail during the development process

⁠

Moderator Tools - supporting the workshop process, participants and individual discussions with their deliverables

Where will people use this doc?

This document will be used primarily in an office environment, working individually or as part of a group. The user device is most likely to be a desktop or a laptop PC, although a mobile device may be used occasionally to view content, review progress etc. P.S.: the nature of the content and the way it is/ needs to be presented means that this doc works better on a reasonably sized monitor than on a mobile device.

When will people use this doc?

Within a workshop context, working individually or in a group, located on-site or remotely. Most importantly, support should be provided for people working asynchronously - contributing to the process at the time that suits them best.

Who will use this doc?

This doc will have two main user types

Workshop Moderators - who are considered to be / become experienced users of coda and the doc itself

Workshop Participants - who are assumed to be not proficient coda users, who may need more guidance and background in the purpose, structure and usage of both the doc and the subject matter content

Further, the document addresses the coda community

⁠

, who might be interested in the design considerations, how things are done and other niceties that aren’t of general interest.

Which packs might you use?

Potential candidates and use cases:

gMail - invite participants, forward documentation and workshop deliverables

Cross-doc Plus - sync master copy of Cheat Sheet data to workshop doc; update master data from workshop additions; examine paid access to Cheat Sheet Content (using “*” for sample content and customer specific secrets for paid content) P.S.: this requirement didn’t actually arise in the current implementation, but mainly because the notion of Content Cheat Sheets wasn’t fully developed

Which templates/ patterns might you use?

Potential candidates and use cases:

To-Do List - making this doc; moderator workshop checklist; participant checklists; tracking participant interactions P.S.: Used only to manage implementation of the doc and as an

Ad-Hoc To-Do List for the Moderator⁠

⁠

Bulk Add - adding moderator tasks on a per-participant basis P.S.: This is a key element in the implementation of Task Assignment

Office Hours Questions - tracking participants questions P.S.: Used in a manner in the Contributions & Conversations functionality, but not in as structured a way as the original

P.S.: Text Placeholders - developed further to many workshop-specific contexts

P.S.: A pattern we’d call a 1:N Table Structure - despite our best efforts, we couldn’t get

The Creative Workspace⁠

to give us a usable presentation of the Item table data. Different views and layouts just weren’t working. Instead we created a new Table with Building Blocks (the 1:) as the display column and multi-select lookups (the :N) of the Items table creating the accumulation we needed.

P.S.: We also used a simple ThisRow() , without any .Item lookup on the Items table, as a sort of Recursive Lookup to create a nice-looking

chip

⁠

representation of the Item itself (a text column) for use in the Workspace canvasses

What infrastructure challenges might be involved?

Audit Trail, Versioning - the doc application would benefit greatly from an ability to rollback (to reset spurious changes) and/or to re-set content to the original Cheat Sheet version. Currently coda does not seem to provide much useful support in this area, although there have been hints that this will change in an upcoming version P.S.: This turned out to be unnecessary. Hat tip to

@Hannah Rochau⁠

for providing a simple approach, which would have done the trick. However, the workshop-centric nature of the data meant that complicated time-based data cleansing wasn’t really necessary

Document Design
⁠

Sketch out your doc’s basic design.

Version 1 (2nd August 2022) looked like this and shows interface layouts, buttons, displays and data structures all mixed up. However, it serves well as a starting point for a database design discussion. P.S.: And it didn’t change much at all during implementation 🤩

⁠

What are are the basic blocks?

The core functionality facilitates participation in an interactive or asynchronous workshop session and consists of a Display Workspace and a Creative Workspace, supported by straightforward data structures. These issues were already addressed in the

Bootcamp Capstone doc⁠

The moderator functionality (working title: Moderator Dashboard) supports the setup, running and documentation of workshop sessions. It will comprise Checklists, Participant Management, and Data Housekeeping functionality.

What are the basic flows?

Workshop Participants - a relatively simple flow that should work similarly for on-site or remote, asynchronous sessions:

Welcome

Background to the Business Model Canvas and it’s use

Background to the Display Workspace and the Creative Workspace

Optional: Help/FAQs and Office Hours Questions

Display Workspace

Iterative loops through Creative Workspace, Display Workspace, Creative Workspace

Voting, content promotion

Conclusion

Workshop Moderators - a more complex flow, involving setup and house-keeping tasks:

Note: this is a preliminary list - needs adjustment/ correction when the doc is completed

Setup workshop doc - copy doc [Alternative: reset doc contents]

Work through Setup Checklist

Add workshop details - date, time, [submission dates,] [office hour dates,] [other scheduling information,] venue, participants, other stakeholders

Bulk Add Data - add[, schedule] tasks per participant

Share workshop doc - make doc available to participants and other relevant parties

Work through Moderation Checklist

Walk-though the workshop, supporting, explaining and moderating the process outlined for the participants

Conduct voting sessions

Promote content, as appropriate

Moderate final discussion, summary and close

Distribute documentation and other deliverables

Work through Tidy-Up Checklist

Determine if workshop results - particularly content additions - need to be incorporated into Master doc and modify as appropriate

[Reset doc contents - depending on “rules of play”]

P.S.: These flows were (more or less) implemented as described. “More or less” because the moderator can define both tasks and task sequence on a per-role basis, giving much more flexibility

Are any special controls needed?

It is envisaged that a set of Controls and Automations will link the two functional blocks.

Buttons within the Moderation Checklist could restrict access/ display/ functionality of the Workspaces in line with workshop progress P.S.: This idea wasn’t further developed or implemented

Specifically, the voting and content promotion functionality should be under the moderator’s control P.S.: Done

Moderator controls should manage data additions and cleansing, including the (re-)population of the (mirrored) Canvas data on the user side [subject to the rules of play] P.S.: Done - very successfully

P.S.: In addition, quite complex control synchronisation was implemented to allow the moderator to control the data seen by all participants - and then to allow the participants to override the moderator’s choice with individual selections

Open Design Questions

Determine Rules of Play

Multiple copies - Master and copies, one per workshop

Consolidation of results is an issue

Content promotion from multiple workshops is an issue

Single Copy without versioning

Requires clean up after use - all/ some data maintained/ cleansed

Source information for added content is lost [Option: simple Created() and CreatedBy() stamping]

P.S. Chosen Approach: Single Copy with Workshop versions - multiple workshop sessions, within one document

Supports iterative development over several workshops

Supports content consolidation

Allows adding of content to Master Cheat Sheet data set

Supports basis Audit Trail

Database Design
⁠

What is your dataset? Or datasets?

P.S.: Please refer directly to the

Content Data Structures⁠

and to the

Moderator Data⁠

documentation

Business Model Canvas Items

By Source and Status

Cheat Sheet content

User generated suggestions

Accepted additional content

Rejected Cheat Sheet content

By Perspective

Internal View

Customer View

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Document Design ConsiderationsDocument Design Considerations

Purpose and Premise ⁠