Menu
▾
▴
1 Attachments
#1317 Have pub information show when hovering over images on title covers page
open
9
2019-11-01
2019-11-01
No
One of the things I like doing in ISFDB is browsing the cover art for a title, and seeing how styles and tastes change over time or between publishers.
However, IMHO it's a slightly "opaque" user experience, in so far as the page (e.g. http://isfdb.org/cgi-bin/titlecovers.cgi?28692 ) just presents a bunch of cover images at you, with no context about which pubs they came from, or indication of why they are in the order they are, unless you click through to an individual publication page.
It would be possible to add information labels for each image, but then the size of the page (in terms of screen real estate, not number of bytes) could get blown up quite a bit.
Could I propose a solution - albeit one only usable by desktop users - where if a user hovers over a particular cover image, information about that publication is overlaid on that cover image. (I think this is a UI concept "inspired" by some other sites/apps, although I can't think which ones off the top of my head.)
As a proof-of-concept, attached are a couple of hacked versions of html/biblio.css and cgi-bin/titlecovers.cgi. THESE ARE NOT INTENDED AS CODE I AM PROPOSING SHOULD BE PATCHED INTO THE REPO IN THIS STATE.
Rather, they are a practical demo of the ideas I'm talking about, which have definite issues and omissions - notably, the publisher ID is displayed, when what you really want is the publisher name, but this would require a SQL query update - but should be enough for someone else to evaluate my ideas, and give feedback and/or provoke discussion on whether it's something that would be accepted for inclusion in ISFDB, at which point I'd spend time and effort on doing it properly.
NB: this demo (and any accepted production code) does not involve additional JavaScript, or alterations to the HTML in terms of new or altered elements. Rather it uses additional CSS and element attributes/classes to leverage HTML5(ish) functionality such as data attributes, pseudo-elements and CSS3 transitions to implement this fairly basic interactivity.
NB#2: although the site uses (X?)HTML4, AFAIK these HTML5 and CSS3 features are still available to HTML4.. All these features are supported in any reasonably modern (<5 years old at least, probably more like 10) browser, and browsers that don't support them should just silently ignore them, giving the same UX as the existing version of the page.
NB#3: this change could/should also be applied to similar cover pages (e.g. http://192.168.1.129/cgi-bin/pubseries.cgi?9+3) but would need a bit of extra tweaking - e.g. there's not much point in popping up the publisher name on each cover when you're on a page that's dedicated to a particular publisher.
Discussion
Anonymous
I have posted the non-technical part of the FR on the Community Portal so that all editors could see the proposed functionality. I also added the following comment of my own:
I agree that it would be useful to provide additional context on the "All Covers" page. However, I am not sure whether it would be better to show the additional information as "mouse-over" or to display the basics like "Lion Book 1953" under each image. We could even combine the two approaches by displaying the bare-bones data under each image and providing more information via "mouse-over".
Not 100% sure on this, but having text below the images might require a bit more work, w.r.t. the images being variable widths. Historically I think this would have been done with JS; Googling indicates that CSS provides "display: table-caption;" which seems to do the right thing, although I've never used it. https://stackoverflow.com/questions/4979487/image-caption-width-to-same-as-image
I'd be slightly wary of getting into discussions about "bare-bones data", as one person's bare-bones/must-have information is someone else's irrelevant trivia - and you run the risk of ending up with more text than image, and/or having to build some config UI to allow people to select the fields they want. On the other hand, restricting the info to what can be displayed in small bars at the top and bottom of the image means that opportunity for scope creep is much reduced.
(Can you tell how scarred and embittered I am from endless bikeshedding meetings talking about stuff like this? ;-)
Anyway, we'll see what comes of the discussion on the wiki, I guess...
Yup, the functional behavior is always hashed out on the Community Portal first. Sometimes the eventual consensus is very different from what was originally proposed, but that's the nature of the beast.