Re: [Koha-devel] A few things you could do before I release of Koha 3.8
At 02:54 PM 4/19/2012 -0400, Owen Leonard wrote:
... very respectfully, it's bloatware. Firebug pagespeed finds a 23% increase in transfer size:
There's no way to "respectfully" use the term "bloatware."
If I've offended you, please accept my humble apologies. We use the term rather loosely to describe an increase in code size (in this case 23% - see my previous post) combined with a (perceived) decrease in user friendliness. If there's a better term, I'll be most happy to use it.
The "old" fitted nicely onto one screen without scrolling; for the "new" you have to scroll for all functions except search.
What are the dimensions of your browser window? It should be possible to make it more flexible.
We us a standard setting of 1024 x 768 on all monitors in our organization (from end-user kiosks to my desk-top.) For a graphical comparison, please see: <http://navalmarinearchive.com/admin/koha_home_page_comparison.html>.
Adding a new Marc record now requires 2 clicks instead of one.
True, if you do all your cataloging using the default framework.
Or any other framework, surely? It's only when you get to the koha-admin/cgi-bin/koha/cataloguing/addbiblio.pl page that the choice of frameworks is available.
We'd have to experiment to see how our "news and links" can be functionally fitted to the left hand side of the screen.
The display of news is essentially unchanged in this version.
Not from what we can see - again please see the "comparison page" link above.
Question: can the css, templates etc from 3.6 be retained? Or do the mods permeate further?
The changes are primarily CSS-based with the exception of the removal two links, "Add MARC record" and "System preferences."
Fine - thanks. The css is no problem, but where is the removal of the two links? In a perl script or in a template? Best - Paul
At 02:54 PM 4/19/2012 -0400, Owen Leonard wrote:
... very respectfully, it's bloatware. Firebug pagespeed finds a 23% increase in transfer size:
There's no way to "respectfully" use the term "bloatware."
If I've offended you, please accept my humble apologies. We use the term rather loosely to describe an increase in code size (in this case 23% - see my previous post) combined with a (perceived) decrease in user friendliness. If there's a better term, I'll be most happy to use it.
The "old" fitted nicely onto one screen without scrolling; for the "new" you have to scroll for all functions except search.
What are the dimensions of your browser window? It should be possible to make it more flexible.
We us a standard setting of 1024 x 768 on all monitors in our organization (from end-user kiosks to my desk-top.) For a graphical comparison, please see: <http://navalmarinearchive.com/admin/koha_home_page_comparison.html>. Yikes ! there's something wrong with your display of the display introduced by bug 7979 !!! (and I understand why you're complaining now). Attached is how it look for (all of ?) us. The menus are on the RIGHT of
Le 19/04/2012 22:47, Paul a écrit : the news, not BELOW ! which version of FF are you using ? any idea welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
I can reproduce that look if I resize my browser window so that it is narrower. I think if you set a minimum width value it would add a horizontal scroll bar when the width is below the minimum width instead of moving the div down. Jon Aker Director of Technology Mountain View Whisman School District "Continuously support team members with their use of technology to enhance productivity and student achievement." 2012/4/20 Paul Poulain <paul.poulain@biblibre.com>
At 02:54 PM 4/19/2012 -0400, Owen Leonard wrote:
... very respectfully, it's bloatware. Firebug pagespeed finds a 23% increase in transfer size:
There's no way to "respectfully" use the term "bloatware."
If I've offended you, please accept my humble apologies. We use the term rather loosely to describe an increase in code size (in this case 23% - see my previous post) combined with a (perceived) decrease in user friendliness. If there's a better term, I'll be most happy to use it.
The "old" fitted nicely onto one screen without scrolling; for the "new" you have to scroll for all functions except search.
What are the dimensions of your browser window? It should be possible to make it more flexible.
We us a standard setting of 1024 x 768 on all monitors in our organization (from end-user kiosks to my desk-top.) For a graphical comparison, please see: <http://navalmarinearchive.com/admin/koha_home_page_comparison.html>. Yikes ! there's something wrong with your display of the display introduced by bug 7979 !!! (and I understand why you're complaining now). Attached is how it look for (all of ?) us. The menus are on the RIGHT of
Le 19/04/2012 22:47, Paul a écrit : the news, not BELOW !
which version of FF are you using ? any idea welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ 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/
2012/4/20 Jon Aker <jaker@mvwsd.org>
I can reproduce that look if I resize my browser window so that it is narrower. I think if you set a minimum width value it would add a horizontal scroll bar when the width is below the minimum width instead of moving the div down.
I can confirm that resizing narrower crams it all to the left. Kind Regards, Chris
At 10:28 AM 4/20/2012 +0200, Paul Poulain wrote:
We us a standard setting of 1024 x 768 on all monitors in our organization (from end-user kiosks to my desk-top.) For a graphical comparison, please see: <http://navalmarinearchive.com/admin/koha_home_page_comparison.html>. Yikes ! there's something wrong with your display of the display introduced by bug 7979 !!! (and I understand why you're complaining now). Attached is how it look for (all of ?) us. The menus are on the RIGHT of
Le 19/04/2012 22:47, Paul a écrit : [snip] the news, not BELOW !
which version of FF are you using ? any idea welcomed !
Paul - merci d'avoir répondu ... FF is version 11.0 (the latest, I think). Now to the nitty gritty. The html|css layout employs nested <div>s which are much more difficult to control across varying sized monitors compared to a <table width="100%">. The <div> does not resize vertical height to respect an overall width -- if you want to do that you have to introduce a horizontal scroll bar (js?) which can get ugly -- whereas the <table> will wrap text wherever it can to respect fixed width. With FF, I can, by reducing font size ( <ctrl> + <minus> ) bring the graphical menu back to your desired position. I thought this might have been because "font size" is not set in CSS, not even inherited from "body", but a live edit to staff-global.css adding a line such as: font-size: 13px; or font-size: 1em; in the body section has no effect. FYI Chrome 16.0.912.77 also breaks the page in the same way (and can be corrected with <ctrl> + <minus>), as does Opera 11.62 and Safari 5.1.1. I only have access to version 6.0.2900 of M$ Exploder -- and it breaks the page but cannot be corrected. The problem with using <ctrl> + <minus> is that a) most users don't know about it, and b) you have to reverse it (<ctrl> + <plus>) when you get to the following page ... ... et ça, c'est ennuyeux. Amitiés et a+ Paul [and apologies, I don't have an available sandbox right now - nor really the time - to do a test install of 3.8. I'm still testing all sorts of combinations of memcached, fcgid and Squid on 3.6 with various flavours of Apache 2.2 and 2.4 -- and of course I can't risk our production server.]
On Fri, Apr 20, 2012 at 5:03 PM, Paul <paul.a@aandc.org> wrote:
At 10:28 AM 4/20/2012 +0200, Paul Poulain wrote:
Le 19/04/2012 22:47, Paul a écrit :
[snip]
organization (from end-user kiosks to my desk-top.) For a graphical comparison, please see: <http://navalmarinearchive.**com/admin/koha_home_page_**comparison.html<http://navalmarinearchive.com/admin/koha_home_page_comparison.html> . Yikes ! there's something wrong with your display of the display introduced by bug 7979 !!! (and I understand why you're complaining now). Attached is how it look for (all of ?) us. The menus are on the RIGHT of
We us a standard setting of 1024 x 768 on all monitors in our the news, not BELOW !
which version of FF are you using ? any idea welcomed !
Paul - merci d'avoir répondu ...
FF is version 11.0 (the latest, I think). Now to the nitty gritty. The html|css layout employs nested <div>s which are much more difficult to control across varying sized monitors compared to a <table width="100%">. The <div> does not resize vertical height to respect an overall width -- if you want to do that you have to introduce a horizontal scroll bar (js?) which can get ugly -- whereas the <table> will wrap text wherever it can to respect fixed width.
Owen has submitted a fix for this which works as far as I can tell. Kind Regards, Chris
participants (4)
-
Chris Nighswonger -
Jon Aker -
Paul -
Paul Poulain