User friendly will be important. USUALLY user friendly can be improved after design/architecting, but in this case MAYBE NOT, as we are designing something of a “human protocol”, i.e. does UX come first here?
- Language can be made more accessible: “before and after” vs “preconditions and postconditions”
- We could create a questionnaire to guide people through making their own HOWTO’s – so that it follows the template – try to make the process of creating a HOWTO as lazy/seamless as possible
Who are we designing this for? Is HOWTO meant to be accessible to someone with limited time/bandwidth to make a quick contribution (say, someone on our facebook group has 2 hours to spare)? If we are designing this for casual and infrequent users, we may already have too much complexity (busy + low bandwidth people go numb when they see more than 5 sentences, or 5 slack channels).
What I really like about the HOWTO approach is that it’s bootstrapping at the core – HOWTO’s are building blocks that we churn out one by one as needed. Has an OODA loop feel to it https://en.wikipedia.org/wiki/OODA_loop
WORKING CODE NOT DOCUMENTATION. This is my greatest fear with HOWTO’s, how can we make them come to life? How can we make a document come to life? I suppose the Bill of Rights came to life, so documents can gain traction, of course. My usual refrain: smart contracts could make this easy (or even normal apps, say loomio). While we are bootstrapping the HUMAN PROTOCOL here, it also must run on an internet protocol, and our internet protocol will influence the human protocol we can develop. More later, need to go to lunch
