Going forward, in the plus menu, you’ll just choose what kind of display you want. This immediately gives you a realistic preview of what the object will look like, then lets you choose a backing table or create a new one.
We found that this experience gives users a better sense visual of what’s happening when creating a new object. It also paves the way for some other exciting improvements we have coming soon.
As an added benefit, you can now search for tables when creating views in documents with many tables:
I gave my opinion in a private call with @Angad on this. I personally don’t think this change serves a useful purpose, and is actually a worse experience.
The underlying problem is: newcomers to Coda have hard time understanding master tables vs views.
The solution you’ve suggested: let’s show the users some bogus placeholder view behind the selection list (what does it solve?). Also when a user creates a Detail view on a + New table, let’s hope the user figures out that this detail view is actually a master table, just with a different display option.
What would be the best thing IMO: to encourage via UX to only create master tables as tables:
Always have an option in the top: New Master table
Options to add Table view, Cards view, Layout view etc, which will:
Offer to select one of the master tables, or
Offer to base it on a new master table, BUT if this option is selected, another dialog shows up asking where to place the new master table — in a separate section or below current view (just like it’s done when extracting select values into a table).
I.e., the options to add Table view, Cards view etc would always add a VIEW, never a master table.
This would make the difference between master tables (grids) vs views more prominent, as well as promote better doc structure (master tables placed separately from views of different sorts built atop of them).
I would personally like to see Codans focus on more important things like design (pretty bad and space-wasteful now), visualisation (colours, icons, effects and material design) and proper mobile experience.
Thanks for the feedback and I agree this solution doesn’t go all the way to fixing the problem.
However, it is a key step for future improvements in increasing understandability.
Keep in mind, that in the previous model, the only time you made the decision about tables vs views was inside a submenu. Many users would miss this menu entirely and our tests with users who did not know how to use Coda showed that this model helped make things much easier to understand.
But your idea about creating a master table as a table view whenever you start with a new Calendar etc is a good one. It’s been a hotly debated topic inside Coda for years and it came up again when we were testing this feature. In fact, the first version of this feature used to work that way but there are a number of issues with that model that we decided to not take on right now. For example, if the user just wants the detail view and not a master table somewhere, what happens if they delete the master table because they don’t need it?
Either way, that is definitely an idea that’s on our mind and this feature would also make it easier for us to do that in the future. By adding the step to make the choice explicit, it gives a user a chance to understand what is happening.
