[Koha] [Koha-devel] Announcing ... New koha.org Website based on Plone

Joshua Ferraro jmf at liblime.com
Sat May 9 03:20:06 NZST 2009

On Fri, May 8, 2009 at 10:57 AM, Thomas Dukleth <kohadevel at agogme.com>wrote:

> The work new website design is attractive much in keeping with the former
> design.  Plone is great and has some man years of development
> sophistication as an advantage over the simple easy to implement design of
> Kea.  Some good work has been put into the new website.  However, there
> are some significant problems which should delay the launch of the new
> website until they are resolved.
> This message reads as announcement of what will happen when it should
> actually have been announcement of a development proposal for community
> comment.  I understand that a few people had seen the development work
> already but it has been evident to me from merely a few minutes
> examination that there are some very serious bugs.  I also understand that
> no consensus amongst those developers who had already seen the new website
> had been reached for at least some important parts of the new website.

This decision to move to Plone is a widely documented one, it was decided in
several official IRC meetings and a Plone skinning contest was announced in
January of 2008 on the mailing lists. Subsequently, none of the skins that
were developed were accepted by the community, so LibLime paid those
developers their awards, and used our inhouse resources to work on a skin
that was closer to the existing theme for Kea. Given the amount of work we
have had on our plates, we're quite excited to have finally gotten this done
so that the Koha community has this enhanced resource to better the
community. In particulare, I'm sure that some folks in non-English speaking
contexts will be quite keen to start transating as soon as possible so that
the Koha website can be used widely around the world.

> I strongly recommend delaying the launch of the new website until a
> satisfactory level of bug fixing has been completed and real consensus has
> been established even about some contentious pages.  I have not yet had
> time to file the bugs in Bugzilla but that should not be an indication
> that the bugs are not real.
> Good localisation support is one the advantages of Plone.  Yet the French
> translation is highly incomplete and there may be some design mistakes for
> how Plone has been implemented which may prevent localisation from working
> properly.  Proper localisation requires preparation for localisation from
> the beginning.
> I find no link to koha-fr.org where at least French localisation works.

There were no localization options on the old website, so this isn't a
blocker. Also, I don't find any links to koha-fr.org on the old koha site

> I am very pleased to see the return of a Koha world map.  I was quite sad
> that feature had been lost when migrating to Kea.
> The word 'showcase'  has never been obviously understood but the Koha map
> conveys a more appropriate meaning for showcase than the previous use for
> Koha demonstrations.  There seem to be many functionality bugs which may
> be related to JavaScript problems in how Google maps has been used.
> The actual number of libraries included currently gives a poor inaccurate
> impression of Koha.  The map had been woefully out of date four years ago
> but gave a much better representation of the distribution of Koha four
> years ago than the current world map gives now.  I hope that libraries
> will actively populate it.

As do I. This is not a blocker for site launch either.

> The demonstration links are broken because demonstrations had formerly
> been linked from showcase which is now more appropriately the Koha world
> map.  Demonstrations are now listed in a links subsection of documentation
> which does not seem to be an appropriate location to me.
> Demonstrations require significant work to maintain and update but some
> considerations to other problems suggests the need to have demonstrations
> as part of koha.org.  The good communitarian example of having
> demonstrations on the general organisation website has been set by for
> French demonstrations at koha-fr.org.  The case of merely linking to
> demonstrations hosted on individual support company websites as koha.org
> has done for English demonstrations should be discontinued, although,
> having such links as well is probably good.  I make no suggestion that the
> launch of the new website be delayed specifically for a problem which has
> never been corrected on the current website.

The demo links are working fine for me, can you specify where exactly you
are seeing broken links?

> The pay for support page no longer seems as communitarian as it should.
> Attribution for contributions to Koha is very important but there should
> be an appropriate place to see the contributions of participants in the
> project.  The heavy weighting given on that page to LibLime and BibLibre
> detracts somewhat from the expectation that everyone will contribute well
> to the Koha community.  The pay for support page would not have enough
> space to provide the most helpful and fair presentation of such
> information.  I suggest linking to a very detailed page or set of pages of
> contributions instead of including such information in the manner in which
> it is now presented on the pay for support page.
> I hope that the Koha history would merely inform such an attributions page
> or pages.  An analytically arranged document showing the creation and
> major contributions to features etc. should be used.  Linking to such more
> complete attributions for credits in Koha itself would also be good.  The
> fantastic contributions of LibLime and BibLibre to Koha would be even more
> obvious in such a document but there would be space to give everyone due
> acknowledgement.
> Linking to a more complete attribution document will also avoid the
> greatest problem present in the new page which has been the source of some
> controversy recently.  The presentation as it now stands violates a
> principle of the Koha community guidelines of trying to avoid the
> appearance of any particular Koha support company seeming more official
> than any other.
> The ordering of listings on the page has been changed from the arbitrary
> alphabet to a less arbitrary but incorrectly specified historical
> ordering.  I suggest providing links to various ordering arrangements and
> allow visitors to the website to choose which arrangement to view.  In any
> historical arrangement, the historical order should be correctly specified
> as I explain below.
> Commenting in library science terms:
> Alphabetical arrangement has been the default ordering scheme.  The
> alphabet is not a rational organisational scheme because it is strictly
> arbitrary by the happenstance of the placement of letters.  It has the
> virtue of being universally understood.  The arbitrary has the possibility
> of seeming fair by being impartial but fairness is not a necessary
> consequence of arbitrary impartiality.  Trade naming choices can also be
> taken to ensure early placement in alphabetical ordering and undue
> fairness but we have not seen that problem in the Koha community.
> Historical organisation is the next worst organisational scheme unless the
> material being organised has an intrinsically historical function.
> Organising the history of something historically is natural.  Organising
> other aspects of something in an historical manner is inappropriate.
> In a proper historical presentation, Katipo and Paul Poulain would be
> listed on their own account even if they would be no longer prominently
> offering Koha support or now using a different name in business.  In such
> cases, there should be links within the page from Katipo to LibLime and
> Paul Poulain to BibLibre with appropriate annotations at the origin of the
> links.  "Katipo Koha interests acquired by LibLime" and "Paul Poulain
> formed BibLibre" would be appropriate annotations.  The use of
> 'grandfathered' is a mistaken use of the expression.
> Geographical organisation is the next worst organisational scheme unless
> the material being organised has an intrinsically geographical function.
> Organising the geography of something geographically is natural.
> Organising other aspects of something in a geographical manner is
> inappropriate.
> Linguistic organisation is the next worst organisational scheme unless the
> material being organised has an intrinsically linguistic function.
> Organising the linguistic aspects of something linguistically is natural.
> Organising other aspects of something in a linguistic manner is
> inappropriate.
> Schemes which are rationally related to the content are the ones about
> which people often have difficulty agreeing because they reflect a
> particular view about the organisation of knowledge.  Contribution to the
> code base might be a good rational organisational measure but the number
> of lines fails to account for the quality or importance of contributions.
> Steve Ballmer is not someone to whom I look for words of wisdom but he is
> not wrong about everything.  His larger than life persona explaining this
> issue in the context of OS 2 development is the best moment in a
> television history of the microcomputer revolution.  Riding the bear [part
> 2] [videorecording]. -- In Triumph of the nerds [videorecording] / written
> by Bob Cringely ; series producers, John Gau, Stephen Segaller ; series
> director, Paul Sen ; John Gau Productions and Oregon Public Broadcasting,
> with RM Associates for Channel 4 and PBS. - 1996 - Based on the book
> Accidental empires by Bob Cringely.
> From the transcript, http://www.pbs.org/nerds/part2.html :
> "Steve Ballmer
> In IBM there's a religion in software that says you have to count K-LOCs,
> and a K-LOC is a thousand line of code. How big a project is it? Oh, it's
> sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And
> IBM wanted to sort of make it the religion about how we got paid. How much
> money we made off OS 2, how much they did. How many K-LOCs did you do? And
> we kept trying to convince them - hey, if we have - a developer's got a
> good idea and he can get something done in 4K-LOCs instead of 20K-LOCs,
> should we make less money? Because he's made something smaller and faster,
> less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always
> makes my back just crinkle up at the thought of the whole thing."

This is not an issue that can easily be resolved unfortunately and the
koha-manage group decided to list by date of entry rather than the above

> 4.  LAYOUT.
> I also note some cases where text containing layout elements are too
> narrow for the content included and text is sloppily spilling out of those
> elements and overlaps the body element.  I have not seen it yet in my
> brief view but the hazard is that text spilling out of one element will
> overwrite text in other text containing elements.  This problem is evident
> with standard browser settings for any user.

Please detail these issues and provide some suggestions for fixes to the CSS
if you can and we'll do our best to update.

> Increasing the text size for disability access would only exacerbate such
> already existing problems.  Plone can be perfectly compliant with
> disability access rules but implementers need to observe them.

If you notice, there is an 'accessibility' link which should address this


Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO                         migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20090508/cbb47b36/attachment-0001.htm 

More information about the Koha mailing list