Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Develop a Frontend Theme System
One of the major issues with Diaspora at the moment is the fact that all of the code is tied together on one frontend, using bootstrap. The code for rendering how the site looks is currently also partially paired with the logic of the site. There’s only one theme, and therefore only one set of templates dictating how the site is laid out. In conjunction with the proposal to separate federation from our foundation base in regards to encouraging modularity, I’d like to push that thought a bit further.
PROPOSED STRUCTURE (subject to change):
A theme’s directory could use SASS/SCSS for actual CSS code, a file containing metadata about the theme, a screenshot of what it looks like, and a separate directory for templates, allowing for themes to look wildly different from one another for little breakage.
MyTheme.tar.gz would contain the following:
-/sass (or just css)
To get to a point that we can do themeing like that, we need to first consider a way to boil down Diaspora’s frontend to bare-bones components. These components could be summed up as the following:
1.) Federation, dealing with how pods talk to one another.
2.) System logic, basically the controllers that dictate how the different parts of a pod work
3.) Frontend, which deals with how the actual interface itself is rendered.
4.) Backend, administration tools, pod customization.
With Rails, it is possible to switch between different themes and templates using the Deface Rails gem. It’s a tried-and-true piece of Spree, a Rails commerce platform. Alternatively, we could try Disguise, which has also been recommended before.
We can see what other options out there, and if worse comes to worst, we could just end up trying to roll our own.
It would be also useful to consider designing a new “official theme” for Diaspora, to exist as a powerful example of how a theme can be customized.
Outcome: We’ll look at this one again in the future.
- Yes: 3
- Abstain: 4
- No: 0
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
First of all: low priority.
I just want to mention the downside of this, which Friendica is a perfect example for: A theme gets outdated quickly, there will be missing functionality, even broken one. Might get as worse as switching to theme and then it’s impossible to switch back since the theme selector throws an error or got updated in the logic to work different but not in theme you just switched to.
Our frontend needs heavy refactoring and clean up anyway, so we my compromise is that we focus on that and on building a single semantically rich document structure instead and then provide CSS theming, but there should be just one html structure.
OT: Oh and now you know why I want competing/concurrent proposals
If anything, you’ve just provided an excellent use case for me to use as an example.
First and foremost, I agree about this being low-priority, however I think you’ll agree that something like this could be relatively high-impact for the project, if we figure out how to do this right. I’m not saying make this a priority right this minute, but it’s still something that ought to be talked about, as far as designing for the future is concerned. A lot of people want to set up and customize their own pods at some point, and I think rather than having podmins hack away on their own frontends, there could be some kind of inroad to making Diaspora easier to customize.
I think maintaining theme compatibility would be easier in the future, after things like a stable tag / stable release versioning is figured out. For now though, you’re right. A basic way to load CSS customizations would be a great start.
The problem with Friendica is an interesting one; I wonder if their work with RED will mitigate that? I think being able to swap out html structures as templates could be great in the future, provided we have a non-crazy semantic way of handling that.
As long as we’re just talking about CSS theming here, using SASS or LESS (I prefer SASS, no TheRubyRacer dependency) would make it pretty easy to keep everything up to date.
There we have it once agan, PRIORITY. We need a way to manage opinion on this, not only proposals and voting. Some things are extremely important (not saying themes are) but should not be high priority fore whatever good reason.
A theming system is very compelling, but I see you are also including architecture here. It seems that in order to do a front-end theme system the backend must be done first, no?
@Sean: since I do not know the history, would you mind explaining why all the code was tied together? I don’t mean to be difficult, I’m just curious to know.
I’m not sure I understand what the relationship of the front end is to federation. Isn’t federation solely a server thing?
I think this is a good idea for the future, once the underlying code for Diaspora is more stable. I think I’ll abstain for now, and vote yes in the future. Although I don’t know much about coding, my suspicions are with Jonne - that if themes were implemented too soon, they would tend to fall down once the underlying code moved on.