tracydurnell[d]It didn't occur to me to ask until I already set it up, but is there a template for what should be in a popup event listing? I just adapted from past events
capjamesg[d][tantek] "is "shoot(ing) the breeze" also an unnecessarily violent metaphor?" > I had never thought about that... I don't think we have a popular equivalent in the UK.
[manton][tantek] Maybe I’m naive but I’m cautiously optimistic about Omicron… If it’s less deadly, might be okay that it spreads more quickly. I’m getting my booster shot today too.
[manton]However, I do think that in-person events need to consider COVID-friendly venues. The place I’m considering in Austin for late 2022 is very open and can be partially outside. I think that will be a requirement going forward.
[KevinMarks]less deadly is not clear yet - UK spread is fast but not worked through to hospital admissions yet, let alone deaths and SA has very different age profile from UK/US
petermolnarthe /why page is a splinter in my toughts to be honest. I know it makes sense as is, but simultaneously I find it incredibly unreadable from a newcomer or non-tech person perspective.
petermolnarand I think that's my main problem, that people arrive at our wiki with the idea of reading through /why and they get immediately overwhelmed, because instead of a nicely written article they get an encyclopedia
[tantek]1That's a natural state in the iterative evolution of wiki pages. The /why page used to have a flow to it, but over time, it grew to be more lists of things that themselves grew organically
[tantek]1I agree. Each section itself should be treated like a mini-article, with a easier to read summary at the top, before diving into a detailed list
[tantek]1This is also the challenge of figuring out both when and how to split longer pages into subpages, because rarely is it obvious how to do so, and different pages need different treatment (there's no universal "here's how you can split up every page!" that works while preserving easy access to content
[tantek]1Key is to avoid the "don't make me click 4-5 times just to read something of substance" which is usually what happens when content gets divited up
[tantek]1yes, some (most?) of the /why sections are now large enough to deserve their own detailed articles, while keeping a welcoming summary and the "best links" directly in place on the /why page
[tantek]1since so many developer problems start with things like "so I have this server problem" or "DNS problem" or "database problem" or "CMS problem"
edgeduchess[d]this might be more a general thought than about fixing the wiki, but if you're thinking about the newcomers flows I think there's value in thinking about what your goals are for them and actively building with those in mind
edgeduchess[d]if you think about what your newcomers comes in the space seeking, and what you want them to learn in the first 15 minutes, that will help building an effective flow for newcomers onboarding
[tantek]1edgeduchess[d], mostly we're doing all that based on actual newcomers experiences, rather than trying to answer those questions a priori. listening to people's empirical experiences rather thank "thinking about", trying to understand the diversity of actual newcomers rather than an "ideal"
LoqiJust generated this week's newsletter! You still have a few minutes to make changes, and I'll re-generate it 10 minutes before it gets sent out at 3pm Pacific time. https://indieweb.org/this-week/2021-12-17.html
[tantek]1nor do they want that replaced with something that makes them feel bad because they lack sufficient "will" or don't "get" the "simple" existing tools (which none of are actually simple)
[tantek]1edgeduchess[d], have you found successful techniques for getting more folks to understand/sympathize with the broader default desire for at least decent and preferably "nice" aesthetics?
edgeduchess[d]I think there's certain types of devs that just will never sympathize with that, and that's ok cause they can build tools for devs rather than for end users
LoqiJamstack is a web development architecture based on client-side JavaScript, reusable APIs, and prebuilt static pages served via a CDN https://indieweb.org/Jamstack
edgeduchess[d]you kinda want to make it so they go from bringing up their website to getting their first comment on whaetever the write to be a "delightful" experience
edgeduchess[d]like you offer a lot of tooling and choices, but you kinda need a minimum path to people being like "hey! there is a community of people here I can be part of! they'll listen to me!"
capjamesg[d]I agree re: NextJS being quite big among personal sites. I used it for a while but it was too bloated / abstract for me. But many people love it and it’s good for commercial sites.
LoqiStatic site generators or SSGs are programs that take a set of flat text files on disk and transforms them into a set of static HTML files ready to be served by a standard web server, or some variation of this example https://indieweb.org/SSG
capjamesg[d]As I built confidence I experimented with JS to add dynamic features like comments. Then I went deeper into each spec and realized I wanted to implement many of them 🙂
[tantek]1re: "meet the dev community where it is" <-- there is no one "the" dev community, that's why we have to offer multiple paths, and hopefully in a way that people can self-direct to the path that fits their dev approach
capjamesg[d]Yep! That’s why I documented some of the ways in which I added IndieWeb features to my Jekyll site. And continue to do so as a static site.
petermolnar> tools with hype and traction behind them should be prioritized and actively pursued - are you sure? Because hypes change every ~half year.
[tantek]1edgeduchess[d] really? I mean, I agree with specific tooling that seems to be picking up, however, JS framework-du-jour is an endemic problem and merits the skepticism that petermolnar is talking about
edgeduchess[d]now Remix is all the new rage, and I wouldn't suggest getting onboard with it soon, but if you had done the NextJS work it'd be easily portable
edgeduchess[d]> Websites that use React often only render on the client-side, which means they are not curlable. The only HTML in the page on the initial browser load of such sites is typically an empty body and some links to Javascript files. This means that microformats parsers are unable to see any of the content there. Websites can solve this by adding Server-Side Rendering.
petermolnaredgeduchess[d] is recommending that someone here should pick up the task of creating indieweb nmp packages that are in theory cross-framework proof, so devs can pick it up. I'm saying nothing is stopping anyone from doing that, but it's unrealistic to expect that people will pick this up just for fun.
[tantek]1edgeduchess[d], appreciate the raising the points about NextJS, looks like it has come up a few times in chat over the past couple of years, and is even mentioned in a few pages: https://indieweb.org/wiki/index.php?search=NextJS
edgeduchess[d]I actually have full intention of doing that when i start working on my own personal website, cause I strongly believe the lack of those is an extremely low hanging fruit to get more people into the ecosystem
[tantek]1however I'd like to replace the "GitHub Pages & GitLab Pages" subsection there with instead something more welcoming to SSG approaches in general, including listing NextJS by name
edgeduchess[d]I think if you do it this way, adding another section for SSG/JS frameworks (even if you didn't want to replace GitHub pages) would visually work
[tantek]1I'm asking because if we can at least link to existing tutorials like that to start with, it will help provide at least a path for folks while we write more docs
[tantek]1Since I'm not a NextJS dev, I don't know if that's a "good" article from a NextJS dev experience perspective, hence why I'm curious about your opinion of it