Killing Mobile Apps with the Mobile Web: Of Portals, and *Scouts, and User Research Tom Lewis, Director Academic & Collaborative Applications

PART 1: UW AT YOUR FINGERTIPS

Problem Statement While there are many valuable resources available to campus, finding and discovering these resources is a persistent problem for students, faculty, and staff. The mobile context magnifies this problem, as not all campus resources are mobile friendly.

THE PAST Inconsistent UX for UW from mobile device. Problematic third-party m.UW native app. Poor central support for campus mobile development, resulting in a well-intentioned but ill-equipped mobile app craze.

Inconsistent UX m.UW native appm.uw.eduResponsive uw.edu THE PAST

m.UW Native App m.UW native app THE PAST Forced mobile web apps into m.uw wrapper, diminishing usability and defying expectations for native apps. A limited and inconsistent view of UW resources. No context, and same resources for everyone.

Mobile Development Support THE PAST Campus mobile app craze, but a lack of expertise. No central support or guidance. No strategy for mobile app promotion, publishing, or ownership. Limited influence on the UX, accessibility, development, or branding of UW resources.

THE NOW Goodbye m.UW. Hello, Mobile UW! Central management of m.uw.edu, mobile.uw.edu, and uw.edu/mobile urls (all point to the same place). Mobile UW developer resources. Clear guidelines, strategy, and process for inclusion in UW native app stores

Mobile UW Web App MOBILE UW THE NOW Mobile-first, adaptive web app. Promotes discovery and findability of critical campus resources. Contextualization of resources for device. Robust API available to campus allows campus developers access to resource list w/ metadata.API

Mobile UW: The Technology MOBILE UW THE NOW Device optimization through adaptive progressive enhancement. Front-end performance optimization, including removal of render blocking css/js.performance optimization Using Git flow and Travis to continuously test code quality and a11y. Front-end code is semantic and accessible.

Mobile UW Dev Resources Building Mobile Apps THE NOW Curated resources for development: Best Practices (Dev & UX) Fundamental Concepts Technologies Guidelines/Process for UW store inclusion. Help with UX, development, A11y, or marketing.

THE FUTURE Iteration on Mobile UW, UW Scout … and beyond!

Mobile UW Iteration THE FUTURE Add authentication, allowing for us to customize “featured” resource lists to specific campus affiliations. Support more robust searching and browsing for non-“featured” resources. Continue to develop API to allow for more specified delivery of personalized content.

UW Scout THE FUTURE SpaceScout for finding study spaces is great, but what about findability/dicoverability of other campus physical resources? (food, equipment, …) SpaceScout + FoodScout + ResourceScout = scout.uw.edu = ONE destination for campus.

UW Scout Strategy THE FUTURE SpaceScout codebase unsustainable & inflexible. SpaceScout used separate iOS native app + web app approach. Have to keep two totally separate codebases up-to-date.iOS native appweb app SpaceScout Server flexible enough to accommodate new scope. Let’s build on it, learning our lessons from past mistakes.

UW Scout Technology THE FUTURE Hybrid approach. HTML content layer wrapped in very thin layer of native code (ex: Stacker).Stacker Content layer is reused across all platforms. Native code layer provides appropriate native context, feel & behavior. Hits sweet spot of native behavior, reusable code, and my shop’s expertise (Html/Python apps).sweet spot

Questions?

PART 2: THE MOBILE (NOT A) PORTAL

About MyUW Main portal for students, faculty & staff. Requires login. Decade-old design & code.

Rebuild Goals Better meet user needs through user research, user- centered design, and agile development. Replace old portal technology. Responsive, mobile first design.

User Research Evidence-based, user-centered design: Design iterations Diary studies Focus groups Interviews Log data analysis for MyUW and UW.edu Surveys Usability studies

Key Research Areas Goals students had for UW career How goals changed over time How day-by-day progress is made Information needs to support progress Use of information resources

Goals and work are date-driven and time-sensitive, yet time management can be difficult. Key Research Finding

They suffer from information overload, yet critical information can be hard to find.

Key Research Finding Students primarily access a small subset of MyUW content, but what they do use, they use frequently. Registration Husky Card account Class schedule Correspondingly, information needs are dynamic but predictable.

Design Goals Provide students with information that is: personal - class and account information critical - important dates and notices curated - avoid wasting time relevant - info for starting workflows timely - when you need it

Design Rule Present personalized content from multiple systems when it is relevant (but allow access to all content at all times). Personalized my grades my courses my financial balances Time-based Early weeks: directions to classes Around registration: time schedule, advising info End of the quarter: finals schedule, final grades

How do information needs change over time? Designing Relevancy

Rule + Relevancy = A card model that reorders the cards based on the week of the quarter to bring timely, personalized content.

Iterations…

Final Design Actionable and personalized content on cards. Different cards shown during different times in the quarter.

Week 1 (Frosh) What do I need to be thinking about before classes start?

Weeks 1&2 Where are my classes?

Weeks 1&2 What books do I need?

Week 4 (Frosh) What classes should I take next quarter?

Week 5 When can I register?

Week 6 What does next quarter look like?

Week 6 What does next quarter look like?

Finals Week When and where are my finals?

Finals Week What grade did I get?

Questions?