Hi Community,
Thinking aloud here, please help me think and keep the ideas sane:
- Makers that have been with Coda for a while, will be familiar with the below roadmap, and are also very excited by it.
- I have a few ideas for docs that fall into the mold of selling it often, but also retaining the ability to improve the document, and then share those improvements with existing customers. One example is the doc that I did for my DOCtorate. It is a simple doc to manage rental properties, but it could be massively expanded.
MO Property Investment Club v2.0
What I have started wondering about, is whether one could use stage 4 to manage docs in the way I mentioned in 2. above.
Assumptions:
The tables in the doc would need to be split into client dependent and client independent tables. With reference to the Property Investment doc, client dependent tables would be the lists of properties and customers. Client independent tables would be contract templates, or the table with recommended reading materials.
Client dependent tables would be prefixed with a client id column.
Each client would get his own doc. That doc would contain two sets of embedded pages. Client dependent pages would only contain rows with data relevant for that customer. Client independent pages would contain all data.
Prohibiting customers of making changes to their doc, would simplify things greatly. However, that goes against what I perceive Coda to be. I assume that the functionality that Coda is busy developing will allow the embedded pages to be locked down via locking, to prevent changes to the columns of the table, or the table itself.
The simplest, and most unlikely way, to improve the doc would be to add completely independent functionality, and make those pages available to the various clients.
However, most if not all improvements will involve existing parts of the doc. For example, it would be helpful to add a todo list of repairs that need to be done to the various properties. In this example, it would be possible to do the improvement without making changes to the existing tables.
The next step would be to upgrade the to do list to a project management tool. That is definitely going to entail changes to existing tables. If, in the main source document, each client has their own pages acting as the source of their embedded pages, it seems as if new columns and tables could simply not be added. The downside to this scenario would mean that each new customer would need manual intervention to have their specific pages created. (Unless one can use DuplicatePage() to set up the pages as well as the necessary filters.)
If however, all the customers use the same embedded page, then once a change is made to that page, it will reflect in the pages of all customers. If the change was a bug fix, then yes, one would want everybody to receive the update immediately.
But sometimes the update would be subject to an additional fee, and in that case there would need to be some mechanism to trigger the update.
The most complex change would be where there are changes to existing formulas. The simplest way to handle this would be to force all clients to be on the same release of the software. Everybody gets all of the functionality, and all of the updates.
Questions:
- Do these pages that are referred to have to be used in docs in the same workspace, or can they be added to a doc in any other workspace? I assume the latter. If so, how does one provide the client the embedded page(s), securely?
- Will there be a way to filter the tables in embedded pages in the destination doc? Or will each client need to have a page in the source doc, filtered to his client id?
- How to prevent data entered by the client to move back to the main doc?
This is not just a ramble,
Rambling Pete