Webkit Dev Report [22/2]

Workspaces Software (General)
1

Status

The prototype is now using the majority of components we had before and project pages now work with any category. Some examples:

SciFi Economics
OCI Lab
Reef
Witnesspedia

Misc. Observations

Colors, icons, text, news are taken from the respective category field on discourse.

Page templates load successfully, and faster than before.

About 50% of components are working in the new template, 75% of those are lazy loaded to improve speed.

Configuration of templates is much simpler, XML tags are only required when you need to display a specific component.

Page thumbnails (on the project page) can be set using the custom thumbnail field when you edit the topic title on Discourse.

Page summaries are parsed and displayed when you hover over a site page on the category page.

UI is standardised across all pages.

The look of the default page template is very minimal - this is intentional. I am avoiding styling decisions (and feedback) until the logic side is complete.

When that is done we can discuss what is missing design and progressively enhance it (and maybe even get UI/graphic designers or artists to contribute). The idea is that with no configuration, you have a decent template to start with.

I already have planned a configuration parameter for narrow and wide layouts.

Content organisation

An issue we’ll be facing in a few weeks when this is ready will be regarding keeping content organised coherently.

Explanation: Each project page will eventually display conversations, events, campaigns, media and whatever other data we collect in that category.

Pages naturally fall into that field, but we have created a ‘summary websites’ category for pages. This is not optimal in some cases :

  1. We end up with two URLs for a project. For example, for Scifi Economics:

    The first is our web content category, the second is the ‘canonical’ SF Economics category. This is user unfriendly and confusing.

  2. If we want to unify two categories, we’ll have to combine bits of data from both categories, which is suboptimal in terms of speed and UX; it means spaghetti code to deal with categories that do not have a ‘mirrored’ category here.

  3. Some webkit pages already exist in other categories and should not be moved, for example the witnesspedia pages need to stay in the witnesspedia category as they are relevant to the contributors there.

Keep in mind that:

  1. Sites, with this new codebase, are readable markdown topics on Discourse. In many cases, they serve just as much as readable content on the platform as they do for the webkit. We may have JSON topics, but they stay siloed away in a sandbox category.

  2. If we want to create a project separate from the other categories, there is nothing stoping us from using the ‘summaries’ category to do just that. Projects pages work with any category, including all subcategories in this one, so nothing will change on this front.

It’s not a huge problem at the moment as we are in the development stage, but something that needs clarifying before we deploy dozens of pages.

cc / @nadia @hugi

2

It’s a good baseline implementation of what you and I discussed in terms of smoothly picking up and presenting content.

First, disambiguation to be sure everyone is aligned in understanding:

  1. “Pages” - When you write this, are you referring to topics on the platform from which content is picked up, the final display of contents from a category or something else? Because it seems that the word “pages” is used at different hierarchy levels in the Information architecture. There is something called Project Pages, as well as Pages as a section on the “Project Pages” standard template. We need to call things so that they cannot be confused from the get go.

    • What is the intended use case for each one of these two in relation to the other?
    • Where are the contents of each one coming from?
    • How and where are they edited?
    • Can you give an example of the flow for editing them?

  2. Directory/Sitemap of what is where and how to edited it - this ought to be done at an early stage as without it we are completely lost in managing these pages (or even knowing which ones exist at all):

    • name
    • URL of “d” outwardly visible rendering
    • URL of where contents are edited
    • Sitemap (which URLS are pointed from/inside the site - internal and external)
    • Tags - which ones are used and for what

  3. “Team” - this is intended to be determined based on platform user’s permission level. However, this is for the entire platform. There will be different teams associated to different projects. So how do we deal with this. Also, we need one section that renders the contributors (i.e everyone who has contributed a post of comment on the platform)

  4. Tell forms: does any of this affect tell forms? If yes, how?

  5. Stability- We need to have a clear timeline for how long this setup will remain the same without the kind of changes as took place between webkit 1.0 and webkit 2.0. And for how long there will be reliable maintenance of the setup.

3

Thanks @nadia

Yes, it needs documenting, but for now:

  • A page is an individual site, such as this site.
  • The configuration of that page is the topic on discourse, from which that page gets its content - so for the aforementioned page, this topic.
  • A collection is a way of bringing pages, conversations, teams, events and more under one umbrella. As we agreed in our call, categories provide the ideal scaffolding for this.
  • So a collection is configured by a category on discourse. In this example, this category.

If I were to move the site mentioned above to a different collection, it would involve moving it to a different category on the platform. If I wanted to modify a collection name, icon, description, color, I would edit the category on the platform.

Collection URLs

The category slug slug is the last element of the path of a category. In the case of OCI lab, you see the slug in the last part of the category url: https://edgeryders.eu/c/ocilab => ‘ocilab’. So that is by default the url path of the collection. Once we set this up on its own domain, the project will be at domain.com/project/ocilab. And so on.

All of these things can be generated automatically by the site, and it is a much better solution than manually maintaining a list. So I will add this as a feature: when you go to the site and add the path /sitemap - you’ll get a page displaying a link to the configuration topic, a list of all linked topics from that site (JSON data and whatnot), as well as tags, partner accounts, etc.

As you mentioned before there are admin roles associated with each user. The problem we will have is what if person X is an admin on the platform, and part of a category (having contributed once to that category) - but not technically on that project’s team. For example: I post in the OCILab category, I’m not part of that project, but if the project page sees I’m an ‘admin’, it will think I am. So we have to figure this out. If you have any ideas let me know, but I’m pretty sure we can find a solution.

Not functionally - they can remain as they are. But eventually there will be a decision on how we integrate forms in a collection: we can group them all together in one category and they can be displayed as one ‘forms’ collection. Or we can have each collection detect the forms in the collection’s respective category, and display them, like pages, events and discussion, as another section in the collection.

This will be the final big part. I’ve done a lot of work on this and it’s been a tough project to implement right… I think this is the closest we can get to something that, while complex, can be understood and used in a simple manner.

When it’s ready my plan is to create a dedicated webkit collection with its own pages for documentation.

Once that is done and the core features are finished, the only changes will be progressive enhancements: adding support for events, media, etc. But nothing new or changing any syntax.

4

Hi!

Still confused about the differences and relationships between:

  1. Edgeryders | The Reef
  2. Edgeryders | The Reef
  3. Edgeryders | The Reef

In terms of their purpose, how/ from where they are generated and or their sections of content from the platform are kept up to date.

cc @owen

5

These are two collections generated from two categories. I put them as examples because I want to avoid the situation where we have duplicate collections like this. 1 is generated from the scifi-economics category and 2 is from the sci-fi-economics category in the “Summary” Websites category. My proposed solution, in this scenario only (where a category already exists) is we do not create mirrored subcategories in the “Summary” Websites category, as it complicates the code and user experience.

That is a webkit page, like we have had for all webkit sites, existing in the sci-fi-economics category. The configuration for that page is here. It is using a newer, faster set of components as part of the work I am doing.

1 Like
6

ok so we need to differential naming of categories for “advanced” summary minisites from names of existing “source” categories. Correct? Or is something else required?

7

@owen one missing “automatically generated” webkit component is display of avatars for each user that has posted either a topic or comment in the “source” category (and the subcategory). Matt developed a script to extract the data: How to get list of people who have contributed to a category?

8

No, the exact opposite… we want to avoid confusion of creating duplicate categories if they already exist

9

User contributions to a category are already available in the api - including their avatars - I believe… that’s how we can calculate members in a category… the difficulty is then deciding who is a team member and who is only a contributor.

10

mmm ok - badges?

11

Ok- another question: do we need to code something every time we want to generate a rendering of the minisites? Right now we are going through netlify and I am unsure as to how we can test the setup with other categories

12

I thought of it, but it doesn’t help. Let’s say I have an admin badge - it doesn’t tell me if I’m a project manager in ‘Project A’ or ‘Project B’ - it just says I’m a manager.

13

No not at all - it works like the read interface where you put in the url of a category to display it, as explained in a post above. There will be no coding for categories.

14

OK I think I understand:

Edgeryders | The Reef - gives you the automagically generated rendering of the category content presentation page, and cannot be edited. But you need to tag topics posted in the category correctly if you want them to be included on the autogenerated page. If this is the case - what is the tagging ontology for the different sections?

  • Pages
  • News
  • Campaigns
  • Events
  • Media
  • Team
  • Edgeryders

Edgeryders | The Reef - is supposed to be for a minisite the contents of which you can edit directly. How is the topic from which you edit the minisite generated?