Hmm, I think you might be getting caught on the how instead of the what. The template architecture is just a technical implementation detail to achieve exactly this reliably:
For this to be the case, we need to be able to quickly iterate based on feedback. We do that through improving in increments, and that’s best done through being modular. This strategy doesn’t contradict improving our participatory event flow, it’s rather going to get us there faster.
Nice summary @hugi, I agree that modularising the most common components is a no-brainer, given Vue’s component system is designed with modularity in mind. I think we are half way there already.
What needs to be concretely done:
webcontent-festival-event, event-date-01_12_2019 (this will be changed to read from the date extension @matthias has integrated into discourse), event-location-brussels (location), event-confirmed (to say it is happening vs proposed). In my view, relying too heavily on custom tags like these can lead to confusion and content breaking if something is missed. It’s not obvious to the person writing the post and it also interferes with the semantic markup that makes tags so useful (I’m not sure how the ethnographic tools work, but I imagine these tags have to be filtered out at some stage as they are not relevant to the discussions). Having extensions in Discourse to handle this, like the existing one for date/time, means we can have standard input fields for events, community calls, organiser bios… The options are clear and we don’t have to second guess how content may be parsed.I agree, I think what’s being proposed here is a part of that cycle… It allows us to create and deploy these sites faster and with less effort so we can put more of our time/energy into other stages of the process.
I would need this to be explicitly worded, and the process for how this would happen also clearly defined with dates, deliverables and milestones.
The work:
Having worked on the components, #2 is more than halfway done. The work on standardising the styles and documentation can be done in a week or 10 days.
#1 Writing the JSON is trivial, agreeing on it is more important as it determines how every site will be generated (measure twice and cut once). I have put @hugi’s pseudo code on GitHub and anyone can make amendments and suggestions to this.
Stages #3 and #4 will take two weeks, at the maximum. Once the base is on GitHub it can be improved on by anyone. The main goal here is to set the standard and deploy a working template.
Total time: 3-4 weeks.
Net gain
@gdpelican, when defining the schema for generating fonts, did you use some particular standard or did you come up with it on the fly?
I would add on top of this/first priority is an audit of the current workflow and experience of the different people who needs are to be met followed by a clear description of the experience that would be needed and specs for different steps of the flow. Only then look at the further development of the modules of this webkit so that they are coherent with the needs of the process and people involved in it.
There are three elements to this:
Those that we would need to be involved in this process are:
So there would need to be some accounting for this in the timeline and budget
I don’t agree with that assessment, and I think we’ll have to work that out before we move forward. I think it makes sense to first put in the work suggested by Owen in his last post. None of those improvements affect the UX. These improvements do however make it much faster for us to become fast and agile at improving UX in the future. Before we have a good architecture, we will not be able to implement the outcomes of such an audit in a structured way, but rather introduce more mess and feature creep.
I would say we do:
In that order. Of course, 1 and 2 could be done in parallell, but I would prefer Owen to focus on the architecture first since he knows the codebase best.
The problem of designing by consensus at this stage is we run the risk of delaying and or obfuscating the basic structure we need… While the people who organise the events and have first hand experience can give valuable input, this feedback will serve on top of a basic foundation that includes:
I don’t think those aspects will be negotiated in a design session, as they relate more to how the site is made than what it contains.
I would say we do:
- Modular architecture refactoring
- Audit
- Update of modules and building of new modules based on audit outcomes
Working this way gives us a foundation to then integrate those proposals and suggestions from the audit. It also lightens the work as it would break the development into two distinct stages - core and concept.
yes, but I would like to see a clear commitment to inclusion of UX design steps by ensuring they are explicitly included in the timeline and budget. With clear allocation of responsibilities for who will be driving and delivering this part of the work. Without this I see a risk of having nice pieces of code but missing the bigger picture because things fall through the cracks.
Agree, it needs to be factored into the budget and timeframe. I think to underline @hugi’s point, this order of development makes sense to me once the above is made clear:
Agreed. Once the work on architecture is done, it’s time to turn towards doing a survey before then moving on to redesign components or create new ones.
Ok but who will take responsibility for driving that/ ensuring it gets done? You?
If the survey and module improvement plan happens later in 2020, I might even be able to secure that funding for myself somehow to keep driving that. But it’s really no different from who takes responsibility for the other parts of the proposed strategy. Since this is an investment from the Core, it falls on the board collectively to follow up on that investment. All that we’re discussing is the sequence of events.
I think @nadia has in mind a design session in January, that would be an appropriate moment to do such an audit. In the meantime I’m happy to work with @hugi on any aspects that need developing before then.
Thanks for the description.
Do I understand correctly, that the sites will be mostly rendered in-browser and live on the “live” API of the discourse instance? This would have the drawback, that you cannot easily save a page locally (I still live without internet connection sometimes, and from time to time save webpages for later reading, the very old style), and one maybe has to go the extra mile to make search engines able to crawl and index the page. You see already, I have no idea about Vue 
I guess it is baked in, but that should be made sure.
On a quick note: If I would have implemented that, i would have tried to go with one of the many stable and well-working static site generators (e.g. GitHub - myles/awesome-static-generators: A curated list of static web site generators. , I guess Jekyll is still strong) that allow meta-data via front-matter; and then build some configurator on top (to play with the styling etc). Deployments of these pages is trivial, but I am not sure how easy it is to come up with maintainable complex site structures, and updating the page would not be instant (vs pulling all data live via discourse API).
@felix.wolfsteller They are rendered in browser at the moment, and it’s a good point about archiving and search crawl. Google crawls sites rendered client side, I don’t know about other search engines.
A framework I have used in the past, Nuxt, allows static generation of sites and we could go down that road - but it would also require as you mentioned a rebuild whenever content is updated. This can be automated with webhooks or a cron job - depending on how frequently it needs to be updated.
This is why we went down this road in the first place. When we had static sites in the past, they quickly became outdated as our projects move fast and often shape-shift. Static sites representing a living community and all it does is also very unsatisfying. Hence this move towards having dynamic and up-to-date curated windows into the goings-on of the communities on Edgeryders.
We also need to consider the backend for such generators, the current sites can be deployed on any server - while server side rendering or static site generators require a specific setup and configuration on the backend… I think what we’re aiming at is a template that can be generated and deployed on its own, without any further server configuration.
For our purposes, where we’ll be displaying a lot of current content, the existing solution works better. We can also add a pre-render plugin that allows non dynamic content to be statically generated for web crawlers.
I thought about static sites that are redone every x hours or minutes and of course pulling the content and structure from discourse. Or even better (but more prone to mistakes and complicacies): are every time a topic in the relevant category is created/edited (but I can imagine that there are nasty edgecases, like it would also really need a rebuild when peoples profiles are changed etcpp, might become a mess to do this properly).
Yes, sure. That would also work. This is in fact how the earlier attempt of the Culture Squad site is deployed. It’s a little bit trickier to get right.