Uncategorized

We: Social Spaces for Collaboration

Published on by zippy

Say that we agree to define collaboration as a group’s ability to coordinate effort to produce some work output.  I believe that the effectiveness of collaboration improves in direct proportion to:

  • how easy it is to create social spaces in which to do that coordination, 
  • the degree of composability of those social spaces (especially nesting)
  • the variety and utility of the affordances provided in those spaces.

Together let’s call these the claims of Collaborative Power.

Let’s look at some examples:

Version control

Git enables easily creating a social space for coordinating work on a code base. It does this by providing affordances such as; committing, diffing, branching and merging, to assist in that coordination. The affordance of branching is itself an example of Collaborative Power. Within the social space of a code repository, a branch also creates a secondary, simple and secure, social space for further collaboration, or a sub-space. It’s a semantically separate and differentiated place for a sub-group (perhaps of one) to work on the code. This was Git’s “Killer Feature”, branching made trivially cheap.

Channel based messaging

Tools like Discord, Slack and Mattermost make it trivially easy to create the high-level social space of a “Team” or “Server”, and within that, semantically tagged sub-spaces of chat channels. This is analogous to the Repo and Branch levels of VCS systems but for messaging.  The ease and low cost of creating social spaces at both of these levels, and the affordances in those spaces (video/audio chat, screen-sharing, bots, etc) make these tools easy to adopt and continue to use. 

Generalized Collaborative Power

Is it possible to generalize tooling for Collaborative Power? In other words, what technical affordances would be necessary for creating generalized sub-spaces within a high-level social context? 

Imagine being able to create a social space for collaborative work-groups, where what is made trivially easy to instantiate and assemble inside the space, is not one single secondary type of sub-space (i.e. a branch as in a VCS, or a channel in a messaging system) but the mini-apps of your choice, within a simple composible frame.

Enter We

We is a new Holochain app we’re building over at Lightningrod Labs that provides this heightened Collaborative Power. We makes it trivially easy for users to create high-level social spaces and add “applets” to them. These applets provide the functionality for the exact types of collaboration intended by the group.

The UI looks a little like Slack or Discord. There’s a left-hand bar showing your “we-groups”, but instead of the right hand being the channel text stream, there is a secondary bar of “Applets” that have been instantiated into that social space, with the main right-hand window space displaying the UI of one or more of those applets.  Here’s a screenshot showing a social space with the Notebooks applet active, which provides a real-time collaborative markdown-editing:

The power of We comes from how easy it is from both a user’s and a developer’s perspective to add new collaboration affordances.  End users simply pick them directly in the Applet Library:


For Holochain hApp developers, this addition makes it very simple to compile, build, and publish to the DevHub their existing hApps as “we-applets”.  Then any such hApps become instantly available for composing into We social spaces.

Distributed Groupware

In a way, We might “just” look like another attempt at a groupware tool, but there are few things things that set it apart:

  • Generality and Openness: We makes no assumption about the content of collaboration. The affordances of the social spaces are entirely customizable by each group according to the group’s purpose.  If a group needs a new social tooling, it can just be added in.
  • Decentralization: Although, as mentioned, cheap branching is a key feature of Git, its primary design goal was to make possible a fully distributed version control for the linux operating system, such that no central authority could possibly take ownership of its development. This design is arguably Git’s true super-power; and likewise, because We is built on Holochain, it also provides generalized group-forming capability in the fully distributed context. No central servers or infrastructure is necessary. Simply install the Holochain Launcher and then pick “We” from the App Library.
  • Agent-centricity: As a consequence of being built on Holochain, We’s core intent of group collaboration happens from an architecture of empowered agency. Individuals can start groups on-the-fly without request from any authority. Within groups individuals must opt-in to any applet that other agents propose for the group.

Where “We” is going…

The initial release of We demonstrates the key Collaborative Power functionality of adding new applets into social spaces on-the-fly. The next steps come from adding compositional grammatics to applets. These grammatics exist at a few levels:  

  1. Visual: the ability to visually compose applet UIs into complex dashboards/layouts instead of just toggling between monolithic UIs.
  2. Templating: the ability to create a preset menu of applets that work well together and are easily installable as a group, including their layouts.
  3. Functional (the 4 “F”s); the ability to evolve social spaces over time:
    1. Forge: meaning the visual and templating for new group formation. 
    2. Federate: inter-group protocols and connections that allow groups membraned interactions
    3. Fork: easy spinning up of new groups from existing groups, including data transferability.
    4. Fuse: easy merging of groups together. 

Subsequent releases of We will focus on adding in all these grammatical elements, listed above.

So, back to the claims of Collaborative Power:

Collaboration effectiveness improves in direct proportion to both how easy it is to create nested social spaces in which to do that coordination, and the power of the affordances in those spaces to be recomposed overtime

We provides a significant upgrade to the ease of assembling affordances in social spaces.  And it does so while upholding the significant properties of Generality, Decentralization, Agent-Centricity along with providing explicit grammatics for visual assembly, templating and evolution of social spaces.  

We hope to see you in We! 

P.S: For the technically inclined, hop on over to our github repo and check out the instructions on how to convert your regular hApp to be We ready!

Where and the Grammatics of Location

Published on by zippy

Consider playing soccer or football blindfolded. Unless you have gotten really good with echolocation, playing the game becomes impossible for the simple reason that you stop being able to answer the questions “where is the ball?” and “where are my teammates?”.

More subtly, consider the difficulties of having hard or delicate conversations using just a pen and slips of paper. The textual medium blindfolds our built-in ability to read facial and tonal emotional cues, thus making it harder to answer the question “where are you emotionally?”. Without them it is less likely that such conversations will come out well.

Collaborative endeavors, like playing soccer or having a conversation, require knowing the locations of the relevant parties in their spaces. As we examine the vast realms of collaboration we see that the ubiquitous need to know “where” both in familiar physical locations, but also in such non-cartesian spaces as education, familiarity, health, happiness, class, wealth, skill, reputation(s), responsibility, intention, completion, etc…

This seems like a fairly straightforward insight. It’s kind of obvious that maps are important to help guide us in achieving our goals in the territory that the map maps.  What doesn’t seem obvious to me are the generalized patterns for groups to understand all the different types of spaces that they might want to locate themselves in, and find the grammar of those patterns so as to build new maps on the fly as the new spaces to navigate are recognized and as existing spaces change.

whereTo begin some exploration of this meta-space we present Where, a simple-as-possible Holochain hApp that equips teams with a tool to create maps and lets team members self-locate on those maps. The underlying Holochain DNA assumes that a Space consists of a coordinate system (more on this below) and various bits of meta-data.  Locations in the space are then simply recordings by agents using the coordinate system of the space, along with optional additional data values to add contextual information about any given recording of a location.

As a starting place we begin with spaces that are just limited to cartesian X,Y coordinates and that all include as meta-data a URL of an image for rendering the “surface” of the space. The initial UI for Where is thus very simple. You can create new maps, move between different maps, zoom them if they are large, and add yourself into the map along with textual tag information to be displayed at that location. 

That’s a pretty simple place to start, but I think it’s a powerful grammar for initial exploration. Using somewhat symbolic images like a mountain-scape, or a forest, small groups can attach group-specific meaning to different parts of the image. This is an initial hack for various non-cartesian coordinate systems of dimensionality less than two, like tree structures, or various linear structures (e.g. time-zones), simply by ignoring parts of the 2D space.

Next steps can include:

  • Templates that describe the basic structure of a space but allow custom annotations/additions to it
  • UIs that can render surfaces of spaces using other coordinate systems: 3D with OpenGL, low dimension tree and graph spaces, Lat.-Long. for geo-spacial maps, 4D spaces (for example 3D + time), and so on.
  • Adding the ability to change the surface of spaces over time, not just add locations on them.
  • More specific grammars for the meta-data of location entries as they emerge.
  • Adding composability of spaces, i.e. locations on surfaces that lead to or render other spaces.

Here is an abstract grammar for Where:

  • Nouns:
    • Space
      • Surface
      • Coordinate System
      • Meta-data
    • Location
    • Space
    • Coordinate Instance
    • Meta-data
  • Verbs:
    • Add Space
    • Add Location
    • Update Location
    • Update Space Surface

Like all grammars, the component parts themselves have sub-grammars. For example Coordinate Systems are likely constructed out of a grammar that includes dimensionality, units, and some other rules of valid values. And note that this grammar also includes parts-of-speech, what I’ve labeled “Nouns” and “Verbs”.  This is really kind of cheating, because what I’ve called “Nouns” are really Noun-Types, as I haven’t shown any actual Nouns, which would be an actual example of a Space or Location. The “Verbs” really are the only “action-words” of this system, and they are fixed and pretty uninteresting. Kind of like how “conjunctions” are limited to a small set in English.

Though this kind of analysis may be interesting for the computer-scientist/coder/linguists among us, most of us are more interested in the various words, the “vocabulary” of the grammar, and then the conversations that might ensue from using them.

The early development of the ideas for Where came from conversations with Jean Russell about increasing group awareness of typically hidden social landscapes.  Here’s one example she offers for a surprisingly simple but really useful space:  

Case Study: The “Iron Triangle”

I have struggled, as many of us do, in teams where different people hold the values of the project or organization with different weights. To make this generic and familiar, let’s use the cost, quality, and time triangle. Note that the center is blacked out, since we can’t have some perfect combination of the three. 

If the team is dominated by time and cost focused people, then they start resenting the person holding for quality. Or, if focus is on quality, then the resistance shows up to the person focused on delivering on time. Somehow this ends up getting personal rather than the person being regarded as a steward of that value. And the group struggles to come into alignment about priorities and actions. 

iron triangle

Note that I have also added, outside the hypotenuse of each angle, the list of consequences people may be trying to avoid by holding that value (at the point of the angle). I believe this too will help others be aware of the risks inherent in not holding to that value.

I am really looking forward to Where as an application I can use with teams to make visible to the group where we each feel the group or project is in the triangle. You could have one where each wants the project to be and another where they think it is now and notice the difference. 

I feel like this conversation about the map and placement will move the conversation from individual tension into shared awareness space. It will help us be more compassionate with the person (aka the value) being resisted. It may help people to be heard, better, in their concern and sense the group’s alignment, particularly of the more quiet members. That’s better collective intelligence!

 

Putting maps like the one in Jean’s example above into Where softens the “Iron” feeling of “pick-two” into a sense-making process where we can better understand how we use the intelligence of the team to collectively come to good answers, simply because we have an opportunity to see what we all see.  I feel quite excited to see what other similar maps emerge as really useful to groups, but frankly I’m even more excited to see the secondary grammars that will also emerge.  Just like the hashtag was grammatical element introduced to Twitter by one of it’s users, I’m guessing that there are some other similar very simple additions to Where that will carry as much importance and value.

If you are the daring technical type, you can play with Where now by following instructions on the github repo

Maybe next will be Who, What, How and Why!

#grammatics

The App: from Killer to Mother

Published on by zippy

Killer AppThe Wikipedia defines “Killer App” as a marketing term for “any computer program that is so necessary or desirable that it proves the core value of some larger technology.” Not surprising that the term comes from marketing, that branch of business devoted to competing for customers and trying to kill off the competition. But if we remove ourselves from the context of dog-eat-dog, and then start from that definition and work backwards to come up with a single word that it defines, well, “killer” hardly seems right. “Mother” fits much better. Those applications that seed the growth of whole new realms, we ought to call Mother Apps.

VisiCalc, the first spreadsheet app, often gets used as the prime example of a Killer App. Lots of folks bought Apple II computers just so they use VisiCalc. More broadly e-mail (as a category of App) frequently gets nominated as the Killer App for the Internet. Pretty obviously nothing was killed in either of these examples but lots got birthed.  More recently the term Killer App has become diluted in common usage to mean any indispensable computer program. Just try typing into google “X is the killer app”, and substitute for x with Facebook, Twitter, Instagram, etc, and you’ll see what I mean.

But I find it really useful to maintain that distinction of source or spring-board. So I offer this definition of “Mother App”: a computer program (or class of program) that uses a technology in a new way to both reveal and unleash its power.” I hope it catches on!