We just launched native support for images in cells - see Launched: New Image Column Type is now available
Nigel & Jamie, the images feature is a great step in that direction. I know you guys have a unique design philosophy, but a lot of the people who are moving over from Airtable and/or Notion are going to find this to be a necessity.
Jamie asked for refreshed use cases. I have one that’s holding me back at the moment - I can’t add attachments to tasks. I’m trying to migrate from Wrike to coda because of everything coda does so well. I can embed or link, but it’s really crucial that the attachment be contained within the task for data/trust reasons.
As well, above, someone mentioned a page view, which also basically comes from Notion. You have a basic page view of a row right now and it’s heading that way. I don’t see how coda could do the same thing Notion does, but that’s fine, it’s not the same product. With the ability to attach files in a cell, beyond images, I think you’re basically where you need to be.
If we reverse it from a business rules angle, one of the more obvious recommended templates is tasks. The core elements of all modern task management apps are within coda’s capabilities now. The only one missing is the attachments.
With that said, coda’s a very robust and interesting app. I’m only about a week into it, but it’s closest to something I spec’d out a while back that does 80+% of what I need. Your continued rollouts and work are appreciated - so thanks!
Hi, My 2 cents here to vote this topic:
it is extremely important to replicate what has been done for images also for files (PDF, .docx, .pptx, etc…).
I really would like to format a column to “file” (potentially reagardless of the type, if it’s an image, pdf, word,ppt…the system should recognize it based on the extension) and hence being able to preview/navigate them (pretty much how it happens for images now).
Using “embed” is not sufficient! It is cumbersome and most of the time i’m dealing with local file system/email attachment.
PLUS… and it’s not the least:
a column that is a “Section/page” itself would be the game changer here so I can have a free canvas inside a cell (like Notion does)
When you guys will implement that I’m sure you’ll win the game for the new Makers how your CEO says
Images is a good step!
Definitely want files too though e.g. for a task backlog, attaching a relevant csv / xls dataset
I couldn’t find more recent threads on attaching files, so I thought I’d bump here - any news?
One proposal for the PDF feature is to include citation extraction so as to replace zotero & mendeley.
Definitly need this too.
Any timeline ?
Basic file repositories are just that… a basic requirement. This is an absolute show stopper for us and I’m sure we are not the only one. Coda is a tool that should enable us to bring all the ‘things’ together. Is there a reason only image uploads are supported over all file types?
@Adam_Abbott I imagine that until they have a pricing model, allowing unlimited uploads causes more problems than its worth from a hardware and support standpoint.
That could be solved with fixed size limits per account/file.
Any update here yet?
I hate attachments in all the “normal” Task/Project management services. It just take ages to upload everything or navigate through tasks.
Coda is really cool with images copy/pasting directly to doc or cell.
What I’d prefer instead of messy attachments - is ability to quickly edit multiple selection if images. Let say you uploaded 10 images and can quickly resize them all in connection to each other.
In terms of attachment - embedding of Google Drive or Dropbox folder is way to go.
Especially now, when Google Shared Drives has unlimited space (why spent money on Coda for that?)
I finally ran into this as well when we started using the system for project management.
For us, the ideal situation would be a way to integrate it with the Google Drive Pack.
Features we need:
- Arbitrary attaching of files to Sections
- Attaching files to rows
- Ideally, if integrated with the Google Drive pack, for a specific column on a specific table the ability to specify a target folder and have any attachments immediately uploaded there.
We’re finding it really difficult to integrate workarounds based on GDrive and Dropbox. Our teams need to create workflow and process around GDrive structures, governance etc, then upload there, pull links, attach those to objects.
It would be great if we could just see native file uploads come to Coda without intensive workarounds.
You mean like - whenever a document is added to a specific Drive folder, add the [secure] link to that document into an existing or new row in a Coda table? Basically - sync the contents of folder (x) into table (y)?
I would like the opposite…
drop a file on a row in Coda.io and the save it to a specific folder in Drive (good for large files, otherwise the coda document would be to large)
Meaning that we need team members to actually leave the doc, create something and a structure on a google drive and then come back with a link. Its not just the process of having to move off of Coda, its that you need additional layers of SOP around governance, admin and maintenance of Google Drives. When in actual fact in most cases a table with attachments and some simple process is self servicing.
Understood. Thanks for helping me see this.
In a few cases I’ve overcome some of the manual tasks that stand in the way of a seamless creation of the connective tissue between Drive and Coda docs, but it’s presumptive and extremely rigid.
GAS, Tags, and Google Drive Change Events
For example, imagine a script process that watches for change events occurring in Google Drive concerning files that contain hash-tags embedded in the documents (or in the document description meta).
Whenever a change in a document that matches the tagging scheme occurs, update a row in every Coda doc where that Google Drive document is represented. If a new Drive document is created that possesses the tag scheme pattern, instantiate the representation of the document in all Coda tables where appropriate.
While this automation approach works really well and eliminates a great deal of the process requirements (i.e., SOP around governance, admin and maintenance as you point out), it requires significant effort to build and define the process rules to make this happen with precision. There’s nothing ad-hoc about it - it’s a machine that performs steps to synchronize visibility - links to Drive documents about (x) appear in Coda tables (a, b, c) about (x).
It’s presumptive in that it fails to embrace any level of security in the context of discrete users, and it assumes document creators fully understand the ramifications of the tag scheme, a potentially dangerous automated sharing proposition.
Clearly Way Off-topic Now
But it does underscore one of the few cases where Google Apps Script can be applied in a non-polling way to sustain real-time connectivity between Drive documents and direct access to those documents in Coda tables and even embedded content.
Why would I even go to this trouble?
Money. People pay me to do whacky things.
I’ve used this approach to create a search abstraction layer inside a Coda document; indeed, across many Coda documents. The business requirement was simple -
… make it possible for Coda users to search [inside] Coda docs to find and access Google Drive content.
Creating seamless findability for documents in Google Drive seems oxymoronic. After all, it’s Google. But this requirement runs deeper than search - it’s about effortless embrace and seamless accessibility of documents external to Coda - literally to your point.
- Watch for change events in a Drive folder (or across all documents that match a specific pattern).
- When a document matches the pattern, harvest the content and create a full-text (compressed) keyword index.
- Update the document’s security setting to “has link”.
- Upload the document’s title, meta-info, URL, and keyword index into the target Coda tables.
- Create a change log record (another Coda table summarizing Drive-based document updates).
My approach does all of this seamlessly and in the background with Google Apps Script. However, it’s not a bed of roses and hopefully, this exposes to the Coda developers some of the drawbacks of making so many presumptions in such a process.