What is WYSIWYDo?

WYSIWYDo is the infrastructure (tooling, applications, protocols, practices, principles,…) to support atomic-level collaboration: The 2-person agreement. WYSIWYDo is intended to scale from this micro-level to macro-level collaboration at global scale.

    • WYSIWYDo incorporates a basic state model for collaborative interactions. It is simple, but extensible.
    • WYSIWYDo recommends a protocol for negotiating (exploring, requesting, confirming, executing, confirming, closing) action items.
    • WYSIWYDo incorporates an extension model whereby it can integrate seamlessly with other applications and services.
    • WYSIWYDo will be available on the web, as well as on mobile devices in order to always be available to support collaborative interactions.

 

Much more to be added here… This is just a placeholder start.

What is Program For The Future?

What is “Program For The Future”?

  1. PFTF originally was the 2008 Conference held December 9,10 208 at the San Jose Tech Museum. The organizers included: Mei Lin Fung, Valerie Landau, Eileen Clegg, Darla Hewett, Joel Orr, Robert Stephenson, Bob Ketner, and Sam Hahn. This conference was held on this date because it was the 40th anniversary of the MOAD. The event was attended by notables such as Steve Wozniak, Alan Kay, Andy van Damme, Ted Nelson, Peter Norvig, … and Doug himself.
  2. PFTF is the name associated with a series of conferences starting with 2008, but including 2010, 2013, and upcoming: 2015 and 2018.
    • 2010 Was organized by Eileen Clegg, Mei Lin Fung, and Sam Hahn
    • 2013 Was organized by Dino Karabeg and Sam Hahn
    • 2015 Will be organized by Frode Hegland, Kennan Salinero, Pavel Shukla, and Sam Hahn
  3. PFTF was the (now lapsed) LLC name for a legal entity that was created to manage assets and liabilities associated with event organization (original managing partners: Eileen Clegg, Darla Hewett, Sam Hahn).
  4. PFTF is the name of a community of individuals who remember and honor Doug and his achievements, and support the general direction of developing collective capability that Doug used as a research agenda.
  5. PFTF is a set of principles (curated by Sam Hahn) that include those most pertinent to those driving Doug’s work. They are:
    • Address Planetary Issues
    • Scale Our Collective Capability
    • CoEvolve our Tool-Systems and Human-Systems
    • Bootstrap
    • Grow a Community
    • Spawn Inter-Supporting Initiatives
    • Improve the Improvers (Apply ABC Model)
    • Inspired and Guided by Doug Engelbart

What is Tweach?

Tweach is an experiment in crowdsourcing life lessons, HOWTO’s, etc. and an attempt to leverage “big data” to come up with how we can guide ourselves and our next generations, based on what previous generations have learned and passed on. It’s an attempt to use Twitter (mostly, though other social media forums could work as well) to share what we learned when.

Proposed Hashtags:

  • #WhenIwas1
  • #WhenIwas2
  • #WhenIwas3
  • #WhenIwas29
  • #WhenIwasInMy20’s
  • #WhenIwasInMy30’s
  • #WhenIwasInMy40’s
  • #WhenIwasInMy50’s
  • #WhenIGraduatedHS
  • #WhenIGotBS
  • #WhenIGotBA
  • #WhenIGotMS
  • #WhenIGotMA
  • #WhenIGotPhD
  • #WhenIGotFired
  • #WhenIGotHired
  • #WhenIGotMarried
  • #WhenIGotDivorced
  • #WhenMyDogDied
  • #WhenMyWifeDied
  • #WhenMy…
  • #WhenI…
  • … lots to be defined

Each of us posts what we learned, with one of these tags. Once enough of us do this, there’s lots to be done with “big data” and pattern analysis to compile very interesting complement to “wikipedia”. Obviously this grows and morphs over time and contributions.

KFJournal.org RoE

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.

9 Artifacts To Seed a Project Team

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:

    1. Contacts List – Who are we and how can we contact each other?
    2. Glossary – What terms do we use and what do they mean?
    3. Project Charter – Why does this project / team exist?
    4. Rules of Engagement – How do we work with each other?
    5. Chronolog – Communications, esp meetings notes
    6. Action Item Tracking System – How do we track what needs to be done?
    7. Calendar – What happens when
    8. References – Links to other related and relevant material
    9. Conversation Space – Where the conversation happens, sp. in written asynchronous form

Let’s take a closer look at each:

  1. 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”
  2. 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.
  3. 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.
  4. 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).
    Elements are:

    • 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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 will blog

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 :)

Sam’s response to Frode’s “Liquid | Space (thoughts for spec)”

Re:  Liquid | Space (thoughts for spec)

Frode, et al –
Great contribution to the discussion!!
Here are some (possibly cryptic) followup thoughts for your consideration:
Regards – Sam


Criteria:

  • Multiple Layouts – created by author
  • Multiple layouts – selected / controlled by user
  • Thinking about (all multiples)
    • relationships (peer-level associations), as well as
    • drilling into detail (drilling down), as well as
    • understanding context (drilling up)

Visual Design

  • For diagrams, it is useful to use visual indicators (colors, line style, line width, icons, size, etc) to bring out intended message or meme to be conveyed in that presentation instance (message)
  • Diagram operations can be a separate discussion, as it can be quite an extensive set of actions / use cases
  • Any VISUAL DESIGN issue is a PRESENTATION ISSUE.
    • in AUTHOR mode, PRESENTATION is for the AUTHOR, and assists in the creation / authoring / editing / reorganizing / etc. of the object
    • in READING / VIEWING / NAVIGATING modes, PRESENTATION is for the READER / / and provides ways that ENHANCE the reader’s comprehension of the material

Interactions

  • on keyboards, keyboard shortcuts are faster than mouse operations, and ought be available, at least until keyboards are obsoleted
  • Rather than having multiple actions create different TYPES of an object class, a SINGLE action ought create an object instance, with easy EDIT-PROPERTIES that allow tweaking it or changing its type, attributes, etc.
  • HIGHLIGHT NODE – the idea of FOCUS is introduced here – very important. FOCUS can be invoked by click (mouse enabled), keyboard shortcut, glare (eye-sensitive devices)
  • FIELDS – ought be:
    • STANDARD / DEFAULT – system-supplied, always available
    • CUSTOM – user-defined
  • VISUAL – user / reader CAN choose this, as well as experiencing the AUTHOR’s specified visual behavior
  • CONNECTIONS –
    • key discussion is CATEGORY TAXONOMY vs TAGS
    • The LAZY way is tags
      • most likely to be used / adopted
    • The intellectually cleaner / elegant way is CATEGORY TAXONOMY
      • less likely to be used / adopted :(
  • AUTHOR-INTEGRATION
    • adding by drag/drop -> leaves a TODO item to review HOW to integrated it into the FOCUS DOCUMENT

 

PS. This is incorrectly indented; the email is better at formatting this response :( . If I can figure out how to correct the formatting, I will edit this to match the email just delivered.

Thanks to Frode…

Thanks to Frode for proposing and creating this forum for us to each keep other informed about our activities, thoughts, blogs, publications, etc. We EACH are (probably) already blogging and keeping our IP artifacts elsewhere, but this can be a place where we share pointers to those resources, and in particular keep a sense of “aliveness” to our shared online presence, distinct from the raw audio files kept at SoundCloud.

Proposal: As you create material online, whether as published articles, blogs, distinct domains, commentary, etc. place a link here to that work. In those works, include links to the source material you are building / commenting on, but ALSO keep a link to THIS SITE so that eventually, this site becomes well known as our central repository… at least until a better one is created :) .