I would like to create a suite of tools in Coda to manage reasonably complex projects, including a CRM tool and a pricing/estimating tool for proposal generation.
I am not shy when it comes to building complex systems, but I would like some guidance on best practices IN CODA for building something like this.
My biggest concerns are stability of the system, scalability for more projects, and ease of use for my team/partners/clients.
Is it best to keep all projects in a set of databases in one document, but filter to each project, or split the projects into individual documents and merge the details back into a single document for tracking purposes?
I can do the former relatively easily, but I have some knowledge gaps to accomplish the latter (how to create new projects programmatically and have the details automatically relate back to the main document, for instance).
Thanks in advance! I would be happy to share more details about what I am trying to accomplish if these details are not enough.
I would love to hear from someone in the Coda team, as well as any of the amazing community leaders Coda has.
There are a very large variety of ways to accomplish that. But I think there is fair consensus that fewer docs, and fewer tables are better.
Where on that spectrum to work depends on many factors, including how Coda as a tool will develop in the future.
At the moment, if somebody has access to a doc, they have access to all of the doc. Separating out confidential info typically was a big reason for creating a new doc. But Coda is a fair ways down the road in improving that situation. So take that into account when thinking.
From my perspective, I pay more attention to developing a framework that people can build on. For example, in the doc below, I have different templates for different types of projects. Users can then both amend the existing templates, or create new project templates.
What I am really hoping for from Coda, is the ability to update copies of a document. What I mean with that, is the ability to release a version one of a doc. Then when version 2 is ready, have the ability to release that to earlier copies of version 1. It will be horrendously difficult for Coda to achieve. But the framework idea I mentioned above will go some way to make it easier - you can reserve certain templates for your use, and provide namespaces for the users so that user enhancements will not be overwritten by your V2 and V3 etc updates.
The other alternative is to simply block user development, but that negates to me the whole idea behind Coda.
What I am really hoping for from Coda, is the ability to update copies of a document. What I mean with that, is the ability to release a version one of a doc. Then when version 2 is ready, have the ability to release that to earlier copies of version 1. It will be horrendously difficult for Coda to achieve. But the framework idea I mentioned above will go some way to make it easier - you can reserve certain templates for your use, and provide namespaces for the users so that user enhancements will not be overwritten by your V2 and V3 etc updates.
Thanks for your response, Piet! This is the area I struggle with. I constantly see concerns about doc sizes and I foresee a time when my doc – serving as a database of all projects – could grow to an unstable/unusable point and lose its benefit to my company.
I am looking for guidelines to build a system that will remain performant, regardless of the total amount of information stored in the doc. To that end, I suppose it would be helpful to better understand what causes a decline in doc performance.
What improvements do you anticipate will arrive in the near future that I might want to consider when building the system?
I would love to see version control, though that sounds like a massive mountain to climb for Coda.
@Eric_Koleda – is this something even remotely on the roadmap for Coda?
A few questions I have for the Coda team and community leaders:
Given your knowledge of the constraints of Coda – as well as the flexibility it offers – is a system such as the one described above advisable to build in Coda?
Do you have any use cases you can provide of complex business structures built in Coda?
What are Coda’s biggest weaknesses currently, and what plans are in place to progress past them?
I love Coda and all that it has enabled me to do, but I have not yet put it to the test of a solid business application. I am hesitant to commit resources to build something out without a better sense of what is feasible/advisable. Am I asking to much of this tool?
“Never say never.” However, Coda focuses on enterprise level customers, so performance (and security) are always important. There are limits, obviously, but it depends on many factors, not just the number of rows or number of tables. The number of rows that Coda can comfortable handled has steadily increased since I started using Coda. @Scott_Collier-Weir and his colleagues have built a pack into Xano “with no row limits”.
When I made the comment about limiting rows and docs it had more to do with the structure of the design - I see time and time again that people come with a database design background and try to design their tables that way. 3NF is no longer the be all and end all of database design. Similarly, people bring their experience of Word and Excel documents, including the traditional folder structure to Coda. NO, THAT MAKES NO SENSE!
For me the whole idea behind Coda is to get all your information into one place.
Coda has this document geared towards improving doc performance.
The improvements that I had in mind that you should consider are discussed in this thread:
Currently, once a person has access to a doc, the have access to ALL of the information in the doc. Traditionally, this has been one of the biggest reasons to split docs apart. As you can see in the image below, the end-goal of the current project is to be able to share a page, and the recipient has access to only the information on that page.
They are releasing pieces of the functionality as it makes sense, but we (and I think they) do not have a clear picture of when this will be available in full. To a certain extent this involves putting limits on the linking between information objects in Coda, where a a fundamental part of Coda’s design is the ability to be able to link just about everything to everything else.
In a sense, Coda is doing the opposite of what traditional software companies are doing. They started with individual docs, that could not talk to each other at all. Now they have to develop ways for excel, word and access to share pieces of information. Coda started with a single doc, and now they need to develop ways to ringfence portions of the information in the doc.
This, though a very valid question, is a little bit like “How long is a piece of string?”
I am an SAP consultant and have worked, among others, for Toyota, BHP Billiton, Coca-Cola and Shiseido. So when somebody says “big”, that is my frame of reference. And no, Coda is not going to be able to support quotations, CRM or project management in that league.
There are multiple dimensions to this question:
Volume of data
I responded to this above.
Complexity
Coda has a fairly robust formula language. Because it is still very young, it is not as fleshed out as other languages out there. BUT, with pack functionality available, it is possible to greatly extend it further.
Number of Instances, and maintenance of the code base
THIS is the most difficult area to me: especially if you want to resell the suite of tools to several/ many customers. Again, coming from the SAP ERP environments, I am used to a Dev/Qas/Prd environment, with a robust change management system, and more recently multi-tenant environments. None of this is available in Coda (yet?).
Some of the things that you will need to think about, if you want to sell the package repeatedly, is whether you are going to sell and forget, sell and maintain, and or sell and improve. If you opt for the latter with the current incarnation of Coda, you are going to need to do some fancy footwork.
But I just had an idea: Once Coda has delivered stage 4 of their “Share a page” roadmap above, it opens up some intriguing possibilities. One of the base concepts in SAP’s software, is the idea of splitting information in the database into client dependent, and client independent. It simply takes the form of a field in the table called “client”. So what is worth considering is to develop your tools from the ground up with something like this in mind. Any table that a customer needs for their implementation has a client field. You then create a doc for each customer, with embedded pages with the relevant tables. Every row the customer creates then has the client column filled with his client id. So the transaction data is unique to that customer, but when you update the table/ functionality in your master doc, it is then immediately available to all customers.
As I said, i just thought of this possibility, and there are definitely some topics that would need to be addressed: E.g. We do not have a development environment in Coda. Yet.
