Sweble Features

Thread to clarify on what features are/will be part of Sweble. @Hannes?

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Sweble Features
Hi all,

while discussing possible Use Cases and benefits of Sweble we were wondering if the features that came to our mind are implemented or planned yet.
If there is some kind of feature list it would be helpful for us to get a hold of it.

Here are some notes on the functionalities we thought of. Are they part of Sweble?

  1. Mobile version of Sweble with editing/commenting power? Or only reading?

  2. Authenticity control: is it possible to ensure that changes from the original document will always be visible as such? This could be important if it comes to official policies. Personal/departmental additions could otherwise be taken as “the original”. The original author could lose control over the information.

  3. Ownership of changes: Can it be followed up who added/changed a document even after changes were pulled back into the original version? This could be important to empower low level employees and ensure them to get credit for their knowledge contribution. (Open Source: nobody writes name into code, but is such a system applicable in company knowledge projects?)

  4. Does Sweble have a confidential factor? Is it possible to mark documents as critical and only give access to certain employees?

  5. How are documents connected to each other? Internal links like in a wiki? Or rather with some kind of tags/channels like in the team communication tool Slack (https://slack.com/)?

Thanks for the help!

  • Team 1

Hi!

  1. A mobile version is not currently in development nor are there concrete plans for the future. However, I would expect that at some point there will be a mobile version. I don’t think it would be fun to edit through a mobile device (but I’m a bit of a Neanderthal when I comes to working with mobile devices). I think the mobile version would be best used for reading pages and commenting changes others have made. But not for authoring yourself.

  2. Unfortunately the collaboration model when it comes to these “merged views” or “overlays” of documents are not ironed out yet. It requires specific support and when I think about it now I would expect that this “authenticity” is a must-have feature. I imagine that a) parts of the original document that are “overridden” by personal or departmental additions will always be flagged (different background, some graphical marker along the paragraph) as such. Furthermore, if the overridden part of the text was updated in the original document there can be a kind of notification that the original has changed since it was overridden.

  3. Yes, all changes are attributed to their author. The history cannot be tempered with. This is already a property of the git version control system. It’s also not something that the program has to enforce but a “mathematical” property of the underlying data structures that you cannot work around.

  4. Sweble will use role based authorization. Individual resources or sub trees of the resource name space can be restricted to specific roles. If a user does not have that role he cannot read and/or modify anything in that part of the name space.

  5. Most wikis actually offer something akin to tags/channels: categories. Sweble will support internal links and also categories.

Cheers
Hannes


Hello everyone, and thanks for the questions.

It is OK to ask us about our roadmap, but please do not feel constrained by it. You are the product managers in this situation, so you should determine the key features that will Sweble help win in the marketplace.

Feel free to ask for clarification though.


Thanks for the help! - Team 1