Published docs auto update

I am publishing a doc and my users will prabably keep it open for quite a while. Is there a way for the doc to update/reflect changes when the doc is updated by me? This works in edit mode, but in published mode the doc is static.

Hi @joost_mineur,

If you’re using view/play mode, the published doc will only update when the end-user refreshes the page. This was a design choice by the team based on feedback for publishing use-cases. An example would be posting an article and have it update and jump around while people are trying to read it.

In edit mode though, the published doc will update just like a regular doc.

Hello Ben,

Thank you for your anwer. I understand exactly what you are saying, but it makes my project impossible (I think). I want for participants to our activity to see in the app when the status of certain things change. If they have to refresh, that is never going to happen. I think there are many projects where you want to push (so to speak) a message to people. In our case, we cannot have the participants be editors (info is to critical and we only want staff to edit the info). And since we don’t know up front who the participants are going to be, we cannot use whatsapp or similar. Since the possibility to make this work seems to be build in, I hope you can make it available to published pages as an option. Even if it would be just a table that reflects changes without refreshing it would be of great help.

Any suggestions?

Thanks again,
Greetings,
Joost

That’s a fair point and something I will add to our notes.

For the moment, would just sharing the doc as “View Only” work for you? I’m talking about not using publishing, just sharing the doc with a link. That should show updates.

Hello BenLee,

I have tried your suggestion, but I cannot get a remote doc to (auto)update. Sharing as view only does not update a page unless you refresh the browser of sign in.

I notice that as soon as I follow the copied link, it opens the page and adds a slash and extra characters to the url - almost as if it creates it’s own instance (?). Would that be part of the problem?

In order to be really useful (for me) it needs an option to auto update and ideally it would allow visiters to filter and sort tables and so on, without being able to alter the content.

Anything else I can try?
If you think this will be possible sometime soon I will keep on building my pages, otherwise I have to find another solution.

I am experimenting with the free version, but I can upgrade at anytime if that solves this issue.

Greetings,
Joost

There are a few different things going on here and I’m not sure we’ll be setting up the publishing feature to accommodate all of this at once.

You’re asking for people to not be able to edit the doc but to still be able to filter and sort. Then needing live data to also flow in and update without requiring a page refresh. I don’t think this will work unless you open up editing and use locking.

Well, I am looking long turn - I hate to invest in an environment and get stuck in the end.
I realize what I am asking and I understand it won’t happen overnight. I am not opposed to locking, but I have to do some testing first.

Let me explain a bit better what I am trying to accomplish.

  1. we have an outdoor activity that is very (good) weather dependent. When I saw the possibility to publish docs like an app, I was sold right away. So easy to maintain, so easy to share, no frameworks or backend (other than the coda environment). So, I started testing and noticed the following: you open the ‘published app’ and taken notice of what is going on (like the current status of activities). You put your phone back in your pocket and look, say an hour later, at the same published page and still see the same thing, while the status might be different altogether. The people looking at this app are people that I don’t know, so I cannot add them as editor. How would they know that they need to update the app? And just for the record, how can I let them update the page, like with a button? Didn’t work for me yet, but I haven’t tried real hard.

  2. similar scenario, but this time I publish a table with available items in different categories. It would be so nice if the viewer can sort or filter (with pre-defined buttons) the (long) list. And as items become unavailable, they disappear from the list at real time, or get a different color background, or…

This kind of interaction would open up whole new levels of usability for CODA.

Please let me know if you would like to get more detail if that would help to consider these options.

I can see how this would be nice, but it’s also something that comes with a cost. Caching would have to be revisited and constant checks for updates would run up data, so it would need to be a pretty dialed in implementation depending on the size of the doc you end up with.

I’ve mentioned this to the team, but can’t make any promises on what works with the engineering side of things. We’re still gathering metrics and building out this feature, so very tough to say what will end up happening here.

Sorry I don’t have more info for you.

Thank you for listening to me and taking it into consideration. I will hang around and see what will happen. There are enough nice things that do work right out of the box.

There’s one thing I don’t understand: if this works in edit or logged in mode, what would be the real difference with the not logged in mode? Number of viewers?

1 Like

In edit mode you’re interacting with the doc which can be used to trigger recalculations which updates. In view mode, you’re viewing and not interacting with the doc.

Right!
Thank you for clarifying that,