We want your Coda experience to be smooth and free of paper cuts, for all the many things you and your team accomplish in your docs. Which is why, once a year, our product team devotes a week to shipping as many quality of life improvements as we can. Here’s a run-down of this year’s updates, categorized by three product principles that guide our decisions.
Docs can (and should) be beautiful.
Default page width setting: We’ve added an option to change the default page layout settings, so you can set the page width of your choice across all docs or on all pages within a doc.
Toggle add column on/off: You can hide the add column button from the table settings menu, giving you more control over the appearance of your docs.
View link column type as button: Create a button column from a link column, directly from the column options.
Copy/paste callouts: Quickly duplicate a callout and retain its formatting, either by selecting it and typing cmd/ctrl + c or selecting “copy callout” from the three dot menu.
Collaboration makes for successful projects and teams.
New notifications and settings menus: Notifications have a new home where you can see all your notifications or filter to your current doc. We’ve also refreshed the settings menu, making it clearer to navigate.
Embed Jira and Trello dashboards: We’ve added support for embedding cloud-based Jira and Trello dashboards, for both canvas and full-page embeds.
Suggest changes from the inline toolbar: Start suggesting changes faster than ever by using the new button in the inline toolbar.
Recent searches: The search bar at the top of your doc’s page list now remembers your most recent search terms to make finding what you need faster and easier.
Simplified workflows = more execution time.
Multi-select checkbox column: Instantaneously check or un-check multiple rows by right-clicking on the selected rows.
Keyboard shortcuts for today’s date: Insert today’s date via the keyboard shortcut (cmd/ctrl+shift+d) or by typing the command /today.
Clear formatting button: There’s now a simpler way to clear formatting on text with our new “clear formatting” button in the inline toolbar.
CopyDoc() result column: When using the CopyDoc() action, you can specify a result column for the URL of the new doc copy.
We’ll be replying to this post with a few more feature updates throughout the next couple of weeks — let us know which one you’re most excited for!
There have been quite a few posts about this - there are different reasons for different docs and/or makers.
Problem 1) workflow is completely bust if people get into tables (table rows) through a search, rather than by means of a logical work flow.
Problem 2) relation tables are used in relation columns - and are often not meant to be used directly, which can happen if you stumble onto them through a search.
Problem 3) hidden pages have a reason. Not because everything is a secret, but because that’s where you setup defaults, park lookup tables and park master tables. We, makers, often carefully filter tables for a reason and search makes this completely useless. It allows people to go where they should not go, either because of workflow or for whatever other reason the maker had in mind.
There are more reasons, but these are some of them.
Our team just quit Coda and choose Notion instead. Just because the whole “only doc maker can add page” thing. it’s surprising how many users you lost just because one function was removed.
I’ve been posting about this for 4 years. It is very confusing to a ‘lay-user’ to have that search there. We can craft specialty searches with formulas, tables and controls, AND you have the very nice table search. The global search is so prominent and beckoning, and gives results on everything and takes users beyond the carefully manicured interface we build for them. I can’t see any reason to have it available to users - it’s for makers. At best have a toggle to enable it. By hiding it you will make interfaces so MUCH BETTER for users and expand the capability of Coda massively.
There are very many reasons to be able to search the whole of the document. Including for end-users.
I can understand the need for a limit in some instances, but definitely not all. On another thread I have expanded on how it seems to me that in “step 3 and step 4” of the coming syncing and embedding functionality, Coda will solve this. And do so thoroughly.
do I understand you correct @Piet_Strydom that in your future coda world all users have their individual documents with only sync pages and cds filtered for them?
Hello Brian. Searching inside a Doc in the context of a normal user is a great tool that can find anything. But for a developer, this ability to search within a Doc is a vulnerability to the workspace they have designed. The most common problem in designing a Doc is delineating access. Both from a security standpoint, so that the user doesn’t get in where he shouldn’t and “break” something in the system. And as a distinction among participants within one Doc. And this “access system” we design ourselves with Coda tools, but no matter how carefully we do not mask and hide the data, all the security is crumbling because of the ability to use the search. So it would be great if the possibility of global search on Doc could be disabled or enabled optionally. And developers can independently figure out how to oragnize access to public information in Doc.
Epic! Please also add settings for default date format. We always use the standard 2024-01-25 since sorting is the best with that format.
Default Doc sharing option would also be great!
Hi Peggy, thanks for reaching out. Our team looked hard at the data, customer feedback, and support questions before making this change, and ultimately landed where we are for a few reasons:
Before, it wasn’t clear who should and shouldn’t be a Doc Maker. Pages have grown from a minor feature to “the new doc” unto themselves, especially to those who come from tools where docs are way flatter. It became confusing. Why draw the line at docs?
The new change preserves content collaboration between makers and editors. One option in a range we considered required Doc Maker status to make any doc schema changes. But collaboration is critical, so that’s why we landed here.
Editors will still be able to do a lot for free on existing docs and pages. In other tools, editors can’t do things like add tables or views, use templates, edit forms and automations, etc. In Coda, you can.
Thanks again for reaching out, and your understanding. Our team’s always happy to discuss your specific use cases and how we might find a solution that works for you. Even if that’s moving to another tool.
In our (IT) team second brain doc scenario, I foresee that everybody can see and do everything. Same with their personal docs.
For policy and procedures the same, because those need to be searchable to just by the top left search bar, but’ in natural language. Any language.
Then for projects working with external consultants, their would be core / source documents. Those doc’s would contain certain information that is shared with the implementation partner(s)
Just in my roadmap for our business’ future I see a range of requirements. And that is before all the surprises from sales, marketing engineering, production etcetera that will surely come down the road.
this idea seems counter productive to me, you have to set up and maintain many pages (in all sorts of source docs) and many docs. It feels like going against the idea of coda as a collaborative app. When clients would ask me for a set up like this, I will send them to you.
Cheers, christiaan
Good update thank you. Biggest pain point for me being from the UK is having to change the date format to dd/mm/yyyy for every column in a new table. I think this format should be set as default based on the user / documents region. Would be a huge improvement and time saver!
