Launched: Hidden sections [PRO]

News from Coda
1

Hi all, today we’re excited to announce hidden sections to help keep your docs clean and organized. You can hide sections to archive old content, or to hide sections with supporting data that make the rest of the doc work but otherwise get in the way.

How to hide a section or folder

To hide a section or folder, click on the 3 dots to the right of its name and then choose “Hide”.

Image 2019-12-03 at 10.19.28 AM.png

Showing hidden sections and folders

To temporarily show hidden sections just for you, click the 3 dots next to the “New” button at the bottom of the section list, and turn on “Show hidden sections”.

Image 2019-12-03 at 10.20.16 AM.png

After section are made visible you can permanently unhide them by clicking on the 3 dots to the right of its name and choosing “Unhide”.

In case you’re wondering…

What plans include hidden sections and folders?

Hidden sections and folders are available in the Pro plan and higher.

Can other users see hidden sections?

Yes, all people with access to a doc can choose to show hidden sections and folders. These features are intended to be used for convenience to improve the organization of a doc, and are not meant as security features.

Can I hide sections only from certain users?

Hiding a section or folder hides it from all users, and it is not possible to specify that different users see different sections as visible or hidden. If different people need to use different sections in a doc, Cross-doc allows you to create different docs for different audiences and share data between them.

Can I restrict what changes user can make in a section?

Hidden sections only affects the default visibility of a section. You can use Locking and Permissions to restrict what changes users can make in a section.

Check it out and share your thoughts! We’d love to hear how you use the feature in your docs, and any feedback you have.

23 Likes
2

Sounds great! Although IMO would be super helpful if it were in fact a security feature (i.e. if a doc owner could restrict un-hiding these sections to certain roles akin to the upcoming “who can unlock” permissions). That’d be easier than having to set up cross-doc. But hopefully that’s on the roadmap for some future updates :wink:

9 Likes
3

Agreed! Step in the right direction but would definitely be more useful if it can be used as Paul describes.

1 Like
4

I was super excited… by the first sentences of the announcement. A second later - Why?! :thinking:

IMO still missing security features which limit the use of Coda docs to mostly internal use are:

  • Lock a hidden section so that only Doc Creators can unhide it
  • Limit who can unlock sections

Probably these two are coming just if you could hurry up a bit would be nice :pray:

6 Likes
5

Awesome progress! Thrilled to see a team that can iterate, test, deploy rapidly.

Despite the complaints concerning security, the deeper story here is the pace of change. Notice how nothing broke when this new feature emerged? :slight_smile:

9 Likes
6

Yes. This is exactly that is needed. Simply add the option to the Permissions & Locking to “hide” a section from certain users. The shortest distance between A and B is:

  • Full Control
  • Interact Only
  • Read Only
  • HIDE
  • Default

And when you add full permissions, allow this to be set by Role / Person / Etc. That’s the cleanest way to hit all possible use cases.

3 Likes
7

As a follow up; cross-Doc does not accomplish what is needed. That’s why we’re asking for this to be a core part of the permissions.

8

Awesome as usual from the Coda team. Fast iteration!

But I echo my peers: The final form of the hide feature has to be as a security feature.

9

Cool addition. A good way to clear the doc of miscellaneous sections.

3 Likes
10

Thanks, really cool feature to have! Though I’d like to point out something (hope I’m not alone here) - hiding the folder does not hide the sections in it. Furthermore, unhiding said folder makes it so the sections seem to be dropped out of it.

Not sure if it’s intended or a bug but either way this confuses me. :thinking:

11

@Matthew_Oates1 this would be ideal if it worked like that — Hide along other locking options. But I see how it may be complex to design. E.g., how would one unlock the section to un-hide it, if they cannot see it? What should happen if a person wants to navigate to a table/view (via Doc map or the table links, or section URL), but the section is hidden? When it’s not a security feature it’s easy — just unhide the section and show the content. But what should happen if the section may not be unhidden for that person?

I think we’ll be getting the hide+permissions later. Just not in this iteration, because that’s a lot of design choices to make. I totally sympathize with Coda here actually — I used to face lots of design dilemmas like that in my last product three.do.

2 Likes
12

Like @Matthew_Oates1, I sometimes conclude a given design change is “simple”. @Paul_Danyliuk makes it abundantly clear [by examples] that there is nothing simple about the nature of a hidden section in a security context. In fact, it’s the opposite of “simple”. If implementation were simple, we would already be using it. Patience.

13

Thanks all for the feedback!

This feature targets a couple of common scenarios where it’s helpful to hide some sections or folders from everyone. For example, customers often show us docs with “You should not be here!” disclaimers on sections that store supporting base tables that no one needs to see or change. Now those can be fully out of the way.

One tip if you need frequent access to a hidden section: add it to your shortcuts, and it’ll be accessible all the time.

We do hear you that building on this feature to enable more scenarios would be great. There’s a few reasons we started here. For one, this is an incremental feature we could get out quickly that addresses a set of real needs. It’s also a familiar pattern for customers coming from spreadsheets.

To go beyond hiding as an organizational feature, and securely restrict which content individual users can see, requires a good deal of additional work to implement. Given how inter-connected Coda docs are, loading only certain sections while preventing access to the content of other sections is technically complex. The content in one section often depends on tables or formulas in another section, and de-tangling exactly what needs to be loaded is complex. We have ideas on how to do this, but it’s a large undertaking.

This is partly why we chose to ship Cross-doc first, as it lets you specify clear boundaries for what data should be shared in cases where separation of data is important.

We also want to incrementally improve the product, and allow features to build on each other. Cross-doc and Locking are still relatively new. We want to learn how you use each of these features, and Hidden sections, and what new patterns they enable together. We also know that some scenarios will still need more, and look forward to better understanding these with your help. Feel free to share more examples below.

We have explored ideas similar to those some of you have suggested, and carefully made decisions with each of these first features so that it’s possible to iterate and expand them over time. It’s great to hear the interest and excitement for more.

I also want to clarify that the upcoming permissions feature, while it allows you to restrict who can unlock a doc, is also not intended to be a security feature as it’s not enforced on Coda servers. Rather, it’s strictly a usability improvement enforced by the Coda client. This can prevent certain users from unlocking when they open a doc in their browser, but anyone who is shared a doc with Edit access can still change any parts of the doc through other mechanisms such as our API.

The approach helps keep Coda a flexible surface for a wide range of scenarios. We see many docs where customers want to enable changes through one part of a doc, while restricting the same or similar changes elsewhere in the doc. For example: allow people to change values only in one filtered view, but not in other views of the same table. Or, allow people to press a button in one section that adds a row, but prevent them from directly adding rows in other views of the same table.

While this means that enforcement only happens in the Coda client, this approach gives the most control to specify exactly what actions you do and don’t want enabled throughout a doc, in a way that matches the needs customers have shown us in their docs.

12 Likes
14

@miller can you double-check that the sections are actually within the folder before you hide it?

This is what I see: https://cl.ly/4efaabade7a5/Screen%20Recording%202019-12-04%20at%2009.40%20AM.gif

If you’re seeing something different, or this isn’t what you’d expect, let us know. Thanks!

15

Oh, that is very disappointing :slightly_frowning_face: Good to know, but this will definitely scare many teams away. You absolutely need to add some server-side data access mechanism.

Although I see that your common suggestion for that would be to just use cross-doc and share limited documents.

2 Likes
16

Good reasoning. There’s surely new complexities and special cases introduced once you can totally hide a section from a user.

Nice app btw! Love the speed record!

2 Likes
17

I totally appreciate the complexities involved in a larger permissions based model of this feature. And your willingness to provide incremental “quality of life” roll-outs in the interim. Very thoughtful of your team and much appreciated. I think we just wanted to make sure the full featured versions were on the drawing board and / or under consideration. It sounds like you have, in fact, already given this a good bit of thought. If there’s a way to make it happen, it would make open up more significant / impactful use cases for our clients. In the meantime, thank you for all your continued hard work and continuous updates / improvements.

4 Likes
18

Here is a (I believe) relatively simple incremental feature to implement toggle in the locking/permissions menu: lock selecting cells (or text) in a page or in a table to prevent copy pasting the contents of it (Excel has that feature and it is exremely useful for us as we have a use case where we want to share content but prevent users from (easily) copying it (screenshot + OCR is always a workaround, I know, but at least we make it more cumbersome to copy outright).

3 Likes