I think Coda is an incredible achievement. I have put quite a bit of time into learning its capabilities and thinking through mocckups for several of my projects.
But in all honesty, I am rethinking this at the moment. That is because I cannot share my documents publicly; even if we get to a post-Beta period with no invites, the need to sign in with a gmail address means I can never truly “publish” a document I write. I cannot embed it on my website. I would not want to share it with a client if the client would need to use a gmail account to view it.
Will this change? If I am correct and Coda is never intended to be used for “publishing” or “embedding” Coda documents elsewhere, that is disappointing- why? If I am wrong (and I hope I am), can the powers that be give us a definite thumbs-up and estimated date when this will be possible; otherwise it does not make sense to build something if I have no clue if/when I could use it publicly in my business.
Bottom line - it’s quite a shame to build a great document in Coda but then have my hands tied as to how I can use the document.
Actually, all options would be great
Sometimes I would like to only share a few sections with read only, other times a full document with some accessible controls that would record the visitor action and result, ideally in hidden sections.
Completely agree. I’ve just started with this tool, but it has a ton of potential for organizing my development streams.
But often I want to make sure i’m in sync with vendors, management, other interested parties and the need to be able to share a document, at least on a view only basis, with outside interested parties is very limiting.
Allow them access to update/edit/etc would be cool if it could be granular, but the really big deal is to allow some view type access…
Being able to turn Coda documents into apps is very important for my use-cases as well. It’s essential in order to “market” Coda internally as an alternative for well-established apps. Without “public” documents being controllable (with user/session-specific—not global—controls), this won’t be possible.
These actually work whether you have a Coda account or not, and also allow non-Chrome browsers access to view the content as well.
We’re working on the in-product experience for exposing this capability right now (along with documentation), but you can actually try this out on docs you have authored right now if you’re curious what it will look like
Go into Google Drive, and find the Coda doc you want to embed
In line with Richard’s initial question, it would be tremendously helpful to be able to share Coda docs with clients externally for viewing without requiring them to create an account. That will be a major barrier for usage, as we’ve just barely gotten some folks used to basic Google docs.
I had some problems with activated Ghostery though: On some (not all) docs, I got an error when embedding & at this point all my open Coda docs/tabs crashed. Deactivating Ghostery solved it. Maybe because it blocked Pingdom or Intercom.
@Shannon_Jones - this is definitely in our plans… we intend to support the sharing of entire docs without creating an account in addition to the embedding scenario I outlined above. Stay tuned.
@Daniel_Stieber - glad to hear it! For now we don’t intend to change the “scope” of what you can embed (e.g. you won’t be able to embed a table without sharing the entire doc), but we do plan on ensuring that we retain the existing behavior where embedding a URL will show whatever content that URL points to.
Regarding the crash, I installed Ghostery on Chrome and didn’t experience the crash you mentioned when viewing those embeds. If you happen to get the crash again, can you email me the output of the Chrome Developer Console (PM me or email@example.com). Thanks.
This is great! @alexdeneui if the main thing is to share complete doc, as a way to share only parts of a doc, we could use cross document features. Are you currently working on a Coda pack, and what are your plans concerning cross document within Coda? Thanks!
Hey Tom - Yes, for now we’re focusing embedding on entire docs and as you point out this does have some limitations.
We’ve do have a Coda pack we’ve been working on internally but we’re missing a few pieces that will make it really great for these cross-doc scenarios. Are you mostly thinking about accessing table content across documents or something else?
@alexdeneui Embedding is definitely a great step forward!
Regarding outside user interaction, as an example, having vendors/contractors/etc provide monthly invoices into an automated Coda process would be very beneficial. I would imagine you don’t want a purely public document that anyone can access or change but a workaround might be to have a “user-lite” account that outside contributors can quickly (and freely or at least free to them even if it costs the main coda user) set up to submit data, provide input, etc.
It would also be helpful to share sections instead of whole docs. I work in real estate development and deal with internal team, consultants, contractors, banks, investors, etc. Essentially, everyone needs a different “view” of the same core of information. it would be cool to be able to, say, copy a master section and whittle it down into a more limited customized view for a particular contractor or designer, etc. This would mitigate redundant data entry and still allow for a single source of truth for your information.
I would want to embed a document where the user can manipulate it but the edits do not flow back to the actual doc. A read-only version where controls do not work would negate all the benefits of Coda.
Embedding an entire document is fine; I do not need to embed single sections.
One question… these Embed options solicit the reader to make his own copy of the document on his own Coda account. Can that be disabled? I want the public to be able to view my document but not to have an exact copy they can edit and re-post at will.
Yes accessing table content would be cool. But what would be the best is having the ability to add views from other documents. This way, I could have my workspace, and some elements showing on a public document.
One thing I think would make this absolutely awesome, is if the visitor of the public document could push buttons, but there would be a way to disable the button after use, for voting system especially. How could we do that? Could you track the ip of the visitor so that we could disable a button after use?
Hey Richard, you are only seeing the Copy Doc button since you are logged into Coda. I’m guessing the vast majority of your audience will not be Coda users, in which case they will see a button to Sign Up for Coda. You can try it by opening this link in an Incognito Window: https://codepen.io/adeneui/pen/mQYVPP
If someone is logged into Coda, unfortunately they will see the Coda button, to support scenarios like templates. Unfortunately we do allow users to duplicate any documents, even if they only have view access, so they would be able to get to that even if we hid the button.
OK fair enough - I will plan private content accordingly. It is an extremely useful feature as is - thank you.
Question - The invitation to copy the file or open a Coda account is quite prominent in location/color (no doubt on purpose) and distracting after first viewed. Is it possible to have an X so the viewer can dismiss the notice?
Hey Richard, thanks for your feedback and excitement about this feature. The design you see at the moment is still a work in progress and we’ll definitely keep your suggestion in mind as we finalize it.
Meanwhile, one thing you could try is to increase the height or width of the embed window to make more room for the doc itself and reduce the prominence of the bottom bar.