Perhaps that's one difference in how we look at this. If the content
editors have any technical inclination at all, like you'll find at a small
startup (and let's be honest, CSS isn't rocket science, you can learn the
basics before lunch on Codecademy) then they can edit the CSS themselves.
With the 'draft' mode for pages this means they can do all the changes of
"Hmm, maybe that text there should be a little bigger" or "Can the section
headers be dark grey?" without requiring a developer or designer to sit
there and use two peoples time to tweak minor things. And if anything more
technical comes up ("Can the bullet points be smiley faces?") then instead
of requiring a new push to the server to tweak a template, it takes 30
seconds to say "Sure" and change the CSS for the page.
At the end of the day it really doesn't matter to me if it's in mainline
Mezzanine, it's easy enough to hack in with the EXTRA_MODEL_FIELDS setting.
I was just pointing out a feature that I've found to be a force-multiplier
for faster development and more efficient use of everyone's time (which is
what we all want at the end of the day, unless you're a consultant getting
paid by the hour) that I thought would be a useful feature out of the box
for those designers who aren't inclined to dig into the code.
- David
On Tuesday, October 13, 2015 at 9:30:51 PM UTC-7, Eduardo Rivas wrote:
>
> I tend to follow a different approach with my client projects. With
> frameworks like Bootstrap you get a UI kit you can customize and provide
> that to your users. For example, when the content editors want to modify
> the style of a button, they can add a modifier class to it. The same goes
> for pretty much any other element. This has the added benefit of being a
> composable approach, allowing to stack multiple modifier clases that are
> available through out the site, not only specific pages.
>
> It also feels weird to store style information in the database. At least
> in my experience, it is not the content author's responsibility to tweak
> styling. It is the designer and the developer who have to provide the tools
> necessary to give the content writers enough flexibility but staying within
> the design spec. Hence the approach I explained above (using modifier
> classes).
>
> Now, that's just an opinion, not really an objective argument. If a custom
> CSS field gains traction, I would ask it to be disabled/enabled via a
> setting, just like the blog post featured image. Definitely not a level of
> control I want to give to the users.
>
--
You received this message because you are subscribed to the Google Groups
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
