-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting09.20.2017
Jason White, Charles, Amaya, Bruce, Jesse, Sina, Jason Schwab
- Jason: the analysis document that I’ve written doesn’t discuss non continuous collecting of objects. i’d argue they still fall in the simple to make broadly accessible category, but maybe I should add a note about those.
- Jesse: (Add the Friction Example to the Google Doc)
- Jason: we should capture that in the analysis and note that as another dimension that we are tracking. So I will add to the list and Sina will review them before the next call.
- Sina and Charles: to start the Google Spread Sheet on Various Drag & Drop options needed to be considered
Jason: What we decided at the end of the previous meeting was that it would be a productive way to make progress to set up several meetings and work systematically through the issues instead of doing it asynchronously. We will do the ground work, establish priorities and then work out our deliverables, and by the end of our last meeting we analyzed the relatively straightforward cases of drag and drop scenarios used in educational spaces. I made some changes to the conceptual analysis document that we developed earlier in the year. My changes take into account some of the ideas that came into play in the last meeting. The objectives for today tis to continue from where we ended last time, by analyzing the more complex and difficult cases and making sure that the simple ones are covered and then we can start discussing the further examples we need and which ones we may have to make ourselves and what’s available elsewhere and what guidance we will give to implementers.
Charles: One other point I’d like to bring up is an email that Matt King commented on the analysis doc and his reference to cut and paste and how that compares to drag and drop. Is there any opinions on that. I’m fine either way, but wanted to know if any one feels we should consider?
Jason: We discussed it last time and I think it was decided it was distinct, but we didn’t conceptually articulate the key differences. I think it’s a legitimate issue.
Charles: I don’t consider cut and paste a drag and drop type of scenario and don’t think we should be derailed and try to justify it one way or the other.
Sina: It’s done with drag and drop, or it can be, but it seems out of scope for what we want to do because we have enough to worry about with single list, multi list sorting, etc. From what I can think for blind users, for speech recognition users, for deaf and hard of hearing, cut and paste has been pretty well solved. I would argue for switch based issues there would be a lot of ideas we could cut up with, but that’s a whole thing on to itself. Jason: I would like to agree with Sina on that, but also the cut and paste, or copy and paste, seems to fall conceptually in the simple category in the sense that you’re choosing the object that constitutes your source and then you’re selecting the destination. The path to travel isn’t significant.
Charles: So Sina, you’re thinking pressing certain keys down as your copying you can non-sequentially or sequentially grab things and that’s the relevant piece, but not the normal way that you would consider.
Jason: We have scenarios where you picking up multiple objects successfully and dropping them somewhere.
Sina: In the wescheme example I sent out we could have supported noncontiguous, and it mimics the one that mimics control X, control c, control v, I think we need to finalize what’s in scope, because there is good working examples in all of these things.
Jason: the analysis document that I’ve written doesn’t discuss non continuous collecting of objects. Zi’d argue they still fall in the simple to make broadly accessible category, but maybe I should add a note about those.
Charles: so is this one of the complex scenarios, non- contiguous.
Sina: Do we only have simple and complex or do we have intermediate. I think dragging multiple things isn’t simple, because the user needs to retain a lot more in their working memory.
Jason: Right, so what I have in mind then is that’s another dimension in complexity and I will take an action to describe it and put it into the document.
Sina: say that if we are going to have more than one as the subject of the operation let’s make that another attribute of the type of component we want to track.
Jason: So you have one object where you choose source and destination, and multiple objects as source objects is more complex, and multiple non-contiguous objects as source objects is even more complex.
Sina: right, the selection operation will be different.
Jason: Yes, I think we should capture that in the analysis and note that as another dimension that we are tracking. So I will add to the list and Sina will review them before the next call.
Charles: It looks like we are having different dimensions of how it is a simple operation, do we need a spread sheet to track these things?
Jason: I’m maintaining the discursive document, so I will make the modifications to that to characterize the issues that we just introduced, so I’ll do that. How you want to track the different dimensions, “information management problem” whatever you think is the most convenient I’m comfortable with.
Charles: So then do you think we should go to Google sheets and link from the doc and the analysis document?
Sina: yes, exactly. We can always import it, but let’s edit it as a sheet.
Charles: Okay, I will create that sheet. Though I could use help on column names.
Sina: If you want to own the document, I’m happy to hop on a call with you and rattle off examples and complexity order.
Charles: Thanks Sina, I’ll talk to you offline and we’ll schedule that call.
Jason: Do we have more examples for the difficult cases. We had discussion about what happens when the speed a user moves form source to destination makes a difference, we need some other cases where path matters and which it could be a large number of sources and destinations which is another problematic dimension. If we get good examples we can look at how they interact with our accessible strategies. And then we’d be close to having advice for implementers.
Sina: when we talk about speed it’s important to know that sometimes interfaces when interacted with accessibility aren’t continuous in nature. Like instances when blind, keyboard user and using the arrow keys, but isn’t holding them down. It’s important to understand if it’s the speed of the operation is captured and linked to a specific input modality, or speed as a whole i.e. how long it took to complete, or some other method measuring speed or time. That could lead to lots of edge cases, like a speed dictation user trying to drag and drop issues.
Jason: That’s right, I agree with you, in updating the doc on the wiki I sited WCAG accessibility guidelines 2.0 that the timing of the individual key strokes must be irrelevant. There are speech technologies that will simulate key strokes that can’t keep the timing.
Sina: A lot of the other examples we’ve talked about here we could exclude base don WCAG requirements, but if we want to come up with a novel way to make it accessible, could we do it or at least partially do it even though it may violate WCAG.
Jason W: How do you design your interface so the timing isn’t essential?
Sina: or expressed though another means. I don’t care about how fast the cursor moves, but that the operation was done in under 5 minutes.
Charles: So like in a PhET simulation your need to stir something and until you stir it fast enough the color one change because it’s a chemical reaction. You may physically not be able to stir it fast enough.
Sina: If speed is going to be critical to the operation then there needs to be a way of adjusting the perceived speed or the speed that is done. And that needs to come from the developer, it can’t be an add on.
Charles: Is there an operation Jesse that you could point to and add to our document.
Jesse: We have a simulation called friction where the temperature of surface between two books increases the faster you rub them together.
Charles: Can you add the example to the document?
Jesse: we’ve been exploring accessibility with it so it has key board navigation, though no description or anything. We’ve been looking at keyboard modifier rater to let you change the rate at which you drag things. I’m not sure how that would work with a switch type of device, but if you have access to a keyboard.
Sina: there are ways of exposing that. If you can keyboard between slow, medium and fast, then everyone could benefit from it.
Bruce: John Travolta is a PhET sim is which you rub the leg of a person across a carpet so it’s like rubbing a foot on a carpet and when you do so the body picks up charges, so it’s like rubbing of the book. I’m not sure if that’s the speed of it.
Charles: I would imagine it wouldn’t matter how long it takes. Jesse: That was targeted for much younger students so it wasn’t important to make speed one of the variables.
Charles: Sina, did you only send an email with the WeScheme link?
Sina: Yeah, when we do the spreadsheet together, I can paste in in the chat at that time. I can also send you info how iOS is doing drag states, windows file manager, Mac. I think there is a rich source of real world stuff we can print to.
Charles: We have about thirty minutes left. Should we end early?
Jason: One category we don’t have good examples at the moment, and if people want to think about it and find out before the next meeting is the category where the path form source to destination is significant and we need good examples to populate that category.
Bruce: We have one called Midi Mercury, you have a blob of mercury sitting on the table top and you wanted to play with it, if you drag your finger though the mercury in a straight line you’d bisect it into two blobs, but if you arced your fingers you might get to the same destination, but you would have created to difference size blobs. So that path matters. And if you go slowly enough on a path the gap you’ve created can heal itself at the edges, so both the path and speed matter.
Charles: That’s a great example.
Bruce: As you play around with this blob of mercury the shape and the size that you create generates musical tones.
Jason: Do you have any websites or documents that was implemented?
Bruce: Yes, we have a document and video of it. Is drawing a form of drag and drop?
Sina: I think it is, but I don’t want to boil the ocean.
Jason: If we take preexisting components and moving them into place.
Sina: UI builders come to mind, layout manipulators. The example of the Mercury, with speed and path mattering and it’s not only that the speed and path matter, it’s the user needs to know what the effects of the speed and path are during the operation and not only at the end of the operation.
Bruce: Where should I stick the link?
Charles: the classifying interactions.
Bruce: Okay, I’m going to call it dragging in a 2D plane. We have a computer version and a web based version.
Sina: Thinking about physics in games where these types of behaviors need to be exposed and they are almost never done in an accessible way. So are we wrapping?
Charles: I believe so, and we can continue on in email.
Jason: I was just wondering if there was any case where you’re selecting multiple noncontiguous scenarios where you start picking things up and then pick up more along the way to the destination.
Sina: If that’s the case a noncontiguous modifier doesn’t matter.
Charles: It’s the ability to pick up more while dragging is what we are talking about.
Sina: We should absolutely be aware of that. Wouldn’t the balloon example be the case on that.
Bruce: You grab the balloon and move it to the sweater, but you’re not trying to sweep up the charges. But I bet there are examples in PhET.
Sina: We haven’t talked a lot about if we wish to illustrate a drag and drop. Like a chess tutorial. Usually you would illustrate it by a pawn hopping or the way a night would move, you would show that with line diagrams. We should put some time in to thinking about how to talk and expose examples of drag and drop when we can’t rely on the user doing it, they are just listening to something, or being told about something.
Charles: So two weeks from now, so Wednesday the 4th of October at this same time. Group: Sounds good.
Charles: Okay, well I’ll send out the meeting invite.