I have published a (rushed, but I can never get my mind still enough to do this properly…) very early proposal for a new document format. Your comments would be very much appreciated indeed:
Frode asks (Facebook status update, 20151027) “Is interactivity a crucial or trivial part of text, in terms of knowledge work?”
The trivial superficial response is “trivial”. The deeper crucial response is “crucial”. But beyond the wordplay gamification:
I’ll respond in terms of “how we experience text”.
When I am “reading” as in “consuming text”, inasmuch as “text” can appear like what used to be called “paper”, and inasmuch as paper could be viewed as “non-interactive”, then the answer here would be on the “trivial” side of the question.
Insofar as we are LIVE, as in living beings, and living beings shift focus from object / issue to object / issue, and physically move, and receive dynamic stimuli from varied sources… then as we “experience text”, we will need to contend with a number of distractions, and attend to a number of ancillary needs, as we try to extract as much meaning and understanding as possible from that text.
- For example, I may encounter a topic, concept, or term that I am unfamiliar with. I may most optimally need to divert myself to addressing that knowledge gap so that I can then optimally experience the original text / document with the best possible frame of mind to leverage that text for whatever purposes.
- In another example, I may want to drill into a particular presentation or line of reasoning, and may want to “lay it out” spatially, or reorganize it some way, so I can look at associated “nodes” or “chunks” of knowledge, to really follow implications and make the most of the connection points between the material and my existing mental model.
- I may need to put my ingest of the material (reading) on “pause”, as life gets in the way of my full attention. After the distraction, I may need to reconstruct my mental context, which may have been lost while I dealt with the demands of that life distraction.l
- I may want to create a citation, or note, or “transclusion” of some sort… so that I can add a snippet or the entire work into my “personal knowledge repository”.
- I’m sure I can come up with more use cases…
So my more serious response is that interactivity is a key enabling mode that can be designed, optimized, adapted, etc. so that knowledge work can be as effective as possible.
I’ll start with understanding clearly what I want to achieve.
- What do I want my reader to “take away” after reading my writing?
Create a workable plan that will achieve that / those result(s)
- What progression of content (to be created or curated / cited) will create that line of reasoning and shift in mental model?
- What could make it most compelling?
- Where shall I put this contribution / artifact?
Create an artifact with this plan.
- The plan is a set of TODO items for the artifact
- This plan is metacontent.
- As sections of content get created, the metacontent can be “checked off” and made invisible
- The metacontent can evolve as the content evolves. It’s essentially the “backlog” for the content creation project
- Appendix / Final section: Where this document exists on the Internet. What single location is authoritative?
Once the metacontent has dwindled to “nothing”, the document / artifact is DONE.
When discussing application, infrastructures, protocols, messaging, etc. it is necessary to precisely agree on semantics of expressions in order to avoid “mistakes”. However, HTML as a representation format has survived largely due to its ability to “tolerate” expressions that are not understood… the browser just ignores those expressions. That has allowed “backward compatibility” of HTML and browser versions, as new language constructs can be introduced that are just seamlessly (mostly) just ignored by older browsers.
Recently, Frode has introduced a need to discuss representation formats. One very strong reason Frode likes HTML is this ability to tolerate expressions that are not currently understood.
Sam (I) was asked by Frode today “If you went off on your own today with $2M+ to build something, what would you build?” I recalled my early 90’s desire to build a “spreadliner” – an application (we thought in terms of apps in those days) that could take a chunk of text, and allow those memes to be spread out spatially so that visual relationships could be depicted (not just mind-mapped), and also have individual nodes / chunks / memes that could be attributed so that they could be viewed in tabular, or spreadsheet, views. Fundamentally, I (Sam) seek knowledge representation that can allow multiple presentation modes (Doug calls them viewspecs), clearly separating the KNOWLEDGE from the PRESENTATION OF THAT KNOWLEDGE. (reference here to GlobalSIM vs GlobalVIZ).
In order that the knowledge be presentable in multiple views, we must design knowledge representation in such a way that metadata required for one view be non-harmful to the fundamental knowledge object, or to other views.
What is still a question is WHERE this metadata ought be located. Is it a part of the knowledge itself? Arguably, it is NOT essential to the knowledge itself, but to the viewspec / presentation mode that is being applied at viewtime.
More to be mulled…
We each have our own diction, aka language. We use terms the way we understand them, regardless of whether they are completely consistent with the “correct” dictionary definitions. For basic everyday terms, this usually is not a problem, and usually no difficulty in the course of human interactions.
In domains with specialization of terms, eg. medicine, construction, sciences, and other highly skilled and technical areas of activity, these differences in meaning / definition / usage / implication / etc. can lead to project complications and even failures, if not caught and managed well.
Dictipedia is a toolset and set of practices that recognize and facilitate that “we each travel with our own language”, and that when we come together to collaborate, or to form teams, bringing these “languages” together is a necessary step in team formation.
- Recognizes that we each have terms and phrases that carry certain meanings to each of us as individuals
- Recognizes that we have potentially conflicting or at least inconsistent meanings when we use the same terms and phrases
- Recognizes that explicating these terms and phrase differences for discussion and eventual resolution is a Good Thing in team formation
- Recognizes that as we go from team to team, we pick up and migrate terms and phrases and bring them into our next teams
- Assists in bringing forth the discussions necessary to align terms, phrases, and concepts
- Assists in tracing the derivation of meanings from individual to individual, team to team, etc.
- Assists in bringing language to the fore as a key First Class Object in team formation
- Assists in disambiguating language so that the team can be in flow as quickly as possible
A dictipedia (noun) is an asset of an individual. A dictipedia is an asset of a team. Allowing teams to form with multiple individuals from potentially different backgrounds, and for teams to form, execute, dissolve, etc. is a key tenet of dictipedia’s services.
Much more coming…
Here’s a quick version of how we’ve (Amigos) agreed to utilize KFJournal.org:
- We each will blog wherever we are most comfortable.
- If it’s NOT at KFJournal, we will post a link to that blog at KFJournal
- Add your blog to a category. If no category exists, create one if you think it’s sensible and appropriate.
- If you want to COMMENT or review another’s blog, do it there (where it is originally posted), or write in your favorite blogging location, and link to it, citing the article you are reviewing / commenting on.
Follow on to: “Thanks to Frode”
Here’s an example RoE for a project team I ran a few years ago: Gucci
We will revise this as we need.
When a new project or team forms, I like to create or designate these minimal 9 artifacts in the shared memory (knowledge repository). This can be a wiki, or something more sophisticated, but here they are:
- Contacts List – Who are we and how can we contact each other?
- Glossary – What terms do we use and what do they mean?
- Project Charter – Why does this project / team exist?
- Rules of Engagement – How do we work with each other?
- Chronolog – Communications, esp meetings notes
- Action Item Tracking System – How do we track what needs to be done?
- Calendar – What happens when
- References – Links to other related and relevant material
- Conversation Space – Where the conversation happens, sp. in written asynchronous form
Let’s take a closer look at each:
- Contacts List. This should be a list of who, role, contact info – so that anyone can reach anyone else, whenever needed (even 24/7). Collaboration typically starts with “Let’s work together”, though after a project has been in existence for a while, “joining a collaboration” is more operational than “forming new collaboration”
- Glossary. The team keeps its terms explicitly visible. Where are may be alternative meanings, they are kept until the team resolves into new terminology, or resolves differences among the multiple meanings / definitions. At creation of a new collaboration, the key foundational concepts / terms can be captured to start such a glossary, and this serves to orient subsequent new members to the team.
- Project Charter. This is a statement of WHY the project or team has been formed. It should be clear enough that prioritizing any other decision or action can be assessed as necessary or irrelevant with respect to this charter. The charter is built out of the seed terms, by the seed founding team. The charter can be revised when appropriate, as decided by the team itself. Eventually, the charter should stabilize as the team understands what its purpose, mission, and goals are.
- Rules of Engagement. This is HOW the team will utilize its collective skills and resources to accomplish its objective, including deciding HOW. This needs to be acknowledged by each team member, and ought be created by the founding team members (one or more, up to all).
- Team Decisions. Decisions that have already been adopted by the team that should be the first practice of newcomers. Practices and decisions can be reviewed by the team if new information / options are available.
- How do we make decisions?
- Where do we keep our work?
- How do we communicate with each other?
- How do we change a decision?
- How do we add members to this team?
- How do we expel members from this team?
- How do we manage assets? liabilities?
- Legal issues / questions / ownership / liabilities / asset management
- Use cases. Use cases are the WHAT that the team will do.
- Methods. Methods are HOW to do the WHAT.
- Chronolog. A time-ordered log of team events, decisions, and actions helps provide historical context for defining moments, and also for newcomers to the team so that they can assimilate this history without requiring inordinate overhead from existing team members for onboarding the newcomer. Past decisions can be seen in temporal context, and the raw materials can be used to be authoritative.
- Action Item Tracking System. Actions taken as a result of planning, or meetings, or other team function, can be tracked in an AITS so that progress along all threads of activities can be explicitly visible and transparently shared among all team members. Sequences of actions create projects or larger-scale collaboration frameworks, but atomically all break down into specific action items.
- Calendar. This allows standard time-based views to be seen in forms familiar to those used to planning things in calendar mode. A calendar that is project-centric needs to offer events and other time-tagged objects that can then be viewed in personal calendars. This way, a project-centric sense of momentum, status, direction, etc. can be leveraged, although personal tracking will likely be based on personal calendars.
- References. These can be background and 3rd party material that provides context for THIS specific project / team, such as: guidelines, meeting minutes, related technical detail, competition, activities in the ecosystem, relevant vision statements, etc. A single place for such references assists all team members to sharing equal access to 3rd party content.
- Conversation Space. This can be a facility where conversations happen. Short of an actual physical meeting place (also useful, some limitations), for geographically dispersed teams, this is usually a content-based (usually text) platform like Slack, Mattermost, Skype, Facebook (limitations), or similar tool that keeps group conversation history (NOT Slack4Business) so that anyone can come to it, and get the background & context.
These nine artifacts are not meant to be comprehensive; it is merely suggested that these seed initial artifacts can accelerate the team’s achievement of PERFORMANCE mode.
More details later…
I’ve tried blogging before; it was a struggle:
- Do people care at all about what I think?
- Once I write something, am I liable for that thought forever?
- Perhaps I’m wrong…
- Suppose this blogging place goes away…?
- Is this the best place to put this?
So today, I’ve resolved to create my blog entries in the most permanent place I know, and then use OTHER blogging presences for “publishing” those blogs.
Today, the most permanent place I know is Google. They’re big, and they’re relatively open compared to other big places. And gDocs is a minimally viable place to write 😉
I will NOT treat my blogs as PERMANENT. I will retain the privilege and responsibility of updating my blogs if I feel they need it. They most always will need updating, as I will write from what I know at time of writing. Later, I am likely to have learned, and may choose to update my writing to reflect that new understanding.
Commentary on my blogs will unfortunately be relevant to specific versions / revisions of my blog entries. Hopefully, I choose blogging places that understand versioning.
So this is my “coming out” blog entry