Modular web kit strategy

[matthias]

@hugi

I read your post very differently. It was phrased as “been toying around”, and as a suggestion to Owen, not a hard requirement. Had I known that you were adamant about it, it would have been a very different story.

That’s how I roll. I make an earnest suggestion, and if it does not work I’ll step up the game. No need to tell people what to do as long as I can persuade them. In this case I basically forgot to follow up on the issue for too long

@hugi

Since the namespace already contains a myriad of seldomly-used tags and appears very ad-hoc, it seemed to me that this implementation would not mess with any carefully constructed order.

It is not yet in order. Some tags are properly chosen and documented (see), otherwise it’s just chaos imported from Drupal, with chaos added on top. When I find a bit of mindspace, budget and time for it, @anu and me will certainly clean it up.

(I deleted hundreds of tags already, but it doesn’t show …)

@hugi

For reference, I read this strong encouragement as being about using YAML rather than JSON in the config file displayed with the webkit.

Ok, hmm. Never thought of that way to misunderstand it, but indeed it’s possible. Communication is hard. Nevermind …

@hugi

but is it also true that other selection mechanisms are as easily exposed with an endpoint as tags?

Yes. If you can make a SQL / ActiveRecord database query to select topics you want from the database, then you can make an API endpoint to expose them.

tangential rant: API redundancy

This reminds me of the other discussion I got involved in regarding the webkit: that adding any redundant API endpoints, like for topic selection by tag, is not a good idea in my view. Because redundancy is never a good idea.

I don’t care strongly about this part, as it doesn’t mess up what Discourse users see. So do how you like … but maybe think about it again. Because I’m pretty sure that kind of software architecture will come to bite you later. It’s implausible to me why you would want to add something redundant to an API – a “nicer” interface for a special-purpose application or caching before there has been an established practical need for caching are not compelling reasons to me.

@hugi

This could be a way of doing it, yes. But it is a bit harder for the end-user applying tags to end up on the webkit. It means the instruction to the end-user becomes a little bit more complicated.

Again, I’d not see the webkit as a kind of fancy editor for text that should appear on websites. Sometimes it will have that role, but its USP is building websites from organic Discourse forum content. That’s its true power: enabling content-rich, dynamic websites with very little manual creation and maintenance effort. And for that, mechanisms like multi-tag topic selection will be needed at some time. But not necessarily now.

@hugi

For example, a specific curation of articles for a slider on the webkit for a specific purpose – like showing an interesting cross-section of different Edgeryders projects. In this case, we need to be able to somehow mark these topics and the most out-of-the-box way to do that is with a tag.

The most out-of-the-box way for this use case is a reference to a topic ID in the webkit site’s configuration file. Tags or other mechanism on the Discourse side are only needed when Discourse users need the ability to add or remove content. For content where the selection of topics never changes in the foreseeable furture, references in the webkit config file are the easiest way to go about it.

@hugi

And if we don’t use one topic per session, we also can’t use the events plugin, which means that we lose access to good features like enforcing the date formatting we need to display on the front end.

In the YAML/JSON-in-Discourse-posts method, you can enforce it using a JSON schema (also mentioned above somewhere). There is probably a YAML equivalent of that.

Another argument against the one-topic-per-session and one-topic-per-bio approach is the user experience of the editing process inside Discourse. Right now there are for example two tags webcontent-ngi-summit-2020-bio and webcontent-ngi-summit-2020-bio-small. Probably they have redundant content, such as the speaker’s picture. That’s an argument for reading the full set of data from one place and displaying pieces of that as required.

Just try editing biographies etc. for two hours here in Discourse, and think if you like how that works, or why not. When doing the NGI Forward website, the first to fetch content from Discourse, I noticed that the user experience on Discourse is important. Basically, how easy it is to find and navigate the web content, and how easy it is to do the most frequent modifications.

@hugi

Hmm, but you can suppress a category for showing up in “Latest”, right?

Indeed. Didn’t know that option, it might be a recent addition. Note, it’s not set for the category you mentioned.

@hugi

I think it might be the case that the curation for the summit will be quite different in nature than the curation we as Edgeryders care about, for example.

Even if; that set of curated articles will still be a good basis to build on after the summit. Tag naming is a signal, foremost, to the user of the Discourse platform. (Because that’s what the feature is designed for, and hacking it is fine as long as it interferes with that original use not in significant ways.) If you can name the same tag differently so that it becomes more useful to the forum user, there’s little reason against it.

There are always multiple ways to do it right. Hope you get the general idea of why I’m arguing against interventions on the Discourse side that are geared towards pushing content to one single, special-purpose website. As much as possible, it’s better to make the website pull content from Discourse that is either totally organic, or made for the website but marked in ways established in Discourse, or known to the software via its configuration file by topic and post ID.