Better default OJS theme?

Some time ago I love to read this from @NateWr:

Recently checked the brand new OJS demo and I realized is a naked white bootstrap, that is great for themes as an staring point, but I’m unsure is the best first impression we like to induce…

Don’t you think would be better including by default a more elaborated theme (like the ones shown in the post)?

Thanks for the impressive work (and for the OJS 3 release!),
m.

Hi @marc,

What’s up on the OJS demo isn’t actually the default theme. I think Kevin, who set up the demo, liked that particular Bootstrap theme so went with it. But everyone’s tastes will differ.

I think the goal eventually is to turn the demo into a multi-journal installation, where each journal could show a different theme. But as you can imagine Kevin’s had a busy week with all the post-announcement stuff and the webinar. :slight_smile:

cc @stranack

1 Like

Bumping :slight_smile:

I have just started to muck around with OJS . A big kudos to the devs and the community for developing this CMS for Journals. From working with it for the best couple of weeks, in a hosted environment where i have limited access to files on servers and from within localhost where i have direct editing of all parts I have some observations. My comments may come across as naive and perhaps critical, but i am just trying to convey the frustrations I experienced.

In terms of the Default Theme. I think that this Theme esp. on hosted services could function for a majority of users if the Header, Footer and Sidebar were to be customizable from within the admin interface. HEADER: I should be able to not only change the colour of the header, but also be able to Style the Title, place Logo and a Background Image. Same for Footer. Images used in these areas should not be handled by a user having to modify the CSS, for example, to place a background image in the HEADER, nor placement of texts and logos. A simple checkboxes of Centre, left, Right should be able to accommodate these needs. Sidebars content should also be customizable by checking off series of what might appear therein. Such as a Fetured Article, a block of text, an image, etc.

If the Admin interface proves not able to handle this perhaps use of Blocks or Forms can be considered. A Form or Block can be assigned via a check box, and a selection that shows which Block/Form can be applied, to replace content in these areas: HEADER, FOOTER, or Sidebar.

I am not overly excited by “Themes”. Seems a very Wordpressy thingy /gimmick to me, and usually means having to delve into the server files. Much better to work within the user interface and make use of Blocks, Forms and Snippets, and none of these get overwritten by Core Updates.

It would also be nice to be able to call a CHILD CSS style from within a text editor window, for end user styling of the core display. such as fonts, hyperlinks etc.
To simply upload a whole CSS file and not know how things will turn out doesn’t seem like a good approach. Not to mention that having to make a simple change means re-submitting the file, rather than making a simple edit, saving, testing, and rolling back if need me.

hopefully this makes some sense.

If you want to perform major modifications, I recommend to read this guide: https://pkp.gitbooks.io/pkp-theming-guide/content/en/

Hi Vitaliy, your link is outdated.

Thanks, this is the new one: PKP Theming Guide