Can Coda replace a Wiki?

[GJ_Roelofs]

Over the past few weeks I’ve trying to hammer Coda into a workspace that allows me to do the following:

• Project Management: w.r.t. Planning & Project, Milestone and Task definition.
• Design document: A central place in which we outline the concepts in the project. Concepts having specific (programmatically accessible) traits, be groupable/searchable/filterable but also flexible enough to use as design documents.

I absolutely love the fact that I can easily references topics and that hovering over links gives me previews to their contents. It works wonders in a table-centric approach to pages. The added benefit being that I can programmatically use this information to provide an easily accessible way to expose designers to concepts & design that is then used to generate code.

However, at the moment I’m not sure how to best approach having a set of pages, a wiki, inside Coda.

• The Rows-As-Pages approach gives me most of the functionality I need. However, I don’t have good control over the visual structure of a page. Building Block Layouts get me there partially, but, per example, the text column in a table doesn’t allow me to add in images directly. I also lose the ability to comment on parts of the “page” as I can only comment on the page as a whole.
• Using Sections-As-Pages gives me more control over the visual. However, I can’t hierarchically group anything, so the size of the wiki structure is extremely limited. I also lose the ability to address the pages through traits.

My Questions to Coda

• Given the above, is Coda actually suited or intended to be used as a wiki for anything but the smallest projects? Or should I use an external solution?
  • Is a workflow planned for implementation that allows for a more “rich” Text column?
  • Do you think that given the scope (hundreds, if not thousands of large pages), Coda is well-suited?
• Given that we can’t refer to other documents, how should such a document be structured? Currently I have various (large) tables for: Projects, Milestones, Tasks, Subtasks, Staff, Glossary, Tags, Templates & Pages. Will Coda be able to handle the size of a 2-4 year running project with 10 people?

@Al_Chen_Coda My apologies for repeatedly pinging you, but I thought that given the above answers would probably be interesting to the community.

Related discussions outlining the needs and issues in this thread:

• Rich text column type
• Add a new format column: "the Canvas"
• Notes in a task
• Multiple Hierarchy

[Juan_Luis_Chulilla]

I’m using wikis (mostly dokuwiki) since 2004. Our internal wiki was started then and, after several refactorizations, is my knowledge trove. I return to it once and again for a formula, a procedure or a script that I wrote years ago and that suddenly I need again.

I hope that Coda documents would be linkable granularly in the future. Then there will be no limit for growth. You are right in the sense that inter-document referral, link, etc., would be an amazing enrichment of Coda group use during long periods of time.

I would also like that an entire document could be exported as markdown for compiling a document, but I’m not in a hurry about it.

Another useful feature would be active headers inside sections. I.e., if you have a First Approach section and you can refer parts of it such as First Approach#Prior art , First Approach#known deal-breakers, etc., the limit that you mentioned would be greatly diminished, specially if an index or an outline can be included or raised for navigating the document

However, I can compare my old project-dedicated wiki and Coda is a huge leap forward, compared with them. Now, when I start a project, I start is as a seed in my general management document. If project growths enough, I create a new document. There we add sections and folders as soon as we need it, and of course internal and external documentation are organized into folders and sections.

If my documentation is too large, I use the same solutions that I used prior to coda: dokuwiki for internal documentation that grows into several hierarchical levels and dozens of documents, and evernote for external, searchable documentation.

But these are extreme examples. In most of the cases I maintain internal and external documentation inside Coda’s sections and folders and I make use of Coda excellent resources for project management.

[Al_Chen_Coda]

Thanks for the questions @GJ_Roelofs! I’ll try my best to answer in-line:

• Is a workflow planned for implementation that allows for a more “rich” Text column? Currently we have the big cell feature that launched a few months ago, but we are still iterating on this as we gather feedback.
• Do you think that given the scope (hundreds, if not thousands of large pages), Coda is well-suited? Yes. We will be launching a new design for how you can manage your docs at the org level in a few months which can help with managing your docs across business functions.
• Given that we can’t refer to other documents, how should such a document be structured? Currently I have various (large) tables for: Projects, Milestones, Tasks, Subtasks, Staff, Glossary, Tags, Templates & Pages. Will Coda be able to handle the size of a 2-4 year running project with 10 people? That’s the correct way to structure things, where each “noun” has its own table. We’ve seen teams of hundreds running their projects and workflows in one doc.

[Juan_Luis_Chulilla]

Thanks for the answers

Have you planned any way of connecting tables between documents?

And what about active references to headers in sections or subsections for expanding hierarchically the document structure?

[Al_Chen_Coda]

Hi @Juan_Luis_Chulilla, connecting tables between documents is definitely on the roadmap. For now, you can use Coda’s API to connect data syncing between your doc. I posted in the community a few months ago about connecting your tables together:

Blog post on one-way sync between two Coda docs

I was working with someone who wanted to sync unique tables in their master source doc with unique tables in their target doc, and ended up writing a blog post about the solution I came up with in Google Apps Script. The post also talks about syncing data between two Google Sheets spreadsheets and the pros/cons of using GAS. Hope you find it useful!

In terms of references to headers in sections, you cannot do this currently in Coda but will definitely submit this as a feature request to the product team!

[Juan_Luis_Chulilla]

I plan to test Coda’s API for this and other uses. I read your post time ago and I find it very compelling. However, No-code building features are one of the main advantages of Coda and the more different docs are connected, the better

For instance, we have a general management doc, with customers, projects, task, timing, etc. As soon as one project takes off, we start a new doc and then we copy and paste tasks, timing and other state variables from project doc to general one. It’s not the Coda way of work, but until I write a viable script for automating that, that’s the way it goes

About referencing headers, @Al_Chen_Coda : Nowadays a section doc is a knowledge pit. It is human operable, but it can be called only as a whole (as a link). Some unstructured data don’t belong to tables, and it would be nice to refer it in smaller chunks.

Besides, is it planned to make folder / section structure deeper? As @GJ_Roelofs implies, such structure would serve to much more complex projects that involve more structured documentation, and would lessen the needing of external knowledge repository services such as a wiki, evernote, etc.

[GJ_Roelofs]

@Al_Chen_Coda

Currently we have the big cell feature that launched a few months ago, but we are still iterating on this as we gather feedback.

My apologies, I used the incorrect term: with “Rich Text” I actually meant a column that would function, for all intents and purposes, as a page. The problem I’m having now is that if I want to use Coda as a wiki, I need to be able to map hierarchical concepts so as to group them properly. The only way I can do this, is through a table in which I map the relationships myself. I then need to map every page as a row and use the Detail View to somewhat structure the content in these rows.

The problem then becomes that I can’t style the content of cell I use for the “contents” of this page as I would an actual page. I.e.: I can’t position images inside the text, I can only style the text.

[GJ_Roelofs]

@Al_Chen_Coda

Given that we can’t refer to other documents, how should such a document be structured? Currently I have various (large) tables for: Projects, Milestones, Tasks, Subtasks, Staff, Glossary, Tags, Templates & Pages. Will Coda be able to handle the size of a 2-4 year running project with 10 people? That’s the correct way to structure things, where each “noun” has its own table. We’ve seen teams of hundreds running their projects and workflows in one doc.

I’ve stress tested Coda with a “complex” table filled with over 5000 rows generated through buttons.
My findings so far:

• Sections not referencing or using the table work fine and seem unaffected by the load.
• If the table is referenced directly, it’s near impossible to navigate. But, this is to be expected.
  • You can somewhat fix this by creating a pager for the table yourself - two controls, a formula and a filter make the table manageble.
• Search function works surprisingly well still, with searches or @ usage now taking 5-10 seconds.

[Juan_Luis_Chulilla]

I think that “tableizing” a set of documents with links between them is an overstretching of any usable table.

The strenght of a wiki is the miriad of ways a team can organize a set of documents needed for present or future operations. When I tried to explain the beauty of wikis in 2002 to my team, first they imagined a huge document. Only after a while, when they saw an actual wiki in action, they realized that a set of documents hierarchically ordered and crossways linked was a huge step forward as a research repository.

Therefore, I tend to think that wikis need to be implemented as such: wiki pages as sections, linked between them and with the possibility of nested them into a hierarchical set of folders for better representation.

While such a solution is implemented, I’m not sure if a “tableized” wiki is worth the effort. Don’t take this as a criticism: mi experience says to me that wikis need to be document-based, but I can be wrong

[GJ_Roelofs]

I fundamentally agree, so I suspect the issue lies in the interpretation or my explanation thereof.
My previous page was just to stress-test how far Coda would go and see some actual numbers, let me better explain my actual intent:

Interaction with this “page-as-table” wiki would not go through the table. Interaction goes through a Detailed View that shows a single page. (See first attached image)

The main benefits that the Table as a backing datasource gives me are:

• Well defined attributes for these pages.
• All the advantages that Tables bring (auto-filling, calculated values, filtering, formula and API)
  • This also easily allows teams to setup forms or search sets specific to their needs. (I.e.: “Show me all pages related to repairing a Mitsubishi Engine”)
• The easy use of @ setup to refer and inline subjects easily. (and group them if on different tables)

In my setup, a wiki table would have several meta attributes:

• Structural: Parent, Siblings, Children, to provide a hierarchical setup so I can calculate page contents. Or Tags to (sub)group pages.
• Content: Title, Summary, Content (and ideally Content would be a column type that would give complete control over formatting and adding inline images etc)
• Domain specific: Specific tags that I can use from a code perspective to generate code or content. I.e.: my goal is that the documentation generates the project, not the project generates the documentation - ideally solving the case where documentation can become stale or out of date.

I’ve been altering the CSS of Coda so that the Detailed View can be better used for this:

Example of single page view:

Example of domain specific attributes of a page:

[GJ_Roelofs]

Another thing that using a page-as-table approach provides is that we can interact with the content in various ways. One thing I’m currently exploring is using different ways to get an oversight of the wiki, per example by generating a graph of its structure:

(Courtesy of Nuclino)

(Courtesy of Kumu)

[Juan_Luis_Chulilla]

Now I understand your idea better and it’s plenty of merit. I am a long-term user or more conventional wikis (indeed before wikipedia was popular), and clear document-based documents are almost here in Coda, with just a couple of improvements pending. It could be a simple, extensible wiki just as my beloved dokuwiki, or a Confluence-like product, maybe not as powerful in some senses but much more complete and flexible in others thanks to table magic.

Anyhow, your idea is really compelling. It’s a different beast and a different way of think about wikis or KBs. Going deep into it:

• I find more natural to structure hierarchically using folders, subfolders, sections and maybe section headers as a subsections. A two-pane outliner is a simple and amazingly powerful tool for visualizing the structure of your master document, project, etc., specially if you can promote, demote and change the structural relation between entities. The more you check the outline, the more you adjust it to what is really needed. However, if a WikiTable can be represented with an outline, it would solve this aspect of the problem quite well.
• Content: no comments.
• Domain specific: adding tags and other flexible and evolvable kind of metadata is very intriguing and compelling. I would be cautious about using it within a team, except if the election alternatives are few and utmosly clear. Anyhow, it could be leveraged in a lot of ways using Views, formulas, temporary searches, etc.

In order to make my thought train more clear, I would say that I manage research projects all the time. I fell in love with Coda because of a lot of different reasons. One of the most important is that it can implement snowflake philosophy really nice. I can start with a phrase, after that a list, after that a set of sections, and after that an entire document populated with tables that contains raw data and are the foundation for KPIs and other measures.

When evaluation phase begin, I can freeze a coda document and use parts of it either for report sections or as data for sustaining our conclusions. Indeed, some coda document sections are direct sections of my report, while other sections and above all tables are sources from which I build another report sections.

I need a clear but flexible hierarchy of elements in order to structure my set of deliverables, but I also appreciate and leverage another transversal relations between the rest of the items of my research. The less I depend of my human memory the better, and I can do that if the information is easy to retrieve and refer.

[Al_Chen_Coda]

Thank you for the thoughtful discussion here about wikis and your use cases. Our team has discussed how to lean into the document side of Coda more to support more basic note-taking use cases.

@GJ_Roelofs adding “rich text” to a column in Coda as a column format has been requested before and it’s indeed on our backlog.

[Ander]

Hi @Al_Chen_Coda,

A feature that would enhance the rich text column type is the ability to adjust the height of the rows in a given column, along with how overflow text should be treated. The different spreadsheet apps have various implementations of this (wrap/unwrap, overflow, clip, pre-set row height options, etc). Each of these implementations have pros, but also cons – and none of them have ever hit the sweet spot for me.

What I have wished for in spreadsheets for a long time, is the ability to:

• set the height for rows in a column (in Coda this could be a simple slider within the column format modal),
• have the text wrap within the available set row height,
• have the remaining text simply disappear when the row height runs out,
• and have all text in a cell become visible upon some simple trigger (like double clicking into the cell, for example).

I have a more detailed analysis of this that I can share later, when it’s more relevant.

Would it be possible for you to include this comment in the backlog notes for the rich text column type – for consideration at a future time? Thanks!

[Al_Chen_Coda]

Sure will do! So you would want to set the individual cell height, not the height of the entire row (like in Excel or Google Sheets), correct?

[Ander]

@Al_Chen_Coda

Actually, I envision it at the data type (column) level.

In Excel/Sheets the user can set the height of rows at the row level. In Coda, I want to set the height of rows in a rich text column at the column level. The height of the entire row would change, not just the one cell in that column. And because it’s being set at the column level, the height of all the rows would change.

In a rich text column format modal, a slider could adjust the size of all the row heights in that column simultaneously (in bulk) – they would all get shorter or taller as the slider is adjusted. The height of the entire row changes, and all the rows change in height.

Hope that makes sense.

There are obviously lots of “what if” scenarios to think through, but this is just intended as a starting point.

[Al_Chen_Coda]

I see, so even if you set the height at the column level (which affects the entire row), isn’t that the same thing as adjusting the entire row in Excel/Googl Sheets? It seems like you just want the ability to adjust the row height by hovering over the top/bottom border in the cell of a column vs. adjusting the row at the very left of the window (as in Excel/Google Sheets)? Is my assumption correct?

[Asaf_Dafna]

@Al_Chen_Coda If I understand correctly, he wants a “Row Hight” control in the column settings of the “Rich Text” column (the drop down menu where you can set column formula, default value for new rows, etc.)

[Ander]

@Al_Chen_Coda

This is tricky for me to articulate without getting too wordy!!

Let me try mapping this concept to Coda’s existing UI:

---

COLUMN FORMATS & OPTIONS

TEXT
-value for new rows

RICH TEXT
-value for new rows
-row height (slider)
-text overflow treatment (dropdown menu)
—options: wrap to unlimited height, >>wrap to slider row height only<<, overflow, clip, etc.

SELECT LIST
-selectable options (formula)
-allow multiple selections (on/off)

PEOPLE
-allow multiple selections (on/off)
-notify when added (on/off)
-display avatar only (on/off)
value for new rows (on/off)

BUTTON
-label (text/formula)
-action (dropdown menu)
-disable if (formula)
-color (colors)
-icon (icons)
-badge (formula)

CHECKBOX
-value for new rows

IMAGES
-size (dropdown menu)
-shape (dropdown menu)

NUMBER
-decimal places (dropdown menu)
-use 1000 separator (on/off)
-value for new rows

ETC…

[GJ_Roelofs]

EDIT: Solved, history per column is visible under the “All comments and Activity” dropdown!

After updating my initial row-as-a-page design, I bumped into the issue that a change history per row is
not accessible as far as I know.

This pretty much halts row-as-a-page design in its tracks and consequently Coda from being a viable solution for an all-in-one integrated product design & task tracking solution.

@Al_Chen_Coda I see of no way to setup Coda as a proper wiki in its current configuration. I would love to be involved in whatever process the engineering team in Coda is working on to support this workflow as I need to make a decision as to whether to use Coda or another solution for our coming projects.

It would also help to see whether someone from Coda can answer the original question that seemed to have been overlooked:

• Given the initial post, is Coda actually suited or intended to be used as a wiki for anything but the smallest projects? Or should I use an external solution?