[Koha-devel] MARC Editor Visibility

[Pierrick LE GALL]

On Thu, 23 Mar 2006 13:11:34 -0800
Joshua Ferraro <jmf at liblime.com> wrote:

> Hi all,

Hi Joshua,

Thank you for sending a clean explanation by mail, I didn't understand
what you were talking about with thd and paul on IRC.

I agree that in a general way, MARC Editor really need improvement. I
bet the best improvement will be to use another technology than
HTML/Javascript... (Paul's student will work on it I suppose).

> [...thd and Joshua experienced usability problems with a verbose
> biblio framework...]
> 
> So we set out designing a 'visibility scheme' with three
> basic goals:
> 
> 1. prevent very rare tags/subfields from being loaded into the
>         MARC editor by default, but allow the user to add them
>         if needed (with a page reload) and _definitely_ load
>         them if they already exist in a record (ie, _no_ data
>         lost when using the MARC editor).
> 
> 2. allow uncommonly used fields to be collapsed and expanded
>         quickly and easily without a page reload.

At this point, I thought you had found a way to /suggest/ which
tags/subfields were rare and which were uncommon. (Wouldn't it be
interesting?)

> 3. [backward compatibility]

So your technical solution is:

> [...] Using the current framework's 'hidden' [...] Given that
> limitation [...]:
> 
>   -9 => Future use
>   -8 =>  Flag
>   -7 =>  OPAC !Intranet !Editor  Collapsed
> [...]
>    8 => !OPAC !Intranet !Editor !Collapsed
>    9 => Future use
> 
> With this scheme, it's quite simple to check for the most
> important cases:
> 
> *if (odd) { collapsed }
> *if (even) { !collapsed }
> if (>=0) { hidden in OPAC }
> if ((<=-4)||(>=5)) { not in the editor unless exists or is added}

Joshua, I implore you to make this simpler on HEAD. If you need 4
boolean values ($display_in_OPAC, $display_in_intranet,
$show_in_editor, $collapse_in_editor), use 4 booleans. Not a 16
values flag. It will be far more readable for the one who did not code
the first version.

The solution you propose is mind satisfaying but hard to
understand and maintain for followers.


Staying on the MARC editor topic, is there a kind of specification for
the future MARC editor Koha needs in 3.0 ? (I mean the one that Paul's
student is supposed to work on)

Cheers,

-- 
Pierrick LE GALL
INEO media system