[Request] Complex Coda Docs — Mapping them out for sustainability and continuous development

Hi everyone :slight_smile:
I’m having similiar issue on a huge doc on coda :slight_smile:
I have to deal with users that want to edit the coda app, but i have to tell them somewhere how the app works, how i designed and “coded” it (formulated? :slight_smile: )
I should document my app, without wasting time in doing so and in a future-proof way (like dynamic)

What if i could use the Doc Map for doing so?
p.s. @Paul_Danyliuk what if the doc builder and the user werent the only “users”? :slight_smile:

What if i need a third type of user that is not gonna build the entire doc, but that wants to be able to understand or modify formulas?

it’s the cool approach of coda, i built it, you play with it and then you modify it :slight_smile:
But i have to create a safe zone in which this can happen, where my work cannot be copied or redistribuited, and what better space than coda doc itself? already protected, with version history for users and all kind of useful tool :slight_smile:
This third type of user need to understand formulas (all your suggestion about formatting and organizing are already applied in my case :smiley:), doc design and doc map.
And i think that creating a static .rtf is not respectful of coda’s nature of being an intuitive and dynamic tool, why not take advantage of already existing doc map?
It could be a great tool for building dynamic documentation for explaining how the doc is builded and designed

My suggestion will be to display all the tables in the first view, so i can see the primary tables and also the subtables below the parents, having all the schema in one page (see doc map for live examples)

It’s easy to sketch a “mind map” of a doc if it have 3 section and 5 tables, is harder in situation like mine
Screenshot 2020-03-20 at 13.07.15

Where all those tables are linked in someways to eachother, i would have a really hard time in explaining how that work to an experienced user, how could i explain that to every “more interested than average in tech aspect” users?

Do you have any ideas regarding those aspects?

Thans :smiley:

I’ve built quite a few docs that are very similar in statistics to what you have :slight_smile:

My general advice here would be: you don’t want the third type of user. Either uplift some users (the ones who’ll maintain the doc and build on top of it) to builders and help them understand everything about the doc’s internals, or let them stay users and only use controls and views laid out for them.

The way to transfer knowledge about doc’s internals that worked best for me so far is 1-on-1 live sessions (training) that’s also recorded for future reference. I walk the person through the doc, explaining it step by step and what part is responsible for what.

This advice may change over time.

3 Likes

@Paul_Danyliuk Thanks for the fast answer :blush:
I’ll tell you more because i think that the third user could be more interesting that what you have imagined :smiley:
Little recap: My App manage nutritional data of animals.
It can create diets (using Recommended Allowance of nutrients from GOV agency and Foods DB from other gov agency) for pets (but the same principle is suitable for humans)

Other software similiar to mine propose to do the same process, BUT they cant be edited as one wants.

So? So nutritionist worldwide have started creating their own “apps” on excel, because they want control on the behaviour of their work tool, knowing what formula does what, having the ability to add or remove calculi or create new formulas (ex. imagine a nutritionist that work for working sled dogs in alaska, no one has ever made a software for managing those particular type of animal’s diets with for example a particular supplements made for bone and tissue improvements and a special focus on omega 3 for heart functions.
He have 2 options; use paper and pen or use a software, if he want to use a software he have to build it because no one have done that before, and no one have done that before because it was hard to code an entire new app for something like that. Coda change that completely. He could then prepare a new table that deals with his own problems and then share this “part of the software” with the rest of the app users, and if another strange guy from canada want to do a similiar job, he could analyze the existing work and fix it for himself :slight_smile:)

There is this “stupid” distance between companies that design those software (that cannot create a custom software for every nutritionist around) and the final users that prefer to use excel (yeah, before me :grin:) instead of using nice looking and modern web apps. that create a perfect space for a coda doc :slight_smile:

If i would choose one of the “classical” way, i could get “basic” users to use finely the app, but more experienced one with what? a copy of the app? no because i want rights over it…
So i would loose all those “pro” users that wants custom features, those are the ones the software is made for!
My plan was to build an ecosystem where those guys could work together to create new evolutions of the app, auto-supporting themselves with a little Knowledge Base of the documented content and a forum beside, in exchange for building and extensively testing the platform i ask for 20$ annually (or something like that, where other software cost 10 times more)

That’s my idea, that is continuously developing further with coda improvements, but i’m pretty sure that i’m not the only one who could take advantage of a similar model,

So, have i been able to inspire something? :slight_smile:
thanks!
P.s. it’s the right time for codatricks, come on!!! :heart_eyes_cat: :heart_eyes_cat: :heart_eyes_cat:

3 Likes