Develop a Frontend Theme System

ST Sean Tilley Public Seen by 47

Poll Created Wed 12 Sep 2012 12:48AM

Develop a Frontend Theme System Closed Wed 26 Sep 2012 10:33PM

by Sean Tilley Tue 25 Apr 2017 5:15AM

We'll look at this one again in the future.

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.


Results Option % of points Voters
Agree 42.9% 3 ST JR SH
Abstain 57.1% 4 TS BO F G
Disagree 0.0% 0  
Block 0.0% 0  

7 of 53 people have voted (13%)


Steven Hancock
Wed 12 Sep 2012 5:08AM

Once we're fully switched over to Bootstrap (no more Blueprint), I don't think it would be too hard to convert some of the Bootswatch themes to SASS (or even create our own).


Wed 12 Sep 2012 9:32AM

I think this is a good idea but definitely not a priority. A good protocol first !

And CSS modification is enough to do anything. So a theme could be only one css file, it will be great.


Jason Robinson
Wed 12 Sep 2012 6:49PM

Long term yes. Might be a good idea if the author of this proposal draws a proper blueprint or something technical to the wiki for example - otherwise this idea will get lost here since no one will have time to work on it for a long time ;)


Jonne Haß Wed 12 Sep 2012 12:56AM

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.


Jonne Haß Wed 12 Sep 2012 12:59AM

OT: Oh and now you know why I want competing/concurrent proposals :P


Sean Tilley Wed 12 Sep 2012 1:16AM

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.


Steven Hancock Wed 12 Sep 2012 5:10AM

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.


altruism Wed 12 Sep 2012 9:44AM

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.


tortoise Fri 14 Sep 2012 4:33AM

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?



goob Mon 24 Sep 2012 1:13PM

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.