Launched: Pages and Updates to Doc Navigation

A few weeks ago, we invited members of the community to try out a new way to organize your docs. Today, I’m excited to share that we’re beginning to roll-out Pages to all docs. As you may have seen in our Beta Announcement, we’re going a step beyond folders and sections as we introduce Pages. All pages have an editable surface that can contain text, tables, views, etc., and pages can nest within each other. Now, the hierarchy within your doc has no limits.

Screen Recording 2020-04-30 at 08.44 PM

You should see the feature immediately for any new docs you create. We are rolling it out to existing docs over the next few weeks so it make take a while to see this feature in your docs. If you don’t see the feature in your existing docs, please don’t worryーno action is required on your part. We are upgrading docs as quickly as we can to have access to pages, and it may take a few weeks. Unfortunately, this timing is not in our control.

Folders will become top-level pages. Previously, they functioned only as containers to hold and organize sections. Now, they contain the same editable surface as all other pages, which means they can include text, tables, etc. They can also be given custom icons. (Please note that this means pages that were previously folders will now count as objects in a doc. In the event that you are using a free Coda plan and see notices about approaching object limits for your doc, we’ve compiled some tips from this community to help you keep your doc within the limits for free plans.)

Sections nested under Folders (now pages) will become subpages. They maintain all of their existing features; however, subpages can now be nested underneath each other. So, a subpage can contain a subpage which contains more subpages, etc.

To help with navigation, any page that has subpages within it will show a “Subpages” header. This header shows the next level of pages that you can navigate to. You can choose to hide or control the size of the header in the Page Options panel.

Left Sidebar Hover

The page list on the left of your doc is also getting an upgrade. Now, if the left sidebar is collapsed, hovering your cursor on the left edge of the doc will automatically open it. You can use this to quickly switch to another page, and it will automatically close again when you move your cursor away. If you prefer to permanently reopen the page list, you can still do so by clicking the double-caret icon ( >> ) in the top left corner of your doc.

Open Page in New Tab

Since we added support for opening the same doc in multiple tabs, users wanted a way to quickly open a page in a new tab. Just like links on your favorite websites, Command + Click (on a Mac) or Ctrl + Click (on a PC) will now open a page in a new tab if multi-tab is enabled.

We hope these new navigational and organizational features help you organize your docs with fewer constraints so that they truly grow with you and your team.

Kelsey

57 Likes

Thanks for this update! :grin:

5 Likes

This sound promising! Improvements in search, could help us move from our current Intranet (Slab) and you can compete with other good solutions like Tettra

3 Likes

And this slient update.

image

7 Likes

Awesome update!
Looking forward to using it in our project management system!

3 Likes

Very good feature. It changes a lot how to work with a doc and gets things more clean. Well done!

3 Likes

How do their tables work compared to Coda?

very basic table feature , just like markdown table.
It’s not the same level app with Coda.

This is great. Is there a keyboard shortcut to add a subpage?
(ideally without adding a link to the current page where I’m in)

1 Like

This is great - definitely moving in the right direction to help Coda be just as impressive when used as a “library” as it currently is when used as a “database”.

On that front, it strikes me that one very useful way to build on this would be to allow the creation of tables where each row represents a page object, and the columns represent an attribute such as page title, page link, parent page (lookup), date-time created, date-time last modified, created-by, authors, etc. This could be done similar to how cross-doc tables work (basically, there’s an ‘anchor’ row that’s a lookup to the relevant object, which can the be used to project attributes into other columns), with the ability to add additional user-defined columns.

Why would this be useful? Well, if I want to use Coda as a content library, then I want to be able to manipulate page meta-data in much the same way as any other table data, e.g. to create views of all pages tagged with a particular tag, or all pages by a particular author.

If this is not on the roadmap already, here’s hoping it can be! :grin:

4 Likes

For now, the insertion menu is the best way to add a subpage to the current page without using your mouse.

I realize that we currently add a link to the subpage in the original page, so I’ll check with our product team to see if we can forgo adding the link since we already show subpages in the header. Thanks for the feedback!

4 Likes

Incredible. This was the biggest thing keeping me on Notion instead of Coda, but now the game’s totally changed!

4 Likes

image

image

Done rate 88.88 % today ( 5/9/2020)

The line will go up up , the rate will up 300% ? 150 updates in 2020 ?

4 Likes

This change is incredible, amazing work as ever Coda team! Can’t express my love enough for this tool, even more so with this change.

Yes, there’s all the fancy tables/packs stuff, but you pay attention to the little things, and that’s why I love it so much.

5 Likes

No idea if anyone reads these, but I have to say. I had just switched over to Notion. I’ve loved — LOOOOOOVED — using Coda for the last year or so, and have built all sort of crazy personal productivity systems with wonky zapier integrations and bla bla. But ultimately, I was finding myself very hamstrung by how difficult it is to use Coda for the simple activity of taking notes. I tried using the big text editor you can spawn in a table row. Too janky (like you can’t really do anything outside of that window without losing the window, and it doesn’t do as much as the raw pages can do). I tried building integrations with other systems. The best I came up with was creating a button in Coda that linked to my Dropbox Paper account, creating a new doc there, and then coming back and inserting the URL to that doc back into the Coda row, so from that point on I could just click a separate “view” button on that row and have the Paper doc load based on the URL. This actually worked quite nicely, but still felt kind of annoying. Like if I had to jot something down quick in Paper, I’d have to remind myself later to link it back up and so on.

The Pages tool, this simple restructuring, caused me to immediately re-up my Coda subscription (or at least stopped me from cancelling, which I’d have done with a sad face). While it doesn’t get me exactly what I need — I SO WISH there were a way to reference Pages within Tables, without manually copying a page URL and pasting it in to a row — it is both similar to and better than what I was doing with Dropbox Paper. And as I was switching to Notion because it had a better blend of “note taking tool with relational database”, and note-taking is a huge part of my job, the fact that Coda now has its own built in way to at least get me most of the way there keeps me here. Thank you thank you thank you.

12 Likes

I SO WISH there were a way to reference Pages within Tables, without manually copying a page URL and pasting it in to a row

Agreed. This is heading on a very similar path to my post above, i.e. better access to pages and their metadata via a referencing mechanism. For example, at the moment, you can “@” to insert a row reference, why not a page reference? And if you could do that, you could then reference related metadata, e.g. “@[pagename].authors”. Would love if it was possible to connect things up like that!

2 Likes

@Barry_Nelson

Your 2 requests:

  1. Nested page in table cell
  2. More easy to relation

I believe Coda Team will update those 2 features .

1 Like

I totally agree with this :+1:

In addition to referencing Pages from Tables, hopefully we could also work on those same Pages from within Tables, without having to constantly make round-trips between individual Pages and their containing Tables.

One very common efficiency and productivity benefit of working in UI grids (like spreadsheets and Coda tables) is that they allow on the fly bulk work on large data sets by enabling the user to simply progress down a list of items (Rows) and edit data (Columns) along the way. Users can:

  1. visually assess large data sets as a group,

  2. visually compare project-specific associations among rows, and

  3. make immediate edits to column data, without leaving the Table.

A UX that requires the user to navigate away from the list (Table) in order to edit individual items (Pages/Rows) would strip away these customary benefits.

If a Page is to be represented by a Row in a Table, one approach might be to add:

  1. A new Column Type in that table called “Page type” or similar, that would hold the Page data right there in the Table (which could always be hidden).

  2. A new Page Type called “Table page type” or similar, that would be eligible for the Column type of “Page type.” For example, it might be limited to text only, certain number of lines, etc. This would be in contrast to the base Page type called “Canvas page type” or similar, the content of which would have no limitations, but also would not be eligible to pull into a Column of type “Page type.”

  3. Column options for “Page type” columns that allow the user to set a min/max/default row height for every row in the column, which would affect the height of all columns (or maybe a slider in the column header for adjusting same).

  4. The ability to click or double-click a cell in that column to access the Page content at its full row height.

Something along these lines would preserve the workflow benefits of being able to manage and/or process bulk data (Pages) in a grid UI.

The primary consideration here is the conservation of user energy during big workflows in which working at the project level (Table) is as important as working at the unit level (Row/Page) – and having to constantly navigate between the two would be a considerable expenditure of energy.

EXAMPLES

(1) PAGES WITH HIGHER EMPHASIS ON RELATIONSHIP OF PAGES

  • project management, where each Page represent a unit linked to other units

  • marketing programs, where each Page represents a channel that interacts with other channels

  • legal contract abstraction and management, where each Page is a clause in a larger contract

  • investment planning portfolios, where each Page outlines an investment dependent on data of other investments

(2) PAGES WITH LOWER EMPHASIS ON RELATIONSHIP OF PAGES

  • asset listing or asset management, where each Page contains asset plans and reporting that exist independently of the other asset plans and reporting

  • websites, where each Page contains a stand-alone webpage

  • human resources, where each Page contains team member details which exist independently of other team member details

  • catalog, where each Page contains product assets that exist independently of other product assets

4 Likes

Are these listed as sections still in the API and are there any plans to add create for pages to the API?

Thanks!