We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 2757 - Major overhaul of Reading Tools
Major overhaul of Reading Tools
Status: NEW
Product: OJS
Classification: Unclassified
Component: User Interface
Macintosh Mac OS X 10.0
: P1 normal
Assigned To: PKP Support
: 2942 (view as bug list)
Depends on:
Blocks: 1652 3121 3496 3619 4597 1421 1424 1433 2499 2882 3910
  Show dependency treegraph
Reported: 2007-04-02 09:57 PDT by John Willinsky
Modified: 2013-05-29 15:10 PDT (History)
4 users (show)

See Also:
Version Reported In:
Also Affects:

Laytout and design of reworked reading tool management. (314.50 KB, application/msword)
2007-04-02 09:58 PDT, John Willinsky

Note You need to log in before you can comment on or make changes to this bug.
Description John Willinsky 2007-04-02 09:57:15 PDT
Designed to be completely compatible with OCS/OJS and long overdue in terms of rationalizing design  of set up and management of tools. Based on interviews with users (Humanities Computing Scholars). 

Still in need of OpenURL integration and notification-if-cited through Google Scholar.
Comment 1 John Willinsky 2007-04-02 09:58:53 PDT
Created attachment 147 [details]
Laytout and design of reworked reading tool management.
Comment 2 Alec Smecher 2007-08-09 10:03:03 PDT
*** Bug 2942 has been marked as a duplicate of this bug. ***
Comment 3 Alec Smecher 2007-08-09 10:15:53 PDT

- 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? 
Comment 4 Dawn Macaulay 2008-05-30 09:30:42 PDT
(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. 
Comment 5 Felipe Lav 2008-11-21 15:05:55 PST
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.
Comment 6 Alec Smecher 2008-11-21 15:07:40 PST
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.
Comment 7 Felipe Lav 2008-11-21 15:35:16 PST
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.
Comment 8 Alec Smecher 2008-11-21 15:37:36 PST
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.
Comment 9 Matthew Crider 2008-11-21 15:44:46 PST
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.
Comment 10 Juan Pablo Alperin 2009-03-14 08:23:17 PDT
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.
Comment 11 Alec Smecher 2013-05-29 15:10:44 PDT
To be considered in re-implementing RT for 3.x.