1. What is content UX? Create document UX artifacts aligned with latest XML in HTML 5 and CSS2 & 3 based on the style guide and standardization Create search research listing wireframes, using Axure, Photoshop and Microsoft word Analzing the data and markup (tag) on the XML which has correct data and markup to support BR/FR Communicate with LBUs, Standardization, Presentation team, Product UX, Visual Design teams Produce content style guide

2. We responsible Document View Page

3. We produce Document UX artifacts Live example We use the data and markup (tag) on the NL XML to create the correct presentation on the document based on content style guide.

4. We produce Wireframes Search result list and Document views (RHS, Jump to and TOC) Data Only Live example

5. We produce Style Guide CSG

6. Content UX production flow LBU Content SME GTO Content Architecture LBU Content Architecture Product management Product UX Visual Design Web Dev Content UX Standardisation UX MockupWireframes UXR / Wireframes Review BRs/FRs UX Design & Visual Design BRs/FRs XML Style Guide Collaboration

7. Content SME (Subject-matter expert) Daphne Beeler (CA), Margaret Palmer (CA), Phil Jappu (UK), Carlo Santa Barbara (PA) and Colleen Kok (PA) Content Architecture and Fabrication Charles Scott Nelson (UK, PA, CA), Paul Kiel (UK, CA) Lesley Reid (CA), Richard Glynan (PA) and Arunas Vaitkus (UK) Product Management Tara Diedrichesen (CA), Sonia Pignorel (CA), Anna-Marie Stella (PA), Viji Alagarsamy (UK) and Alex Palmer (UK) Standardization Jane Ashby (Lead) and Gareth Williams (Specialist) Product UX Michelle Kish (PA), Tris Kurniawan (PA), Zoja Bajbutovic (UK) and Nicholas Kizirnis (CA) Visual Design David Lovell (US), Jenny Nam (UK), Donna Lea (UK), Simmone Waldron (UK) and Erin Bird (UK) Presentation Team Terrie Shouse, Lindsey Decot and Bency Thomas Handshake Document Bency Thomas, Kevin Zumkehr, Brian Bohman and David Wills (UK) Last update: 25 th July 2014

8. Production flow – Roles and Deliverables Content SME SME provides content expertise, selects documents for UX and wireframe creation, provides feedback on presentation and leads content enhancement and remediation to support the desired presentation. Content Architecture and Fabrication Create new processing pipelines and amend and maintain existing ones. Take editorial xml or word files and process those files through conversion scripts into Rosetta xml. Divide or collate files where appropriate (e.g. separate precedents from drafting notes) Move data around within the files if required. Add information to create links. Validate the files to make sure they won’t break. Process attachments through. Supply the files to the US systems. Product Management Coordination amongst Product UX, Content UX and SME. Providing Product and Content support and business direction in resolving issues. Also, creation and clarification of product and content requirements Standardization Standardisation is part of the Global Content Strategy and Content Process Management Solutions team. They are at the heart of seizing opportunities to standardise our content and content creation processes and to that end have a close relationship to content and the presentation thereof.

9. Production flow – Roles and Deliverables Visual Design Coordination amongst Product UX, Content UX and SME. Providing Product and Content support and business direction in resolving issues Product UX Product Interface and Interaction decisions, building product prototypes and wireframes Help with implementing content interaction and presentation rules. Work closely with LBU product team on Business and Functional Requirements Pspec and V-spec Team They used to be a separated team, but now they are all in one team. The Presentation Team is responsible for transforming the raw xml into the XHML that will be used by the application to display the documents. We also add metadata to support functionality such as breadcrumb trails, pagination, etc. The Blueprint requirements and UX provide the rules our team uses to create the our designs (Presentation Spec, Handshake and stylesheet design), View Spec and Stylesheets. We also work closely with the XPP and CSS teams to communicate the presentation rules. Handshake Document A handshake document is created/maintained by the App/Stylesheet team. It is created based on a baselined Presentation Spec along with the baselined mockups. It defines the constructs needed to transform the XML content into a structure that can be interpreted and acted upon by the Application/Web Development.

10. Content Styling Process Flow *Any interactive or functionality elements will be control by the GDS project Signal Hide/Show Comments buttons Hyperlinks Any icons (i.e. pdf, margin note…) Expand and collapse container Citator table Search review list RHS on the wireframes And many more…

11. We responsible Collaboration project combined with product and content Live Example Content Product Product (button) Product (hide/show box) Product Product (signal)

12. Collaboration Document View Page Collaboration Content UX Product

13. We responsible Document View Page Collaboration Content UX Product

14. We responsible Search result page Data only Collaboration Content UX Product

15. Purpose for creating UX mockup and wireframe A Primer on Samples to Stylesheets (1) Introduction This document is intended to guide content experts and UX resources in understanding the needs of Lexis Advance development teams in the proper selection and mockup of samples for use in conversion from Rosetta to New Lexis. It makes no special assumptions about the level of understanding of the reader, therefore some parts of this document may seem unnecessary to some audiences. This is meant to provide a baseline of understanding for the requirements and interrelationships from sample selection to Stylesheet development. Parts Definitions Sample: a real-world, not hand-crafted, example NL XML input document. These are provided by business/content experts. Requirements: a collection of functionality needs that has been gathered in a particular tool, BluePrint. These requirements are usually grouped (or “tagged”) by asset, and in the case of content, the asset is the content type (e.g. Cases, or Legislation-Acts, etc.). These can be business requirements (BR’s), Functional Requirements (FR’s), and/or Derived Requirements (DR’s) – the point of these is to guide the development teams in creation of the final deliverable, customer-facing searchable legal documents. These are provided by business/content experts, as well as by technical experts.

16. Purpose for creating UX mockup and wireframe A Primer on Samples to Stylesheets (2) Schema: a description of a type of XML document. It is the definition of the elements and attributes that documents can be fit into in such a way as to enable a variety of presentation, search and retrieval options. Schemas are developed and maintained by the Content Architecture group. Conversion Instructions (CI): A document that identifies rules to map content from a source XML document into a target XML document of different schema. These are provided by content architects, the owners of the schemas. Mock-up: a visual representation of what a sample would look like inside of the application if Stylesheets and presentation specifications were applied. These are provided by the UX team, and approved by content experts. Presentation Specifications (or “P-specs”): Explicit rules for how functionality and content should be derived from the sample. These are delivered either by content experts or application technical specialists who work closely with the business/content experts. View Specifications (or “V-specs”): technical rules to filter and organize XML. These are derived from the p- specs and delivered by application technical specialists. Stylesheets: presentation rules to translate documents from XML to XHTML. These are built by the Stylesheets team within the CS&R organization and are based on the v-spec, p-spec, mock-ups, conversion instructions, and converted content.

17. Purpose for creating UX mockup and wireframe A Primer on Samples to Stylesheets (3) Process Discussion The development process for delivering content has many sub-processes, and each has a varying degree of influence over other parts. To understand the complete process, you need to work backwards from the customer’s perspective – from the delivered content, to the functionality around that content, to the parameters that the content is delivered in, to the conversion of the content from its native format, to the architecture of the XML schemas, to the meaning of the content. To end with a product that totally meets the needs of the end-user community, we need to start with a good base of information. This base of information is the samples that are selected to drive delivery of mock-ups from!

18. Purpose for creating UX mockup and wireframe A Primer on Samples to Stylesheets (4) What makes a good list of samples? The following questions should be asked in order to determine a good list of samples to provide and generate mock-ups from for a given content type: Do you have a TOC? Do you have pagination? Do you have footnotes? Do you have block-quotes (something special) Forms? Tables? Links? (Right-side, embedded, intra-doc links, etc.) Jump-to navigation? Signals? Images? Special processing for print (any behavior that differs from display)? Copyright? Hover-over? Copy-Cite? If you can answer affirmatively to any of these questions, you need to produce a mock-up that represents that functionality. The same mock-up can represent multiples of these functions, so you could theoretically have 1 mockup that covers all of the above – the problem with that approach is that there rarely appear examples “in nature” that do that – so you should plan to deliver multiple mockups. If there is a question of whether a mock-up is required or not required, it is best to provide it (err on the side of caution). In the end, the better the selection of samples, the more accurate the presentation spec, which will result in a lower amount of requests for new mock-ups or revisions, and ultimately a more efficient and predictable process to generate Stylesheets that meet the objectives of the requirements provided by business/content experts.

19. Standardisation - In some cases we cannot apply the standard presentation rules across all LBUs, because of localization requirements and inconsistent mark-up elements Each LBU has different XML structure and mark-up Localisation (different product requirement) Getting response and decision from stake holders Locating the right person to resolve issue Tight deadline Lack of experience resources Product requirement can impact presentation Content presentation work often starts before product requirements are finalised Obstacles and challenges Content UX

20. Create high fidelity UX artefact and low fidelity wireframe document We must Understand business and functional requirements Pay attention to detail Write clean coding and following the HTML5 and CSS3 coding standards, so everyone can understand Do not use short cut or inline coding to compensate for quick fix on the UX. Review UX and wireframe with LBU, product manager and product UX teams before the UXR and wireframe review with bigger audience. Rules to follow Content Development Guide CSS3 Coding standards HTML5 Coding standards M OCKUPS H OUSE K EEPING M OCKUP C REATION C HECKLIST W IREFRAMES C HECKLIST Check list before internal review UX mockup and wireframe

21. The time estimation is based on senior level professional, also included time for research and preparation. Wireframe Research and understand business and functional requirements: 1 hour Create low fidelity wireframe document: less than a day work Creating UX mockup and wireframe Timeframe expectation

22. UX mockup (complicate and lengthy document) [difficult] Building from scratch: 1 day Rework to update styling to new content style: 4 hours Live example Creating UX mockup and wireframe Timeframe expectation

23. UX mockup (complicate and lengthy document) [difficult] Building from scratch: 4 hours Rework to update styling to new content style: 2 hours Live example Creating UX mockup and wireframe Timeframe expectation

24. UX mockup (complicate and lengthy document) [difficult] Building from scratch: 3 hours Rework to update styling to new content style: 2 hours Live example Creating UX mockup and wireframe Timeframe expectation

25. UX mockup (straightforward, but lengthy) [middle] Building from scratch: 2 hours Rework to update styling to new content style: 1 hours Live example Creating UX mockup and wireframe Timeframe expectation

26. UX mockup (straightforward) [easy] Building from scratch: 2 hours Rework to update styling to new content style: 1 hours Live example Creating UX mockup and wireframe Timeframe expectation

27. UX mockup (straightforward) [easy] Building from scratch: 1.5 hours Rework to update styling to new content style: 1 hours Live example Creating UX mockup and wireframe Timeframe expectation

28. M OCKUPS H OUSE K EEPING FOLDER STRUCTURE: 1.Folders must be organized for maintainability, without good folder organization, editors will not be able to maintain the site. 2.Always use underscore to separate between words (e.g. CA_Administrative_Decisions) SVN: 1.When using SVN, always update before you start working (right-click, and SVN Update), and always check in when you are done with your work, minimum once a day. 2.Send an alert email to the team members, you just committed or updated which files HTML & FILES: 1.Avoid bad habits such as inline styles 2.No BR ( ) in html Mockups 3.Follow naming conventions 4.Must follow XML labeling in HTML 5.All the HTML coding structure must mirroring or similar to XML mark-up structure. CSS: 1.No team member can commit any css files to the server, except project leads. 2.Whoever need to create a new style on css files. Must submit a request and the project leads will create new style for you. 3.CSS class labeling must be consistent and follow XML labeling, this makes it easier for others when editing mockups and referencing XML.

29. M OCKUP C REATION C HECKLIST MOCKUP: 1.Get all the latest LN XML from sources (Pspec, xml architects) and make sure you are working on the latest LN XML version 2.Check blueprint for Business / Functional Requirements (BR/FR) 3.Scan XML for structure, may differ for content types 4.Look at presentation rules for the new GDSI design (guidebook / PSDs) and match them with XML markup. 5.All mockup creation must true to the XML 6.Check markup and x-path structure on the XML. Can they supports the correct presentation rules 7.All mock-ups are purely visual, no links are supposed to work (including links to images/external sites). 8.Where styles repeat, we add paragraph ‘---(breaks)---’ into the PNGs to manage the overall length of the mock-ups. This will not affect the data or the final look and feel of the product. 9.Deliver good quality mockup: – Follow process rules – Consistency – Attention to details 10.Unsure / can’t find presentation rules: – Do your research Check Content Standardisation Guide (CSG) website Check the Pspec documents Check the resolved issue trackers (there maybe some presentation rules had confirmed without recorded on the CSG or Pspec documents Check other LBU mockup with the same content stream, they might have used that presentation rules After found the conclusion – must get confirmation from the content UX lead before taking any action – If you have any question, always ask content UX lead first before asking the team members 11.If we don’t have any specific GVS guidelines for the element, please discuss with content UX lead. 12.If needed to create new presentation rules for the element. Must consult and review with content UX lead, before implementing to the mockup. 13.After mockup created must pass to another team member for peer checking MOCKUP SEND OUT BEFORE WORKSHOP AND UXR: 1.For workshop - 1 day before 2.For UXR - 3 days before

30. W IREFRAMES C HECKLIST BLUEPRINT: 1.Go through all Blueprint requirements and check for Business / Functional Requirements (BR/FR) in details 2.Review Blueprint frequently as requirements are actively being updated 3.Check your wireframe if it is functional and matches requirements 4.If you are aware of a base lined requirement not up to date in the Blueprint, request update’s to be made accordingly. However you must verify with Team Lead before request. 5.Raise issue ticket - If the Business / Functional Requirements (BR/FR) are unclear or not enough information for building the wireframes 6.Be actively chasing relevant departments when gathering more information, if details in Blueprint is not clear or raises more questions. 7.Presentation preparation : where you have organized your wireframe in scenarios and sections A XURE : 1.Check if we have the latest wireframe from Source (focal person), if not request from the Product UX team if available HANDOUT PDF: 1.Create a PDF and annotate with BP references number and details of each BR/FR if necessary 2.All BP references number must linkable to the BP BR /FR location from the handout PDF 3.All data input must be based on requirement and data from your detailed research or provided by Product UX/LBU 4.Do not put random data that is not based on legitimate and relevant data HANDOUT PDF SEND OUT BEFORE WORKSHOP AND UXR: 1.For workshop - 1 day before 2.For UXR - 3 days before

31. Check list before internal review _____Check that mock-ups contain all NECESSARY INFORMATION (ie source name? breadcrumb? ‘up to date to’ information? page breaks?) Are things missing that you would expect to see? _____Check for (and alert us to) EXCESSIVE WHITE SPACE _____Check text for the presence and accuracy of HEADINGS; is the hierarchy correct? _____Check for the accuracy of LIST presentation; do list items at the same level align? Are sub-lists differentiated by indentation? _____Check for SPECIAL CHARACTERS/SYMBOLS _____Check that FOOTNOTES are displaying correctly _____Check that BLOCKQUOTES are recognized and differentiated from standard paragraphs _____Check that FORMATTING (bold, italic, underscore, superscript) has been used correctly _____Check TABULAR MATERIAL: crashing of text? borders/rules where they should be? _____Check ARTWORK and FORMS are present; size ok/do they fit to page? _____Check that elements are presented CONSISTENTLY across samples. If not, please detail how they should appear. _____Check new (NEW LEXIS) DESIGN ELEMENTS for typos/errors _____Make a GENERAL SCAN of the data; are any elements missing? Is anything repeated? Are things breaking over lines when they shouldn’t? _____Check the consistency mockup by mockup within the same stream, that don’t mean stream by stream, because each can apply different, even if the mark-up and X-path is the same. Depending on the LBU decision with agreement with standanisation and PSpec team NOTE: Please use Rosetta source files as a reference point when checking UX mock-ups. The creation of UX mock-ups is a manual process and, as such, inconsistencies and errors may appear in sample files. Please raise any problems you encounter. Certain design elements may differ from the existing Rosetta style; this is likely an intentional result of the creation of the New Lexis Style Catalogue. If, however, you are concerned that the display or placement of elements is wrong, or will cause usage or contractual problems, please raise this as an issue. By all means, please request design enhancements. However, some design elements will only be possible if the data supports them. Similarly, if you see a design element that you know the data cannot support, please raise this as an issue.

32. Introduction Workshop and UXR process Workflow Process: UX Mockup/Wireframe Reviews (1) INTRODUCTION In order to stabilize the process of developing detailed user-interface requirements and executing on those requirements in the Lexis Advance application environment, there needs to be a formal set of expectations and procedures that will make clear all of the proper reviews and due diligence have taken place prior to document handoffs. This document will explicitly indicate the expectations for the handling of documents as well as the procedures for performing the reviews. This will ensure some uniformity in delivery and allow all teams involved to deliver to the highest levels of expectation. UX Roles/Responsibilities Artifacts UX mockups will be static images (PNG format). They will be located in a version controlled SharePoint site and will go through a base lining process. UX may also create HTML mockups for internal reference or to demonstrate interactive functionality but the static images will ultimately outline desired layout/look & feel and should not be considered complete. Basic versioning is requested to help differentiate versions that match the baselined Mockups from “possible future directions”.

33. Introduction Workshop and UXR process Workflow Process: UX Mockup/Wireframe Reviews (2) Preparing for a review Mockups are to be made available by UX three business days ahead of formal review meeting in a specific designated SharePoint document repository (business days exclude holidays and weekends). In the process of creating these mock-ups, UX is expected to work with content architect and LBU to align with the scope of the project. Providing any change is made to the mock-ups during the three days (this should be an exception, not the standard practice), UX must notify related parties (LBU, presentation team, project manager(s)…) via an email outlining the changes. The team may decide to reschedule the review meeting should these changes be considered “substantial”. Substantial is defined as deviating from the originally understood and expected functionality or interface standards already set, and requiring more than 2 hours of research and/or development time to clarify or confirm the new direction. See bottom of this document for specific SharePoint location information. There should be a subdirectory set up for each specific content type; for example “CA01 - CA Case” – and inside each of these subdirectories will have another subdirectories of each document folder; for example “Perrier v. Daigle “ – and inside each of these folder will reside image files (PNG format) and NL XML for mockups as well as a Word document for wireframes. Each document will have a “Status” field filled in – during initial development; the status of each file should be In Progress-UX. Live example

34. Introduction Workshop and UXR process Workflow Process: UX Mockup/Wireframe Reviews (3) Formal Review Meeting Static image files are used as primary artefacts in review meeting. They may be accompanied by HTML files for clarifying more complex behaviour/interaction that cannot be captured by static images alone (but are not required – if provided, they must be consistent with the static images). When documents are ready for review, their status value should be changed to In Review-SS. At the end of the review meeting, the UX team could have a list of changes to make. If this is the case, the Stylesheets team will change the Status back to In Progress-UX and send an email notification to the UX team. A new due date is then agreed to for UX to have their final adjustments and address list of issues in the mock-ups (generally three days). When all fixes and adjustments are in place, mock-ups are marked by the UX team as status of Completed-UX and a confirmation email is sent out to the project team by the UX developer. Baselining If no further change is requested within three business days after mockups are marked as Completed-UX, their status will be change to Baselined by the LBU. From here further changes to the mock-ups will require a full change control process (Lexis Nexis Change Control Process, Change Control Decision Form ).Lexis Nexis Change Control ProcessChange Control Decision Form

35. Introduction Workshop and UXR process Workflow Process: UX Mockup/Wireframe Reviews (4) Additional mock-ups When additional mockups are requested post-baseline, they are expected to fall into one of three types: 1.Adjustment impacted by the business — Require change control 2.Presentation Spec supporting materials (identified new elements and need presentation rules)— typically requested by the Stylesheet team for clarification purpose. Doesn’t require change control. 3.Adjustments impacted by markup conversion — certain elements may need to be handled differently as a result of the conversion process. Less likely to require change control (see CC decision form) In any of the above cases the Stylesheet, content architecture, presentation spec, and engineering teams must be notified of the additional mock-ups. Through a desk review, the team will work through the decision process for whether or not the changes warrant a change control request. All the additional mock-ups request will raise through issue logissue log

36. UXR W ALKTHROUGH G UIDELINES W EB E X CONFERENCE PRESENTATION : Make sure you have prepared well in advance XML and Mockup should be ready for presentation Keep screen clear only relevant document should be displayed while presenting Listen. Pause. Pause. Talk… this gives you more time to answer question if it’s relevant to you Not all questions is for you to answer, ask who the question is for if you are not sure No unnecessary mouse movements as this causes distractions for others Do not do live correction of Mockups while in presentation Take note’s while in a WebEx meeting If there is a incorrect information / or mistake presented on the wireframes or mockup, never try to explain how that happen or name the person who gave that information – just say –I will make a note of it and amend it after the call –I will look into it and amend it, then I will review it on the next workshop/UXR

37. Introduction Workshop and UXR process Team 1Team 2 UX MockupWireframes BRs/FRs Visual Design Assets XMLs Internal briefing Create mockups and wireframes Peer checking Amendment Mockups and wireframes ready Workshop 2 Issue Resolution Raise issues and update mockup and wireframes Workshop 1 Issue Resolution Raise issues and update mockup and wireframes Mockups and wireframes ready UXR 2 Issue Resolution Raise issues and update mockup and wireframes UXR 1 Issue Resolution Raise issues and update mockup and wireframes Mockups and wireframes signed off OSR *Continue to next slide

38. Introduction OSR process OSR 2 Issue Resolution Raise issues and update mockup and wireframes OSR 1 Issue Resolution Raise issues and update mockup and wireframes OSR OSR documentation Publish Final OSR documentation

39. Presentation Process – 5,000 Feet View Requirements Converted xml UX/Wireframes UX workshops & UX Reviews P-spec P-spec Review View spec StyleSheet Data / UX Analysis Conversion InstructionData Remediation Conversion Programming Testing Issue Identification / Resolution Sync Requirements, Converted xml content and UX mockups / wireframes LBU GTO-CAUX Presentation 39 UX, LBU, CA, Presentation teams

40. Who does What (Roles) Full-Content Data Delivery Architectural Analysis Conversion Presentation Analysis Presentation Development TestingRelease LBU Pre- Processing Data Receipt ConversionFabrication Loading to ML Iterative Content Development– How it works with groups and owners Data Preparation for Production – Who is responsible for each part Original UX mockup Final UX mockup FTK ICCE FPD FTP Loader LBU GTO-CA GTO-CEUX Presentation GTO-Fab Pipeline GTO-CS&R Approval Setup 40

41. Presentation Flow 1.Presentation team participates in requirements elaboration, tagging and POF discussions related to presentation requirements 2.User Experience creates product wireframes (results list view) and full document UX mock-ups. The wireframes/UX mockups contain sample documents defining the desired display of the content and are used by the presentation team to define the presentation deliverables 3.Converted Content to LA Schema needed to explicitly define the xpaths to create the desired presentation 4.Presentation Spec is a Design Document that describes how to apply product and wireframe/UX requirements to the data to achieve the desired display 5.View Spec is an XML document used to generate the display of content in the Lexis Advance App. The view spec is stored in MarkLogic and consumed by Content Search & Retrieve 6.Stylesheets – XSLT document; stored on Network file system; consumed by Content Search & Retrieve

42. Pro-active Communication Collaboration Work as a team, not solo unit Transparent Style guide Our goals Content UX