EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #06705


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] UX/UI Refresh - good practice advice sought


The public facing stuff can be made responsive. I've done a fair bit of work to apply our corporate style to eprints.soton.ac.uk

However, where it's tricky is that the deposit workflow has HTML generated by code, not templates, and lots of it uses tables. It is possible to have an alternate template applied for logged in users, which goes some way to address this, but isn't a full solution.

Where EPrints got it right was all the CSS classes are prefixed with ep_ which means it's possible to merge in a corporate stylesheet and they won't clash in names of classes. However, our university style sheet adds unexpected style to a few basic HTML elements, such as tables, and I had to make some additional css to override this inside EPrints pages as it made a mess.

The place I've put in most of my effort was the item record pages, such as https://eprints.soton.ac.uk/267112/ , which are now properly responsive.

Where I had the biggest challenge is that the XML nature of EPrints templates mean that the whole main page content needs to be wrapped in a single element, and some pages are automatically generated HTML, others are quite flexible. This means you can't have several full width "content" sections on one page, and wrapper the whole page in a single content section for automatic pages. (sorry, hard to explain). Pages likes the search results are quite constrained, so I'd start there, learn the constraints, and then work within those constraints for more general pages like the homepage and item-summary pages. I wouldn't try to make it fully responsive for the "user area" (logged in) parts of the site, as that's a much bigger and harder job.

We've also put a lot of thought into the sections and ordering of the metadata on the summary pages, trying to put the most specialised information lower down.

As part of this set of improvements, we also stopped using full citations for search results, and have gone for a cleaner display for people to skim read. https://eprints.soton.ac.uk/cgi/search/archive/simple?screen=Search&dataset=archive&q=eprints&_action_search=Search but we still put the full citation on the summary page.

At Southampton we've got one of the most established EPrints repositories (as you'd expect) and we've invested hugely in back-end features, but at the expense of the public user interface which was always "important, but not as important as X".

One other interesting decision we've made is to flatten out the structure of the organisation. We have faculties which are administrative groupings, but not relevant to an external reader, so in our revised approach, "Chemistry" is now part of an alphabetically ordered list of departments, rather than you having to find it under whatever faculty grouping it's in. This is a work in progress, but I think we're heading in the right direction. https://eprints.soton.ac.uk/view/divisions/ (nb. very few records as we have to run a full update to repopulate our new 'divisions' field and we're waiting for a time when we can cause that load on the system without causing a bother).

There's some things in EPrints that could do with a "responsive" tweak, such as the 2 column list of options in forms, and the 4 column list of options some /views/ have. This is quite hard to do in the code without risking messing up existing repositories when they upgrade. One solution would be to use _javascript_ (probably jQuery) to tweak the HTML after the page has loaded to be a more responsive "shape".

When we built the _javascript_ elements of EPrints we backed "prototype.js" rather than jQuery, but for bootstrap you almost certainly want to use jQuery too, so you'll need to ensure you have:

  <script type="text/_javascript_">$.noConflict();</script>

Because both libraries like to take over the "$" variable. The noConflict mode for jquery means it lets prototype.js have the $ and it just uses "jQuery" for everything so where you'd normally do $("p.special") you'd do jQuery("p.special") instead. No all jQuery extensions and libraries that use it respect that however, so watch out. Worst case, you can just search and replace over them.

Sorry, that turned into more of a blogpost!

On 14/07/2017 08:28, Vials Moore, Adam wrote:
Hey all!

As a summer project we’re updating the CSS/HTML front end on our eprints front end (I know, I love pain).

Last time round (2+ years ago) I just hacked the relevant CSS into template/default.xml and static/index.html – but now we have 2 repositories (both 3.3.15) on different servers and I’d really like to:

Update to at least bootstrap – so that it looks OK on mobile devoices / not horrible at different resolutions etc &c
Make everything a little more clean and modular
Not have to do it lots of times (preferably!)

I do have some corporate CSS to include so can’t completely freeform . . . .

All advice appreciated


*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

-- 
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/