Open btopro opened 6 years ago
Jekyll includes the concept of a theme. There could be a base Apereo theme that both the apereo site and project sites build off. https://jekyllrb.com/docs/themes/
Github also recently rolled out the ability for any theme to be used with GitHub pages https://blog.github.com/2017-11-29-use-any-theme-with-github-pages/
@btopro would you be interested helping to set this up?
if you use web components #19 to build the majority of this stuff instead of Jekyll then we could devise more complex ways of handling it that would benefit things other then a static site generator ;)
If web components can help simplify the process they'd be a welcome addition. If they are adding complexity I'd be hesitant.
I started wit Jekyll because it strikes a good balance between flexibility and ease.
_layouts
allow developers to add any html wrapping they want.
Collections allow non-technical authors to write content in markdown.
Combined with the GitHub platform. Anyone can open a pull request, collaborators can approve and merge pull requests. Build and hosting is taken care of by GitHub pages.
Using HAX would be pretty cool from a usability standpoint. To keep the same open-ness, it would great if it supported GitHub flow, so anyone can propose changes.
maybe we should talk via IM or something to see if it makes sense. I'm opening to helping apereo via said site if I won't needlessly add complexity :p
as for HAX, this is a recent video of what those images come from, it if makes sense / would help in the process then I'd be happy to help shift it in whatever direction that would need -- https://www.youtube.com/watch?v=ktlODSnGAOw
I'm more providing the counter arguments / thoughts that lead us off of jekyll / markdown and onto web components (cause I made this same sorta big site, small site w/ jekyll, then over to web components ultimately sorta transition w/ some personal stuff / internal projects)
maybe we should talk via IM or something to see if it makes sense.
Sure let's chat, I'm @cmurphy
on Apereo slack.
And/or I could setup a video conference call.
as for HAX, this is a recent video of what those images come from, it if makes sense / would help in the process then I'd be happy to help shift it in whatever direction that would need
Very cool. ~Is there a reference for JSON Outline Schema?~ edit: nvm was included in #19 https://github.com/LRNWebComponents/json-outline-schema
I'm more providing the counter arguments / thoughts that lead us off of jekyll / markdown and onto web components (cause I made this same sorta big site, small site w/ jekyll, then over to web components ultimately sorta transition w/ some personal stuff / internal projects)
I'd be interest to hear more on what frustrations with Jekyll motivated the decision to switch. If there are issue(s) that the apereo site will run into, I'd rather know now while pivoting technology is relatively easy, rather than years from now. :slightly_smiling_face:
mostly re-purposability and the need for a build chain in order to publish. I like that w/ the HAX stuff we pump out I can basically copy and paste stuff (which is a + for web components / custom element investment way more then anything specific to HAX). I think it's a great setup (Jekyll that is) when working w/ github workflows... and no one else in the world will use it aside from that.
We also found that we said "oh, it's markdown people can edit that and we can democratize the content process" and yet found that sadly markdown was still more of a barrier then people would meet. I don't want to hijack your train if your happy w/ Jekyll (or scope since this issue was a bit pie in sky)
I think it's a great setup (Jekyll that is) when working w/ github workflows... and no one else in the world will use it aside from that.
:laughing: true In this case, I think that a GitHub, or a GitHub like version control strategy is what we're looking for. Anyone can open a pull request, and a group of trusted people have merge access. That being said, Jekyll isn't the only option, I'd also considered VuePress and Gastby before starting to prototype with Jekyll, and continue to be open to other options.
I don't want to hijack your train if your happy w/ Jekyll
I'm not particularly attached to the idea of Jekyll. I am very fond of not having to managed infrastructure, if it works with GitHub pages hosting, with the free for open source CI/CD platforms, I'm happy.
yet found that sadly markdown was still more of a barrier then people would meet
It can still be a barrier, I've found WYSIWYGs like the one build into GitHub or https://github.com/benweet/stackedit can lower the barrier to writing markdown even further. It also somewhat side steps the issue that HTML also has a learning curve. :slightly_smiling_face:
Having an official Apereo theme would be great, PRs are welcome. :+1: I'm a bit hesitant to move to a dynamic content system for managing content. I haven't come across a dynamic CMS that has the same level of transparency and freedom to collaborate as a static content system built on a Git repository.
@btopro I've been thinking more about bridging the gap between technical and non-technical users. What if HAX could be used to manage the site, with https://www.netlify.com as the backend for it? Netlify is an Open Source bridge that connects WYSIWYGs to source control management and provides services like identity management and form management.
That way the pages, content, and the source code could stay open, while giving users an editor based experience, and dog fooding HAX.
Thoughts?
seems reasonable, I dont know enough about netlify to be honest but something that gives people control of their stuff in formats that are easy to break back out of. thats what we're going for with HAXCMS + Surge as well as experiments surrounding HAXCMS + beaker browser (decentralized publishing on dat protocol, very cool stuff)
If there was a smaller micro-site template that was apreo branded / maintained that then individual projects could pick up and PR against to manage their own content you'd be able to standardize UI/UX while still decentralizing the management of the content generated by each project (even if it's a single page that they could manage to describe and link off to updates about their own project).
This could reduce strain on the apereo foundation to maintain the site while still maintaining brand consistency