Oink Network Graph Visualization

We added a new feature that allows you to browse your oink network as a graph:

As I wrote before in this blog, Oinker’s document oriented data is not well suitable for graph representation (nodes and edges) because an oink network tends to have nodes with large amount of text or other miscellaneous data that would be meaningless or too verbose as a node in the graph display.

To keep a graph reasonable to browse, we have to find some way to simplify an oink network. I’ve been thinking about this for some time and recently I came up with an idea of “topic nodes“.

Oinker’s graph visualization doesn’t display all the nodes connected to your room’s board. Instead it displays the nodes selected by a certain rule and we call them topic nodes. How are topic nodes selected? Though the way of selection is subject to change, currently a topic node is:

• a node whose content has only one word or sentence.
• a node whose content length is shorter than or equal to 30 (in English. It becomes shorter than that in multibyte character languages).
• a node whose content is not Markdown (starting with #md)
• a node whose content is not a URL
• a node whose content is not a file

With this topic nodes visualization, Oinker now has a good balance between abstract and detail level. To begin with, Oinker adopted the document oriented style because we believe it should be essential to collect and accumulate detailed information (a.k.a contexts) as much as you can when you want to find valuable ideas or concepts. Mind maps are great to share an overview of an idea. However, without the context, most of its value will be lost in interpretations by each individual.

In Oinker, the graph view is one of the ways to overview the results of your knowledge-building. It’s like an observation platform on a mountain, which allows you to view the panorama after you climbed the mountain.

Impact Mapping – https://oinker.me/room/marubinotto/impact-mapping

Oinker as a Content Publishing Platform

Public room

Rooms now have the capability to control anonymous access to their content (of the timeline and board).

As in the above screenshot, you can make a room open to public so that anonymous visitors can view the content.

If you check the Public room checkbox, then anonymous visitors (not logged-in to Oinker) can view the board. In addition to that, you can allow logged-in users who are non-members of the room to view the timeline (Public timeline), and optionally post messages to it (Free oink).

So, with this public room feature, you can not only publish your content, but also collect feedback from audience via the room’s timeline.

What kind of content can you create in Oinker?

You can create more dynamic and connected content compared to normal websites. Dynamic means that even anonymous audience can see the things being updated right there in real time. And the connections are what Oinker is all about.

We’ve been working on a sample content (public room) “Unknown Tokyo” to demonstrate the content publishing feature.

Oinker rooms are SEO enabled?

After publishing “Unknown Tokyo”, we were surprised to find that the page was indexed in Google. That means you can search your public rooms with keywords in your oink nodes like:

https://www.google.com/search?q=%22Impresssions%20of%20Moukotanmen%20Nakamoto%22

According to the following article, Googlebot now correctly interprets pages generated with complex JavaScript at browser-side like Oinker rooms.

• The Latest In Advanced Technical SEO From SMX Advanced
  • http://searchengineland.com/latest-advanced-technical-seo-smx-advanced-222971

Embedding Google Maps

You can now embed Google Map just by pasting an embed code like below:

To get a Google Map’s embed code, click the main menu ​in the top left corner,

And click “Share or embed map”,

At the top of the box that appears, choose the Embed map tab, then copy the code and paste it into your timeline.

File Upload in Oinker

The new File Upload feature is now available.

As you can see in the above movie, the upload feature lets you drag and drop multiple files and upload them at once.

You can treat each uploaded file in the same way as a normal oink: dropping it onto the board and connecting it to another oink.

Reoink – Sharing an Oink-Graph among Multiple Rooms

An oink belongs to the room where it’s posted. That means that a user who is not allowed to enter the room can’t access or view the oink. That’s natural and is basically what the room is all about in Oinker.

Though Oinker’s visibility model is designed to be private by default so that you share information only with your roommates, Oinker provides a way to circulate information beyond the border of rooms. That is a feature called ‘Reoink’.

If you feel some oink is interesting and want to share it with other users who are not a member of the room or just save it for yourself, you can do that by re-oinking (re-posting) it in another room of which you are an owner or member.

An interesting part of Reoink feature is that a re-oinked message is not a copy of the original, but the same oink which the members of both the source and destination rooms share. For example, when a member of the source room changes the content of a re-oinked message, the members of the both rooms can view the change. That would be straightforward, but what about this? When you connect an oink to the reoink as a sub-node (or child), every member of the both rooms can not only view the sub-node, but also add an oink to it to grow the oink-graph that has the original reoink as its root.

Therefore, Reoink feature allows you to share a oink-graph starting from a reoinked node among multiple rooms and let outside users to join to grow the graph.

Since any member can reoink an oink reoinked from another room (reoink chain), you can’t control who can view your reoink. It’s possible for someone you don’t know to view your reoink in a room also you don’t know and contribute to growing the graph. So it would be almost like publishing an oink unless you reoink in your private room.

It would cause problems to allow a member of any room to change a reoinked graph freely, so Oinker doesn’t allow you to make destructive changes to the relationships of an oink node from another room.

It would be no doubt that Reoink feature is one of the most important features in Oinker and sets it apart from other collaborative knowledge management tools. It has a potential risk of unexpectedly leaking oinks to other rooms when connecting oinks (in the future, it’s possible to add a feature to warn it), but its potential is certainly interesting. If you share your knowledge generously with others via reoinking, you might get returns more than expected.

Changing the Focused Node in Traversal View

The second topic in Zhao Wei’s feedback:

The ctrl+enter SHORTCUT works well enough but new note is added only as a subnote to the topmost visible item in side panel. … Executing the shortcut would drop the note into under the topmost item and not inside the bottommost item as expected. This means had you needed it under the latter or further down the line (eg. 5down), manual drag and drop would be needed.

As explained in this article, you can append an oink directly to the focused node (with orange border) by posting it with the ctrl-key pressed.

However, as Zhao Wei pointed out, the problem is that you can’t use this shortcut when you want to add an oink to one of the subordinate nodes in the traversal view which always has the focused node as the topmost item.

It’s also a problem that there is no way to focus a subordinate node in the traversal view if the node doesn’t appear in the board except for searching the timeline for it.

To solve the problem, I’ve modified the traversal view a little, so that you can put the focus on any of the subordinate nodes:

Graph Style (Nodes and Edges) or Document Oriented Style?

Oinker user Zhao Wei wrote:

No CONNECTORS in true mindmap style? Either like freeplane or bubblus (web service) with line connectors linking nodes back and forth, arrowheaded and with labels both to/from ends and in center.

Actually, Oinker has a graph (network) structure as its core model, but its representation in the user interface, unlike other ideation tools, is not a nodes-and-edges style.

Why? Honestly, I don’t know. The concept of Oinker popped up in my mind, out of nowhere.

Possibly, Oinker’s document oriented style was inspired by Wiki whose data model has documents as nodes (pages) and hyperlinks as edges. The only difference is the representation of edges. A link in Oinker means visually embedding a node to another node.

Both styles have pros and cons. For example, nodes-and-edges is good for grasping the overview of a whole idea represented in a graph while the amount of information on a node is inevitably compressed (ideally, to a word or phrase). Document oriented style is suitable for building full-fledged documents which contains plenty of text and images, and it’s also important that the elements in a document are arranged in order from top to bottom.

In hindsight, one of the reasons Oinker adopted the style is that it aims to promote a bottom-up ideation approach where a user makes a large document from collected details. If you are suppose to draw a map like a mind map or concept map in nodes-and-edges format from the beginning, you would tend to build an idea from an abstract level.

Oinker’s bottom-up approach could be called a From Detail to Detail approach where you collect details by chatting and create a structure from them. Then you give body and substance to it with other newly collected details.

When you want to overview the emerging structure, it would be helpful to view it as a nodes-and-edges network. However, it should be noted that a document tends to contain many meaningless nodes which a network view should deal with somehow to avoid the verbosity of being precise.

Task Management with Oinker: from the Simplest Form to Kanban

Task management is one of the areas where you can get the most out of Oinker. It’s more flexible than most task management applications and even allows you to generate knowledge directly from your tasks. It seamlessly connects task management and knowledge management.

In the simplest case of task management with Oinker, you just create two oink nodes such as “ToDo” and “Done” and move the tasks between them:

When you move a task node to the “Done” node, don’t forget to drop it with the shift-key pressed, which means to “move the node“.

One of the important requirements in task management is an ability to change the priority of tasks anytime. With Oinker, you can easily change the order of tasks by drag-and-drop:

If you are working with a team where there’s more than one assignee of tasks, adding “Doing (by someone)” nodes allows you to assign tasks to team members and track what’s going on in the project:

You may want to add a validation phase by placing a “Validated” node, which allows the project manager or stakeholders to verify that each “Done” task produced the expected result:

If this kind of task flow is driven by the validation, say, you can move a task from “ToDo” to “Doing” only when a “Done” task is validated or there are no waiting “Done” tasks (aiming to limit work-in-progress). It is called a “pull system” or “Kanban” method which gives you a way to get feedback and make problems visible as early as possible.

It’s quite simple and flexible, but you might think that it can be also done with a whiteboard and it’s more intuitive, as many of Kanban projects actually use it. That’s probably true. However, there are several merits to use a digital system, especially Oinker:

• You can save all the completed tasks and search them later.
• You can attach any additional information to a task and easily navigate it.
• You can build your knowledge base with completed tasks and information attached to them.
• You can collaborate with team members who work remotely.
• You can create tasks directly from a chat.

 

Pursue the natural order in knowledge management

As David Allen wrote in Getting Things Done, we are living in the era where “Almost every project could be done better, and an infinite quantity of information is now available that could make that happen”. In this flood of information, we feel constant pressure from our knowledge work to organize everything in order not to drown in the chaos. For example, you may feel the urge to decompose your task into a work breakdown structure, or to outline your ideas in mind maps, etc.

There would be almost no knowledge workers who are skeptical of the value of practices like organizing complex information into a simple and comprehensive form. Besides the purpose of organizing, the urge of doing so can be explained in terms of the tendency of the human mind. The architect Christopher Alexander explained it in his essay A City is not a Tree as “because the mind’s first function is to reduce the ambiguity and overlap in a confusing situation and because, to this end, it is endowed with a basic intolerance for ambiguity – that structures like the city, which do require overlapping sets within them, are nevertheless persistently conceived as trees”.

As Alexander pointed out, when we organize something, it almost always means to arrange the things in a “tree” structure. That is partly because of our underlying tendency, but the tree is actually a powerful tool because it is easy to deal with and gives us a focus on important things.

However, while it simplifies the mental process, Alexander argued that “there is some essential ingredient missing from artificial cities (which are always organized to form a tree). When compared with ancient cities that have acquired the patina of life, our modern attempts to create cities artificially are, from a human point of view, entirely unsuccessful”.

His answer to fill the missing part of the tree is a more complex abstract structure called “semilattice”. To put it simply, the semilattice is a multi-parent structure while the tree is single-parent. In a tree as single-parent, any element can belong to only one context, which, Alexander argued, does not reflect the reality of natural cities.

As a knowledge organizing tool, Oinker adopted the semilattice as a data structure where you can put the same node into different parents:

Although Alexander’s argument about the tree and semilattice is for urban design, I believe that the same can be said in knowledge management since both of these are artificial things.

If an issue can belong to only one topic, you can only understand it in terms of its single context. It is simple, but kind of being caged up in a single point of view. On the other hand, if the issue can belong to multiple topics, you can approach it from the various angles and even create a new context to explore another topic. This spontaneity is definitely important when you are brainstorming new ideas.

Of course, there would be worries about uncontrollable situations due to the complexity of the semilattice. However, in the rapidly changing situations we have to deal with, we probably have to look for a way to build the natural order in our knowledge management to adapt quickly to a new situation rather than simplifying everything into a rigid structure.

Markdown Support

Oinks are usually plain text with simple formatting (newlines, URL links and images, YouTube players), but you can also use Markdown syntax to add richer formatting.

When an oink starts with “#md“, it enables Markdown formatting:

Markdown cheatsheet

This is intended as a quick reference. For more complete info, see John Gruber’s original spec.

Headers

# Header1
## Header2
### Header3

Header1
=======

Header2
-------

Emphasis

Emphasis, aka italics, with *asterisks* or _underscores_.

Strong emphasis, aka bold, with **asterisks** or __underscores__.

Combined emphasis with **asterisks and _underscores_**.

Strikethrough uses two tildes. ~~Scratch this.~~

Lists

1. First ordered list item
2. Another item
  * Unordered sub-list. 
1. Actual numbers don't matter, just that it's a number
  1. Ordered sub-list
4. And another item.

Links

[I'm an inline-style link](https://www.google.com)

[I'm an inline-style link with title](https://www.google.com "Google's Homepage")

Code

Inline `code` has `back-ticks around` it.

To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab:

    This is a code block.

Or just wrap your code in ``` and you won’t need to indent it by four spaces:

```
function test() {
  console.log("Markdown is a text-to-HTML conversion tool for web writers.");
}
```

Tables

First Header  | Second Header
------------- | -------------
Content Cell  | Content Cell
Content Cell  | Content Cell

| First Header  | Second Header |
| ------------- | ------------- |
| Content Cell  | Content Cell  |
| Content Cell  | Content Cell  |

Colons can be used to align columns.

| Tables        | Are           | Cool  |
| ------------- |:-------------:| -----:|
| col 3 is      | right-aligned | $1600 |
| col 2 is      | centered      |   $12 |
| zebra stripes | are neat      |    $1 |

Blockquotes

> Blockquotes are very handy in email to emulate reply text.
> This line is part of the same quote.

Quote break.

> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote. 

Horizontal Rule

---

Hyphens

***

Asterisks

___

Underscores