Still lost (finished all intro videos) — ISO hierarchy, map, object list with characteristics, glossary

[Kirby_Krieger]

I suppose I just don’t learn by an enthusiastic demonstration of possibility, but rather by comprehensive listing of parts, what they do, and how they inter-relate. I have watched, taken notes, and re-watched all 90 minutes of the intro videos in the Learn Doc and I remain lost. I would like to learn the way a surgeon might: this is a knife, this is how you hold it, this is what it can do; this is a body; this is what the knife does to the body here … and here … and here … and here (ie: comprehensive, not “You can make an S, or a K, or an O, you can pin the flaps here or there — this tool is so adaptable it’s totally up to you.”)

Can anyone point me to a guide to Coda that lists every object, every property of every object, the hierarchy of each containing object, and how every object inter-relates to every other object?

As an example of where I go wrong from the get-go: I thought everyone had one Doc, and one created Pages inside the Doc. At some point in the videos “Workspace” was mentioned, but not clearly defined. What is a good practice for setting Coda up as a general hub of knowledge and project management? What is the hierarchy of containers in Coda, from my account (read: global) to what I might call “statements” such as text phrases or formulas? (Individual typed characters would be the next smaller level, but I come to Coda with an understanding of them.)

I — me — need to understand that in order to sensibly use Coda.

Another example: Layouts. Tables are an object. That object can be presented in … Views? … one of which is called … “Table”? One of the “Views” is called “Detail”, but some of the Views of Tables, including Table View, have a detail view as well. That detail View is call a Layout. The Layout is shared by Views including the Detail View. Yes?

The Learn Doc is a Cross-doc and a Doc? I don’t know, and I don’t know how to tell, and I have no idea when to use one and when to use another.

Thanks.

[Nina_Ledid]

@Kirby_Krieger

I just don’t learn by an enthusiastic demonstration of possibility

Hi @Kirby_Krieger , and welcome to the Community! Loved your intro sentence

You’re touching on a key point, that’s very easy to lose sight of once one becomes more familiar with Coda: It’s difficult to find one’s way around in the beginning. What makes Coda so utterly powerful is exactly what makes it hard to understand, the whole notion (pun not intended, but I’ll take it) of “You can do anything, the sky’s the limit!”.

I’m not replying to your post because I have an anwer, but rather because I wanted to thank you for bringing this up as a discussion point. Personally, I think a lot more resources have to be generated to make a users start with Coda easier/better/smoother. Those resources, I think, will have to be targeted specifically depending on the user’s use case and prior experience.

Oftentimes, the marketing message of “Coda is so easy, allowing anyone to build whatever they desire” tunes out the fact that one still needs to get a lay of the land prior to being able to building-whatever-they-want.

Long story short: I love Coda, and I love talking about Coda. And I vividly remember feeling lost in the beginning and not sure where and how to get started. Thankfully, I found a wonderful group of Coda enthusiasts who were always willing to share their expertise with me (above them all, @Xyzor_Max. He’s just a legend. Read his posts on the Community forum, and I promise, you’ll agree with me

If you’d like, I’d happily jump on a call with you to walk you through “my understanding of Coda”. Just DM me.

Additionally, I’m adding some resources which found helpful getting started in Coda:

• Community Champion @Christiaan_Huizer has a extensive [blog] where he tackles all things Coda
• Community Champion @Scott_Collier-Weir is actively sharing his knowledge on Twitter
• Community Champion @Paul_Danyliuk is building Coda-course, and also on Twitter
• There’s a growing selection of Webinars to choose from
• When stuck on a specific problem, peruse the community forum, there are many active members here who are so very generous with their time and sharing their insights.

All the best from Austria,
Nina

[Xyzor_Max]

welcome to this very helpful and supportive community, @Kirby_Krieger.
(and thanks @Nina_Ledid for the mention).

my first advice to anyone coming into coda for the first time is to build an actual practical and useful project. somewhere to list your favourite movies, or recepies, or youtube videos about your hobbie, etc.

or use coda to gather your notes and links for a research project.

anything that is useful to you. doesnt matter what you start with.

this then gives you a purpose and a reason to learn how all the basics work - and rewards your hind-brain with enough dopamine-hits to keep you motivated to learn more.

like you; i keep the entire structure of every detail in my head as a huge cognitive data-structure, a great big framework upon which i can hang every minute thing i discover about a tool…

but its an illusion (i.m.h.o) that our left-brain looks for a-priori before it will start to make things. it wants the full map of the entire territory opened-up in full view before it feels safe exploring the jungle. understandable. but not practical.

better to go exploring (with a purpose in mind) and hack your way through the undergrowth, filling in your map as you go.

so, to build that first noddy project, you will have to figure out pages and tables and different data types. the result is a useful document that keeps track of all the albums you want to listen to (or whatever the project is about).

hopefully some day (as nina says) there will be a greater body of materials for the newcomer. several people are working on those right now.

but meantime - get started making things - and then asking specific questions here on this forum.

if you have experience with spreadsheets - pick one that is useful to you and undertake the exercise of migrating it to coda.

respect
max

[Paul_Danyliuk]

Hey @Kirby_Krieger,

I’ll rather be brief and just offer you a free, no-obligations call to get you on the right track.

I’m working on the Coda Fundamentals course so that’s going to be helpful for me as well. Moreover, I’m working on a free “Learn Coda in X minutes” quickstart guide so picking your perspective will be super valuable for that too.

(Thanks @Nina_Ledid for the mention!)

[Lynn_vK]

Hi Kirby,

In addition to the great advice given by these Coda champions, I suggest searching the gallery for templates or docs that you find useful, and then making copies after which you can look under the hood at the structure and formulas and modify them to your purposes. IMHO, there is no substitute for learning by doing. Over time, you will come up with your own unique approach to building docs. Also, if stuck on a particular objective, for example “how to create a summary table”, you can find your answer most of the time by searching older community posts. In addition, Maria has some great quick tips on YouTube which address common use cases in just a couple of minutes.

I use the Workspace to organize all my docs into multiple folders, personal and business and share individual docs with our staff or my family. It is my understanding that you can invite members to join your workspace or keep it private, which is my preference. The workspace is like a dashboard for all of your docs.

When building a doc, I start by creating tables as the repository of my data, and then use the various views of the tables to display the data in a meaningful way. The Detail, Card, Chart, and Calendar views all use the underlying table data. You can copy the table multiple times and have all of these views in the same doc, usually on separate pages. There is no one design rule for organizing doc pages and subpages. The structure depends on the use case and your preference.

The Detail view has numerous presentation options at the bottom of the screen that are available when you “edit the layout”,

If you ever need to review your doc structure, access the doc map by clicking on the cog wheel in the upper right corner of your doc. That has saved me multiple times, especially with complex docs!

Consider developing a table naming convention that is meaningful to you. For example, you could create a primary table, named “DB Cities”, and then name the detailed view of that table “DB Cities Detail”. Going forward, you can then identify the root table of that data.

In summary, start simple with small wins and build from there! Over time, you will be amazed at what you can build with Coda.

[Jake_Nguyen]

You are overcomplicating it fam

There is only a row of data with fields. It is still at the end of the day tabular data.

Coda just lets you visualize this tabular data in different layouts

Compared to Excel (which has a CELL based programming), Coda’s formulas are all fields based

Don’t worry about “what to use,” it depends on the person. The underlying data is the same tabular data

[Kirby_Krieger]

Thanks to everyone who replied . I’m methodical; I like to think over what you’ve taught me before replying, as this helps all of us channel our efforts. Hence the delay in getting back to your timely responses .

Jake’s comment is somewhat elliptical — I’m not entirely sure what it means — but it opens up an area of discussion that is both interesting and germane. Coda, like many (likely all) of the low-code apps that have vaulted in popularity recently, is, afaict, a DBMS. Database Management Systems have been around for decades — I’m pretty sure you could get a PhD in the science of databases as far back as the '90s. Databases are not and have never been spreadsheets — they resemble each other as much as oryx and wildebeests. (The continued lack of understanding among personal computer users of the difference should be a demerit against the software industry, but ignorance seems to be the highway laid by VCs and their marketers.)

DBMS manage tables of data linked by joins. In a DBMS the primary unit of information is a record. Tables can have infinite numbers of records, and records can have infinite numbers of fields.

The record in a DBMS is immediately recognizable as the confusingly simplified name in Coda: a row. (This seems inadvisable to me from a pedagogical standpoint — and for me, teaching how to use a tool is primary — since “row” can mean many things (something in a spreadsheet, for instance) where “record” means only one thing in this context. (Tellingly, one can have records in a spreadsheet, but only when the spreadsheet is configured to mimic a simple database.)

The field in a DBMS is immediately recognizable — with even greater foundational confusion — as what Coda’s programmers have called a column.

The join in a DBMS is called — I think — a lookup in Coda.

Coda to me — I have written at least one sophisticated DBMS in Microsoft Access, was certified in Excel and Word, and also in the late great image DBMS Aperture, and have managed millions of images in the current state-of-the-art image DBMS Adobe Lightroom — is at heart a DBMS.

This is my interpretation of Jake’s point: Coda is a program that allows you to store data in tables and retrieve it in many ways. The primary unit in Coda is the, er, row.

@Jake_Nguyen

at the end of the day tabular data

Can we still call such a program a DBMS?

And one of my biggest questions for Coda: How can I see all my tables, each with their own columns, and how they are joined?

Such a view would answer many of my questions about the structure (or topology) Coda lets me create. That understanding would greatly help me create in Coda the advanced wildly-functional DBMS I have in mind.

What are the containers in Coda? What is the hierarchy of containers? What properties does each container have, including how they are privileged in the UI? How do the containers inter-relate?

[Kirby_Krieger]

Thank you so much for your validifying reply! It is, imho, exemplary for any forum. Kudos.

There are two particulars I’d like to talk about more.

My previous experience, which seems to be functioning as boulders and not as stepping-stones, is with databases. Clearly (no?) Coda is a database of databases, but equally clearly the programmers have gone to lengths to keep users from experiencing it as a database: the terms are simplified, details are hidden, settings are folded under and folded under again. (It’s a complex structure {like, say, a human body} presented as a befriendable cartoon super-hero.) Is there a guide — even a suggested way in — for users comfortable withe databases and DBMSs?

I want to convert my skill with databases to a facility with Coda.

Aperture, one of the finest DBMSs ever released, and now sadly defunct, was similar to Coda in one respect you emphasize: it came as a toolset, with no built structure. It provided a workbench and powerful tools, but everything was put away — it was not only like walking into a woodshop where there was no wood, it was like walking in blindfolded and not having ever seen a saw or a plane. I didn’t get anywhere with it until I listed what data it used, in which states that data was stored and retrieved, and which tools made containers and which tools modified containers and things contained, and gave myself an empty structure that could be filled with my data (images — Aperture was an photo management system for processing recorded light data files and producing publishable image files) and modified to my needs.

Once I knew how data was stored and retrieved, what parts of containers and what data could be modified, and which tools modified what how, I was ready to make using Aperture tools the recorded-light-file management system for my needs.

I’m not looking to roll through Coda accumulating solutions for the problems of the days — I’m looking to build something robust for long-term use. Of course some of that learning comes from making and playing with objects in Coda — but that learning can be accelerated by a précis of the objects makeable in Coda, their particulars, and which tools make them and change their particulars.

I am pursuing the links you helpfully included. I look forward to taking you up on your kind offer.

Thank you for all.

—Kirby.

[Piet_Strydom]

Short answer: No, Coda is not a DBMS system.

Longer answer:

@Kirby_Krieger

The primary unit in Coda is the, er, row.

The primary thing in Coda is whatever this thing after the shish kabob is.

That “thing”, call it a container if you will, could be a paragraph of text, it could be a heading, it could be a link to a URL, or to a file, either of which can be embedded. It can contain formulas of the @ and = variety. And very often, it contains a table.

That thing “is” usually, but not always, contained in a page, or sub page.

If you want a hierarchical structure, you need to define where you want to start your definition:

• with the App that is Coda,
• your workspace, which is could be likened to a folder with two levels, or
• do you want to start at the doc level?

In my view, it starts with the doc. That is where everything happens, where all the functionality is exposed. Inside the doc, you always “start with a blinking cursor”. From the blinking cursor, you can bring in any Coda object, including text.

And this basically blows the concept of a hierarchy of objects out of the water.

For example:

1. You could replace the blinking cursor by starting type a novel on that page. Each enter would be a new object of text. Some of the you could change into different levels of headings. And then somewhere in the middle, you can decide to put a table, with rows and columns. And then the next object is again text.
   In that table, you could have a column type people, which gives you a link to people records in Coda - their names, emails, Icon, etc. But you cannot call it a hierarchy, because you could access that same object from the page using the @ formula.
   Or you could have a canvas column, which in turn gives you access to many (but not all ) of the objects to which you have access on the page.

2. Or you could design something closer to an app, and replace the cursor with a set of buttons that allow you to trigger, well, anything. It could be to add a row to a table, or it could be to CNN, Spotify, Wikipedia or any other website you want to go to. (Why, I don’t know, but the structure allows you to do that.

3. Or you could start with purely a table, and add columns and rows, to your heart’s content. and create new tables and link those, or not link them. You could add a canvas column, and write your novels (or chapters) in different rows in their own canvas cells. You could cross-doc information from a table view in another doc… See my comments about DBMS below as well.

4. Or you could pull in the Google Drive Pack, and build a non-hierarchical file storage structure.
   etc, etc.

I would go so far as to say, from what I can see, Coda was designed NOT to be hierarchical.

@Kirby_Krieger

Coda, like many (likely all) of the low-code apps that have vaulted in popularity recently, is, afaict, a DBMS.

Over and above to the above comments, Coda misses MANY of the features of a database.

• There is no data dictionary, to start of with, and therefor no entity relationship diagrams. (You could use the Explore Doc to get a lot of information about the objects in your doc.
• It is NOT ACID.
• It does not provide joins or queries.
• It does not use the concept of keys, primary keys and unique identifiers of records and rows. The idea of a display column addresses some of that, but is on the other hand also much more than just a key into a table. And definitely not unique. (Unless set up by you in such a way.)
  The idea of “joined tables” in Coda works very different to what it does in a database, and can more accurately be thought of as Vlookup formulas. Although a lot more user friendly.
  Edit - Coda will also not enforce referential integrity on its table objects. If needed, you will need to attempt to code it by yourself.

And I do not get the analogy to Aperture: What “data” are you referring to in the quote below?

@Kirby_Krieger

I listed what data it used, in which states that data was stored and retrieved, and which tools made containers and which tools modified containers and things contained, and gave myself an empty structure that could be filled with my data

Because in Coda you can store text, files, images, tables containing all of the above, pages containing all of the above, but I think you have something differnt in mind.

Sorry to add more confusion…

Rambling Pete

[Kirby_Krieger]

Thank you Max for the good and welcome advice. Facility will come with use, and play is a great use case . I am getting more comfortable, but I still feel frustrated turning up rocks and leaves in a field when I want to see the long arms of galaxies, the web of gravity, the strange attractors of solar systems and their planets, as well as, of course, the myriad fields thereon.

I shall essay a specific question here in this thread, but in the future will look for answers and ask questions on their own.

What criteria determine whether you put a Table in a new Doc or in an existing Doc? I started by putting all my Tables in one Doc and made a hard-to-navigate thing. Then I moved each Table to its own Doc, which was much easier to navigate, but I didn’t figure out how to reference one Table from another when the Tables were each in their own Doc and I moved several back. My current practice is to put any Tables I expect to reference in the same Doc. But I expect to reference most of my Tables from most of my Tables — and even expect to make a Table of Tables at some point — which would put me back in the all-in-one Doc set-up.

[Kirby_Krieger]

Thank you Lynn_vK . Your expanded example (Workspace➞Folders➞Docs➞Tables for storage and Views for retrieval) is helpful, along with your other suggestions.

I remain bemused about “Table” in Coda. It is both an object that holds data, and a particular way to display that data as well, isn’t it? We make a Table, but there is also a Table View.

Is the original Table privileged in any way? Is there a safeguard that prevents me from deleting the only container of the data when I delete a Table in Table View?

This confusion was shared by almost all users of Notion we encountered when I worked at Notion Mastery (a site that teaches Notion use). I pioneered the concept and use of a Databasement as a place to store original Tables (Databases in Notion) for safekeeping*. Does one need to do that in Coda?

(*Notion handled Views particularly poorly — the Databasement additionally provided a much-needed single-source-of-truth for Views.)

[Kirby_Krieger]

(Will publish when finished. Sorry for the unfinished posting.)

[Kirby_Krieger]

@Piet_Strydom

And I do not get the analogy to Aperture: What “data” are you referring to in the quote below?

@Kirby_Krieger

I listed what data it used,

The data in Aperture are files of recorded information about light stimuli simultaneously striking a sensor. One imports files in any number of recognized formats (constantly updated as engineers at camera mfrs come up with novel ways to package measured recorded light). Those become “original” images or videos. Of interest (but not relevant here), the original light data files are never over-written. Aperture then converts them to displayable image files, one “adjusts” (an Aperture term) the pixels in the displayable image files to one’s liking, and then one prints one’s files or exports shareable image files in whatever format one wants when one wants to make an image available to someone else.

To understand Aperture (and, imho, use it well), one needed to know about the following data file types, where they were stored, how to back them up, how they were displayed, and how to make them available to others:
. files created by light-recorders
. image files created by Aperture from the light-recorder files
. image display files created by Aperture and used as placeholders for the actual (full-size) image files
. sidecar files containing (as it turns out) text information about adjustments applied live in Aperture
. printer files created to be used by a printer
. image files created outside of Aperture that could be used by other programs

The primary unit of information in Aperture was an image. Weird but worth understanding: some image files only existed when Aperture was running (because many images are much more efficiently stored as a text file with instructions detailing how to adjust an image file). Weirder still: the files in which many “pro” cameras store recorded light data are not image files. They must be converted to image files in order to be displayed (and must be displayed in order to be seen). (Happy to go into this further – it’s brilliant, imho – but it’s not relevant to Coda afaik.)

The anology – useful to me, and maybe in the abstract – because Aperture was a suberb DBMS – is that you imported primary things into Aperture, and you used the tools in Aperture to 1) make from those things other things that you wanted to share, and 2) create a system of storage and retrieval that allowed you to keep safe and find when needed (ad hoc, for working sessions of any duration, or permanantly) any of the primary things.

The primary unit of information in Coda seems to be the shish-thing. Where is it stored? How is it backed up? How is it retrieved? What tools are available to me for storing, retrieving, and publishing (sharing) any thing or any collection of things?

What rules determine this thing’s display format and position relative to whatever container is displaying (or formatting) it and other shish-things? What characteristics does it inherit from its container? What characteristics does it not inherit from its container? What characteristics of the primary thing are privileged in the UI by each of the containers that display the shish-things?

[Lynn_vK]

Hi Kirby,

When you delete a table view, the original table is not deleted. When you delete the original base table, Coda provides a warning prior of all the views that will be eliminated along with the original base table.

Also, you can lock some editing capabilities if you have a team account.

Previous versions of the doc are available too! As Maria likes to say, in Coda, you can have a “redo”, unlike in life.

[Jake_Nguyen]

When naming my objects I usually will row index the object like this

For example, a page ID will be “RowID(thisrow) + " | " + thisrow.Page_Name”

In this way, you can very easily customize your “database” or “object models.” This is also a good way to make a unique primary key. IMO it’s a mix between a database and a spreadsheet GUI (but there will not be any cell based programming). The frontend spreadsheet GUI, at least, is a beast.

Also, coda is a doc. When I first used it, I evaluated Coda as Word / Excel / Powerpoint / Mini-App-Maker that works like Google Doc (many people working together online). I’m sure it’s more elegant than that to MANY people - you could really build something great in this cloud.