Below is a general report on where I think we have problems, and what proposals I recommend to solve them. This is a starting point for a discussion, and the issues here are what I see as anti-patterns we need to avoid. I have found four recurring ones that especially need addressing in our strategy for making, deploying and maintaining sites.
1. Code Fragmentation
Some sites are using non-webkit architecture, others are using JSON configuration topics, others are using XML. Some experience slow page loading and performance issues, heavy resources (images, css, js) that are loaded either remotely (from the platform) or locally from the deployment (files in the GitHub repository).
Archive old sites that are no longer needed or upgrade them to use webkit templates and configurations.
Implement performance improvements that include:
Create one core webkit repository with the content parser, view constructor and basic CSS for development. Use code splitting for loading optional components, templates and themes. This means only components required are loaded on page load.
Load images and components asynchronously to increase performance of first page load.
Eliminate redundant or avoidable packages (see for example the package.json for Worldbuilding site).
Reduce custom layouts and stylesheets
Avoid heavy handed styling unless necessary: this creates unnecessary forks in components, which must be consistent both for performance and for visual identity.
Optimise local assets and move all assets that should be remote to the platform.
2. Design Fragmentation
Lack of consistency and visual uniformity between sites.
Use the read template as the base template for all sites. It works out of the box with zero configuration, it looks decent with no customisation. It can support custom components if they are needed.
Evaluate which components are most useful for sites moving forward (galleries, people, sliders, topics…)
Update the read template to support these components with a clean unified UI. Write documentation for these basic components and a simple tutorial on how to include them in a post.
An example of this can be seen on this work in progress page for The Reef.
The layout is simply the read template without the sidebar. It supports some styling options and custom fonts if required, but the overall design and components are minimal and clean.
There are 14 total lines of ‘code’ in this post. This is to say, we shouldn’t need massively customised pages to create something distinctive.
3. Content fragmentation
Sites belonging to the same topic/theme are fragmented.
Smart collections: that generate a simple and clear overview of all content types (sites, articles, newsletters, campaigns, media) related to that topic. Make this smart collection easily accessible from each sub-page.
4. Configuration and deployment
Creating a simple one page site for a newsletter or one pager pamphlet is still too complicated.
Use smart templates that adapt to the type of content, in the same way the read template does for articles. These smart templates require zero configuration: they are loaded automatically based on the url. Have smart templates for newsletters, videos, audio, campaigns that work out of the box.
Sites are split across pre-webkit, webkit v.1 [using json configuration] and webkit v.2 [using inline XML configurations]. See table below for details.
Certain sites have assets stored locally in the GitHub repository, others have assets stored on the platform in the configuration thread. See table below for details.
Certain sites are not being used and should either be archived or replaced. For example http://er-campaigns.surge.sh is useful in concept, but useless in practice. Content is not tied to the platform (but airtable). Other sites such as OCI Lab are pre-webkit and need to use a webkit template.
There are mobile issues on some sites. See table below for details.
There is an issue where absolute URLs to images on the platform are automatically converted to relative path URLs by Discourse. This behaviour breaks images on webkit sites. There is a solution to this, but it remains to be seen if this affects all posts or only some (to my knowledge it has only occurred on tell form pages).
|http://remote.edgeryders.eu||2.0 (XML)||Yes||Platform + Github||No||-||Code splitting (performance)|
|http://research.edgeryders.eu||2.0 (XML)||Yes||Platform||No||Yes||Code splitting (performance)|
|https://scifieconomicslab.net||2.0 (XML)||Yes||Platform||No||Yes||Code splitting (performance)|
|https://scifieconomics.world||2.0 (XML)||Yes||Platform||No||No||Social media sharing cache|
|http://resilience.edgeryders.eu||1.0 (JSON)||Yes||Github||No||Yes||Update to latest webkit.|
|http://anywhere.edgeryders.eu||2.0 (XML)||No||Platform + Github||No||Yes||Replace with smart template for campaigns|
|https://thereef.brussels||-||-||Unknown||-||-||Replace with webkit single page site|
|https://sensestack.edgeryders.eu||No||No||Github||Yes||-||Replace with webkit single page site|
|http://work.edgeryders.eu||No||No||Github||Yes||-||Replace with webkit single page site if necessary|
|http://freelancers.edgeryders.eu||No||Yes||Github||Yes||No||Replace with smart template for freelancers|
|http://festival.edgeryders.eu||No||Yes||Github||Yes||-||Replace with smart collection for freelancers|
|http://openvillage.edgeryders.eu||No||Yes||Github||-||-||Replace with webkit single page site|
|http://wellbeing.edgeryders.eu||No||No||Github||-||-||Replace with webkit single page site|
|http://er-campaigns.surge.sh||No||No||Github + Airtable||-||-||Replace with webkit smart template for campaigns|
|http://academy.edgeryders.eu||No||No||Github||-||-||Replace with webkit smart template for courses|
I’ve set aside the next week for support and questions regarding imminent work and working with teams on the Sci-Fi Economics, Research Network and Future of Work projects.
Taking this page for the reef as an example, I think there is an opportunity to standardise the visual side as well as improve performance and bring old sites up to date. That template already implements lazy loading for images, for example, and there is an opportunity to keep things inline with that template moving forward.
In my view the issues raised in this report are more urgent to address than building something new, and @nadia made the right call to assess this now. Whether they should be addressed before or after the tell forms configuration work I leave up to you.