[Branding-Discussion] Customization

[Sean Tilley]

Hey devs,

I wanted to open up a discussion about branding, and the possibility of making customizing a pod a bit easier. There were some ideas raised in the last discussion for the Branding Pack, and I think it merits bringing up again with some of the experienced Rails developers that work on our platform. :) This may fall a little beyond the scope of the current branding stuff, but I think it merits some discussion and thoughts.

Steven kicked around the idea a little while back about the possibility of using Engines for customizing the default experience of Diaspora pods, and I think this might make for a novel way to customize theme templates, as well as possibly offering additional functionalities as "extensions", rather than actually touching the core codebase. This could resolve some of the problems forkers have had in the past: rather than just forking the entire platform, they could wrap up the features they want into a Rails engine and offer it as an installable extension that could sit atop the main branch codebase.

Additionally, one gem that might be worth looking into would be the Deface gem, which is used by the Spree open commerce platform. It allows for overrides to existing templates, so a podmin could easily drop in their customized HAML templates (This discussion seems to indicate that HAML is in fact supported now), and customize their output of how their particular pod looks. I'm not sure of the current limitations to Deface, but I think it might be worth considering for sake of future flexibility.

I'd love to hear some thoughts on this, as it'd be great to make customization a very modular experience.

[Raven24]

On Monday, April 2, 2012 10:47:00 PM UTC+2, Sean Tilley wrote:

Hey devs,

I wanted to open up a discussion about branding, and the possibility of making customizing a pod a bit easier. There were some ideas raised in the last discussion for the Branding Pack, and I think it merits bringing up again with some of the experienced Rails developers that work on our platform. :) This may fall a little beyond the scope of the current branding stuff, but I think it merits some discussion and thoughts.

I think one of the points raised there, was a script that is capable of changing the "Diaspora Alpha" wording in the logo. To me this is a nice feature-idea.
But since I am enthusiastic about everything that is not an image on webpages, my first thought for that is to provide a config option or something in the admin area where the admin could specify the pod name and it is then rendered on the page with CSS @font-face instead of an image and the name can also be used in footers and in the notification emails.

Steven kicked around the idea a little while back about the possibility of using Engines for customizing the default experience of Diaspora pods, and I think this might make for a novel way to customize theme templates, as well as possibly offering additional functionalities as "extensions", rather than actually touching the core codebase. This could resolve some of the problems forkers have had in the past: rather than just forking the entire platform, they could wrap up the features they want into a Rails engine and offer it as an installable extension that could sit atop the main branch codebase.

My personal rails experience is not the most comprehensive, but this seems like a good way to do it. In the long run it will be mandatory (well, not mandatory, but I guess it's almost stupid, if it wouldn't) for D* to provide extensibility without modification of the core code. And for Beta and beyond these facilities should be as forward-compatible as possible.

Additionally, one gem that might be worth looking into would be the Deface gem, which is used by the Spree open commerce platform. It allows for overrides to existing templates, so a podmin could easily drop in their customized HAML templates (This discussion seems to indicate that HAML is in fact supported now), and customize their output of how their particular pod looks. I'm not sure of the current limitations to Deface, but I think it might be worth considering for sake of future flexibility.

What I think most "regular-joe" users (probably) wouldn't use would be the possibility to customize the look on a per-user basis. But for power-users an additional js snippet here or a few lines css there could make all the difference. So, per-pod modifications are definitely a good start, and that would cover a lot of user-stories, but for later we should also keep per-user modifications in mind as a bonus-feature.


may the star wars quotes be with you,
Florian

[Steven Hancock]

Nice find, just looking at the docs for the deface gem makes me want
to use it for something :grin:

I think between that and engines, once we're more modular most
customizations should be possible without touching the code (just add
a gem and maybe run a generator or a rake task). :)

I definitely have an idea for a really simple proof-of-concept, if I
can make it work I'll be putting it on github in a couple days.

On Apr 2, 1:47 pm, Sean Tilley <s...@joindiaspora.com> wrote:
> Hey devs,
>
> I wanted to open up a discussion about branding, and the possibility of
> making customizing a pod a bit easier. There were some ideas raised in the last

> discussion<https://groups.google.com/forum/?hl=en&fromgroups#!topic/diaspora-dev...>for the Branding Pack, and I think it merits bringing up again with some of

> the experienced Rails developers that work on our platform. :) This may
> fall a little beyond the scope of the current branding stuff, but I think
> it merits some discussion and thoughts.
>
> Steven kicked around the idea a little while back about the possibility of
> using Engines for customizing the default experience of Diaspora pods, and
> I think this might make for a novel way to customize theme templates, as
> well as possibly offering additional functionalities as "extensions",
> rather than actually touching the core codebase. This could resolve some of
> the problems forkers have had in the past: rather than just forking the
> entire platform, they could wrap up the features they want into a Rails
> engine and offer it as an installable extension that could sit atop the
> main branch codebase.
>

> Additionally, one gem that might be worth looking into would be the Deface<https://github.com/railsdog/deface>gem, which is used by the
> Spree <http://spreecommerce.com/> open commerce platform. It allows for

> overrides to existing templates, so a podmin could easily drop in their

> customized HAML templates (This discussion<https://github.com/railsdog/deface/issues/4>seems to indicate that HAML is in fact supported now), and customize their

[Steven Hancock]

Here's an example of what can already be done by combining engines and
the deface gem https://github.com/stevenh512/pod_legal

It uses deface to add "Terms of Service" and "Privacy Policy" links to
the footer of the layouts/application template, installs editable
templates into the app (default Rails generated "blank" templates) and
mounts the engine that provides the routes. This is just a really
simple proof-of-concept. Combining engines with the deface gem is a
simple but powerful technique to customize your pod or add new
features. :)

[Steven Hancock]

Apparently that doesn't work as well as I thought, in a dummy app it
works perfectly but I get an error when I try to use it with an actual
Diaspora pod. Still, it's an example of what should be possible and
once I fix the but it'll be usable. :)

On Apr 5, 11:13 pm, Steven Hancock <stevenh...@gmail.com> wrote:
> Here's an example of what can already be done by combining engines and

> the deface gemhttps://github.com/stevenh512/pod_legal

[Steven Hancock]

Wow, triple-posting lol.. but just to add to this, after quite a bit
of experimenting with Deface I've found that HAML support is far from
complete. There's a bug that will prevent us from being able to use it
for now.. If real-life allows (meaning, if I don't have to tear the
car apart again) I might put a little time into fixing that once I'm
done with the 2 features I claimed from the wishlist since it could be
extremely useful once it's working right. :)

[Sean Tilley]

On Friday, April 6, 2012 6:20:10 AM UTC-5, Steven Hancock wrote:

On Apr 6, 12:23 am, Steven Hancock <stevenh...@gmail.com> wrote:
> Apparently that doesn't work as well as I thought, in a dummy app it
> works perfectly but I get an error when I try to use it with an actual
> Diaspora pod. Still, it's an example of what should be possible and
> once I fix the but it'll be usable. :)
>  

Aw, bummer. Well, I certainly hope that it's nothing too bad...

> > Here's an example of what can already be done by combining engines and 

> > the deface gemhttps://github.com/stevenh512/pod_legal 

This is neat, thanks! I'll pull this onto my localbox and play around with it a little bit.

 

> > It uses deface to add "Terms of Service" and "Privacy Policy" links to
> > the footer of the layouts/application template, installs editable
> > templates into the app (default Rails generated "blank" templates) and
> > mounts the engine that provides the routes. This is just a really
> > simple proof-of-concept. Combining engines with the deface gem is a
> > simple but powerful technique to customize your pod or add new
> > features. :)

 I could definitely see this working out in the long term as possibly being a way to go about extending things in the future (in both terms of theming and extensions), and if anything could help keep things modular and prevent hardcore forking, this would be a good thing. It'd be cool to maybe take some of the "big feature" pull requests that don't get pulled in, and see if folks could recreate them with engines in this kind of "hot-pluggable" way.

[Sean Tilley]

Double posting (so don't feel bad about triple posting, Steven)

Another (far smaller) task that I think would be good for customization would be to figure out how to turn certain variables into customizable strings that a podmin could easily configure, such as things like a site title, default logo (okay, not a string, it's an image, but still), and a few other variables used in the site that would need to be customized.

So, first thing's first, let's hammer out a list of things that could be stringified:

-Pod name

-Path to a logo (could be determined automatically by a file uploader or something)

Can anyone think of anything else that would fit in here pretty well?

[Maxwell Salzberg]

On Fri, Apr 6, 2012 at 11:41 AM, Sean Tilley <se...@joindiaspora.com> wrote:

Double posting (so don't feel bad about triple posting, Steven)

Another (far smaller) task that I think would be good for customization would be to figure out how to turn certain variables into customizable strings that a podmin could easily configure, such as things like a site title, default logo (okay, not a string, it's an image, but still), and a few other variables used in the site that would need to be customized.

I like this approach.  Lets worry about how a pod runner gets it into their app in a way that means they dont have to explicitly fork and re-apply git customizations every time.  I'd rather have people tracking master fork a "theme gem" and figure out how to include different gems in their bundle at runtime(or something).

While I think Deface could be cool for some small level of string replacing, I have a really bad feeling about using it for more than the simplest of tasks, as defining any sort of themeing system based off of tightly coupled view partials sounds like a very bad idea for a full blown template system.  Also, it would not work for any client side rendered code, of which we are moving to much more heavily.

It does seem rather pragmatic for this smaller scoped problem.  We may be able to solve this at the smaller scale, and have it drive out the engine/dynamic gem loading infastructure, which would could then re-accesses how to actually apply changes. 

Also of note, since I am the only person on the core team that actually likes HAML, it would seem pragmatic to change the templates we wanted to customize back to ERB.  I will be sad, but it will be me alone crying in the corner about it.

-m

So, first thing's first, let's hammer out a list of things that could be stringified:

-Pod name

-Path to a logo (could be determined automatically by a file uploader or something)

Can anyone think of anything else that would fit in here pretty well?

--
You received this message because you are subscribed to the Google Groups "diaspora-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/diaspora-dev/-/9DDs-h55nJ4J.

To post to this group, send email to diaspo...@googlegroups.com.
To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diaspora-dev?hl=en.

[Sean Tilley]

Away, don't kill the HAML templates. That would make me a sad panda.

Might be necessary though. :/

[Steven Hancock]

The HAML bug in Deface has been fixed in the 'dsl' branch (thanks to
BDQ for figuring it out, I just gave him a couple failing tests lol).
I've also updated the engine to fix a small bug involving main_app
routes in a mounted engine (easier to catch these in the engine than
to change every view in the main app), so it's working now (following
the updated installation instructions) with no need to get rid of
HAML. :)

On Apr 6, 2:01 pm, Sean Tilley <s...@joindiaspora.com> wrote:
> Away, don't kill the HAML templates. That would make me a sad panda.
>
> Might be necessary though. :/

> On Apr 6, 2012 3:56 PM, "Maxwell Salzberg" <maxw...@joindiaspora.com> wrote: