Support a validation interface on mobile

[maubinle]

I'm opening up a thread for discussions around the mobile validation interface. I have done some preliminary mockups to test out:

1. onboarding experience, I think we can either do a "slideshow" experience where we show the user what they should do ahead of time, which seems to be popular on mobile, or try to do an "interactive" tutorial more similar to what we have on web.
2. how to show context (what is a curb ramp vs not a curb ramp): I tested out buttons vs scrolling. I think I prefer scrolling in my example but will need to test it.
3. task complexity: I haven't mocked this up yet but it would be interesting to see how people react to the # of tasks they have to do or how difficult they perceive this to be.

Potential "slideshow" onboarding experience

Potential "interactive" onboarding experience (more similar to the tutorial we have today):

I also played around with a "wider" interface, which I think I prefer because it profits better from screen space (though is it an issue not to have labels by the buttons?):

I still need to mess around with task complexity, as I currently have quite a simple setup overall (which mirrors the web experience more). If anyone has preliminary thoughts on these, please let me know!

[jonfroehlich]

Thanks for this @maubinle. I like how you're thinking through the full user experience, incorporating colors from our logo, and integrating mission elements in your design.

Can you try to mock a few designs that:

• Maximize the presentation of the GSV image. It feels like you have too much whitespace. Perhaps you need to consider landscape too?
• The PS branding takes up too much space and it should really be a tertiary element in the UI (let's maximize space for functional components). (In fact, what happens if you take the PS logo away from the validation screens all together, how does that change your design?)
• Generally, I push my students to come up with 10 interface ideas before downselecting to the 1-3 most promising designs. So, can you try pushing yourself to come up with more UIs for validation?
• I also encourage students to use the fastest mock-up technique possible (which is often paper sketching, see https://github.com/ProjectSidewalk/SidewalkWebpage/issues/535#issuecomment-415233192)

[manaswisaha]

Just wanted to swoop in and say, I love the mockups and how it's shaping up! Nice work, @maubinle!

[maubinle]

Yay thank you @manaswis, I'm glad you like these!

@jonfroehlich I took your advice on board and went back to sketching. I had done a few paper mocks already and added more after your comments.

A couple of things from these that I quite like:

• Scrolling to get more info (like in number 5)
• Simpler interfaces with pictures one at a time
• Simpler interfaces without rating validation (unless we deem this is important)
• Some indication of the previous and next image (like in 1)
• Some way to maximise the image completely (like in 10)
• We could think about how to switch from vertical to horizontal. For example, in the Youtube app on the iPhone, when a user clicks on the "expand" icon, it flips vertical and fills up the whole screen. We could consider something similar.

[jonfroehlich]

I really like these. Thanks for expanding on your ideation and mocks. I'm short on time now but a few quick thoughts:

• I'm definitely attracted to mocks that maximize the GSV interface.
• One concern about landscape that I didn't think about before is that it requires two hands (for comfortable use) rather than one... Hmm.

[ghost]

W. O. W. They are amazing!!!!! Awesome job!

I am a cs undergrad with zer0 HCI experience, so I am not sure if I can provide any professional HCI perspective. However, there is one thing I would like to mention: for phone app, I think space is important as we need to show a lot of information in a small screen. I personally think the "Project Sidewalk" logo is very cool but it's a little too big and takes too much space (pretty much 25% of the screen). Maybe we can shrink it to a small logo in corner so we can use more space for the tutorial, such as show more details on the road?

[maubinle]

After user studies, here are 3 more mocks that I think accurately consolidate the feedback I've been hearing. Here are some of the consolidated learnings from initial user testing (I left my book with most of this info at work so will add more later):

• Swiping interface did not perform as well as expected. People felt this was a learned behaviour instead of a natural one, so it would not be appropriate for an app that you use once for a few minutes. It also became clear that the swiping devalued the "unsure" option
• There were mixed reaction on the sideways interfaces. Some people said they preferred them to see the picture better. Others said that they are not in the habit and might not be willing to turn their phone sideways, especially if it's on a browser instead of an app
• As expected, a combination icons + labels worked the best for validation
• Scrolling to get more information was unnatural to most users; they prefer an interaction style that has you actually click on a button
• Making the "curb ramp" section bold caused some users to believe it was a link

Mock 1: Maximizes the image by using overlays Mock 2: minimalist design and labels Mock 3: A sideways example, with some notion of "history" I'll be conducting more user studies tomorrow and trying to settle on a single design. Heads up that I started a fever today so might not be super on the ball for the next couple of days but will try my best to push to one final design.

[jonfroehlich]

I like Mock 1 the best. I'd still prefer that you use all of the phone screen for the image and just do overlays.

Jon

On Sat, Feb 2, 2019 at 9:52 PM Marianne Aubin notifications@github.com wrote:

After user studies, here are 3 more mocks that I think accurately consolidate the feedback I've been hearing. Here are some of the consolidated learnings from initial user testing (I left my book with most of this info at work so will add more later):

• Swiping interface did not perform as well as expected. People felt this was a learned behaviour instead of a natural one, so it would not be appropriate for an app that you use once for a few minutes. It also became clear that the swiping devalued the "unsure" option
• There were mixed reaction on the sideways interfaces. Some people said they preferred them to see the picture better. Others said that they are not in the habit and might not be willing to turn their phone sideways, especially if it's on a browser instead of an app
• As expected, a combination icons + labels worked the best for validation
• Scrolling to get more information was unnatural to most users; they prefer an interaction style that has you actually click on a button
• Making the "curb ramp" section bold caused some users to believe it was a link

Mock 1: Maximizes the image by using overlays [image: image] https://user-images.githubusercontent.com/16949591/52173108-ea579580-2731-11e9-8257-6f1074f5c843.png Mock 2: minimalist design and labels [image: image] https://user-images.githubusercontent.com/16949591/52173110-f2afd080-2731-11e9-83fa-d71498b07149.png Mock 3: A sideways example, with some notion of "history" [image: image] https://user-images.githubusercontent.com/16949591/52173112-fc393880-2731-11e9-8bdf-f86ba7821967.png I'll be conducting more user studies tomorrow and trying to settle on a single design. Heads up that I started a fever today so might not be super on the ball for the next couple of days but will try my best to push to one final design.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/1395#issuecomment-460025532, or mute the thread https://github.com/notifications/unsubscribe-auth/ABi-9fIUOroDwPy7iBwlloJHR9ic6zPgks5vJnkngaJpZM4aKASY .

-- Jon Froehlich Associate Professor Paul G. Allen School of Computer Science & Engineering University of Washington http://www.cs.umd.edu/~jonf/ http://makeabilitylab.io @jonfroehlich https://twitter.com/jonfroehlich - Twitter

[maubinle]

OK, after more user studies on these 3 mocks I came up with the final mock which I think is quite close to the final form:

This design truly maximises screen space, and also rearranges the "more info" section based on user feedback. I will solicit more feedback on the slack channel and try to close on the design this week.

[jonfroehlich]

I like it!

I'm still not sure about the order of Yes to No. Have you done any design research on this? The advantage of the 'Yes' button on the right is that it will be thumb accessible for right-handers and we expect 'Yes' far more than the other options.

Jon

On Mon, Feb 4, 2019 at 10:37 PM Marianne Aubin notifications@github.com wrote:

OK, after more user studies on these 3 mocks I came up with the final mock which I think is quite close to the final form: [image: image] https://user-images.githubusercontent.com/16949591/52256890-4f93be00-28cd-11e9-9937-2b223b6b5659.png

This design truly maximises screen space, and also rearranges the "more info" section based on user feedback. I will solicit more feedback on the slack channel and try to close on the design this week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/1395#issuecomment-460529727, or mute the thread https://github.com/notifications/unsubscribe-auth/ABi-9eL2CnueQzrQS7JZHMVwSgV9xF9Eks5vKSa9gaJpZM4aKASY .

-- Jon Froehlich Associate Professor Paul G. Allen School of Computer Science & Engineering University of Washington http://www.cs.umd.edu/~jonf/ http://makeabilitylab.io @jonfroehlich https://twitter.com/jonfroehlich - Twitter

[maubinle]

Notes from the PS meeting:

• instead of the label, maybe consider using arrows?
• make the white text blue/black
• maybe some sort of confirmation screen after you've clicked the check mark

[jonfroehlich]

I don't think we want a confirmation screen after clicking check mark--will slow down the user too much. And I've used @aileenzeng's validation interface enough to know that mistakes don't occur that often, so I don't think it should be a big concern.

[maubinle]

ack. no confirmation screen it is.

[jonfroehlich]

The key will be to get an interactive MVP going so we can provide more nuanced comments from actual use. I think all the comments you got from today's meeting could be deferred (and I think sticking with the circular label rather than an arrow for now is fine and easiest).

[misaugstad]

Just to clarify the confirmation screen, I thought that was in response to users who said they didn't know if their validation "went through" -- so instead of a confirmation screen, I have seen things like a slightly transparent overlay that shows up briefly, then fades quickly, that would have a checkmark"

[jonfroehlich]

Helping users understand that their input was saved seems important but I don’t understand Mikey’s suggestion.

Sent from my iPhone

On Feb 5, 2019, at 3:53 PM, Mikey Saugstad notifications@github.com wrote:

Just to clarify the confirmation screen, I thought that was in response to users who said they didn't know if their validation "went through" -- so instead of a confirmation screen, I have seen things like a slightly transparent overlay that shows up briefly, then fades quickly, that would have a checkmark"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[maubinle]

Quick stylistic question -- should I create a new landing page (e.g. sidewalk.cs.washington.edu/validatemobile) or should sidewalk.cs.washington.edu/validate take you to the web interface on web and to the mobile interface on mobile? I feel the 2nd option makes more sense, but want to make sure this is aligned with your take.

[jonfroehlich]

Yah, I like the latter if you can manage it.

On Mon, Feb 11, 2019 at 6:48 PM Marianne Aubin notifications@github.com wrote:

Quick stylistic question -- should I create a new landing page (e.g. sidewalk.cs.washington.edu/validatemobile) or should sidewalk.cs.washington.edu/validate take you to the web interface on web and to the mobile interface on mobile? I feel the 2nd option makes more sense, but want to make sure this is aligned with your take.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/1395#issuecomment-462592731, or mute the thread https://github.com/notifications/unsubscribe-auth/ABi-9bKErznTSqF2zDjHBbeNXHOWBJlWks5vMiuCgaJpZM4aKASY .

-- Jon Froehlich Associate Professor Paul G. Allen School of Computer Science & Engineering University of Washington http://www.cs.umd.edu/~jonf/ http://makeabilitylab.io @jonfroehlich https://twitter.com/jonfroehlich - Twitter

[misaugstad]

Helping users understand that their input was saved seems important but I don’t understand Mikey’s suggestion.

ok @aileenzeng made this to help me demonstrate what I mean (thank you!). The idea was that something like this checkmark would show up and then quickly fade, just to show that the response was recorded. Similar to how Tinder has "like" and "nope" stamps that show up on the images as you swipe.

[misaugstad]

You know me, always forgetting to add the images:

[maubinle]

Inspired from Aileen's breakdown of tasks going into the validation implementation. I will likely discover more things as I go along, and will add to this I'm sure.

Infra & Backend work

• [x] Route users to mobile validation page if they visit project sidewalk on mobile
• [x] Create mobile controller to handle requests to mobile
• [ ] Include in table whether a label was contributed via mobile or UI
• [x] Add new mission or resume existing mission when user visits validate page from mobile

UI

• [x] Display GSV to validate
  • [x] Fetch GSV to validate
  • [x] Maximise GSV to full screen
  • [x] Make GSV moveable with fingers
  • [ ] Enable zoom by pinching
  • [ ] Figure out a way to stabilize label
  • [x] Show label to tell the user where they are validating
    • [x] Scale label for phone
• [x] Progress bar
  • [x] Get # of labels in mission
  • [x] Get # of labels already validated
  • [x] Update progress bar accordingly
• [x] Add validation question
  • [x] Fetch validation label type
  • [x] Display validation label type
• [x] Add validation buttons ("yes," "no," "not sure) with icons
  • [x] Overlay validation buttons on GSV
  • [x] Add icons to buttons
• [x] Load new label when validation buttons are pressed
• [x] Allow user to skip by pressing forward arrow
  • [x] Show button
• [ ] Allow user to go back using backward arrow
  • [x] Show button
• [x] More information screen
  • [x] Add informational icon button
  • [x] Load "more information" screen when user clicks on informational button
  • [x] Add dynamic label and description
  • [x] Add dynamic pictures and examples
  • [x] Allow users to close information screen
• [x] Leave feedback
  • [x] Include leave feedback button
  • [x] Show leave feedback modal
  • [x] Successfully send feedback to the backend
• [x] Submit validated labels to backend after completion
• [x] Add mission start screen
• [x] Add mission completed screen
• [ ] Prevent landscape mode
  • [x] Create modal panel for landscape mode
  • [ ] Trigger modal panel whenever phone goes to landscape

Logging

• [x] Log visit to the page
• [ ] Add to validation_task_interaction log
• [x] Log if user skips mission
• [ ] Log if user goes back to previous mission

[jonfroehlich]

Thanks for this @maubinle. Fair bit of work listed here but I look forward to seeing your progress!

[misaugstad]

closing via #1572