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