Friday 4th March & Friday 11th March

1. Webinar – e:Vision Rebooted
Friday 4th March & Friday 11th March
Mark Rennison – Technical Development Manager
Kate Whincup – Senior Developer
Rik Lewis – Development Team Leader

2. Webinar – e:Vision Rebooted
- What problems are we trying to solve?
- How have we solved these problems?
- What are the benefits?
- How will this impact upgrading?

3. What were the problems?
- e:Vision was built using out of date HTS templates and
standards (10+ years old, when everyone was using
desktop PCs)
- Devices people use to connect to the internet have
changed
- Layouts were unresponsive – displayed badly on smaller
devices
- Layouts were not keyboard accessible

4. What were the problems?
- Inconsistent look and feel due to new functionality being
added which was out of the scope of the templates
- Proliferation of stylesheets – difficult to maintain and make
consistent
- e:Vision was inaccessible to screen readers – lack of labels,
aria tags, and poor structure
- Tribal has a contractual and legal responsibility to be
WCAG 2.0 compliant

6. What were the problems?
- Layouts were table based – tables had been used for
structure and for layout of forms
- Tables are intended for data – they are not for layout, not
for structure, not to make things line up nicely
- Tables didn’t display well on smaller devices (lots of
scrollbars)
- Tables confused screen readers – layout may have made
sense visually but not semantically

8. How have we solved these?
- From version 9.1.0 onwards, we use a responsive,
accessible framework, with consistent styling and a
modern look and feel
- e:Vision displays well on any device and screen
size/orientation, using fluid proportion based grids and
stylesheet media queries (no horizontal scrolling)
- Tables are now responsive and only used where
appropriate (for tables of data)

9. How have we solved these?
- Semantically well built HTML, so that assistive technologies
(such as screen readers) will understand the content
- All HTML built so that it will be supported by all modern
browsers
- IE8 still functionally supported for student facing screens,
including the system tools (some styling issues may be
ignored if they are IE8 specific)

10. How have we solved these?
- New stylesheet framework based on a branch of Bootstrap
3 (all classes prefixed with “sv-” to avoid conflict)
- Introduced a new stylesheet with the new Bootstrap
classes called “sv.css” (optionally using LESS as a CSS pre-
compiler to make maintenance easier)
- Stripped back “sits.css” – this can still be used for
backwards compatibility
- Moved font and colour styles from old “sits.css” to new
“sv.css”

11. How have we solved these?
- Used breakpoints to define screen sizes (in “settings.js”)
- New compliant templates for web development using “div”
based layouts in a 12 column grid throughout e:Vision
- New responsive portal page navigation
- Included jQuery and “sits_ajax.js” on every page, so you
don’t need to include these yourself

12. How have we solved these?
- Converted HTS files based on priority (high/medium in
version 9.1.0, medium/low in version 9.2.0 and low to
follow – aiming to finish in version 9.3.0)
- Converted programs and javascript files that generate
HTML
- Re-styled jQuery widgets to match Bootstrap (eg. Chosen,
Plupload, DataTables and TableSaw)
- Made sure all widgets are responsive and accessible

13. How have we solved these?
- Form layouts use “sv-” Bootstrap layout (eg. panels instead
of tables and divs instead of table rows)
- Use TableSaw widget for static tables and DataTables
widget for dynamic tables (where larger data sets can be
manipulated)
- These widgets make tables responsive (eg. being able to
swipe, choose columns or stack) as well as allow sorting
- jqGrid is being superseded and phased out

14. How have we solved these?
- All pagination should look consistent
- Should sit at the bottom of the table/panel (unless there is
a specific reason for it not to)
- Always should a maximum of 5 page buttons at a time
- Consistent “next” and “previous” functionality

15. How have we solved these?
- All error messaging should look consistent
- Better field highlighting with messages placed in tooltips
when there is limited space (eg. in a table)
- Errors are correctly linked to fields using aria tags
- Inputs groups are used (eg. for “list” buttons)

16. How have we solved these?
- New approach to development – if something doesn’t fit a
standard, a new standard should be created and ratified by
the Web Standards Group
- Improve system tools to aid configuration of responsive
content

17. How have we solved these?
- New mode added to Task Bar Type on TKT – “Responsive
Button” mode
- Table layout replace with a panel – falls back to collapsible
panel list on smaller screens

18. How have we solved these?
- New mode added to Display Mode on TTE – “Responsive
Mode”
- All structure built by the program, with minimal
configuration for institutions (but with less flexibility)
- No HTML specified in prefix or suffic
- New type added to Field Input Type on TTQ – “Raw HTML”,
for embedding content

19. How have we solved these?
- New “Responsive Mode” flags added to POD (for letters)
and DML (for vistas)
- New “Responsive Mode” flag added to the Advanced
Intray via COP parameters
- Other smaller enhancements to the Advanced Intray as
well, such as the ability to have more than one responsive
intray on the same portal page

20. What are the benefits?
- Massive investment by Tribal to resource the changes
- Investment by institutions will also be required
- This is work that had to be done to bring the product up to
date and make it responsive and accessible
- Institutions have also been requesting this and beta testing
seems to have gone well (good feedback received)

21. What are the benefits?
- Easier to customise and maintain moving forwards
- Fewer stylesheets with LESS files to make global style
changes easier (LESS variables, etc.)
- Shouldn’t interfere with other applications of Bootstrap
- Useable and accessible on many more devices
- Progressive approach – system tools have responsive flags
so they don’t have to be converted straight away – old
styles should work alongside new ones

22. How will this impact upgrading?
- All of the header has been stripped away in each HTS file –
this was done via a conversion process that you can run on
HTS files or WRF records
- DOCTYPE, <html>, <head>, <meta>, <title> and <body> are
now all defined in “body-start*.hts” files only
- All default <link> (for stylesheets) and <script> (for
javascript) are also defined in here, so they should never
need to be defined elsewhere

23. How will this impact upgrading?
- Any comments in HTS files will now be displayed in the
page source – this is required for the IE8 shims to work
- “body-start*.hts” files also contain the opening <div> for
the page contents
- The closing </div>, </body> and </html> are defined in the
matching “body-end*.hts” files, including the page footer
- This means that all screens should have a consistent look,
as the individual HTS files only contain the page contents

24. How will this impact upgrading?
- Responsive page headers are controlled by system
parameter “SIW_PORTAL01” – must be set to “Responsive
Horizontal” (RH) for new headers
- Must use the <<TAB_LIST.DUMMY>> field in your
“body-start*.hts” files
- Uses breakpoints to determine how many tabs to display
(controlled by logical “EVISION_BREAKPOINTS”)
- Search can be included using <<SEARCH.DUMMY>> field
- Parent/child pages are supported

25. How will this impact upgrading?
- “Responsive Style” added to Portal Style on MUA, and to
system parameter “SIW_WEB_006” for default value
- Column widths on CPG have been converted to grid
columns using new 12 column grid system
- Columns stack responsively on smaller screens
- Many of the fields on CON/CGR are not used in this mode,
as styling comes from the stylesheet
- An extra stylesheet (“sv-portal.css”) is required for content
mode container options

26. How will this impact upgrading?
- More time will be required for testing and customisation
- We advise taking all Tribal HTS files (layout changes and
amended/replaced WRFs) and then re-customise the ones
that you use/need to
- We advise prioritising tasks, vistas, and other system tools
configuration, and convert them one at a time, using the
responsive modes/flags to switch them over
- Also Web Letters and IPP application forms

27. How will this impact upgrading?
- Make use of FMU for HTS, CSS and JS files management
- Remove references to jQuery and DataTables (they are
now in the “body-start*.hts” files

28. What are we working on?
- Responsive portal – Tiled mode (with or without panel)
- New options added to CON/COP to control styles
Coming in version 9.2.0!

29. What are we working on?
- Responsive raw mode tasking
- Prefix and suffix fields are used to give complete control
over layout and markup
- Added footer on TTE to allow closing of tables (without
using the suffix of the last TTQ)
- Buttons on TTE/TTQ to auto-populate prefix and suffix
fields with default markup, to allow quick setup which
matches responsive mode, but can then edit as needed
Coming in version 9.2.0!

30. What are we working on?
- Raw HTML task questions (non-database TTQs)
- TTQ sequence 900-999
- Automatically set to “Raw HTML” type but without the row
“div” around
- Not stored on MTK – used only for layout/structure
Coming in version 9.2.0!

31. What are we working on?
- Responsive mode tasking – button options
- Buttons are in a form group with a label by default
- Option to move button into TTE button section, alongside
TTE buttons
- Option to move button into TTE button section, above TTE
buttons
Coming in version 9.2.0!

32. What are we working on?
- Dropbox and Google Drive integrations
- TTQ type “Upload” has option to select from cloud storage
- TTQ type “Document Upload” also has this option
- Flag on Document Upload Options to enable
- Upload to e:Vision directly from the cloud
- No need for students to have their documents (eg. CV)
downloaded on their phone or tablet
Coming in version 9.2.0!

33. What are we working on?
- Quick Analysis charting enhancements
- Client has the option to use new jsChart plugin for charting
(can still use Google charts if they prefer)
- e:Vision uses new jsChart plugin, with options for different
charts, including pie, bar, area, line and column
- e:Vision table of results is responsive
Coming in version 9.2.0!

34. Questions?