Toward a better theme system

[JonWhipple]

I have been exploring OJS and the changes in recent versions as I have been engaged to do some custom theming work for an OJS journal. I have been giving a lot of thought to how things might be improved for better OJS adoption and maintenance, while not breaking existing installations or customizations.

First some general observations followed by some specific proposals.

Generally
-It would be wise for the default stylesheets to NOT EVER include !important attributions on any of the elements in the CSS files.
- And if a stylesheet(s) from a theme is(are) detected or loaded, then the defaults should be disabled or removed from the header entirely.

This would allow the designer/developer a great deal more control over the creation of an appropriate theme.

Specifically
These goals are achieved if the common styles were made into a plugin theme that is enabled by default. That way when the admin selects a different theme, the default is replaced with the new selection and all stylesheets and any important attributions would be removed and the new ones from the newly selected theme would be enabled.

If the template (.tpl) files were part of the plugin themes, this would enable admins and designers to create layouts not bound the the default HTML layouts.

Making the common design a Default Theme, and moving the layouts (.tpl files) into the plugin theme architecture is better from OJS development point-of-view as well as OJS admin perspective:
1. It allows OJS to be distributed and deployed with the same common elements and themes as is currently the case. Documentation can stay pretty much the same and customizations won't necessarily break
2. It provides a complete starting point for a designer because it includes all the relevant files for reference, revision and reuse as required by any new theme
3. Local stylesheets can still be used based on the Default/Common Theme
4. Custom Themes that were created relying on the core common templates can simply be remade by duplicating the Default Theme and replacing the elements that the custom theme overrides
5. This places control of the layout in the hands of the admin user, who know better what the content demand in terms of layout and style
6. This allows OJS and its users to move away from problem HTML that the current defaults currently have* without user breaking customizations that rely on the old code
7. It allows designers and developers to implement more specialized layouts and customizations without being hamstrung by the base HTML/CSS/js and include but are not limited to:
- iOS formatting
- other mobile layouts
- touch UI implemented with tools like jQtouch
- inclusion of custom code for special requirements in the form of included php and javascript files
- using HTML boilerplate frameworks and CSS frameworks for standards conforming HTML and CSS and rapid design and development
- implement tools like modernizr.js etc.
8. It simplifies the Theme Development process, because instead of looking for overrides, workarounds, and hacks to get past the built-in layouts, designers and developers can arrange items on a page as they see fit with their own HTML and CSS

The layout (HTML in .tpl files), visual styling (any applicable CSS), and user-level behaviour (CSS + JS) are clearly separate from the data. My proposed model is a lot like the Wordpress model where HTML is sprinkled with PHP keys that call for different information from the system. The designer can create any HTML and populate it as required. This too offers an advantage to OJS and its adopters as many online publishers and authors are familiar with WordPress.

I also think that this model would be applicable to the other sister applications the PKP suite, though I am not familiar enough with them to be sure.

Looking forward to seeing where this might lead.

Jon Whipple, CGD

*I want to strongly encourage OJS to drop the HTML element named "body" (in HTML: div id="body" and in CSS: #body) because of the conflict with the HTML element: body. I have found in testing that my CSS must inherit and override #body, AND I must use "div#body (element)" to have consistent results displayed across browsers. You could safely leave this old code this way were you to adopt my theme recommendation.

[mcrider]

Hi Jon,

Thanks for your input. The !important directive is, to put it bluntly, bad. But this is a necessary evil due to what is generally just a not very well designed layout in OJS. The OJS layout is very 'brittle', and if certain things aren't absolutely set, the whole layout can collapse quite easily. Fortunately, we've redesigned the whole layout, and though it might not make it into OJS for some time, its what we're currently using in Open Monograph Press (and you can take a look at it here: http://github.com/pkp/omp). OMP will be much more easily themeable, and out of the box will support all of the jQuery UI themeroller themes.

As far as packaging themes, I don't know if it would be worth it to keep all the CSS in a plugin (assuming the CSS is well structured, it would be better for the plugin to just include CSS that overrides core CSS), but having the core layout templates live in a plugin is actually an idea I had pushed for long ago and was never followed up on. Especially interesting is that you bring up mobile layouts and touch-based layouts, which could be detected by the plugin and would then load different sets of templates and JS/CSS files. AFAIK, this is possible by using template overrides--but the discussion I found from about a year ago never went into details about how this would work and I'm not sure how it would be possible. I'll ask one of the other developers to see if he has any advice to this end.

Cheers,
Matt

[JonWhipple]

Hi Matt,

Thanks for the reply. It's good to know that other parts of the suite are improving in this regard.

Making the defaults just another plugin theme make everything cleaner. It means that there would be nothing to override and the default set could be adopted as a starting place for subsequent development. Leaving default layout and CSS in other parts of the system opens the door to problems, however unlikely.

My model also enforces a better separation of data, layout and behaviour and adds predictability in the presentation layer.

I am proceeding with some work for some journals (all from the same publisher) and will be working around the situation as it is now.

If I work out some useful universal override and reset CSS, I will be sure to share.

Jon

[fernao]

Hi there!

I agree with Jon in all of his points. I've just published a OJS with lots of .tpl modifications, on the following address: http://www.brasiliana.usp.br/almanack.

Some time ago I realized that OJS has includes the possibility to customize .css files, but not for template files. The problem is that now I'm planning and update (from OJS-2.3.2-1 to 2.3.3-3) and found lots of modifications on the template files, and it's being painful for me to do that!

I've already worked on websites that used smarty with tikiwiki (blergh!), and there was a good custom layout system. There was a folder with all default .tpl files, and another with the customized theme (like a plugin). If we wanted to change any template, we pulled the file from the default template folder to the custom template folder and edited it there.

So, the template engine first of all search on the custom template for the .tpl file. In case of founding, it gets it. Otherwise, it uses the default template.

I think it's just like Jon's proposal.

Cheers,

Fernão

ps: the same for !important (I've to edit the common.css to remove then)!