Hi, At present we distribute two OPAC themes with Koha, "prog" and CCSR. I like both of them, though it is nice having a mobile theme in the shape of CCSR. That said: in my view having two stock themes is going to present us with a long-term maintenance problem, even nightmare. Any template change to one *must* be applied to the other. Inevitably, one theme (most likely prog) will fall off the radar of most Koha developers. Also inevitably, functionality differences will creep in between the two themes. Furthermore the prog theme will continue to have users who will justifiably complain if a stock theme becomes a second-class citizen. How do I know this will happen? The Evergreen community went through a similar experience with its old-style OPAC, which at one point had a stock theme and a visually more modern theme called Craftsman. Since the underlying templates were duplicated, a point came where Craftsman accrued functionality gaps, but still had its adherents who preferred how it looked. I would like to avoid that risk. Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. One way to do that would be to offer stylesheets that can be managed via the opaccolorstylesheet sysprefs. We could also decide to add support for skins (which would be a named set of stylesheets) or perhaps redefine OPAC themes to be just named sets of stylesheets, not separate sets of templates. Thoughts? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I think the key thing to do is to provide a consistent and well documented set of template variables that do not change within any given version. This is a pretty common practice for many CMS and other templatable systems. That way, we always know what parts we have to work with. This would greatly increase the flexibility of Koha, as multiple templates (including local ones) could be developed and maintained by consulting only a single, slowly changing resource (the template API documentation). We should also keep an eye here towards backwards-compatibility, so template maintainers have more time to adapt their work. Out of the box, I think Koha should support a single template. Any other templates that other entities wish to maintain are just fine, but I think the release team shouldn't have to split their attention between multiple templates. My $0.02, adjusted for their recent market value. -Ian On Mon, Apr 8, 2013 at 11:45 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
At present we distribute two OPAC themes with Koha, "prog" and CCSR. I like both of them, though it is nice having a mobile theme in the shape of CCSR.
That said: in my view having two stock themes is going to present us with a long-term maintenance problem, even nightmare. Any template change to one *must* be applied to the other. Inevitably, one theme (most likely prog) will fall off the radar of most Koha developers. Also inevitably, functionality differences will creep in between the two themes. Furthermore the prog theme will continue to have users who will justifiably complain if a stock theme becomes a second-class citizen.
How do I know this will happen? The Evergreen community went through a similar experience with its old-style OPAC, which at one point had a stock theme and a visually more modern theme called Craftsman. Since the underlying templates were duplicated, a point came where Craftsman accrued functionality gaps, but still had its adherents who preferred how it looked.
I would like to avoid that risk.
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. One way to do that would be to offer stylesheets that can be managed via the opaccolorstylesheet sysprefs. We could also decide to add support for skins (which would be a named set of stylesheets) or perhaps redefine OPAC themes to be just named sets of stylesheets, not separate sets of templates.
Thoughts?
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Galen Charlton <gmc@esilibrary.com>
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. [...] Thoughts?
I think this is right. Having a good base theme, especially if there are basically examples of the right way to adapt it with CSS, would be a good way for Koha to learn from Evergreen's experience. Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript. In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences. Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version. Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pland moremember.pl display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Mon, Apr 8, 2013 at 12:17 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Galen Charlton <gmc@esilibrary.com>
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. [...] Thoughts?
I think this is right. Having a good base theme, especially if there are basically examples of the right way to adapt it with CSS, would be a good way for Koha to learn from Evergreen's experience.
Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
+1 for going into this direction Probably, there is too much logic in the templates too? And related to translation as well? Take e.g. some statuses; if the template decides in nested if-then-else's how to display a status (in various languages), we'd better move the logic into a module and send the translated status to the template or have something unified and more intelligent deal with translating that message. Marcel ________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Kyle Hall [kyle.m.hall@gmail.com] Verzonden: woensdag 10 april 2013 13:23 To: MJ Ray Cc: Koha Devel Onderwerp: Re: [Koha-devel] Koha.next: Consolidate OPAC themes? This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript. In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences. Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version. Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pl<http://circulation.pl> and moremember.pl<http://moremember.pl> display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Mon, Apr 8, 2013 at 12:17 PM, MJ Ray <mjr@phonecoop.coop<mailto:mjr@phonecoop.coop>> wrote: Galen Charlton <gmc@esilibrary.com<mailto:gmc@esilibrary.com>>
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. [...] Thoughts?
I think this is right. Having a good base theme, especially if there are basically examples of the right way to adapt it with CSS, would be a good way for Koha to learn from Evergreen's experience. Thanks, -- MJ Ray (slef), member of www.software.coop<http://www.software.coop>, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
There isn't necessarily to much logic in the templates, as long as it is 'display' logic. To me, it makes sense to calculate totals and such in the templates and not in perl, because that is purely for display only ( though it'd be better to do the totals at the db level anyway ). Not the best example, but's all I can think of atm ; ) I think the key to what you are writing about is to push more template logic into TT Plugins, so we aren't repeating TT code over and over. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Apr 10, 2013 at 7:37 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
+1 for going into this direction
Probably, there is too much logic in the templates too? And related to translation as well? Take e.g. some statuses; if the template decides in nested if-then-else's how to display a status (in various languages), we'd better move the logic into a module and send the translated status to the template or have something unified and more intelligent deal with translating that message.
Marcel
------------------------------ *Van:* koha-devel-bounces@lists.koha-community.org [ koha-devel-bounces@lists.koha-community.org] namens Kyle Hall [ kyle.m.hall@gmail.com] *Verzonden:* woensdag 10 april 2013 13:23 *To:* MJ Ray *Cc:* Koha Devel *Onderwerp:* Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript.
In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences.
Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version.
Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pl and moremember.pl display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
On Mon, Apr 8, 2013 at 12:17 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Galen Charlton <gmc@esilibrary.com>
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. [...] Thoughts?
I think this is right. Having a good base theme, especially if there are basically examples of the right way to adapt it with CSS, would be a good way for Koha to learn from Evergreen's experience.
Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes.
I agree. I don't have any ideas brewing for the visual redesign aspect of it, but I would really like the OPAC template to use a more modern CSS framework (not YUI) and have a fully-responsive layout. Bootstrap might get us both of those things, but I think there are some structural aspects to Bootstrap which might not be ideal for potential customizations. I'm thinking in particular of full-column borders and backgrounds. I tried to start a conversation about this process a while ago: http://lists.koha-community.org/pipermail/koha-devel/2012-October/038168.htm... I would still like to hear feedback about what we could do to help better facilitate customization via CSS and JS. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Le 08/04/2013 17:45, Galen Charlton a écrit :
At present we distribute two OPAC themes with Koha, "prog" and CCSR. I like both of them, though it is nice having a mobile theme in the shape of CCSR.
Thoughts?
My 2cts: I pushed the patch because ccsr theme had only 4 .inc and a .css files. Templates (.tt) are shared between prog & ccsr. The patch included some fixes to handle correctly the loading of files partially in prog & partially in another theme. However, I agree it would be a good thing to unify things in the next release. What I dislike the more is the the fact that you must update the them AND a syspref to load the .css . This is a mistake that should have been fixed before pushind the patch. +1 for your others comments/ideas -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
participants (7)
-
Galen Charlton -
Ian Walls -
Kyle Hall -
Marcel de Rooy -
MJ Ray -
Owen Leonard -
Paul Poulain