Ideas on how embeddable collaboration list could look on a wiki page:
Given that the embeddable can be long I suggest

• adding a few filters, so users can filter by all other filters except those used by the organizer or at least filter by dates alone
• Make the embed scrollable

Different sizes of the embedded list

Full	Mid	small

Thoughts/Notes after seeing the presentation:

We should not/cannot have filters, it will cause too much complexity and risk
We should provide a link back to the collaboration list, if possible maintaining the filters set by the page creator

In terms of the "out-of-the box experience" we have two directions, both with issues

• We assume that the users are experienced with wiki text and provide them with a barebones feed that they can style themselves
  • this risks alienating less capable users as it would provide an unattractive feed initially

• We assume that the users are not wiki text power-users and provide a more full featured experience
  • This would provide a much more functional product out of the box but removes the flexibility and customisation that a more capable wiki text user would prefer.

Overall I like the designs, but guidance from those with more community experience would be useful. I am more used to working with an undefined user base and so tend to err on the side of caution.

• We assume that the users are not wiki text power-users and provide a more full featured experience
  • This would provide a much more functional product out of the box but removes the flexibility and customisation that a more capable wiki text user would prefer.

@MHorsey-WMF Does this option need to 'remove the flexibility and customisation that a more capable wiki text user would prefer'? Can't we provide something out of the box but users still have the ability to change it as they please?

I had some comments on this topic in T385729#10602473 that are still valid. I'll try to summarize those and more thoughts below.

• Embedding filters: I'd be extremely cautious. Special page transclusion is odd. For starters, keep in mind that we can't include OOUI components in the transcluded version of the page, due to T388427 and related core bug. So we'd need Codex at the very least. But even then, I don't know what might happen. It could work, or it could just break horribly, or it could break but in subtle ways. I don't think there's any other special page transcluding controls, so at the very least it isn't well tested.
• Forcing a layout (width, height, border, scrollability, etc): as I wrote in T385729#10602473, I believe that these aspects should be up to the including page. This makes the special page flexible and reusable in a variety of different including pages. If someone needs a border, or a maximum height, or scrollability, they can add it in a way that suits the including page.
• Offering presets: again in T385729#10602473 I wrote that we can offer multiple presets, like a more compact version of the page that is more suitable for a reduced-width including location (such as a column layout, or a sidebar). However, I also warned that these would add complexity, so we shouldn't just add a ton of presets just because someone somewhere might use them. On the same note, I asked whether this is something we're intending to do now, or if we should rather wait for user feedback on the MVP (which does not offer presets). At any rate, this would work as long as it's also possible to get the "raw" version and format it freely.
• User technical skills: One of the questions today was what is the average level of technical (=HTML/CSS) competence that we can expect from users. The answer is, most likely pretty low. I have personally spent countless hours purging wikipages of nonsense CSS crap. As I mentioned, there's a lot I could say on this subject; in fact, I think I might have a collection of HTML gore somewhere. The average user knows nothing about HTML or CSS, and that's fine because they don't have to. They might know a very limited subset of styles for some simple use cases (like changing the font size/weight/color), but that's it. Historically though, people have been able to put together creative interfaces with minimal knowledge. One way is through templates, but those do not generally allow much customization, so I'm not considering them here. Another way is asking technical users: there might be someone willing to help. And then we have copying existing examples: once you have a new shiny page that uses say a two-column layout, people will go "oh that's nice, I'm gonna do the same in the XY page", copy the HTML from the original page, paste it into their page and adapt it. At times this is particularly evident, because the original page might contain nonsense or syntax errors that also get copied over, and slowly propagate and infect more and more pages. Is this ideal? Of course not. Wikipages (including articles) can be full of accessibility and usability issues. Just open a random WikiProject page on mobile and you'll see what I'm talking about. Note, here I am inevitably thinking about itwp as my home wiki; but enwp and frwp, to name two, seem no different. So, what can we do about it? Maybe provide examples, would be my answer. Have a section in the documentation that explains that the page is transcludable, and give wikitext snippets with some examples. After all, how are people going to learn that the page is transcludable, if not via documentation? That gives them something they can copy and that will mostly just work.
• On "size": also mentioned in T385729#10602473, I would not call these "sizes". We should not make the embedded version have, say, a fixed width. People are going to use it the wrong way, precisely because they're not familiar with HTML, CSS, or accessibility. The width of something should be determined by the context. For example, in a two-column layout you want the thing to be thinner than if it were full page. But you don't just set a fixed size on the embedded list and call it a day, otherwise what will it look like on a smaller screen? The lack of technical competence implies that the user won't even ask that question. So if we just provide a "small" version, it'll get misused. And I don't think there's a way for us to make it responsive without having access to the transclusion context (i.e., the including page). That's why I said the presets should not focus on size, but rather on the layout, the compactness of information, etc. But then I'll ask again: do we need this now? It adds complexity, we have yet to see concrete usages, and we can provide examples in the documentation for the time being. And it can always be added later.

Given these considerations are we still able to add a link to the collaboration list special page or do we also leave that to the wiki text user @MHorsey-WMF @Daimona

Link on top	Link at the bottom

In T387794#10647024, @gonyeahialam wrote:

Given these considerations are we still able to add a link to the collaboration list special page or do we also leave that to the wiki text user @MHorsey-WMF @Daimona

Yep, we can do that, and probably should since we can't have pagination in the embedded version.

I guess we need to make a decision for what the MVP will be like, either:

1. Have some basic (may be just a scrollable list) default presets and give users the flexibility to remove or customise as they fit
2. Have no preset and as @Daimona suggested:

Maybe provide examples, would be my answer. Have a section in the documentation that explains that the page is transcludable, and give wikitext snippets with some examples. After all, how are people going to learn that the page is transcludable, if not via documentation? That gives them something they can copy and that will mostly just work.

I propose we do 1, though.

cc @ifried

Hi @Daimona and @MHorsey-WMF, we have a few questions:

• What would be an example of the wikitext/template that someone would use to add the Collaboration List to their wiki page?
• Is there a way to set the number of events shown via transclusion? How?
• How would someone add the ability to scroll via transclusion? In other words, what extra snippet/wikitext would they add?

In T387794#10653327, @ifried wrote:

• What would be an example of the wikitext/template that someone would use to add the Collaboration List to their wiki page?

{{Special:AllEvents}}, like for all transcludable special pages. See https://www.mediawiki.org/wiki/Transclusion#Special_pages and the links there for more information.

• Is there a way to set the number of events shown via transclusion? How?

We can make it a parameter for the transclusion. Special:Recentchanges works the same way, see example.

• How would someone add the ability to scroll via transclusion? In other words, what extra snippet/wikitext would they add?

This depends on the including page and its layout. In order to make it scrollable, they need to set a maximum height on the transcluded part, and then explicitly mark it as scrollable. For example:

<div style="max-height: some-sensible-value; overflow: auto">{{Special:AllEvents}}</div>

But again, it depends on the layout. Sometimes it might make more sense to use a fixed height instead, and the height value itself depends on the context. Or there might be entirely different ways to achieve this. There isn't one single way that works everywhere.

In T387794#10653350, @Daimona wrote:

In T387794#10653327, @ifried wrote:

• What would be an example of the wikitext/template that someone would use to add the Collaboration List to their wiki page?

{{Special:AllEvents}}, like for all transcludable special pages. See https://www.mediawiki.org/wiki/Transclusion#Special_pages and the links there for more information.

Yup, thanks. Makes sense.

• Is there a way to set the number of events shown via transclusion? How?

We can make it a parameter for the transclusion. Special:Recentchanges works the same way, see example.

Yes, I think it makes sense for this to be a parameter that people can include, if they want.

• How would someone add the ability to scroll via transclusion? In other words, what extra snippet/wikitext would they add?

This depends on the including page and its layout. In order to make it scrollable, they need to set a maximum height on the transcluded part, and then explicitly mark it as scrollable. For example:

<div style="max-height: some-sensible-value; overflow: auto">{{Special:AllEvents}}</div>

But again, it depends on the layout. Sometimes it might make more sense to use a fixed height instead, and the height value itself depends on the context. Or there might be entirely different ways to achieve this. There isn't one single way that works everywhere.

This is helpful. I just wanted a concrete example of what a user *could* be adding in, if they want. To me, this seems relatively basic, so I don't think it is asking too much of editors to add in something like this.

Overall, this makes me think that, for the MVP, allowing users to set formatting and styling changes via wikitext is doable and not extremely challenging, if we give the users some guidance. I would prefer that we focus on this approach (i.e., formatting via wikitext) for the MVP, so we can release an early first version that we can test with communities. We can provide training/outreach via the ambassadors and clear documentation with examples for how to add various styling choices, which aligns with how people already so many things on the wikis (such as creating tables and other formatting/styling options via wikitext).

cc @gonyeahialam & @JFernandez-WMF: feel free to add any thoughts/questions/ideas you have, along with anyone else!

Based on the above:

• The default will be the raw transcluded event lists.
• Users will set up the formatting themselves using wikitext.
• We will provide documentation on formatting using wikitext.
• There will be an 'Explore more events' link at the end of the event list linking to the full collaboration list, and when users visit the main collaboration list, the filters in the transcluded list will also be applied

cc @ifried @MHorsey-WMF @Daimona

In T387794#10658708, @gonyeahialam wrote:

Based on the above: [...]

That's my understanding, yes.

@gonyeahialam: Yes. Thank you for this summary!