Somebody (a new member) mentioned in the Community earlier this week that they could not find a best practices document for Coda.
First off, I don’t think that something like that is possible, because Coda has just too many use cases - from writing a blog, to tracking expenses, to managing businesses, a personal information manager and a thousand and one uses in between.
Having said that, I rambled a bit about my experience, and what I found useful. I have copied that to my Quick Example Guide, and expanded it a little bit in some areas.
Here is that page in the document:
I hope newcomers find something useful in there - and the most important of all of those notes: You WILL redo your first few docs.
And within each use case, there are implementation variants.
I think the best practice will emerge if you focus on the user’s expectations and objectives. Remember - you’re not just building a document; it’s an app in almost every sense of the term.
I asked the question, and accepted that my diction was poor. “Best” implies a single solution that will always be inappropriate. Yet the need expressed by the question is real: the novice Coda-user finds very little applicable advice on how to structure a Workspace. This is heightened for those who bring with them know-how of knowledge-work and it’s tools: processors for words, numbers, and data. Perhaps “Guidelines” is a better aim.
What guidelines for using Coda would you suggest for novices — particularly those who are comfortable with word processors, spreadsheets, databases, and OS file-managers?
How should that novice (me, but one of tens of thousands) conceive of Coda and its parts? One Workspace? Several? One Doc? Hundreds? One Page? Thousands? Depth of Pages? Hierarchy of parts? Back-end? (added: Naming conventions?) ToC? Navigation? Public? Private? How to map my existing digitized and organized information from “old style” documents to this new-style “Doc”? How to re-map my conception of organization to this Coda? @Bill_French: it’s an app “in almost every sense of the term”? Can you explain?
What mistakes novices regularly make that should be avoided?
I haven’t looked at @Piet_Strydom’s ramble ( ), but I’m looking forward to it: I expect it to be valuable in that his shared wisdom will shorten my journey. I thank him in advance — Thanks Piet! — and encourage others to add their learned wisdom so uninformed, wrongly-informed, and less-informed users can make good on Coda’s promise of a better way to work.
For many Coda users, even their first encounter is unlike other document-centric systems. I think we can all agree that one of the compelling aspects of Coda is that it pulls us into a new relationship with other users – the subtle power that comes with the ability to make something that others can use and by “use” I mean – operate in a manner that is more like a solution and less like a document.
This is apparent when you encounter ribbons of content blended with data, interspersed actions (like buttons), and proactive elements like Dory and Pulse. By using the vast array of integrated components, makers create solutions and solutions are fundamentally apps.
Since the dawn of spreadsheets (VisiCalc) provided a glimpse of solution-building magic despite its isolation in numbers. From 1979 until recently, not much (besides incremental innovation) has changed in the world of spreadsheets. Many of the limitations in Excel existed in Lotus 123, QuatroPro, SuperCalc, MultiPlan, and even Google Sheets.
Coda allows makers to take a fairly big leap forward and sideways in terms of meeting business requirements. Any collection of relatively complex requirements reaches a tipping point where the “document” is now a "solution. It’s hard to pinpoint such tipping points but makers know when they crossed that line because the resulting doc can be regarded by users as a solution.
Unfortunately I am not going to answer that question, rather make it more “interesting” in another dimension.
It is possible to type @, and then Coda will allow you to reference any object. BUT ALSO, any text that is included in a cell in a table anywhere in the document.
This has great implications. Say for example I have put together information on French painters, and elsewhere I have the same on Dutch painters. When I do something new on Van Gogh, I can @ reference information from the first two tables.
Which is great, but there are limitations and implications. The reference is to the full cell all the time. This has the implication that if the references cell is too large, it is unclear exactly what you are referring to. One solution would be too write in smaller cells.
Another would be to ask Coda to expand the @ function to also pick up references to paragraphs on the canvas…
I am still playing around with this, unfortunately not much time at the moment.
But now the questions come up: do I put everything I write in a table(s)? How many tables? How many columns? One single column? How do I handle the overflow of information when I type @?
Indeed, and this issue is about to expload when the canvas column type will soon be made available; it will have the opposite affect – the definition of a cell will contain the content of a full page. I suspect the Codans have already pondered this implication in great detail.
But in as much as the intra-hyperlinking capabilities are transformative, they may be overwhelming for new users attempting to decide how best to organize information. In that sense, there is probably a case for identifying some “best practices”, a term that is bit inappropriate because it is too constrained to serve in a valuable way given the information architectures that are possible with Coda.
In contrast, I tend to tilt toward the term “success patterns” - a collection of smart ways to embrace and organize information to meet specific business requirements. I think this is more about how your target users relate to the information in the context of getting stuff done. There is no right way perhaps, but there are certainly some bad ways.
I’m familiar with @ referencing objects such as pages, tables, and rows, but I’m not familiar with a way to call out a reference to a specific cell. How do you do that?
You’re right here : The @-ref method will work only in a formula (canvas or table) so effectively, you won’t be able to do this without writing a formula first .
Yeah, and since @ref... begins for makers and users as a very chummy way to hyper-link other relevant data, it should ideally extend this approach to specific cells - i.e., complete the UX such that it allows any level of reference to be designed without a formula. This is not easy, of course.
@ will pick up a reference to the information in any cell, but then post a link to the row, not the specific cell. To get to the specific cell, you would need to use the “=” formula builder as PcH explained.
), but I’m looking forward to it: I expect it to be valuable in that his shared wisdom will shorten my journey. I thank him in advance — Thanks Piet! — and encourage others to add their learned wisdom so uninformed, wrongly-informed, and less-informed users can make good on Coda’s promise of a better way to work.
(if that makes sense 
)
(sorry if that’s the case 
!
.