Launched: Pages and Updates to Doc Navigation

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:

6 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!

5 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.

15 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

6 Likes

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

Thanks!

1 Like

Thanks for the detailed feedback, Ander! I’ll forward it to the product team.

4 Likes

@Sam_Smith yes in the current version of the API pages are still listed as sections. In the future, we will rollout a new version of the API that has more built-in support for pages. I’ll be sure to add your request for create page to our backlog.

5 Likes

Great updates! However, it seems like one feature that I really liked disappeared along with this. It would be very nice to have this back. The feature was the ability to shrink the left sidebar just enough to show the icons for each page, and only the icons. Now, when I try shrink the left sidebar to hide the text and show just the icon, it closes all the way…

My docs are set up so I can quickly navigate them by using the icons as a visual menu/navigation, which was working pretty well up til now!

Thanks team!

1 Like

Hi @raina0983— I’m the designer that worked on this. Good question. Before, there were only two levels. But since you can now nest pages inside pages several levels deep, there wasn’t a way to make all those levels clear in a mini sidebar.

We do think the ability to quickly switch is useful, so we added the ability to show the sidebar on hover as mentioned above. Not exactly the same of course, but hopefully it enables you to navigate just as quickly. Would love to hear what you think of the hover sidebar, and how your doc is set up specifically, feel free to send me a private message on the community here.

1 Like

Hi Evan,
I find the reveal on hover really annoying and distracting. I would prefer to toggle manually AND have a re-sizeable left panel with icon only view.

Life would be better without the side panel jumping open on a mouse movement.

T

Is it possible to hide a subpage in the sidebar but still see it under the title of the parent page on the canvas?

I have a doc with a top level page, 4 subpages, 16 sub-subpages, and 64 sub-sub-subpages. I would prefer if when I click on a subpage listed on the canvas under the parent page’s title that the entire page list doesn’t unfold in the left sidebar. It’s quite annoying for docs with many pages.

Just like I can toggle Subpages on or off at in the Page Options panel, I’d like to be able to hide subpages in the doc list (left sidebar) - but still see them listed on the canvas under the title of the parent page.

That said, I have found one workaround: refactor the entire page list under one top level page, essentially porting the doc list onto the first page.

1 Like

I’d love the ability to edit Subpages listed on the canvas. Instead of having to move my mouse over to the left side bar.
Screen Shot 2020-06-11 at 8.22.46 AM

2 Likes

Hey Evan, wow I am really late replying but I didn’t realize you had replied to me! Still a relevant topic. I just mostly have one-layer docs. However, I see your point. I made a quick mockup to illustrate a simple way this function could work that supports multiple layers.

Screen space is valuable, I don’t care about the names of the items (I know what they are), and the click-to-open, click-to-select, click-to-close process is just not good for frequent tab switching.

4 Likes

I pulled in a Notebook from Notion with subpages.

How do I get a subpages header to show on the parent page?