Taxonomy and layout discussion

[mattstratton]

Let's use this to think about overall layout etc

First topic!

Maybe we should rethink the taxonomy. We tend to think about the grouping a yearly basis, but what if...the taxonomy was city oriented?

So you end up with a structure like this:

content/
└── events
    └── ponyville
        └── 2023
            ├── index.md
            ├── logo.png
            ├── speakers.md
            └── speaker-images
                └── twilight-sparkle.jpg
        └── 2024
            ├── index.md
            └── speakers.md
    └── hoofington
        └── 2024
            ├── index.md
            ├── logo.png
            ├── speakers.md
            └── speaker-images
                └── twilight-sparkle.jpg
        └── 2025
            ├── index.md
            └── speakers.md

[nimbinatus]

Hm! That might be useful, especially if then we kept the "archived" pages under that. I was thinking that would be a very easy way to then tell programmatically that a page is "old" and gets a banner (maybe the creation script adds a tag to the metadata in the data.yml file that reveals the banner?). And if we did it right, we could even have the sponsor logos be kept static for each event.

Maybe

assets/
└── events
    └── ponyville
        └── 2023
            ├── logo.png
            └── speakers
                └── twilight-sparkle.jpg
            └── sponsors
                └── company.jpg
    └── hoofington
        └── 2024
            ├── logo.png
            └── speakers
                └── twilight-sparkle.jpg
            └── sponsors
                └── company.jpg
content/
└── events
    └── ponyville
        └── 2023
            ├── index.md
            ├── speakers.md
        └── 2024
            ├── index.md
            └── speakers.md
    └── hoofington
        └── 2024
            ├── index.md
            ├── speakers.md
        └── 2025
            ├── index.md
            └── speakers.md

[nimbinatus]

Once there's no more "current" tag, it adds a banner and preserves it. And if we did a basic city landing page, we wouldn't need to have each year on each event's page, which removes the need to build it each year. Just always link back to the city page...

[mattstratton]

That’s why I said use “draft” because it’s built into Hugo so we don’t have to build our own logic and it just is a flag to the command to CHOOSE to include them when building!

[mattstratton]

But that’s backwards logic from your proposal (mine is flag everything BUT current, etc) but it’s the most error proof for folks running the build to not accidentally include old stuff etc.

Also much less logic built into our code that now has to think about “do I build or not?” on every page in our execution vs the far more optimized bc in the Hugo binary version.

[mattstratton]

One thing you will discover with this site, is that we hit death by 1000 cuts a lot. Because it’s SO MANY PAGES. So adding even small logic increases the build exponentially :/

[mattstratton]

Once there's no more "current" tag, it adds a banner and preserves it. And if we did a basic city landing page, we wouldn't need to have each year on each event's page, which removes the need to build it each year. Just always link back to the city page...

Yeah the nice thing about a “container” page for the city overall is that meta nav gets solved.

Now, let me tell you the wrinkle in all these …. event_group - there are cities who are different geo cities but get grouped together for nav because their the same “event” just in different city locales each year (Sydney/Melboune does this, for example)