My proposal is named "joshcrowd" and is half-baked and sprawling right now.
PROCESS:
1) Understand and Design:
study users, identify big changes needed.
2) build system.
Scirra builds the structural changes and tools needed.
3) run and maintain.
Scirra launches and manages the new help system as it builds itself.
PARTS:
1) HELP SQUAD: To create good content, Scirra gets intermediate and expert users to spend time improving docs. This section sketches ideas for what might motivate such users.
2) "Big Fixes": Scirra staff improve structure of help experience. Once big problems are confirmed with the docs experience, they build tools/process to enable HELP SQUAD to do the rest of the work.
a) make the official manual, the hub of docs.
b) make it easier and quicker for new/intermed users to access answers
c) add new ways of getting help
3) Create a FIX LIST: Work that the HELP SQUAD can do with little/no involvement from Scirra, once the big fixes are done.
4) NERVES: get constant feedback on docs, and get it to those who can use it.
---------------
HELP SQUAD
How will Scirra recruit enough intermediate/advanced users to do all this work? Assuming these users don't want to donate their time for free, Scirra needs to strike a deal. What do these users want?
1a) Scirra announcement: Anyone who we notice improving docs significantly gets...
[] a "priority" email to Scirra devs
[] a free copy of Construct
[] credits in Construct
[] listed as "recommended consultant" on Scirra resources
[] to view and vote on priority of upcoming features
[] to design a Construct feature that takes 10 hours for Scirra staff to implement
[] exclusives - invitations to studio, conference elite treatment, etc.
[] paid / income - e.g. a % of Construct sales.
Just a brainstorm list here. identifying which of these are best is part of the "big fix" work.
1b) Scirra can measure and display user community progress toward 1a) by repurposing/making community points and badge systems eg in forums
---------------------------
2. BIG FIXES:
Here, Scirra staff do some 'classic' UX design e.g. interview users to identify nature of big problems and make structural changes as needed.
EXAMPLE ASSUMPTION: Users want to generally understand Construct's way, and will follow a tutorial to build some random sample game to learn it.
EXAMPLE REALITY: Users don't want to grok Construct's way. Our journey is: Do a 'getting started' tutorial, then start building our game. Get stuck during building, look at help because we want to solve a specific problem.
EXAMPLE SOLUTION: Identify top problems that stump beginners and intermediates. Add mini-tutorials for those problems. Improve access to help in editor, while coding (links on error messages? better error messages?)
EXAMPLE MEASURE: Less forum posts from new/intermediates. Improved retention and usage of Construct after 30 days of download. more published games per user. higher user conversion rates.
---------------------
3. FIX LIST:
These are the hugely time-consuming tasks that the HELP SQUAD can do. They're mostly ongoing improvements to content not structure of help system.
a) Discover the naive search terms users are trying in their attempts to find help. Fix them (SEO plus make a glossary) until users are getting to the correct heading in construct manual.
b) Every sample code is cross-referenced and/or embedded in Construct manual. "for arrays of numbers example, see line 22 of Block-crusher.c3p here. for arrays from JSON, see line 393-444 of ghost-shooter.c3p here"
c) Every forum post is reviewed and vetted. "WRONG VERSION" (if search originated from Construct 3 help system) or "OUTDATED" (if older than 5 years) or "PROBABLY WRONG" (for known inaccurate advice)
d) Every good forum post in "how do I..." or other areas not already linked to manual is starred, and connected to the manual-linked forum topic. For example a post in "how do i..." about sequencing but titled "if/elseif" is linked to "Events" manual topic.
e) Hugely expand the "best practices" section, by reviewing the feedback and reviewing the common queries in forum "how do i" and/or chats, github comments, other places.
----------------
NERVES
As with all design, we need feedback from docs users. We need 'little' and 'big' feedback.
For 'little', we improve what works from other help systems: each help section adds a "I still need help". This records a negative experience, and frwards the click by giving aaccess to more help . Exmaples include:
[] text chat with intermediates online now
[] "someone will contact you ASAP." - a message sent out on user's behalf to help squad.
[] AI-based glossary guessing "suggest looking at Arrays and JSON, see here"
[] Google search "scirra" plus terms.
end. whew.