Created attachment 147 [details]
Laytout and design of reworked reading tool management.

*** Bug 2942 has been marked as a duplicate of this bug. ***

Notes:

- Suggest leaving the locale selection out of the administration interface; the reader should get reading tools in their current locale, if available.

- Citation formats have been moved into a plugin format so that the reader can choose them; IIRC there is an entry elsewhere describing a way for the JM/CM to limit choices to a subset of available plugins.

I think this entry is suitable for a 3.0, as it's quite a break with the current sets & definitions -- JMs will need to do some legwork to migrate settings etc. I'd like to consider releasing a separate RT with these changes included. John? 

(In reply to comment #3)

Suggest making the reading tools context sensitive (like the help files) so that a different reading tool appears in conjunction with different journal sections. 
 

I don't see what's the need to use a frameset to display Reading Tools, as they could be placed in a side bar next to the main contents and then styled with CSS.

Frames are considered "problematic" according to official W3 Accessibility Guidelines (http://www.w3.org/TR/WCAG10-HTML-TECHS/#frames). They're not completely inaccessible, but they "generally make a site less accessible and usable" (http://www.456bereastreet.com/archive/200603/evaluating_website_accessibility_part_2_basic_checkpoints/#frames).

They also represent quite a few usability issues - according to http://www.456bereastreet.com/archive/200411/who_framed_the_web_frames_and_usability/ - and cause problems for search engines, as you can see here: http://rurlz.com/mm95

Iframes aren't much better

If the reason for keeping frames is the way they look, it would be possible to do the same with CSS: let's say we have RT wrapped in a "div"; if you apply position:fixed (which doesn't work quite well in MSIE6, but this can be solved with this http://www.cssplay.co.uk/layouts/fixed.html or this http://code.google.com/p/ie7-js/) the div will stay... well, on a fixed position; if the content of the RT doesn't fit the div, you can apply overflow:auto or overflow:scroll so the div gets scrolling bars.

I think that, overall, the downsides of not having frames are largely surpassed by the benefits.

We're forced to use frames because we need to support PDF galleys (and other formats) in addition to HTML. I agree that it's technically problematic, but if we're to use embedded media in formats other than HTML, it's necessary.

What about using frames only on PDF galleys? 
HTML Galleys could use a non-framed version, and would (or might) get better indexed by search engines.

By the way, I think PDF files only open within the browser if use Acrobat as a browser plugin - which, very probably it's the immense majority of users - but if you use something like FoxIt PDF Reader (an alternative PDF Reader for Windows) or eVince (default PDF reader for GNOME), they open on the sofware window itself, not within the browser.

Agreed, using frames only for non-HTML content would be a good solution. It should also be possible (if we're overhauling the RT anyway) to do this without having to implement it twice.

Just an observation--Web crawlers should be able to find articles just fine even if there are frames, since we use the <noframes> tag..  They will will just be directed to the 'frameless' article view page.  They will just (probably) have difficulty indexing the reading tool's sidebar.  But, yeah, agreed--frames are evil.

I had this idea just now.  What about if we provide a way of embedding reading tools within an HTML page?  We could provide some kind of variable replacement so that HTML galleys could include something like {{readingtool:name}}.  Each reading tool can have a defined HTML snippet that it will use for the replacement (in some cases only a link, in others it could include an image).  These could also have options.