<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi, <br>
<br>
First, I want to raise my hat to LibLime team for the new website.<br>
<br>
<br>
I also want to thanks Thomas for the time he spent to analyse the new
site and for bringing those worth to discuss points.<br>
<br>
Here is, briefly, my comments.<br>
<br>
1. LOCALISATION<br>
If we do not make the French (France) link point to koha-fr.org, I
strongly recommand to remove it until the french version of the site is
almost completed.<br>
<br>
3. DEMONSTRATION<br>
I'm aware that the demo site are maintained by LL team, however, since
this is a demo for the community, wouldn't be faire to remove any
reference to LL in the demo site?<br>
This includes the username/password, logo and name. As Thomas
mentionned, it would also be nice if the URLs were using the same
approach as the koha-fr site, I means <a class="moz-txt-link-abbreviated" href="mailto:something@koha.org">something@koha.org</a><br>
By the way, I just tried the demo site and here what I noted:<br>
- can not log on the intranet using liblime/liblime at the moment (both
public and academic)<br>
- there is a 404 when we click Catalogue in the public demo<br>
<br>
3.2 PAY FOR SUPPORT<br>
<blockquote type="cite"><span class="" id="parent-fieldname-description">Support
companies are listed by the date they joined the Koha community. </span></blockquote>
I really don't want to remove any credits to LibLime or BibLibre. You
guys are doing awesome job. However, I'm a bit confused about the
contribution part.<br>
<br>
As far as I can tell, a contribution should be something that the
company as paid or provide the ressource to do something. Features
developped for and paid by a client shouldn't be considered as a
contribution.<br>
<br>
Has contributed over 55% of the entire Koha
codebase, including the integration of Koha and Zebra<br>
Has contributed over 35% of the entire Koha codebase<br>
Was the developpment payed by a client? If so, the client should be
credited for the integrations/development, not LibLime... does it make
sense?<br>
<br>
In March 2007, LibLime acquired the Koha division of Katipo
Communications, Ltd., the original developers of Koha 1.0.<br>
Not really a contribution... This is marketing stuff and shoud stay on
LibLime website.<br>
<blockquote type="cite">the koha-manage group decided to...</blockquote>
What are the factor making for someone to be in the Koha-manage group?
There is no mention of such a group on koha.org.<br>
<br>
My main point here is that the Koha.org website should be as
vendor-independant as possible. I really think that the Alphabetical
order is the best way to reach that goal. <br>
<br>
Here some broken links that I found on the new (now current) web site.<br>
<br>
<a class="moz-txt-link-abbreviated" href="http://www.koha.org">www.koha.org</a> (with www) bring a Zope Quick Start Page...<br>
In the footer: LibLime Link<br>
Support » Free Support » Koha Mailing List<br>
Documentation » Reference Manual » Koha 3.0 or Koha 3.2 » All content
on one page... It takes a long time to load and after a while, it
request to log on our Google Account...<br>
<br>
Regards,<br>
<br>
Eric<br>
<br>
<br>
Thomas Dukleth wrote:
<blockquote
cite="mid:35516.173.52.140.37.1241794664.squirrel@mail.highspeedrails.com"
type="cite">
<pre wrap="">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.
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.
1. LOCALISATION.
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.
2. KOHA WORLD MAP.
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.
3. ORGANISATIONAL PROBLEMS.
3.1. DEMONSTRATION.
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.
3.2. PAY FOR SUPPORT.
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.
3.2.1. ORDERING OF PAY FOR SUPPORT.
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.
3.2.1.1. ORGANISATIONAL SCHEMES.
Commenting in library science terms:
3.2.1.1.1. ALPHABETICAL.
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.
3.2.1.1.2. HISTORICAL.
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.
3.2.1.1.3. GEOGRAPHICAL.
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.
3.2.1.1.4. LINGUISTIC.
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.
3.2.1.1.5. RATIONAL SCHEMES AND IRRATIONAL MEASURES.
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, <a class="moz-txt-link-freetext" href="http://www.pbs.org/nerds/part2.html">http://www.pbs.org/nerds/part2.html</a> :
"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."
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.
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.
Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
<a class="moz-txt-link-freetext" href="http://www.agogme.com">http://www.agogme.com</a>
212-674-3783
On Thu, May 7, 2009 8:12 pm, Joshua Ferraro wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
We're pleased to announce that we've nearly finished migrating
koha.org from Kea to the Plone Content Management System--the new site
should be ready to launch by the end of this week.
</pre>
</blockquote>
<pre wrap=""><!---->
[...]
_______________________________________________
Koha-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Koha-devel@lists.koha.org">Koha-devel@lists.koha.org</a>
<a class="moz-txt-link-freetext" href="http://lists.koha.org/mailman/listinfo/koha-devel">http://lists.koha.org/mailman/listinfo/koha-devel</a>
</pre>
</blockquote>
</body>
</html>