Recently, I’ve been thinking about ways to make the topic list page more relevant to particular users on forums with a wide array of activity.
One topic on the subject is here:
Another approach would be to allow users to customize what tabs appear for topic lists, and what is shown within them (via a search query or a selected list of categories).
For instance, I don’t really need to see the Bugs or Features tabs here on Meta, so I might hide them. Or I might want to create a tab for Ideas which would include #features#ux and another one for Issues which would include #bug and #support. I might also want to add a Following tab that includes topics that are in:watching or in:tracking.
(I swear there is a topic exploring this idea, but couldn’t find it…)
I fully agree that alternative display modes is well worth pursuing. I don’t think it could be part of GSoC though,
because there’s no solid spec for it yet (and I wouldn’t be able to draft it myself), and
it’s a very complicated task, most likely only suitable for core developers (I’m having second thoughts about adding WYSIWYG to the list for that same reason).
I’ll volunteer to write up a spec for the user-customizable tabs. I don’t think it’s necessarily that complicated and may be doable as part of GSoC (but we can defer that discussion until there is a spec to review). I’ll keep the scope of what a first iteration might look like in mind as well.
AMP is not ready for prime time. The most productive thing to do would probably be to take my branch and take out the AMP stuff, leaving just lean plain HTML.
Also, probably rename the trigger from ?amp to ?nojs.
It’s just hellishly complex to do natural language processing. That alone is a giant red flag for me.
And let’s compare:
(typical discourse reply to a topic)
Hi this is DiscourseBot! Please upload an image and make it your logo!
with
(full screen)
Welcome to Discourse! Please click the button (the only button that’s on the screen right now), to upload a logo for your forum.
I think the former is completely awful compared to a simple full screen setup wizard, to the point that I oppose it violently.
Anyway this gets into first run setup which is massively strategic for us this year, and there’s no way in hell I would outsource that. It’s deserving of a much deeper conversation far outside the scope of Google SoC.
I’m a Googler who’s worked with AMP last week and I believe it is quite ready for prime time. More and more publishers have been providing article versions abiding by the spec, and it’s supported by Google, Twitter, LinkedIn etc. If there are specific issues I could help with, I’d be happy to do so or refer to my colleagues.
capabilities to connect between multiple Discourse communities and having some overview of recent post, the posts of the persons I follow, something like a RSS reader just for Discourse
(of course with opt-out/opt-in function for users and admins)
An even more elegant way how group members could work together:
