Rice 2 2 KRAD Topics for Collaboration Call

Rice 2. 2 KRAD Topics for Collaboration Call 4/9/2012 Candace Soderston, csoders@uw. edu

What we’ll cover today • Introductions & Roll-call -- Candace • Update on Rice plans (2. 0 available since the last meeting on Feb 13), 2. 0. 1 is available, 2. 1 coming up, then 2. 2 -- Jessica • 2. 1 and QA status – Matt • 2. 2 requirements update & walkthrough -- Candace • Validation Messaging • Online Help • Rich Lightbox and Question framework • other • Update on current collaboration topics and opportunities for Rice 2. 2 KRAD – Jerry / Candace • KRAD Developer-User Group meetings and training • Every other Monday at 2 pm EST (led by Jerry Neal), with the next one on April 16 th. This is a great opportunity to learn and ask questions related to developing applications with KRAD. If interested, join through KIS (KRAD User Group mailing list page). • Other topics? - All • Other Questions or Requests for future meetings? -- All 2

Rice 2. 2 KRAD requirements update 1. Validation Messaging 2. Online Help 3. Rich Lightbox and Question framework 3

1. Validation Messaging – Rice 2. 2 KRAD Strategy • User submits complex form (after field-level client-side validation, if any, is done). • Application finds validation problems in multiple fields on the page, across sections of the page. • At top of page there is a page-level summary of validation messages - focus is placed here when the application returns after a submit with validation problems – the summary includes the # & type of errors & other messages in each section, not the full message text. • User can jump directly to any of the sections that have messages, because each section in the summary is marked up as a link: • If there are section-level summaries, the focus(link) moves to the section’s summary, and from there the user can jump to any of the fields. (this is recommended) If there are no section-level summaries, the focus(link) moves to the header of the chosen section. (Application can implement w/o section summaries but this is not recommended) • The page level and section level headings are appended with the # of errors & other messages. • The user can get back to the page-level summary using standard shortcuts for moving to top of page (or we could create a custom global shortcut). 4

Validation Messaging – Scenario Review • Example page-level summary, with heading text-variable filled in: <h 2 id="page. Summary. Heading" class="error. Summary. Heading">17 errors in form submission</h 2> • Example group and field-level error messaging: • Error state indication is placed with the field – see icon and field visual treatment. (Helps low-vision & all users!) • Error text is placed in section-level summary above the section’s fields AND placed in an error tooltip. The tooltip appears contiguous with the field when the user hovers over and when the field is selected. Try out the behavior in a sample code implementation here! 5

Validation Options topic a – Display list(s) By default in Rice 2. 2, KRAD will display validation messages in summary list fashion at the page-level, not the text of each message: • • You also have the option to have section and/or sub-section level summaries. The text of each message is displayed only in the tooltip and in the list of the nearest summary – e. g. , in the sub-section list if there is a sub-section summary. If there are multiple messages on a single field, only the highest severity message text is displayed in the summary list, with a “+ 1 warning” or “+1 warning and +1 informational message” (if there is an error and a warning and an informational message associated with the field). The text of all messages associated with a field are displayed in the tooltip on hover/focus on that field: Other Potential Options: • Turn off the list item summarization –instead display the text of all messages in the summary lists. • Turn off the display of summary lists (instead, display messages only with their fields). 6

Validation Options topic b – display tooltip By default, in Rice 2. 2, KRAD will display validation messages in a tooltip when user hovers or focuses on the field in question (in addition to displaying in the summary lists). KRAD will also support the option to turn off the tooltip display. In that case, the current plan is that the message will be displayed inline in the form beneath the field, between the field any associated constraint text. Other Potential options: • Turn off tooltip display of messages with their fields -- instead display the message text inline beneath the field • Turn off tooltip display of messages with their fields -- instead display the message text only in the summary lists 7

Validation Options c – display field labels By default KRAD will display the field labels in the section (or sub-section) level summary lists, along with the validation message text: • • • Address: Error message text is here Phone Number: Warning message text is here Inventory: Informational message text is here • Some Kuali applications include the field label in the text of the messages themselves: Other Potential options: • Turn off the display of the field label in the summary listings of the messages 8

Validation Options topic d – use validation titles There is an option in Rice 2. 0 KRAD to include a validation message title with each message. Questions: • Do you use a validation title parameter in your validation messaging today? • We’re planning to eliminate the validation title parameter in Rice 2. 2 KRAD, as it is redundant with the auto-summarization KRAD provides (covered in previous slides). If you foresee problems due to this, please supply an example scenario. 9

Validation Options topic e – granularity of control In most cases, would you want to control these options at … (which levels … ? ): q At the application level – consistent user experience across pages, sections, and fields. q At the page level – consistent user experience within each page, but different experience supported across pages. q At the section / subsection level – consistent user experience within each section / sub-section, but different experience supported across sections /subsections on page. q At the field level – change on each field - no consistency ensured – different experience supported across and within all levels of fields. 10

2. Online Help – Current UI Challenges o Student-facing applications need “just-in-time” self-service help: § Students want to “learn by doing” – they don’t have time to read a users’ guide. They actively explore, looking for relevant task-specific 'nuggets' of information (in tooltips and other) when they use a new application or infrequently use it. § Applies also to IT and BA-facing applications that can't assume a steep learning curve or external, scheduled training for infrequently performed tasks. o Long-term goal: applications provide context-specific online help: § Field-level help § Section-level help § Page-level help § View-level help 11

Example a – Other Visible ‘Help’ already in Rice 2. 0 KRAD: KRAD makes it easier to associate "visible” context-specific information with input fields: • Instructional text • Constraint text • Watermark in the input field (or pre-filled with a valid default) • Auto-complete behavior (recognition/typeahead - suggest). Other visible information in KRAD today: • Styled explanatory text can be provided anywhere it is needed (top of page, beginning of section, etc. ) KRAD and KNS: • “Requiredness” indicator (*) • Drop-down control that enables the user to select from a valid set of alternatives (not shown) • Other controls, such as a lookup or inquiry icon, to the right of the field (not shown) 12

Example b – What Applications do today Help icon in KNS (see example) Opens new browser tab Applications open to context-specific information within the application-level help: Applications open to document type-specific information: 13

Coming in Rice 2. 2 KRAD – Context-sensitive Help Tooltip Example simpler tooltip – concise text … Example richer tooltip • • • Help tooltips appear on hover (mouse) and on focus (keyboard) on field label and section header Information tidbit 1 Information tidbit 2 Link to additional help information in separate browser window • Supported on controls, field labels, headers 14

Coming in Rice 2. 2 KRAD – Help icon – new window • Launches a new browser window (not a tab) – user can view simultaneously, doesn’t lose their task context • Opens with a default window size and placement relative to the application window • User doesn’t have to be on same server as the help (can go to any external URL). Supports linking to Confluence wiki, docbook, doc-to-help, and other web content repositories. Try out the behavior in a sample code implementation here! 15

3. Rich lightbox and question framework • In Rice 2. 0 KRAD - A modal dialog with a simple user-response set 16

Improvements requested for Rice 2. 2 KRAD Support for richer lightbox content & interaction • HTML and CSS styling: • • • fonts layout background images semantics (labels, titles, legends. Alt-text) • Multiple fields: • • Radio buttons Checkboxes Dropdowns Text input fields • Dynamic sizing: • Lightboxes that grow or shrink dynamically in order to accommodate changing contents • Declarative, conditional logic • (Note: Keyboard support and Browser Back/Forward support to be determined in other 2. 2 reqs) Additional information: Kuali Rice 2. 2 Requirement 17

Example Scenario from Kuali Student • Rich styling • Dynamic sizing: Lightboxes that grow or shrink dynamically in order to accommodate changing contents • Progressive disclosure: Declarative, conditional logic 18

Example Scenario from IRB • Dynamic sizing • Progressive disclosure: Declarative, conditional logic • Question results returned to application: 19

Q&A Other comments / critiques? 20