Group projects as appropriate

typelevel / typelevel.github.com

Web site of typelevel.scala

https://typelevel.org

40 stars 99 forks source link

Group projects as appropriate #375

Open jducoeur opened 2 years ago

jducoeur commented 2 years ago

The old website grouped projects together -- for example, projects that are specifically adapters for Shapeless were grouped together.

We probably want something of the sort on the new site, but we should pause and take a little time to think about design before jumping into that. Do we want "static" groupings like the old site had? Do we want something more modern and dynamic (eg, click on Shapeless and it expands to show the sub-projects)? How much effort are we willing to go to here?

rossabaker commented 2 years ago

I don't have the skills for the UI, but I can comment on the information architecture:

Are projects a tree, and if they are, are they a tree of depth 2? This is how it works on the current site, but only two projects have children, and some of those children are dubious. But it might let projects like http4s and scodec bring their children.
Are projects a graph, with links to related projects? Messy, but someone more talented could do visualizations.
Do we tag projects? If we do that, something as simple as the way we tag blog posts works, and is within my skillset.

jducoeur commented 2 years ago

Yep, agreed on all points. I do think we need to step back and do some analysis, which is one reason why I specifically want to put this one off for a little while, so we can think about it properly.

jducoeur commented 2 years ago

(We also may want to loop those affiliate projects explicitly into this conversation, and get their viewpoint on how they think about it, and what sorts of display make sense from their POV.)

rossabaker commented 2 years ago

We can reach the maintainers of Typelevel projects on the maintainers discussion. We don't have such a convenient list of affiliate developers, though there's much overlap.

jducoeur commented 2 years ago

Yeah, I'm not surprised. It'll take some time and effort, but we should probably deal with it gradually.

ChristopherDavenport commented 2 years ago

I love the idea of tagging so that folks can limit based on dep, the tree then is the core TL libs and the the surrounding ecosystem branching off, and we can add tags as appropriate as we have more libraries join.

Like - cats, cats-effect, fs2, shapeless, scalacheck, discipline, http4s as initial tags that folks could filter by.

Just musings more than real thoughts.

jducoeur commented 2 years ago

I don't know the site well enough yet to grok how it would work, but I agree that a tagging-oriented approach makes sense. (Especially given that some libraries are essentially glue, and conceptually belong under multiple headings.)

rossabaker commented 2 years ago

I was thinking more like "HTTP", "Database", "Testing", etc., for people who don't know what the hell is an fs2. Chris' set is nice for "I know the basics, what works well with...", and my set is nice for "I'm new here, how do I...". They're both valid use cases, but I'm not sure how to render both without being confusing.

jducoeur commented 2 years ago

They're not mutually exclusive -- that's why I like the tag approach, because it can handle multi-dimensional ontologies.

How we display that -- I don't know, and we're going to have to think hard about the information architecture here. But using tagging as the basis probably makes sense regardless.