Hi everyone,
Over the last couple of months I’ve been working with PKP on a part-time basis to improve the UI for OJS 3.0 beta. I’ve been watching this thread for a while but I didn’t want to jump in until I had a better understanding of the OJS 3.0 codebase and a good sense of what we can actually accomplish in time for the beta release in August.
Thanks to some work from @beghelli, the OJS 3.0 beta will have a (pretty) clean separation between the reader frontend and the administrative/editorial backend. That means we’ll get independent HTML markup and different CSS stylesheets (compiled from unique LESS files).
The upshot is that we will be able to dramatically rethink the UI for the backend without worrying about how this will effect the reader frontend. On the flip side, themers like yourselves will be able to build completely customized reader frontends, using whatever toolset/framework you like, without having to worry about whether or not you’ve broken the administrative and editorial functions of OJS.
In order to make our August deadline, I’ve been focusing on cleaning up typography, contrast, visual hierarchy and vertical rhythm. I’ve also targetted some big low-hanging fruit, like restructuring the backend navigation and content panels to de-clutter the management UI. But the bulk of the application’s complex components (grids, tabs and forms) are only getting a re-skin to enforce good design standards across the backend.
I’ve focused entirely on the backend so far. In the process, I’ve made some snap decisions regarding code structure, naming standards, etc. Often I’ve just adopted a pattern which was already there in the code and tried to stick to it as best as possible. There’s no reason these patterns need to be set in stone, but I’d much rather push forward for OJS 3.0 beta and, once there, talk about which patterns work best for us, which are worth changing and what needs documentation.
My sense, though, is that the standardization discussion we’re having here is primarily geared towards the reader frontend. There we have blue skies. We can pursue just about whatever we want, and we can produce multiple themes tackling different goals.
In the short term, my goal for the August deadline is to have a clean, attractive default theme in place. I’ll probably be doing the bare minimum in order to make that happen on time.
In the long term, though, I’d love to help you work towards a community-built “starter” theme, built on a common framework and designed to be easily adapted and extended by third-party themers. I’d recommend you use Bootstrap. It gives you a complete set of standards for HTML, CSS and JavaScript components, so you don’t need to document things yourselves. Other frameworks are good, too. But Bootstrap’s wide adoption is it’s primary benefit: people know it and can find answers to their problems quickly by searching Google.
I hope that the final 3.0 release of OJS will ship with an ambitious default theme that makes strong, informed choices about the reader frontend. But the truth is that a default theme needs to be a platform serving diverse needs more than a highly tailored product. That may limit the scope of what we can do out-of-the-box.
For this reason, I think it’s good to begin thinking about the reader frontend in pluralistic terms. A community-built starter theme is a great foundation on which other people can iterate.
If I can be of any help, please let me know. I think you’ve nailed down a pretty good consensus on what to use. I’d suggest your next step is to start building a custom theme based on these principles. But to be honest, you’re probably better off waiting until the 3.0 beta, because a lot of things will be changing in the next two months.
Minification shouldn’t be a problem with [Mr Clay’s Minify code on Github][1].
