Closed jonfroehlich closed 8 years ago
Possible ways to reduce the attention to the ?
s:
examples
in gray below the button, make it clickable to the example@kotarohara hey i'm having trouble with my dev environment. do you mind screenshotting the current interaction? what does the screen look like when you tap on the question mark vs tap on the button?
@nguyenist
When you click the button, the interface looks like:
The interface opens the window with examples when you click the "?":
the user flow/interaction that seems likely / intuitive:
have been researching. here are some preliminary ideas that could be helpful to make the user interactions simpler and more smooth. will sketch to have these make more sense.
"Redo last (Obstacles)"
---
Ramp
No Ramp
Obstacles
Other
Sketches representing concepts above. Note: Components from the sketches can be combined / mixed / matched. They do not have to be viewed in isolation of each other. I tried to add a different spin on each of the layouts so we had options. Would love to discuss! @kotarohara Let me know if a call / skype may be easier to explain.
https://www.dropbox.com/s/8zu4lx84k39vhbm/IMG_2115.JPG?dl=0
https://www.dropbox.com/s/cdkrffge4f02c6y/IMG_2116.JPG?dl=0
@nguyenist This is great. Reply inline:
- User double taps to "move" down the street. thoughts: "i don't know what i'm going to see. so i'm not going to be in a mode all the time." -- "i don't want to have to choose from 4-5 different options before labeling. i want to tap and label very quickly so i can get points / help out the community / [insert whatever incentive they have for being on this site]"
- One single button. it might be called "Label" when you click on street view image somewhere, you see a menu of items (ramp, no ramp, obstacle) and can choose what that component is. Allows user to move more quickly through versus memorizing button placement, then tapping the streetview area, etc.
Having label options at the top has a benefit of constantly reminding people what they have to find in Street View imagery, whereas context menu (which our very first interface had originally) hides what needs to be labeled from the users. So we should keep the options always visible to the users. Not sure what you proposed would allow people to move more quickly; why you think so?
icons w/ text -- change to a single word where possible. (1) Ramp (2) No ramp (3) Obstacle (4) Surface (5) Other -- sidenote: how likely is "surface problem" going to be chosen as an option? 5 options is quite a lot for a user to have to choose every single time they label something. ideally-- reduce # of options for quicker labeling. can surface problem be in "other"?
Hmm, I agree I'd like to shorten as much as possible, but "Ramp" and "Surface" don't really make sense. Maybe "Obstacle" is fine. Surface problems happen time to time (e.g., tree root breaking sidewalk surface). I think we should keep it.
- list that is vertical with a question mark next to each item
- select category "curb ramp mode". then on the interface of streetview, it says "curb ramp mode" and a help button next to it that allows you to see more infromation.
- when you first select the item for the first time, the help menu comes up anyway so the user is forced to see it and can come back to it if they want.
- when you click on a point in street view, a menu pops up under your mouse with options. you keep your mouse click held down and move through the menu of options "curb ramp, missing curb ramp, obstacle, etc." and when you let go it makes the selection. the last selected option is the default. Say you chose Obstacles for the last component you found in streetview. You would see a menu that says"
I like these đź‘Ť Let me take a look at mock ups you drew and comment.
@nguyenist Actually I like the following ideas.
I like having "Explain This!" on the overlay message box when you click label type. It's kind of hidden from the user, but I guess that can be mitigated when we combine the second idea (i.e., show the examples when the user click label for the first time.)
Also, thank you for also brainstorming the design of what we show after clicking the help buttons :) Should we chat? Maybe tonight or tomorrow night.
Usability study 1: Observed user click through current dashboard to understand what information they gathered from the current buttons + "?" buttons.
what do these buttons represent? (pointing to the top 5 at the top) I would click on one of those buttons then click on something on the street image
what do each of the buttons mean? curb ramp = there is a curb ramp missing curb ramp = no curb ramp. the crosswalk drops right down. obstacle in path = might be a curb ramp but cant use it bc obstacle in path surface problem = cracked or too bumpy or something other = something that's not those 4
what do you imagine would happen if you clicked "?" "it would bring up a tooltip that explains what it was. a text based one that explains what this button means."
what would be in the tool tip? "example images. it was part of the tutorial so it foreshadowed what i thought i might see."
action: actually clicked on it: confused because text is quality 1: good // rating 4: very hard to pass. "what does quality versus rating mean? words seem to not be consistent."
could you explain what the numbers mean? a 1 means the best top quality. a 4 means the worst. not sure what the scale is. 1 = "these are the qualities i would be looking for. the ramp dump right into the crosswalk." 4 = "not usable i guess but wait it doesn't make sense. it seems like the rating should go the other way because it's not rankings. its rating. a 5 is good and a 1 is bad."
clicked on missing curb ramp "?"
clicked on obstacle in path "?"
clicked on surface problem "?"
Could you label a curb ramp?
Takeaways for user 1:
@nguyenist
This is awesome! Can you do the same thing with 2 more people? It would be awesome if you can combines the takeaways for user 1, 2, and 3 and come up with a high priority task.
Did they have any comments on the mocks you sketched? I wonder how they felt about the design of "?".
@nguyenist: I agree, awesome job. Very interesting. Like Kotaro suggests, would be great to get feedback from a few more people, then triangulate on common problems to inform our design update.
You rock!
@kotarohara @jonfroehlich Thanks for the feedback. Yes, definitely planning on doing a few more :) Will update the transcribed interview as I go along / grab folks to get more thoughts.
We worked a little backwards and it is important to first observe how people currently use the dashboard. Then note the pain points / problems around those buttons before deciding the best way to fix them.
My proposed method:
Obviously because of time constraints, we don't have forever to go through these steps in micro-detail, but I can go through what I can to learn as much as possible with the resources we have. Any user research and perspective is helpful / better than none and the product will be more user friendly for it :) Would love any thoughts as we go along.
Yay team!
Usability study 2: Observed user click through current dashboard to understand what information they gathered from the current buttons + "?" buttons.
what do these buttons represent? (pointing to the top 5 at the top)
the user's natural interactions regarding the button // without being asked
what does each of the buttons mean to you?
started clicking on the ?'s
How do you rate?
action: clicked on curb ramp "?"
action: clicked on missing curb ramp "?"
action: clicked on obstacle in path "?"
action: clicked on surface problem "?"
action: clicked other
Thoughts reflecting on experience thus far
Takeaways
Usability Study 3:
At first glance, what is happening?
What do these buttons means
User interacts with sidewalk interface. Started playing with the labels
? on buttons - do you see that? is it A? because you’re asking me to label things. those are the ways you are signaling me these are labeled and color coded
missing curb ramp ?:
obstacle ?:
surface problem ?:
other:
what are the labels called? tags, labels or markers.
asked question again. what does this website allow you to do? you could give someone who needed the information the accessible paths for them so they would know if there was a problem. best way to get there.
Takeaways:
Overall takeaways by priority: 1 2 3
Will add here later.
@nguyenist Are you going to summarize the takeaways? It would be great if you could separate (a) the design of the "?" marks and (b) other things that you've found out (e.g., it seems like you've got good feedback on how to design the actual help window).
Yes I will. Haven't forgotten. More soon.
On Tuesday, June 21, 2016, Kotaro Hara notifications@github.com wrote:
@nguyenist https://github.com/nguyenist Are you going to summarize the takeaways? It would be great if you could separate (a) the design of the "?" marks and (b) other things you've found out (e.g., it seems like you've got good feedback on how to design the actual help window).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/78#issuecomment-227539669, or mute the thread https://github.com/notifications/unsubscribe/AERsLb2gOuooCui-PkTWvYvJ-GARbjVOks5qODX1gaJpZM4IKRn5 .
Sent via mobile device
@kotarohara
Takeaways for ? marks:
Takeaways for other things on help page:
Here is what I will ask / test:
Option A: Horizontal buttons -- note: here I simplified the screen to try and create some button hierarchy. Want to see what buttons people want to click first and right now there are many.
Option B: "Explain this!" -- will appear upon clicking a labeling button. The overlay will be thicker, the font will be larger to accentuate the task + help option.
Option C: Plain text option -- UX researchers suggests sometimes people just need clear language prompts instead of non-universal iconography / images. See this Nielsen Norman article for context. Perhaps one link could bring up ALL of the button labeling explanations in a different window so they don't have to be dispersed on each button.
@nguyenist
Takeaways for ? marks:
- Number one takeaway: Design "?s" to stand out. Right now, people don't seem to know you can click on them until I point them out. Notes for me-- consider using words like "read more" or "learn more" -- think about ways to do this for all buttons w/o looking redundant.
Great! But I don't think we will go though a massive interface redesign, so Option A would not happen. I like both B and C. For C, probably we don't need parenthesis. Also for C, are you envisioning a single help window that opens up after clicking "click here to ..."? Do we have enough space to explan all the accessibility feature types?
Are you going to see which one (B or C) people prefer?
Takeaways for other things on help page:
- Change ratings logic. 1 = worst. 5 = best.
- Lower the task length. Need feedback sooner to reduce shock of being so far from done (relates to #66)
- Clearly explain ratings once you actually click on the "?" -- make language consistent (severity, quality rating), give reasons for why something should be a 1, 2, 3, 4, 5. For example) Think about how to rate Surfaces. Smooth (5) vs bumpy (1)?
- Redesign the "help" screen to include the ratings bar so people can easily see the correlation when they have to rate.
I feel like (1) keeps coming up all the time (not only the last few month but since long time ago). We'll decide this week. (2) Ok. Sounds good. I'll make them shorter. (3 & 4) I'll get descriptions and try to get pictures. Once that's ready, I'll probably ask you to design the help window.
@kotaro sounds great.
Re ? (1) Yes I think it's possible to design a single page. There is a ton of text and if we can condense it down to a simple page concept that will resonate w users that would be ideal. Based on tests they will start rating based on what is in their head vs reading a ? help page 5 times which may skew results otherwise.
Re other (2) no need to gather all photos just yet. Want to see how much info is necessary for someone to understand how to do rankings for each. Would be great to get a better understanding for what counts as 1, 3, 5 for each category to start.
Feedback based on 3 usability studies:
User 1 takeaways:
User 2 takeaways:
User 3 takeaways:
User 4 takeaways:
Overall takeaways:
/cc @nguyenist
I gave thoughts on this. We are not going to flip the scale. 1 means accessible and 5 means inaccessible. This scale will be consistent across all the features. Meaning of scale 1, 3, and 5 are: (1) Passable: Not an accessibility problem. Wheelchair users can navigate without a problem. (3) Could be a problem: The problem could pose an accessibility problem for some people with mobility impairments. (5) Not passable: The problem is a major obstruction for people with mobility impairments to use the sidewalk.
\cc @nguyenist
Feedback based on 3 usability studies:
This is awesome, but I was a bit confused by 'Would like to go with the overlay with "Explain [insert button titles: sidewalk problems]"' Could you explain this a bit more or show a design mock?
@kotarohara
Screenshot / Option B. Instead of "Explain this" it would say "Explain Sidewalk Problems" / "Explain Curb Ramp" / "Explain Obstacle in Path" etc.
@kotarohara Cool! Can people define any of the categories by using just this high level explanation? Expecting users to know / learn 5 separate categories with slightly different definitions might be asking a lot. I like being able to embed the concept 1 = good, 5 = bad throughout the categories.
A few questions:
Missing Curb Ramp
Obstacle
Surface Problem
@nguyenist
Yeah, what do you think? I'll welcome your opinion! I would put 1-5 scale issue aside for now though :) First, it's an optional information people can provide, so I wouldn't worry to much about it. And regarding "If N/A why allow this as an option," (a) you'll never know if it's obsolete or not, so collect as much data as possible; (b) we are just trying to provide as much instruction as possible, there isn't even a guarantee people will follow our instruction so why don't we just do our best and not bother any more? (c) Once we have data, we can conclude this. We don't even know if this rating is reliable (What is the "reliable" rating anyway?)
It's great that we settled on the Design B. As you move on to building it, you'll probably need my help navigating the code base. So I think it's a good idea for us to sit together and code for 2-3 hours this weekend and knock it out of our way. It would be great if you can come to College Park, but if not I can come to DC. Either way, can you (i) refresh your memory and set up your dev environment, and (ii) polish the design of B and make sure we can focus on coding when we meet?
Would totally try to meet you but I'm out of town until Tuesday. Happy to chat with you via Skype and parallel work on this. We can chat more details so I make sure I'm understanding everything as you'd like.
Does that work? How about Friday?
On Thursday, June 30, 2016, Kotaro Hara notifications@github.com wrote:
@nguyenist https://github.com/nguyenist
Yeah, what do you think? I'll welcome your opinion! I would put 1-5 scale issue aside for now though :) First, it's an optional information people can provide, so I wouldn't worry to much about it. And regarding "If N/A why allow this as an option," (a) you'll never know if it's obsolete or not, so collect as much data as possible; (b) we are just trying to provide as much instruction as possible, there isn't even a guarantee people will follow our instruction so why don't we just do our best and not bother any more? (c) Once we have data, we can conclude this. We don't even know if this rating is reliable (What is the "reliable" rating anyway?)
It's great that we settled on the Design B. As you move on to building it, you'll probably need my help navigating the code base. So I think it's a good idea for us to sit together and code for 2-3 hours this weekend and knock it out of our way. It would be great if you can come to College Park, but if not I can come to DC. Either way, can you (i) refresh your memory and set up your dev environment, and (ii) polish the design of B and make sure we can focus on coding when we meet?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/78#issuecomment-229571422, or mute the thread https://github.com/notifications/unsubscribe/AERsLf9qBddksx4Co0HF13viRY3AAofZks5qQ2JXgaJpZM4IKRn5 .
Sent via mobile device
You mean tomorrow, right? Sure! I'll be working all day, so call me whenever you want :) So my understanding is you'll spend time tomorrow and finish the design and implementation of the question buttons tomorrow?
Just texted you. Will keep you posted after I get back in town.
On Thursday, June 30, 2016, Kotaro Hara notifications@github.com wrote:
You mean tomorrow, right? Sure! I'll be working all day, so call me whenever you want :) So my understanding is you'll spend time tomorrow and finish the design and implementation of the question buttons tomorrow?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProjectSidewalk/SidewalkWebpage/issues/78#issuecomment-229822312, or mute the thread https://github.com/notifications/unsubscribe/AERsLUh9zogtCz4jiLErrbmS9ldnNG8gks5qRFpggaJpZM4IKRn5 .
Sent via mobile device
@nguyenist Do you have updates?
Done
Great, can I test it out? When can you deploy this to production?
I think it's important that users can easily view examples of what constitutes an accessibility problem for each label along with ratings. And, while we are moving in the right direction on this, we're not there yet. I find the current implementation with '?' overlays to be highly distracting. I think we need to find a better way of allowing users to quickly see examples.
As now, the '?' are given too much attention. Compared to the label buttons themselves, which are the number one interactive objects in our design, the '?' will be much less used and, thus, does not deserve its position in the interface or its salience.