Structure - no duplicate titles in a doc?

1

Like many new to Coda, we’re wondering about structure setup. A first question would be, is it really not possible to have two pages, or subpages, or even tables for that matter, to have the same title?

Here’s a basic example of what we want to set up:

Overall All Customer Performance
Customer 1
     Performance
Customer 2
     Performance
Customer 3
     Performance
....
Customer 90
     Performance

In this example we’re tracking some customer metrics, as well as rolling up their metrics to view maybe a chart of overall performance. Note that we have a decent number we’d like to track, 90 in this example.

I’d love your thoughts on this.

Option #1: Coda’s general recommendation, based on videos and help docs I’ve read, would be to have one single “Doc” contain everything. Within that doc, each customer would be a “Page”, and Performance would be a “Subpage”. A problem/annoyance with this seems to be we can’t have two subpages named “Performance”? So we’ll need to name them “Performance 1”…“Performance 2”…etc Even worse, two tables can’t be named the same, so the tables in each of these will also have to be named…“Table 1”…“Table 2”…etc

Option #2: One doc per customer, and Overall All Customer Performance would also be a doc. A main problem here seems to be that docs can’t be sorted in a custom order; docs are listed by last modified? Seems like an odd, basic missing feature. Additionally, rolling up the data from each customer to get an overall view seems difficult, only recently made possible by cross-doc

Any thoughts on how you’d structure something like this would be greatly appreciated!

2

Hi John,

I will provide a workaround which is not ideal but has allowed me to achieve a lot for instances when I need same column names or no names at all or similar.

Use of special character after the name you want to be duplicated.

Here are some examples:
non-breaking space (https://www.compart.com/en/unicode/U+00A0) - It is ideal for situations when 2 words need to stay together, but also works OK for column/table/button names. I use this a lot even for instances when I don’t want a column to have any name.
thin space (https://www.compart.com/en/unicode/U+2009) or
hair space (https://www.compart.com/en/unicode/U+200A) - Also ideal as they require very little estate and you can use it 10 of these in a column/page name and it would hardly be having any effect on the width of the name.

Not perfect, but honestly, it has worked great for me for almost any case. Use it for names of columns, tables, Lookup, button names, canvas… practically everywhere you need to keep words together (non-breaking) or have identical names (thin/hair space).

Let me know if this helps.
Stefan

3

Dear @John_John, welcome to the community :handshake:

  1. I would like to advise not to focus on getting it right from the first time.
  2. Don’t worrie at this moment on what page you have the info, it can be moved later on.
  3. If you have already sets of data and processes in place, try to get them in a basic version in place
  4. You mentioned that you measure performance of your customers, could you eloborate on it to get more details? All the measurement scores are comparable, have the same weight/importance?
  5. How often the performance will be measured is also an important factor and how long the result will reflect in the calculations.

Further more, I strongly recommend to copy some of the templates and have a look under the hood, just to see how it’s structured.

A recommendation: just to get a better feeling how data can be structured and having only one source of thruth:

  • Here you can see that a dish has different ingredients and some of the ingredients are used in one or more dishes
  • In “sign up to help”, section 3 is a “detailed layout” table where in this lay-out are shown other relevant tables like “ingredients table” and the “resource table” as they are important elements to be able to create your dish

After all, you will have a better understanding of what are: docs, pages, sections and tables

Feel free to share your dummy creations and question what’s on your mind, there are no stupid questions and you will become proud of your self when you understand that also you “can make it”! :construction: :building_construction: :construction:

4

@John_John

  1. How consisent are the data between customers? Same data fields from same data sources? Or disparate?

  2. What kind of content is contained in each Page type (Overall Page, Customer Page, Performance Page)? One Table per Page? Several Tables per Page? Views? Big blocks of text? Charts and graphs? Multi-media?

5

Without knowing a little more about how much you are wanting to store per-customer it is a bit difficult to make recommendations. That being said, my personal approach to something like this would be as follows:

Set Up a Customer Table
Using a table instead of pages would allow you to avoid the duplicate pages - your doc would also be a lot more consolidated and you can search things easier.

image
image1006×370 6.67 KB

Add a Button to Expand the Row
By adding a button column you can activate the expanded row view which can be customized to your liking (pardon the lack of detail in this - I just threw this together as an example):

activaterows
activaterows1684×916 424 KB

To do this you add a button column and do a custom formula for the button:

image
image517×724 28.4 KB

Better Looking Pages
If you wanted to have your performance and/or customer information in a better-looking format you could still use the above but then use page formulas and create a template that would update based on the selected customer.

prLp2QVkxR
prLp2QVkxR1920×920 206 KB

To do the above:
*Create a multi-select on the template page and use a formula to pull in customer names:

image
image742×500 20.7 KB

The general formula would be [Your Table].[Customer Name Column].Unique().Sort()
This returns a list of unique values in the designated column that are sorted.
I also would disable “allow multiple selections”

*Create a view of your customer table on a different page (I usually would call it helper or data and then hide the page) and then filter that table based on the value in your select box:

image
image1676×370 22.4 KB

*Fill in your template with formulas referencing your filtered Helper table:

image
image879×468 18.7 KB

You could also add charts and other tables using some of the same/similar methods above. @Ander is asking some great questions though so depending on those answers this solution might or might not be viable.

2 Likes
6

Hi @John_John,

And welcome to the Coda Community!

There are a few reasons we don’t allow items of the same name within a Coda doc, the biggest reason being that it become impossible to reference those same items through other means. For tables, you might need create a formula that pulls data from a particular table, if there are 90 of them with the same name, you’re not able to find the table you’re looking for. Also, linking to pages using “Command + k” would mean that you can’t reference other pages as they are all the same name.

Please do check out the answers above as they are all from great makers! I’d check out the one by @James_Eades as well because that gets into how Coda operates and helps to simplify data. The use of views and filters means you don’t necessarily need 90 separate tables. It could be that you do, but I’d look into Coda Views and also Filters first.

7

Thanks everyone, I’m looking through everything you mentioned. To answer some questions

1.) Data fields are consistent between customers

2.) On the Overall page, we hope to have a graph of average performance of all customers. We’d also like to be able to view average performance of different segments of customers, e.g. “graph of average revenue from customers that have type = SMB”

3.) The Customer page will simply be some general info about the customer. Customer name, internal notes about the customer, etc. Likely nothing that would be used in a table/data elsewhere. (customer names and unique ids would probably be stored in a separate, single table somewhere)

4.) Performance page. Here we’ll house data for each specific customer, and a graph or graphs at the top of the page where we can view data over time. The data itself may be in one single table, or in multiple tables, not sure yet. Basically a review will be done of each customer once per month, and the results of that review will be added as a new row. This will be primarily numerical data e.g. “Revenue from this customer this past month”. In the graphs at the top of the page we’ll want to be able to view this metric over time, for this customer. In the “Overall” page, we’ll want to be able to view an average of all customers for this metric, over time

5.) Over time, these tables will grow large, many thousands of rows of performance data for each customer

And a comment for @BenLee: the solution for that issue is a very basic tenant of software development, unique IDs. Multiple pages named “Performance”, each having a unique id, is the solution. When searching, linking to pages, etc, they can then be displayed along with the unique id

Performance (abc123)
Performance (def456)

8

@John_John here is a very rushed example that you should be able to copy over to your account and play with:

image

Note: I would probably make a lot of changes to this for efficiencies and also to base lookup formulas on CustomerID instead of CustomerName. Not sure how well it would scale as-is (the button in the column to edit the customer would have to go).

1 Like
9

Hi @John_John,

Our team did some work to make this a possibility. They also worked to help provide a little bit of extra info so you can tell which page is which when they have the same name.

Check out the launch post here:

3 Likes