Web & Mobile. Application Branding & User Experience Guide V 3.6. v3.2

Transcription

1 Web & Mobile Application Branding & User Experience Guide V 3.6 v3.2

2 Table of Contents Introduction... 4 Grand-Fathered Applications... 4 When to Involve Web & Mobile... 5 Key Stakeholders... 5 Related Documents... 6 Requirements Checklist... 6 Branding Requirements ()... 7 Browser Compatibility... 7 Screen Resolution... 7 Browser Window/Tab Management... 7 Header... 8 Navigation Global Navigation Drop Down Behavior Local Left Navigation Utility Navigation Search Breadcrumbs Footer Google Analytics Tracking Code Login/Logout Login Logout Page Design/Layout CSS Font Multimedia Video: Audio: Images: Document & Download Icons... 15

3 Table of Contents (continued) User Experience Guidelines (Optional) Page Design/layout Forms Text Box Radio Buttons Check Boxes Drop-down Box Buttons Tables Charts and Graphs Maps Feedback Application Response Time Page Load Times Accessibility Change Log... 19

4 Introduction This guide exists to provide guidance to software designers and developers working on EPRI web application projects and web properties. The use of these guidelines and standards will help maintain EPRI s brand identity and provide a unified customer experience for internal and external customers. The points laid out below should be applied to all web properties and applications, with express permission provided for any variances from standards. Every application developed for, or deployed on the behalf of, EPRI must adhere to the required standards within this document. Requested deviations will be reviewed on a bi-weekly basis by the Web & Mobile leadership team. Non-compliant sites and applications will not be released to a production environment until compliance with these guidelines are met or exception(s) are made to approve the variations. This guide, and the information contained herein, is managed and maintained by the EPRI Web & Mobile group. Other referenced materials are own respectively by their creators. Grand-Fathered Applications Applications developed before the first version of the brand standards were released in October 2010 will be given some latitude in complying with the full set of requirements. If an update is made to the application, the application team should move toward full compliance with these standards and guidelines wherever possible, but are not required to do so. The original release date of your web application determines the applicable standards version: 1. Re-launched Web Applications First Release date is prior to October First Release date is after October 2010 Applications submitted for initial Digital Solutions review in 2011 may use either the original standards or the new web application version. Applications submitted after 2012 must use the new web application standards. Please refer to the requirements checklist section to identify which standards your web application must adhere to. Applications will not be permitted to enter production environments without approval from the EPRI Web & Mobile group.

5 When to Involve Web & Mobile The Web & Mobile group reviews all web applications for standards compliance as part of the BETA and pre-production process. However, the earlier in the development process you involve us, the earlier we can provide feedback and help avoid any last minute delays once the code is complete. As the work becomes completed send screenshots, wireframes, or a link to a build of the application on the development server. This will allow us to give feedback early in the process and save rework. From the review, the Web & Mobile group will provide feedback based on the following categories: 1. Changes: Must be met in order for the web application to enter production 2. Recommended Changes: Usability/User Experience Enhancements 3. Notes/Observations: Unusual or unexpected behavior of the web application **The Web & Mobile group may attach sample mockups to the feedback, if applicable When your web application has been approved by the Web & Mobile group, a notification will be sent to the Security and Software Assessment Services (SSAS) group referenced in your project documentation. When you are ready to involve the Web & Mobile team, please contact: Bing Xie Web & Mobile Program Manager (704) bxie@epri.com Key Stakeholders The Software Security Assessment and Business Applications team in Information Technology are critical stakeholders in the development and release of all web applications at EPRI. If you have questions about engaging the teams, please contact: Manuel Morales Software Quality Assurance Manager (650) MaMorale@epri.com

6 Related Documents The Web & Mobile group maintains this document and a complete set of HTML template files on the Member Experience website at (employees only). These files may freely be shared with a vendor who is working on the behalf of an EPRI initiative. Additionally, all efforts should ensure that they are meeting the general guidelines outlined in the latest EPRI Graphic Identity Standards. The contents of this document should be seen as web specific extension of those guidelines Requirements Checklist Use this table to determine which requirements are applicable to your web application. Re-launched web applications First Release date is prior to October 2010 First Release date is after October 2010 Standard Re-Launched Web Application New Web Application Browser Compatibility Screen Resolution Optional Window & Tab Management Optional Header EPRI Logo Application Title Welcome Message If applicable If applicable Background Color Navigation Global Navigation Optional Drop Down Behavior Optional If applicable Local Left Navigation Optional If applicable Utility Navigation Search If applicable If applicable Breadcrumbs If applicable If applicable Footer Login/Logout CSS Optional Font Page Design/Layout Multimedia/Images Document & Download Icons User Experience Guidelines Optional

7 Branding Requirements () All web applications must adhere to their specific requirements (re-launch vs. new) listed in this section. Browser Compatibility Browser compatibility standards are non-negotiable, regardless of the standards definition that is applied to your application. Both and must meet the following minimum browser requirements. All EPRI web applications must be fully compatible with: Internet Explorer 8.x and higher Firefox Current version Chrome - Current version Re-launched Web Applications must be follow compatible with: Internet Explorer 7.x and higher Firefox 10.x and higher Chrome - Current version Please note, applications for Mobile must clearly document the supported operating systems (ios 4.x/5.x Android 2.x/3.x/4.x etc.) and platforms phone/tablet. Mobile applications should also clearly specify the optimal display dimensions, orientation(s), and/or form factor. Screen Resolution Optional The recommended resolution for web applications is 1024 x 768 and higher. Web pages should not scroll horizontally at this resolution or higher. The maximum displayed content at this resolution should be 980 pixels to accommodate for the browser s scroll bar. Responsive or Adaptive scalable layouts should conform to the web browser s viewport size. The content region of such layouts does not need to consume the entire viewport area. Web pages may scroll horizontally on monitors with a screen resolution of 800 x 600 or less. In these cases, the site should remain usable and navigable. Resolutions at or above 1024 x 768 should not require a horizontal scrollbar at any time. This includes during load, during transition between pages, or due to animation within a page. Appropriate CSS overflow control should be used to negate any potential problems in this area. Browser Window/Tab Management Optional The use of pop-up and modal windows is highly discouraged and should be reserved for cases where no other solution is possible (i.e. inline help). An in-page modal should be used wherever possible. If a link opens in a new tab or pop-up window, it is not allowed on the primary navigation and must be placed within the page content area (preferably in the same location on each). Links leading out of a site or application should be designated with the approved icon and open in a new tab/window.

8 Header Maintaining consistent placement of page header elements is important so that users can easily recognize, navigate, and understand their current location within a site structure. The guidelines provided in this section should assist you in creating interfaces that are both instantly recognized and easy to use. Please review the sections listed for specific details on the requirements for your application. There are 6 basic elements that make up the current EPRI global header. EPRI Logo Application Title Welcome Message Global Navigation Elements Utility Navigation Elements Search Functionality Welcome Message EPRI Logo Application Title Utility Navigation Breadcrumbs Global Navigation Search Functionality

9 EPRI Logo In applications and on websites EPRI primarily uses the Full Color Blue & Gray EPRI Signature referenced in the EPRI Graphic Identity Standards. The Graphic Identity Standards can be found on InsideEPRI at: To ensure that the logo is recognizable, readable, and visually effective, it must be of a certain size and location on your website. The following guidelines should be followed when using the EPRI logo. 58 px 258 px Standard Logo size is 258 pixels x 58 pixels Do NOT resize, scale, skew, or otherwise distort the approved logo The logo has a horizontal configuration. No other configurations are allowed The logo must be placed in the top left corner of the header with padding of 10 pixels all four sides of logo The logo is to be vertical aligned middle within the space allowed for it in the header Always treat the logo with respect Incorrect Use of Logo Do not scan it Do not recreate, skew, or otherwise distort it in any way Do not obscure, overlap, or partially cover the logo with other objects Do not combine it with another symbol, artwork, or logo Do not attach it to any product or business name Limit its use to one logo per page The EPRI logo was created to work best as a simple, two-dimensional design. Three-dimensional effects are not supported at this time. Do not put a border around the entire logo The EPRI logo should always stand alone. Business, product, plant, or location names should not attach to the EPRI corporate logo. For any question involving the logo, usage, branding, co-branding, or general display, please contact: Jeremy Dreier Sr. Corporate Communications Manager (704) jdreier@epri.com

10 Application Title Title placement should be in the right corner of the header Title should be vertically aligned middle in the header Welcome Message If applicable If applicable Welcome message should say Welcome First Name Last Name Placement should be in the top left corner Background Color All header background colors should be white to support the corporate standards and colors of our logo. Navigation Navigation links are reserved for moving within the current application only Avoid relying on the basic web browser navigation controls (back and forward) Use labels and concepts that are meaningful, understandable, and easily differentiated by users Global navigation elements should always be located at the bottom of the header If applicable local navigation items can be placed in dropdowns from the global navigation items, as a vertical list on the left side of the page, or a horizontal list on the top of the page Global Navigation Optional A represents the Selected state of a global menu item. B represents the Hover state of a global menu item C represents the Normal or Default state of a global menu item The following sections describe different acceptable navigation schemas. The selected schema must remain consistent throughout the web application. If necessary, components may be mixed and matched to meet the needs of your users. For example - local left navigation with drop downs from the main navigation.

11 Drop Down Behavior Optional If applicable A represents the Hover state of a drop down menu item. B represents Normal of Default state of a drop down menu items Usage: Only display level 2 menu items Do not use a drop-down menu if the menu length is would be excessively long Activation and Deactivation of the menu should be based on user intent and should not activate immediately upon the cursor being moved across the menu. Appropriate event timing delays should ensure that the menu does not flicker, open to slowly, or close too quickly. The menu should be fully Accessible following the W3C WCAG 2.0 Guidelines. Local Left Navigation Optional If applicable A represents the On state of a level 2 menu item. Once a user has clicked on the link. o The link becomes Bold and changes color to identify this is the page or category you are now visiting. B represents the Normal or Default state of the menu items C represents Level 3 links ALL links in the local left navigation use underlined text as the Hover state, while maintaining all of their existing user interface properties and should use the pointer cursor ( )

12 Utility Navigation Placement is in top right corner of the header section EPRI.com should always be included and hyperlinked to Logout link should always be included and point to All links should be separated by a visual pipe, but the actual character or character entity should not be used due to the impact on Accessibility. Consider using a border or background graphic positioned appropriately. Search If applicable If applicable Should be placed in upper far right corner below the global navigation bar Search Button should be a standard browser button Breadcrumbs If applicable If applicable If appropriate, the application may use breadcrumbs below the header. Should be located under the header section, above the general content, and should be aligned with the left most column or gutter The Breadcrumb introduction, You Are Here: should be bold. Use a visual carat symbol > between pages/levels, but do not use the actual character or character entity for Accessibility reasons. Consider using a border or background graphic positioned appropriately The active link sections between the introduction and the current page should be links and should use a standardized link color, an always-on underline, and should have the same font-size as the rest of the breadcrumb area. The last portion of the breadcrumb should be maintained as link, should be bold, and should share the color and font treatment as other breadcrumb sections. The exception is that it should not show an underline when a user hovers over it. The link should be maintained for search engines and Accessibility reasons.

13 Footer The EPRI footer is required on every page within the web application. The footer is global to all EPRI websites and should be inserted as an include file. If you are unable to insert it as an include file then go to the link provided below and recreate it exactly as is for your web application. Path to include file: Address Block, Copyright, Policy Links are to be used at the footer of website. The copyright statement should be placed under the address block in the footer on all EPRI web pages. Protect our intellectual property and publications by including the copyright symbol and statement on them. The copyright indicates that EPRI owns the rights to the materials and that we have exclusive rights to control their distribution and use. Google Analytics Tracking Code In order for us to track activity on your site and provide you with metrics, the following code will need to be inserted in the footer on each page. <!-- BEGIN GOOGLE ANALYTICS CODE --> <script type="text/javascript"> var gajshost = ((" == document.location.protocol)? " : " document.write(unescape("%3cscript src='" + gajshost + "google-analytics.com/ga.js' type='text/javascript'%3e%3c/script%3e")); </script> <script type="text/javascript"> var pagetracker = _gat._gettracker("ua "); pagetracker._setdomainname("epri.com"); pagetracker._initdata(); pagetracker._trackpageview(); </script> <!-- END GOOGLE ANALYTICS CODE -->

14 Login/Logout Login Access to the application must be controlled through EPRI s OAM access management software. Please contact EPRI s IT department for more details regarding OAM. All web applications must redirect users to to login to the web application. Logout All web applications must contain a logout link located in the utility navigation area of the header. The logout link must redirect users to Page Design/Layout The specific page layout and design will be decided by the Web & Mobile team The page layout, whenever possible, will use the existing page layout patterns to maintain a normalized structure and appearance of EPRI web properties Every page is required to have a title Page titles will be left aligned Page titles, section headers, and labels should be stored in title case o Do not use all capital, camel case, or all lower case letters o Styling of the text will be accomplished using CSS Do not underline text, underline is reserved for hyperlinks only CSS Optional Consistent use of a style sheet visually reinforces EPRI s brand by providing a consistent look and feel throughout our web applications. For future compatibility, we suggest using CSS 2 and CSS 3 for use within you application(s). Path to default CSS style sheet: Zip file of Demo: Font Using a limited set of typographic fonts provides branding support by consistently displaying text throughout our web sites. All text should be displayed using the Arial font face, with a fall back to a default Sans-Serif font on desktop applications. For the best system integration and performance on Mobile Web devices, the device optimized version of Helvetica Neue and Roboto will outperform and be more legible on small-screen devices. For mobile web applications, the font cascade should be Helvetica Neue, Roboto, Arial, Helvetica, Sans-Serif.

15 Multimedia Video: Preferred solution: HTML5 (<video>) + <object> + <embed> o Accepted fallback platforms: Adobe Flash Microsoft Silverlight 5 Streaming from YouTube is permitted o Video must be uploaded to the EPRI YouTube channel Engage the EPRI Web & Mobile team for assistance o Note: Videos must be publicly available to be utilized in this way Audio: Preferred solution: HTML5 (<audio>) + <embed> o Accepted fallback formats are MP3/MP4 o WAV and WMA formats should be converted to MP3, whenever possible Images: Image file sizes should not exceed 50K All images should have alt tag definitions All images should have their width and height properties set within the HTML Images resolution should be 72 DPI, or higher for specific targeted solutions Accepted formats are JPEG, GIF, PNG, and SVG Thumbnail images should be 90px width, auto height, and 3K or less in size All images should have their embedded meta-data removed from the file prior to publishing to the website All images should be losslessly compressed prior to publishing to the website A service like Kraken.io can be used to help automate the process Document & Download Icons Icons should be use when documents are linked for direct download. It is highly discouraged to have popup windows, however, if required. The open in new window icon is required. Icon Set: (11px X 11px) Adobe Acrobat Microsoft Outlook Microsoft PowerPoint Microsoft Excel Microsoft Word Open in New Window

16 User Experience Guidelines (Optional) The guidelines in this section are not required, but should be taken into account with every project. They are a list of usability and web design best practices that will create a more satisfying user experience for your users. Page Design/layout Make it obvious what is clickable and what is not Use headings that are unique from one another and conceptually related to the content they describe Do not use all capital letters or all lowercase, use sentence case Use link labels and concepts that are meaningful, understandable, easily differentiated by users, and inform the user where they are going Forms Distinguish clearly and consistently between required and optional data entry fields All data entry fields need to be clearly and consistently labeled, labels should be left aligned Do not require users to enter the same information more than once unless needed for verification Use tabindex only if the logical order of the form dictates it Leave all data fields blank when the page first loads o An exception to this is when placeholder text will better explain the information needed o Only use the placeholder attribute, do not use JavaScript alternatives. Group related fields together For dates use a calendar popup overlay and auto-format the selected date (DD-MON-YYYY format) Labels should be used for very form field. Labels should be linked to the target field to enhance Accessibility and Usability Text Box Width should be kept relevant to expected user input Provide example format of input, using the placeholder attribute Provide max character restrictions Label should come before the text box Except for passwords, always display the users entries as they type them Do not inhibit the use of keyboard accelerators o Cut, Copy, and Paste Radio Buttons Text description must follow the radio button Should not be used for Boolean options Should have a default selected value Grouping label should be used and should target the default field Use a minimum of Two Radio Buttons at a time Click on the button or its text label will activate the selection Check Boxes Can be used for Boolean options Text description must follow the check box Each checkbox should be able to be selected independently Click on the box or its text label will activate the selection If appropriate select the most likely choice by default

17 Drop-down Box Used when there are multiple options but users can only choose one Label should come before the drop-down Options should be grouped in option groups when a hierarchical nature exists The default selection must be the first item within the list Buttons Ensure that a button s label is descriptive and clearly indicates its action Submit buttons should be disabled until all required fields contain data Make the most frequently used button the default action, which is activated when the user presses the enter key Show the buttons in this order: OK (or OK equivalent) Cancel or Clear (or equivalent), Any other button(s) Help if help is available for the form. Use buttons for primary actions Ok Submit Etc Use links for secondary actions Clear Cancel Reset Etc Keep buttons separate from data input fields Repeat command buttons at top and bottom of input form, if the form is larger than the viewport Tables Tables are for tabular data and should not be used for layout, spacing, or other utilitarian needs Provide a descriptive heading for each table Ensure that tables have clear, concise, and accurate row and/or column headings If tables are long, consider the use of pagination and display the number of records that are showing and total number of records (1-20 of 200) If table headings are sortable provide cues to the user (visual carrot) Provide users with the ability to export data into standard file types (.pdf,.csv) Provide filters to help users reduce the amount of possible matches o Search / Filter results Charts and Graphs Include units of measurement on all charts and graphs Provide meaningful titles and axis labels for charts and graphs Use standard scaling practices for charts and graphs Include a key with each graph Do not clutter charts and graphs with useless information Only display what is important Use interactive graphs with filtering and querying Only if the data warrants it

18 Maps Use vector maps to show points, lines, and areas Pick appropriate symbols for points Use raster data for continuous images and photos Use appropriate scaling techniques Separate information using layers Pinpoint locations by latitude and longitude Provide a legend, Compass Rose (north arrow) and a scale bar Provide tools for zooming, panning, and centering Feedback Feedback promotes a users confidence in their ability to negotiate and manage the application, and in the underlying functionality that supports their every action. Feedback must be provided in case of system failure Error messages should be clear, precise, and help the user solve the problem Error message should be polite, not intimidating, and should never blame the user Error messages should list the missing fields or pieces of data needed to successfully complete the action Application Response Time Application and web page response time are an important factor. Decreasing response times and load times can greatly enhance a user s experience with EPRI and can also directly impact the SEO ratings of EPRI s web sites. The table below identifies the three important limits to application response time. Time (seconds) Description UI Element The limit for having the user feel that the system is reacting None, display result instantaneously The limit for the user's flow of thought to stay uninterrupted, even Busy Mouse cursor though the user will notice the delay. 10+ The limit for keeping the user's attention focused on the dialogue. Users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Percent-done progress indicators Page Load Times Fast page load times are a key element to user retention on your application. The table below identifies types of pages and what their preferred load time should be. Page Type Description Load Time Content Pages This type of page just contains static content < 3 seconds / Not including marketing or social content Data Heavy Pages This type of page contains rich interactions, displaying data from a database, querying data from a database, or the use of multimedia 5 seconds average / may not exceed 10 seconds

19 Accessibility By following accessibility guidelines content will be more accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general and may have the added benefit of being more search engine friendly. It is recommended that all EPRI web applications should conform to Level A of the W3C Web Content Accessibility Guidelines (WCAG) 2.0. Change Log 10/2010 Version 1 released (Initial baselines and standards) 10/2011 Updated header requirements and templates 07/2012 Version 2 released (Complete version) 08/2012 Added Google Analytics Tracking Code 09/2012 Updated font color for content class to #333 10/2014 Removed epri.com from breadcrumbs example 06/2015 Version 3 Initial Draft (Updated baselines and formatting) Content and formatting refresh Typographical mistakes corrected Updated browser standards Update sections to modernize language Update sections to make the points for directed UX Guidelines now required for New Applications