Short-term plans: Event-sourced mobile web

Current progress

Draft version is deployed at: es.auginte.com. It includes:

• Simple write-once storage
• Real time updates
• Adding and moving elements
• Mobile/touch screen support
• Optimization: Time based UI updates

This is not stable version: data could be removed/corrupted, functionality could be changed without notice.

Meaning – you can play around or do some low-risk workshops, but it is not yet recommended to store some sensitive data.

By the way, feedback is always welcome. Use comments or contact directly.

Why event-sourced version is so important?

There were 3 reasons for me to prioritize development of event-sourced functionality:

1. Event-based/real-time updates makes collaboration more natural. Collaboration is the main difference between personal knowledge management and group knowledge management. While older versions of Auginte tool were concentrating on personal knowledge management (E.g. perception, memory, cognitive overhead), new versions tries to also include aspects of group knowledge management (E.g. implicit/tacit knowledge, reuse of information).  How do you generate new ideas or come up with a better solution?.. Despite searching in the Internet or brainstorming, you can also leverage expertise from colleagues of different backgrounds. Wikipedia (or MediaWiki as a tool) is one of the best known update-save-refresh tool for information collaboration, but real-time (E.g. face-to-face) communication is more natural. Need to periodically press Refresh distracts participants from the topic being discussed to the use of the tool itself. In my opinion, seeing changes as soon as possible is the key aspect of  knowledge-management-oriented tools.
   • Keeping-up with the context is more easier, if you see intention sooner. For example, knowing the end goal, you can try to guess colleague’s next move. If your guess is different, colleague can be making something wrong, something better than you would have done or something out of the topic. So you can fix problems, when those are still inexpensive or stop to realign, to follow the topic again of ask to use a different terminology.
   • Speed of feedback becomes very visible, when discussion is between people from different backgrounds. The more diverse group is, the better chance of getting better solution. While verbal discussions can be very fast, explanation by example can lead to goal sooner. I think, the speed of how fast you can see changes of examples, makes feedback loop smaller and participants can still be concentrated on the topic, not the pauses of the user interface.
2. Storing changes as events means not loosing data.
   • Over time context (E.g. trends, goals, priorities) is changing. I used my own Auginte tool for project management of same tool ☺ and now I regret, that did not started from event-sourced storage. To know, how initial idea and market changed, I need to use backups, copies of summaries in same workspaces and some hypothesis to recreate lost data – lots of manual work. Therefore, I want to finish event-sourced version first and patch older/other Auginte versions for backward compatibility (e.g. import/export), so I will not be loosing data any more.
   • Talking about short time changes – users (including myself) are so used to Undo function, that content creation without ability to revert changes, makes user experience not so pleasant or even scary. Making backups was a short-term solution and even saved a few times, after program crashed, but recreation from memory was still time consuming. Moreover, lack of trust in storage was creating bad habit to concentrate on remembering last sentence and not on essence of whole work or topic at hand.
   • Talking about distributed environments, conflicts of changing same data by different users can be a really big work stopper. Concerns of lost data, when solving merge conflicts, waiting for others to store their part – is blocking work for all of participants, especially then there are more than few. Using small messages/sentences was short term solution, because there was lower probability of changes by different users in separate elements. Moreover, popular version control systems (E.g. Git) can merge most of the plain data automatically. One of solution of merging distributed data is just store all changes (event source is just like that). I think, it is better to show one newest state and allow the users to recover conflicting data later, when they have time, because disturbance in knowledge creation is less important, than correct data in every operation.
3. Separation of read and write events can make user interface more responsive. User interface that freeze from time to time – is very distractive and makes concentration of the topic very hard. Prototype version of Auginte had long auto-save time, so newer version included database as a storage. Saving only new elements or changes was faster, then storing everything from zero. However, working with larger amount of data (~40000 nodes, 1000 visible elements) even synchronization between database become visible. From technical side: it is very hard to create not-blocking/asynchronous user interface, when it is based on blocking/synchronous storage. Storage is one of the slowest parts of the system, especially when considering distributed environment. I think, basing system on write and read streams could make user interface more responsive, dealing with acknowledgements and visualization of not fully loaded/stored elements separately.

What were other alternatives?

• Better business model: including platform for reusable knowledge, paid Jira integration plugin, donation button, premium features, etc –  is good to have money, but I think it is better to have product to be proud of, rather than just another alternative to competitors. At least at current stage of the project…
• Have better communication channels for feedback and collaboration – one person cannot change the world. Well, this blog is a result of better public relation. So small part is already done, but I think is easier to get other attention, when you have something to show, not only to sell hopes of what you could do.
• Stable product, not project – currently there are ~4 different not-fully-finished versions of Auginte tool. One good product would be better, than many drafts. However these are not different projects, but more like a generations of the same project, where technical/business challenges required almost full rewrites. It is only the matter of time, when those will converge into single product.
• Context tracking was almost migrated from Prototype to Infinity zooming version, but not fully finished. This

Conclusion

Here you go – this was one of the first blog posts, how and where Auginte project is going. Later there will be more blog posts about technical details, knowledge economy and further plans for Auginte project, so do not forget to subscribe to RSS, Facebook, Twitter or Google+ notifications.

• About
• Latest Posts

Aurelijus Banelis

Software developer and author of Auginte project.
Technology enthusiast and a speaker, sharing knowledge in local technology meetups (E.g. VilniusPHP, NFQ talks) and conferences (E.g. Infoshow, Fosdem).

Latest posts by Aurelijus Banelis (see all)

• Speed-up UI with separation of rendering and state - 2016-11-01
• Short-term plans: Event-sourced mobile web - 2016-10-23
• Auginte blog starts its journey - 2016-10-17