[Koha-devel] Default search options in the OPAC

[BWS Johnson]

Salvete!

    My inclination is that I'm answering this too soon and that I've not thought enough about your questions in particular, but I've thought over structure in general and I want to honour an expedient timeframe for your question in especial.


> We could all chime in about which features we think are the most
> important, and we'd have as many different views. The questions I want
> to get at:
> 

    Niyayo, but it is not unusual to see a pattern after preference voting. We all want the conference different places, but a vote settles where we hold Conference in a given year. I realise that features and Conferences are different birds. I am glad that you highlighted that which is important to you. That is why I suggested a committee or some sort of group work. We will all like different things. The power here is seeing a pattern.


> - Is it a (mostly-) common goal that the OPAC default search options
> be simple and few?
> 

    There are two OPACs as things are currently. While our Patrons are not dumb, I feel that we did our best as a Community when we had a simple text search box as the first thing a user saw in our Catalogue for Patrons. I realise that this was quite a long while ago, but I still think that the search from 2.X - just the box first - was the best. To my perhaps faulty recollection, a user could toggle to advance search if they wanted interface clutter in their lives so that they could hone in on specifics. This is very similar to the evil Google, I realise.

    I think it is safe to assume that Librarians ought to be more proficient than most Patrons. (My weasel words are in there as an acknowledgement that sometimes this is not always the case. In the rare exceptions, it would not be out of the pail for a Librarian to grant a highly proficient Patron, such as a Bibliographer, Staff Access. But programme first for the rule then for the exception, yes?) So for the Staff search, I think the common goals can be arrived at in few and in order of frequency of encounter within one's daily routine. I would advise breaking skins or templates into Library types (small rural Public (or just Public to start), large private Academic, et cetera.) 

    So, in my world, one has a matrix of 

Library type: Academic, Public, School, Special

     and there's another toggle for size: 

Large, Medium, Small. 

    It's complex, but finite. Granular, but not overwhelming. At least to my pea sized brain. Your mileage may vary.


> - If not, should the solution be something more structured than
> javascript-based customizations?

    I think you have a very good handle for local customisations. I remember thinking "Oh, if only I could change things just a touch so that I could add my Library's picture and name." You and others made this happen. :) That was more than I ever really thought I'd see since it was a good "It would be nice if" enhancement. I think some folks are always going to customise their OPAC, but I think there will be natural variance from site to site. Wordpressesque skins are a good way to address this added personal touch that perhaps not everyone would care for. We've had brilliant response to SQL reports in terms of contributions, and now I think we are building the same sort of base of jQuery stuff. Perhaps skins would be another bank of stuff that might build, or perhaps not given the way templates are. I don't know.

    In short, (too late, I know!) two dials are better than one here given that they're both logically constructed, which I think is best done with users working in concert with developers. Not that we don't already do that. 

Cheers,
Brooke