Remove "/dashboard/" from router

[rabernat]

My feedback on the router layout is simple: let's remove the /dashboard/ prefix. My preference on the router links was given in #12 (comment):

• bakeries (note that the current API doesn't have enough info on bakeries, see Proposal: eliminate bakeries.yaml - split into database entry and bakery-specific config roadmap#47)

  • /bakeries/ routes to a paginated, browseable list of bakery cards
  • /bakeries/{name} details on that bakery, links to its recipes

• feedstocks (e.g. pangeo-forge/noaa-oisst-avhrr-feedstock)

  • /feedstocks/ routes to a paginated, browseable list of feedstock cards
  • /feestocks/gh/pangeo-forge/noaa-oisst-avhrr-feedstock is the landing page for that feedstock, within links to connected recipes and datasets

• recipes (technically "recipes runs", but I think recipes is a better name to use on the front end size).

  • /recipes/ routes to a paginated, browseable list of recipe cards
  • /recipes/{id} gives details on that recipe run.

  A recipe may or may not produce a dataset. If so, it will be available via recipe.dataset_public_url. I still think we should have a separate browse path for...

• datasets, even though there is a 1:1 relationship between datasets and recipes, I think many people will just want to browse the data

I'm happy to discuss whether this is a good url scheme or not. Feedback welcome from @cisaacstern, @rwegener2, etc.

For example, should we use recipe_runs instead of recipes?

[jhamman]

Thanks @rabernat - dropping the dashboard prefix is easy. Two quick questions though:

1. The main reason I put the /dashboard/ prefix on the site was to separate the namespace of the api-backed pages from other pangeo-forge pages (docs, etc.). With this change, how should the top-level nav bar look?

   Home -> /
   Feedstocks -> /feedstocks
   Bakeries -> /bakeries
   Recipe-runs -> /recipe-runs (or recipes, currently following the naming scheme in the api)
   Datasets -> / datasets
   Docs -> https://pangeo-forge.readthedocs.io (note that we could make this docs.pangeo-forge.org without much trouble)
   GitHub -> https://github.com/pangeo-forge
   

   My initial reaction is that this is going to end up being too many routes for the nav bar.

2. Your examples have a mix of {name} and {id} identifiers. I've implemented all routes using the {id} identifier because the API accepts that as a query argument. This makes the dynamic page routing much easier. However, we could reverse course (a bit of work but doable) to use the more informative {name} identifiers. Thoughts on which way to go here?

[cisaacstern]

As a middle ground which might achieve

1. A minimalistic top-level nav bar; while also
2. Surfacing the information most relevant to new/beginner users

What if we made the navigation

.
├── Home
├── Datasets
├── Dashboard
│   ├── Feedstocks
│   ├── Bakeries
│   └── Recipe Runs
├── Docs
└── GitHub

should we use recipe_runs instead of recipes?

Yes, regardless of the nav structure, I vote for using the name Recipe Runs for the page which reflects information contained in the API's /recipe-runs/ route. Dropping "runs" I think is asking users to hold too many overlapping concepts under the umbrella term "Recipe" (the object they submitted in their PR, a run of that object, etc.).

But for totally new entrants to the platform and/or data catalog users who never become recipe contributors, I'd also argue that throwing Recipe Runs up on the top level nav may be overly technical. That's why I like the navigation I've proposed above: simple for new users, and more detailed info just one level down in Dashboard.

[jhamman]

In our discussion today, we decided to go with the site layout proposed by @cisaacstern. I'm going to close this for now. Easy to revisit in the future if we need to.