Organizational structure of the usage guide

[MrPowers]

This issue is to brainstorm the best tree structure for the usage guide. This issue is just for the usage guide that will be created from markdown files. The programmatically generated API docs can be discussed in a separate issue.

Search engines don't like URL changes, so it's best to lay out the documents properly from the outset.

Here's what I'm thinking for the initial docs.unitycatalog.io pages:

quickstart/
best-practices/
usage/
  catalogs
  functions
  schemas
  tables
  volumes
integrations/
  duckdb
  parquet
  csv

So I am proposing pages like docs.unitycatalog.io/usage/tables and docs.unitycatalog.io/integrations/parquet.

Perhaps Parquet shouldn't be categorized as an integration. Would there be a better structure?

Do we want a single docs.unitycatalog.io/usage/tables page or do we want separate pages for managed and external tables? Feel free to provide your thoughts!

[tdas]

I would love to see the integrations more front and center, for example, always visible as left-hand side menu. For example,

UC/ 
   Quickstart or Tutorial
   Usage/
     ....
Spark
DuckDB
Daft

This is so that even the landing page of the docs shows the wide support from the community, without anyone having to click into the integration section.

Open to other ideas regarding menu / page structure as well but let's try to get the above working.

[michelleon]

The proposed structure for url structure looks good to me

Re: Homepage content agree that we should elevate integrations, but it doesn't mean that we need to tie url structure to be docs.unitycatalog.io/duckdb vs docs.unitycatalog.io/integrations/duckdb

[MrPowers]

Thanks @michelleon and @tdas. I think we might be able to get the best of both worlds here 😎 Let me try to figure it out!