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

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.

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.

THE PAST
m.UW native app m.uw.edu
Responsive uw.edu

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.
m.UW native app

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.

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

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.
MOBILE UW

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

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.
Building Mobile Apps

Iteration on Mobile UW, UW Scout … and beyond!

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.

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.

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.
SpaceScout Server flexible enough to accommodate new scope. Let’s build on it, learning our lessons from past mistakes.

THE FUTURE
Hybrid approach. HTML content layer wrapped in very thin layer of native code (ex: 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).

Questions?

PART 2: THE MOBILE (NOT A) PORTAL

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

Better meet user needs through user research, usercentered design, and agile development.
Replace old portal technology.
Responsive, mobile first design.

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

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.

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

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

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

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

How do information needs change over time?

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

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

What do I need to be thinking about before classes start?

Where are my classes?

What books do I need?

What classes should I take next quarter?

When can I register?

What does next quarter look like?

What does next quarter look like?

When and where are my finals?

What grade did I get?

Questions?