Icons

[townxelliot]

Have you considered using the Tango icon set? (I noticed you mentioned
needing some media icons.)

http://tango.freedesktop.org/Tango_Icon_Library

[Gabriel Farrell]

The Tango icons are great. If we can pull together icons from there to
accurately denote books, journals, DVDs, etc., then that set will be
included in the project.

If not all of our needs are in Tango, it might also make sense to
design some icons that coordinate with the Tango core, and start a new
additional set for general library needs.

gsf

[Jodi Schneider]

New icons should be smaller* than the current book icon. For internationalization, separating text and icon might be preferable.

Icons should include: book, journal, ebook, ejournal, online resource, DVD, VHS, laserdisc, CD-ROM, microfilm, microfiche, thesis, article.
What should happen when there are multiple formats?
Should reference materials be distinguished?

*Based on preliminary usability testing with 3 users and Paul Smith's catalog, the book icon is too big (150x48 pixels, including text). http://library.paulsmiths.edu/media/book.png . Common complaints: "looks like a dictionary"; "could be 30% smaller".
Somehow the magazine icon (150x60 pixels, including text) comes across as smaller and might be the size to aim for.
http://catalog.spl.org/hipres/images/formaticons/ipac-icon-magazine.gif

(I'm assuming that MARC doesn't distinguish popular magazine vs. academic serials--but this would be a nice distinction to make. Coming across " Éire-Ireland; a journal of Irish studies." as a magazine is odd.)

-Jodi

[Dan Scott]

I've actually downloaded the Tango icons at least twice, thinking
about trying to pick appropriate ones for use in FBO but haven't got
past the point of perusing them and finding a few that seemed
appropriate. I'm certainly in favour of keeping text and icons
separate - not only for i18n purposes, as Jodi suggested, but also for
accessibility purposes - and I would suggest harvesting the
low-hanging fruit first before we worry _too_ much about
multiple-format / academic vs. public requirements.

Heck: just using plain <span class="xxxFormat"></span> tags, either
with an icon supplied by CSS (content property) or with text that can
be i18n-ized by Django for each value of xxxFormat might be a nice
flexible way to go - and for starters, we could style the contents
with text, until we have a complete-ish set of icons. It's a backwards
step, but at least we wouldn't be stepping on anyone's toes. Note that
spl.org switched to HTTPS for their catalog recently - I wonder if
they got slashdotted after the CiL article came out - ouch / sorry if
that was the case :(

Although... one approach to solving the multiple-format problem might
be to try an Evergreen-style multiple format icon display,
highlighting only the icons that match the formats behind the
retrieved records.

Take a peek at http://demo.gapines.org to see what I mean if I didn't
explain myself clearly :)

--
Dan Scott
Laurentian University

[Dan Scott]

On 27/11/2007, Dan Scott <den...@gmail.com> wrote:

<snip>

> Note that
> spl.org switched to HTTPS for their catalog recently - I wonder if
> they got slashdotted after the CiL article came out - ouch / sorry if
> that was the case :(

Nevermind that - it looks like the reason I started seeing raw HTML
coming back for the IMG element was because a recent Django update
started automatically escaping the HTML that was getting pulled from
config.py on output in the view. An {% autoescape off %} block would
probably fix this for now, although I'm toying with a change to the
indexing + displaying of formats to be more i18n & styling-friendly.

A quick test of the CSS content property suggests that Firefox and
Konqueror support it reasonably well, using a style like:

.bookFormat:after { content: "Book"; }

The :after attribute is critical for Firefox. Someone with IE6 will
undoubtedly tell me it won't work there. Ah well.

[Dan Scott]

By way of demonstration, attached is a patch showing the direction I
was heading for reworking the format properties. The challenge is
making the faceting happy, too; it looks like some more
re-mah-jiggering of the facets may be required at display time to
provide the correct i18n-ized representation of the content.

For example, in the currently committed code, we store the format as
"Book" or "Music CD" in the Solr index, which results in English-only
facets in the currently committed code. My patch would store those as
"bookFormat" or "musicCDFormat", which makes the facet names equally
ugly in all languages, but makes it easier to map to CSS classes. When
we build the format facets, we could run the results through a
function that maps the format name back to an English string that has
the magic _() ugettext() alias so that we can provide a translated
version of the format name and display that in the facet section
instead.

My proposal is essentially the opposite of what the committed code
currently does, and arguably it's not much of an improvement over the
status quo. But it feels right; other feelings would be appreciated :)

[Dan Scott]

And here's the patch. Sigh.

[Gabriel Farrell]

On Nov 27, 8:38 pm, "Dan Scott" <deni...@gmail.com> wrote:
> And here's the patch. Sigh.
>

Thanks for the patch, Dan. In the spirit of the ZenOPAC (or whatever
it will be called), however, I'm inclined to keep the HTML and CSS as
simple as possible. The CSSZenGarden site includes text in the html,
but some designs use images instead of text, akin to what we'd be
doing with various icon sets, with a display:none on the text element.

I think the place for the i18n stuff is in the Django templates, so
the text shows up as a straightforward HTML document in whatever
language is chosen. To that end, I'd also like to put the CSS in a
separate file.

I don't feel I'm being especially clear, it being the end of the day.
I'll try to whip up a patch for this tomorrow to give a better idea of
what I'm rambling on about.