Killing Mobile Apps with the Mobile Web: Of Portals, and *Scouts, and User Research

Tom Lewis, DirectorAcademic & Collaborative Applications

PART 1: UW AT YOUR FINGERTIPS

Problem StatementWhile 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 PASTInconsistent 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 app m.uw.edu Responsive 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 NOWGoodbye 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.

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.

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 FUTUREIteration on Mobile UW, UW Scout … and beyond!

Mobile UW IterationTHE 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 ScoutTHE 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 StrategyTHE 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.

UW Scout TechnologyTHE 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

About MyUWMain portal for

students, faculty & staff.

Requires login.Decade-old design &

code.

Rebuild GoalsBetter meet user needs through user research, user-centered design, and agile development.

Replace old portal technology.

Responsive, mobile first design.

User ResearchEvidence-based, user-centered design:

• Design iterations• Diary studies• Focus groups• Interviews• Log data analysis for MyUW and UW.edu• Surveys• Usability studies

Key Research AreasGoals 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

Key Research Finding

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

Key Research FindingStudents 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.

Design GoalsProvide 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 RulePresent 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?