Let’s say, there is a rather complex table I’d like to present to my colleagues.
I already made a few controls that change quite a few values/formulas inside the table so the viewer can get exactly what they need out of it.
Problem is, once they change the controls setting, everyone else now sees the same view, which in this case is not ideal. What I’d love to see is an option to set a control element “asynchronous”, which wouldn’t share its local value with the other users viewing the doc.
I assume it would be far from easy to implement, but it would be great to hear whether someone else would find that feature useful or how impossible it would be to implement
Having a control implies there’s no single best way for users to view a given table, and you want to give them the option to filter it different ways.
But then why should that filtering propogate to other users? By definition the controls are there for individual users to make the decision to override the table’s default sorting because they have unique needs/interests inthe data.
(aside - I also think a clearer title for this feature request would be “User-Specific Controls”)
@Nick_HE, this is a question we see pretty often and we see use-cases that would benefit from this regularly as well. It’s one of those features that hasn’t quite made it to the top of the list, but it’s definitely talked about and paid attention to.
Something that’s somewhat surprised me is just how many questions pop up when seemingly small features are being put into play. There is quite a bit of planning that goes along with it and the order in which things are added can affect other things too.
I can say that Coda sees this as a feature that would add value for sure and it is important. I can also say that the order in which features are added isn’t necessarily an order of importance or demand. Some items need to be in play before others can be added and some things need to be tested before other things can be built on top of those. There is a big list of questions and interactions that need to be considered, like how will locking and permissions work with a per-user search field?
For now, using the suggest work-arounds is the way to go, but this is something that is on our list and is seen as an important feature.
Agreed this is really needed for when an app is shared with multiple users.
What I’m working on is a financial transaction ledger app that also has a “dashboard” page that shows a snapshot of a company: copany info, contact details, transactions and comments.
The user (User2) can pick which company to look at using a “select control”, say companyB. Problem is… if another user (User1) is also looking at that page and had selected CompanyA… as soon as User2 changes the select control to CompanyB, the page also changes for User1…
I don’t see how Coda is used in practice by large groups of users… Am I missing something?
This is a known request, and one we’d like to turn some attention to when the time comes, but for now a workaround is needed.
It’s not too tough of a setup, but instead of using canvas controls, you would use a table where each user gets their own row. Then add columns for each option you want to filter the table by and also make it per user.
Thanks @BenLee. I tried to understand that workaround doc and some others and I don’t see how this is scalable into a system that is robust and can be rolled out to an organization.
That said, I’m still trying to understand though, what use cases and scenarios drove the default behavior of Coda where all users want to see the same view of an entire dataset?
<…putting on flak jacket…>
The forum is full of (very clever!) work-arounds and hacks for features and functionality that I would expect a system you’re charging a monthly fee for to have.
Don’t get me wrong, I think Coda has enormous potential to be the next “doc” but it needs to work straight from the box for most people without workarounds. I would hate to see Coda become the next Google Wave…
We started with table views, so each person can have their own customizable view. That’s been part of the idea from the start. Coda offers a very customizable setup in this way, and there are a lot of scenarios where this is used, but you’re right that per-user controls are a necessity as well.
Coda is a pretty young company that’s growing fast, and we’re constantly improving the product. And please don’t misinterpret the order that features are added as an order of importance. There are a lot of factors at play that affect the order of operations chosen. We just have to find the right time to move this particular one to the front burner.
It’s difficult to build for the future if you’re not allowed any time to build. That’s just part of growing and part of being an earlier user of software instead of later.
If you want to open a new topic and share more about your use-case, we can try to find a better suited solution for your particular instance.
I have found this article a very true explanation of startup SaaS issues like those described in this thread.
TLDR: " People love to conclude that something wasn’t done because they are stupid , or possibly lazy"
not saying this of the Coda team of course, the thought however is that Coda is not implementing something because they chose not to. However in Coda’s case they are most likely still developing some of the basic core functionality and that just simply takes time. The features will come, when there is either the time to free up a developer for that feature, or future features will rely heavily on said feature, therefore it must be pushed up the queue.
Nearly every “interactive filter” I create is exactly for this purpose - per-user exploration of a view. If I wanted the filter to be global for everyone looking at the page, I would just make it a regular, non-interactive table filter.
The workaround mentioned is clever, but a lot of lift to implement every time I need an interactive filter and not something I’m likely to do.
Adding this as native functionality of a control (instead of the workaround) would also open a bunch of new use cases and possibilities for Coda docs more general, I think. Would make it easier to make “apps” from Coda docs. For example, I could then have buttons that take a user to a given subpage, with a certain values for that page’s controls, without interrupting other users already on that page and reducing the number of individual subpages I need to create to offer dynamic functionality.
Since Coda open a new window for published docs, this feature is beyond any other. When we talk about private docs, we could make workarounds (even though they are massively painful), but for published docs there is no way to make a doc behave differently to each person that visits or site. I was trying to build a public database where people could individually search content and, for my surprise, the “search control” is even blocked to non Coda users.
Are you publishing the doc in play mode?
It should work well in play mode.
The Viva Pizza sample works in play mode and lets you tweak everything even in incognito tabs. Sandboxed, of course, and the changes are not saved, but the experience is that of an editable doc.
P.S. In case anyone finds this thread, the common solution to this request is this:
This is strange. I selected “Edit” mode, that should have even more permissions than Play mode. But in fact, play mode does allow individually usage. Thanks Paul!
Hi all, we’re collecting more feedback in this area. We’d love to hear more about how you use canvas controls in Coda, and the behaviors you prefer. If you have examples you can share or describe, let our team know here!
