change_instructions_navigator

This goes to several recipients who have individual groupware-related projects of their own, me trying to figure out how they share or differ in opinions how their projects might relate to the topic of developing an entirely different web, a new and better hypertext system, which might not be of relevance/concern for groupware work or even conflicting with it. As I keep thinking about starting a sort of general, agnostic, neutral groupware/collaboration tools umbrella software development project/effort/brand as the home/collection/library/toolbox for similar/related methods and tools, I'm pondering on if in our activities we should just go with the most simple approach, which would be to build something for the web/browser, as that works out of the box without prior installation for the user, lots of people know how to use and develop for it, there's existing code already available and it's easy to update/change things (continous delivery, live production system). For my hypertext work, the web/browser is just a horrible model, but developing a better model is lots of work and risky to some extend, foundational research that leads to long waiting time, less adoption and it's unclear if it can work in the way expected or at all even. There is also a fundamental difference between what I imagine this groupware to do and a decent hypertext system: the groupware is more interactive in terms of providing software functionality design that supports/encourages/enforces certain interaction policies, while in contrast a hypertext system can/might support everybody to do everything on their own or collectively by the use of federation principles. Collaboration tools might want to discourage/prevent such freedom/options as the value of the tools in part relies on carefully designed artificial restrictions to help teams/groups to work better together, the particular methodology/structure applied (from a toolbox of different ones, using one or several that fit best for the task/goal at hand) being the tool to introduce some coordination/coordinated action, where it's absence would lead to less alignment, less efficiency, less effectivity, more chaos, etc. Now, sure, hypertext and groupware might converge eventually, support each other, be compatible, but to truly do it in Engelbartian tradition also requires some of the ARC/NLS heavy lifting in advance, and we're not necessarily bootstrapping from literal scratch (no computers around, no networks, no structured programming, some of which would be favorable to design it properly and not go with historical conventions, but fundamental (re)design is difficult, tedious, slow, risky and one is only forced to do bootstrapping from there if nothing else is around, but we can bootstrap, crossstrap from the existing crappy web as Engelbart did from existing print, paper reports/proposals), so would it even be an option for users to install some native software in advance or is that a no-go, is it absolutely, exclusively required to be available via the web without prior installation? For the rather problematic web way, I did several projects already that could be repurposed and allow very fast, rapid prototyping: <ol> <li>System to keep notes/tasks about/for individuals <ul> <li><a href="https://refugee-it.de/demo/index.php?lang=en">Live demo</a>, login name: demo, password: demo - feel free to play around and change things, you can't really damage things, don't worry about any data in there</li> <li><a href="https://worldie.com/media/viewvideo/191">Video</a></li> <li><a href="https://gitlab.com/refugee-it/note_system">Code</a></li> </ul> </li> <li>Experimential online voting/polling component <ul> <li><a href="https://gitlab.com/voterflow/voterflow">Code</a></li> </ul> </li> <li>Ticket system for offers/tasks <ul> <li><a href="https://refugee-it.de/local/74321_bietigheimbissingen/computers/index.php?lang=en">Live instance</a> (click the buttons)</li> <li><a href="https://worldie.com/media/viewvideo/194">Video</a></li> <li><a href="https://gitlab.com/refugee-it/ticket_system">Code</a></li> </ul> </li> <li>System to report events that lead to subsequent notification of somebody who needs to learn about their occurrence to then address or dispatch <ul> <li><a href="https://gitlab.com/refugee-it/asylum_event_system">Code</a></li> </ul> </li> <li>Petition system to collect "signatures" (list of people who "subscribe" or declare interest, not electronic signatures) <ul> <li><a href="https://gitlab.com/refugee-it/petition_system">Code</a></li> </ul> </li> <li>Blank message system for simply leaving messages that then can be retrieved by somebody else <ul> <li><a href="https://gitlab.com/refugee-it/message_system">Code</a></li> </ul> </li> </ol> These type of things can be cranked out and set up fairly easily, adjusting them and prototyping and playing with them until they do what you/we want/need. Is this what you have in mind, or if not, what other/else interaction/technological model would be needed? What's wrong with the approach of these 6 examples? Copyright (C) 2019 Stephan Kreutzer. This text is licensed under the <a href="https://www.gnu.org/licenses/agpl-3.0.html">GNU Affero General Public License 3 + any later version</a> and/or under the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 International</a>. See also the <a href="https://skreutzer.de/htx/de_skreutzer_20190216T155347Z_groupware_versus_hypertext.xml">revisions</a> (<a href="https://skreutzer.de/htx/de_skreutzer_20190216T155347Z_groupware_versus_hypertext.xhtml">rendered</a>) of this text.