Here's a (non-functional) page for the FoC Wiki with placeholder content. I'm looking for help with the following: • High-level design feedback, preferably stuff like "here's a problem with the overall direction" rather than "maybe tweak this spacing". The latter stuff will be great for people to contribute in PRs once the repo goes public. For now, I want to address stuff that would actually stop you from reading this wiki. • Testing — Desktop, tablet, phone. Light mode, dark mode. Keyboard, screen reader, etc. Weird extensions in your browsers. Non-Apple platforms. If you spot issues, please share screenshots and tell me which device, browser, and configuration. • Organizational ideas — the design includes stuff like "categories" and "backlinks". It doesn't include search, yet, because search won't be helpful until there's a lot of content (and at that point, the design will need other changes). But what else is missing? • Opinions on whether CC0 is a good idea.

Looks stellar and very neat and readable on Chrome and my Android device. On My Android its a light theme and on Desktop its a dark theme. I am surprised you are going for two themes out the gate, seems like a nice-to-have, that causes extra effort and long term overhead, but both look great to me. The thing I find make-or-break to me for viewing is embedded media, but I can't see what that looks like yet.

Hard to say much about the “how it works” aspect of the design from this mockup, but it looks nice.

Looking good on windows. I also ran lighthouse, it only nags a little bit about some small accessibility issues regarding links

• Looks good on all my devices, including the most exotic one, an Android-based e-ink tablet. • No ideas on organization before there's something to be organized. • CC0 is fine with me, but so is anything in the CC family.

Thanks for the early feedback everyone. @Tom Larkworthy — CSS vars makes dark mode is easy to set up and maintain. And, we already have a dark mode on the main futureofcoding.org site thanks to @Ibro, so I just borrowed those colors and tweaked them a bit. Good point on embedded media. I'm sure code blocks with syntax highlighting would be a good wishlist item.

yeah I know the abstraction, but CSS vars falls apart when including 3rd party styling (e.g. for code blocks), for image background (not part of CSS) or someone doesn't know to use the project specific CSS vars everywhere (potential contributors) and more doubles the work of visual checking, as you have to look in two places AND execute the LM/DM switch. Its sorta seems trivial and a perfect fit for CSS vars but in practice not as minor as we might think, because of leaky abstractions like images (including SVG) and other imported dependancies that have their own opinions on what the their background color is.

It sounds like you've had much worse experiences with css vars than I have. Considering the small scope of this project, and the somewhat idiosyncratic goals I'm pursuing (eg: no build script dependencies on things that aren't relatively "universal", ie would be effectively identical in JS, python, ruby, etc), I think we're going to have different issues than the ones you foresee. But I appreciate the words of caution.

A question: is this a separate project from the "moving away from Slack" idea? Because if I squint, I can see an intriguing future where this wiki page would have comments on the bottom (or maybe even Google Docs-style inline comments?), then those comment threads (plus some sort of a way to aggregate them) could be the thing to replace Slack. For the design, I would still love to have search, as I think it makes using backlinks nicer - for example, whenever I forget the name of some note, I often look up a related note, then explore the backlinks to actually find what I'm looking for. By the way, I actually use a pretty similar layout on my personal website - to deal with button overload in the header, I use a masonry layout. I think something like that can allow a lot more links to fit - but of course it might require some design adjustments to work better with touch and such.

@Ezhik Yeah, the wiki and slack successor are separate projects, mostly for the sake of scoping. If the slack successor fails to materialize (high likelihood), I don't want that to tank the wiki, or leave the wiki in some sort of half-finished state. There are also really different goals and use cases for these projects. On the other hand, the fact that these projects are going to be open source, and built with a desire for hackability / kit-bashing, means they'll surely be interconnected in some way. A lot of folks have mentioned the desire to take a slack conversation and tie it to a wiki article in a way that goes slightly beyond just hyperlinking. Dunno what that'll look like, but I'm keen to see it. Yeah, we'll definitely get a search at some point. I just don't want to block on that for the initial release. Masonry, plus some tighter spacing (maybe get rid of the implied "button"-ness on hover) would definitely let us squeeze in 1 or 2 more links on narrow phones*. That's why I'm eager to figure out how many links we'll need. If it's 1 or 2 more, great — masonry it is! If it's 10 more, then we'll need something different. Anyway, thank you for the feedback and suggestions! (* Yes, I realize that phones don't have hover, and so it's probably silly to keep that behaviour on the narrow layout. One thing at a time :P)

Hey if you would like a hand setting up Github actions to auto preview on PR open I can help. I dunno where the repo is, if its private my GH identity is https://github.com/tomlarkworthy you might need me as a contributor anyway so I can trigger GH actions on PR.

@Tom Larkworthy Thank you! I'll shoot you a DM if I hit any snags. Yeah, the repo is private but I'll make it public as soon as I'm ready for people to contribute articles. Shouldn't be long.