The Primo GUI – Critique and
improvement suggestions
by Matthias Einbrodt - University Library Bolzano, Italy
1. The University Library Bolzano
The University Library Bolzano
… Bolzano?
The University Library Bolzano
Multilingual region/university
The University Library Bolzano
Some numbers from 2013
- Books & Non-Book Material: 249.256
- E-Books: 50.300
- Loans: 186.665
- Journal Article Downloads: 119.629
- E-Book Chapter Downloads: 90.031
- Active Internal Users: 3.886
- Active External Users: 2.254
The University Library Bolzano
Our Setup
Alma
- Part of Alma Early Adopter Program Europe
- Live with Alma since 01/2013
Primo
- Live with Primo since 11/2011 (ver. 3)
- Current Primo Version in Production: ver. 4.7
- Our current and future Primo
2. Our experience with the Primo GUI redesign
Our experience with the Primo GUI redesign
We started the standard way …
- Default stylesheet left untouched
- New custom stylesheet created which overrides default CSS
Our experience with the Primo GUI redesign
… but after some time …
- … custom stylesheet became difficult to debug/maintain
- … custom stylesheet grew bigger and bigger (~40 KB minified) and we were not even half way through
⇒ We wanted a lighter and more maintainable solution.
Our experience with the Primo GUI redesign
Weight of assets of Primo default GUI – initial page load
Subsequent requests are much lighter ⇒ JS/CSS assets are cached
Our experience with the Primo GUI redesign
Download times of all Primo GUI assets with different connection speeds
|
Weight |
512 kbit/s |
1 Mbit/s |
2 Mbit/s |
4 Mbit/s |
Conversion: 1 Mbit = 125 KB |
854 KB |
13 sec. |
6 sec. |
3 sec. |
1 sec. |
841 KB |
13 sec. |
6 sec. |
3 sec. |
1 sec. |
- Download time ≠ Page load time: Other factors influencing overall page load times such as network latency or time for the browser to render the page have not been taken into consideration.
Our experience with the Primo GUI redesign
Distribution of connection speeds – cable and WIFI
Our experience with the Primo GUI redesign
Distribution of connection speeds – mobile
Our experience with the Primo GUI redesign
Connection speeds – bottom line
- Impatient users
- Broadband internet still far from reality
⇒ Primo GUI assets need to be optimized for speed (there is no faster Bit than no Bit).
Our experience with the Primo GUI redesign
Primo GUI is not mobile ready
Certain changes to GUI are induced via Javascript when two conditions are met:
- Horizontal/vertical resolution smaller than 500px
- Primo is accessed from a mobile device
Our experience with the Primo GUI redesign
Why is the Primo GUI not mobile ready?
Mobile changes will never fire for mobile devices with a vertical/horizontal resolution larger than 500 px such as:
- iPhone 4 (640 x 960), iPhone 4S (640 x 960), iPhone 5 (640 x 1136), iPhone 6 (750x 1334 - 1080 x 1920)
- Several Samsung Galaxy models (e.g. Galaxy S III, Galaxy S4, Galaxy Note etc.)
- Blackberry Q10, Blackberry Z10
Our experience with the Primo GUI redesign
Other problems with the Primo GUI on mobile devices
- One single breakpoint (500px). What if you need more flexibility (e.g. hide or modify an element already at 768px)?
- When rotating device from portrait (< 500 px) to landscape mode (> 500 px) previously induced changes to GUI are not removed.
Our solution
Reduction of Http Requests
Image assets
- We didn't use a lot of CSS background images to simulate gradients etc. (comes with the design).
- For our images (except the big footer images) we used a CSS image sprite
- For our icons we used a custom icon font
Our solution
Reduction of Http Requests – Results (Homepage)
|
Requests before |
Requests after |
Comments |
1 |
1 |
|
4 |
5 |
Four default JS files + our custom JS file ⇒ Concatenation possible? |
2 |
3 |
Our custom CSS files + add2Home.css ⇒ Concatenation possible? |
16 |
0 |
Mostly icons ⇒ replaced by icon font; no CSS bg-images used to simulate gradients etc. |
3 |
5 |
|
0 |
1 |
Icon font ⇒ replaces CSS images |
1 |
1 |
|
27 |
18 |
|
Our solution
Rewriting CSS from scratch with the following in mind
Our solution
Using a dynamic stylesheet language
- An own stylesheet language (very similar to CSS syntax) providing mechanisms such as: variables, nesting, mixins, operators, functions and partials (splitting up stylesheet files)
- In our case LESS (Other options exist, e.g. Sass)
New Workflow:
- Write LESS code in *.less files
- Preprocessor compiles *.less files to (minified, concatenated) CSS
- Upload CSS to server
Our solution
Using a dynamic stylesheet language – some advantages
Split CSS/LESS declarations to different files using LESS partials
- More manageable than one big file with 1000+ lines of code.
- Meaningful naming of files and folders create an additional layer of metadata helping to understand the stylesheet.
Our solution
Using a dynamic stylesheet language – some advantages
Metaphor for the division of style declarations (Thanks to Robin Rendle)
- Quarks (elementary particle and a fundamental constituent of matter): basic building blocks such as paragraphs, headings, form elements, images etc.
- Atoms: more complex objects incorporating one ore more quarks (e.g. data tables, buttons, drop downs etc.)
- Molecules: Structural elements such as header, footer, menus, facets etc. including one ore more atoms
- Additional folders for utilites and vendor specific declarations
Our solution
Using a dynamic stylesheet language – some advantages
- All partials are integrated by central file (Primo_unibz_britta_v2.less).
// Excerpt from Primo_unibz_britta_v2.less
@import "utils/mixins.less";
@import "config.less";
@import "main/quarks/normalize.less";
@import "main/quarks/box-sizing.less";
@import "main/quarks/forms.less";
@import "main/quarks/iframes.less";
@import "main/quarks/images.less";
@import "main/quarks/links.less";
@import "main/quarks/typography.less";
@import "main/atoms/button.less";
@import "main/atoms/carousel.less";
@import "main/atoms/data-table.less";
@import "main/atoms/drop-down.less";
@import "main/atoms/grid.less";
@import "main/atoms/icon.less";
@import "main/atoms/nav.less";
@import "main/atoms/overlay-and-popup.less";
@import "main/atoms/search-forms-elements.less";
@import "main/atoms/slider.less";
Our solution
Using a dynamic stylesheet language – some advantages
Creation of a central configuration file
- Contains variables with values for important parameters of the GUI (colors, font sizes, margin sizes, responsive breakpoints, etc.)
- These variables are referenced in the CSS/LESS declarations instead of hard coding the values
Our solution
Usage of a CSS preprocessor – some advantages
Creation of a central configuration file
// Excerpt from config.less
@base-font-size : 16px;
@base-line-height : 24px;
@base-font-family : Tahoma, sans-serif;
@secondary-font-family: Trebuchet MS, sans-serif;
@line-height-ratio: (@base-line-height / @base-font-size) * 1em;
// Excerpt from /molecules/page-skeleton.less
html {
background-color: @brand-color-1;
}
body {
font-family: @base-font-family;
font-size : @base-font-size;
line-height: @line-height-ratio;
color : @brand-color-5;
}
Our solution
Usage of Media Queries
Our solution
What is still missing?
- Note to change Browser for users that access Primo with older Browsers (e.g. IE8 and below)
-
Improve the conditional loading of the (large) footer images:
- To date: images are not loaded on mobile phones assuming that the bandwith is slow
- Our goal: Images lazy loaded if user is 200-300 px away from images and if connection speed is high enough
- Final Testing and Bugfixing
Our solution
Pro & Contra
Pro |
Contra |
CSS is lighter (around 90 KB minified vs. 200 KB minified) |
Rewriting the whole CSS was time consuming |
CSS is easier to maintain |
CSS preprocessors and OOCSS have a certain learning curve. |
|
You don't work directly with the CSS anymore ⇒ tools like Firebug can't be used (source mapping for preprocessor files not yet implemented) |
Primo GUI is responsive |
CSS declarations for new objects need to be added manually to preprocessor files (e.g. date slider) |
3. Object Oriented CSS in detail
Object Oriented CSS in detail
The DRY principle
- DRY = Don't repeat yourself
- DRY principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
In terms of CSS;
- Don't write the same CSS for logically related items
Object Oriented CSS in detail
Goals & Principles of OOCSS
Goals
- Code reuse
- Faster mor efficient stylesheets that are easiert to maintain and extend
Principles
- Separation of Structure from Skin
- Separation of Containers and Content
Object Oriented CSS in detail
Separation of Structure from Skin
Object Oriented CSS in detail
Separation of Structure from Skin
Object Oriented CSS in detail
Separation of Structure from Skin
Object Oriented CSS in detail
Separation of Structure from Skin
Object Oriented CSS in detail
Separation of Structure from Skin
Object Oriented CSS in detail
Separation of Structure From Skin
Structure = the elementary properties that constitute an object
Skin = visual features of an object (colors, font sizes, shapes, border styles, etc.)
In terms of CSS …
- … define a base class with elementary properties of an object that is only used on elements representing this object.
- … define skin classes which you can potentially mix and match with a variety of objects.
Object Oriented CSS in detail
Separation of Containers and Content
Object Oriented CSS in detail
Separation of Containers and Content
Object Oriented CSS in detail
Separation of Containers and Content
Object Oriented CSS in detail
Separation of Containers and Content
Whatever the container/context, the properties (color, shape, size etc.) of the toolbox don't change.
Object Oriented CSS in detail
Example: The Simple/Advanced Search Buttons
Object Oriented CSS in detail
Comparism Default CSS and OOCSS for Simple/Advanced Search Buttons
|
Size (minified) |
Maintainability |
758 Bytes |
Structural/design changes to logically related element made at more places in CSS. |
414 Bytes (-45%) |
Structural/design changes to logically related elements made at one place in CSS. |
462 Bytes (-39%) |
Structural changes to logically related elements made at one place in CSS. Design changes are made by
adding desired classes to elements in Html markup. |
Object Oriented CSS in detail
Other objects in Primo GUI that can be optimised
- Dropdown menus
- Popups & Overlays
- Horizontal and Vertical Menus
- System Feedback/Error messages
- Result lists
- Data Tables
- Tabs
- Search form elements
- Layout - Grids
- Headings, Paragraphs, Lists etc.
- ...
Object Oriented CSS in detail
Don't reinvent the wheel
CSS frameworks that implement DRY/OOCSS
Object Oriented CSS in detail
Good reads
OOCSS & Atomic CSS
Stylesheet structure
Miscellanea
Using smaller external Javascript Libraries (?)
|
Used for |
Weight (minified) |
Possible Alternatives |
Virtual Browsing |
~ 53 KB |
slick.js (~ 27 KB minified) / jCarousel (~ 18 KB minified) |
Add notes to items saved in e-Shelf (?) |
~ 44 KB |
Tooltipster (~ 17 KB minified) / Opentip (~ 34 KB minified) |
Date slider |
~ 23 KB |
noUISlider (~ 11 KB Basic minified, ~ 17 KB Full minified) / Ion.Range Slider (~ 13 KB minified) |
Opening/Closing Lightboxes (Find Databases etc.) |
~ 15 KB |
Featherlight (~ 4 KB minified) / Colorbox (~ 12 KB minified) |
??? |
~ 16 KB |
Datepickr (~ 6 KB minified) |
Miscellanea
Conditional loading of Javascript code (?)
- Only load portions of the JS code if the feature it should power is enabled.
- Example: An institution doesn't use Virtual Browsing/Find Database functionality ⇒ don't load its corresponding JS
Miscellanea
Optimize Html
- Accessibility
- Markup often too nested
- Respect imposed standards for class names and ids
- Reinventing the wheel not necessary: CSS Framework usually present optimised markup for the objects they style.
- It helps to make the Primo GUI responsive and lighter
Miscellanea
iFrames 
- In our case (Alma) used to pull in availability information/access options for items and in e-Shelf to show details of saved item
- No control over assets (CSS, Images etc.) of loaded page ⇒ Layout/Design breakers
Miscellanea
Layout Editor in Primo Admin GUI
Miscellanea
Layout Editor in Primo Admin GUI
- Great tool. It gives you some control over the markup of Primo without having to alter the template files.
- However, the markup changes are not applied to the e-Shelf, Queries and myAccount views.
Miscellanea
Default markup of e-Shelf, Queries and myAccount is different than other views
/* Skeleton Html Markup of Home Page, Brief Display, Full Display */
<html>
...
<body class="EXLCurrentLang_en_US">
/* An overall wrapper is present here */
<div id="contentEXL" class="EXLCustomLayoutContainer EXLContent EXLBriefDisplay">
<div id="exlidSkipToContent" class="EXLCustomLayoutTile EXLSkipToContent">...</div>
<div id="exlidHeaderContainer" class="EXLCustomLayoutContainer EXLHeader">...</div>
<div id="exlidHomeContainer" class="EXLCustomLayoutContainer EXLHomeContainer">...</div>
<div id="footerEXL" class="EXLCustomLayoutTile EXLFooter EXLClearBoth EXLFooterTile">...</div>
</div>
...
</body>
</html>
/* Skeleton Html Markup of Home Page, Brief Display, Full Display */
<html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
...
<body class="MyAccount EXLCurrentLang_en_US">
<div id="exlidSkipToContent" class="EXLSkipToContent">...</div>
<div id="exlidHeaderContainer" class="EXLHeader EXLClearFix">...</div>
<div id="exlidHeaderSystemFeedback" class="EXLCustomLayoutTile EXLSystemFeedback">...</div>
<div class="EXLMyAccountTabsRibbon">...</div>
<div id="exlidMyAccountContainer" class="EXLMyAccountContainer">...</div>
<div class="EXLFooterTile">...</div>
</body>
</html<
Miscellanea
Default markup of e-Shelf, Queries and myAccount differs from markup of other views
- When overall width of the page is 100% there is no problem.
- Other layout options (e.g. overall page width of 960px and page centered) require different styling for these two different skeleton markups ⇒ Bloats the CSS and makes it more difficult to maintain.
Last but not least
Some examples of great Primo GUIs
My wish for next year
A completely new Primo GUI which is optimized for speed, maintainability and mobile readiness. It is furthermore based upon well established best practices/standards of the Web Development Community.