Last modified: 2014-05-07 15:29:55 UTC
I find the swipe-right action for accessing the TOC to be a major burden. I activate it all the time when intending just to scroll. The potential for user confusion is even greater since the menu drawer is *also* activated by swiping to the right, but only if you start from the left edge. It's also really frustrating that you cannot *push* the TOC back toward the left, you have to grab the edge of the article and pull it back. The resulting physical metaphor is that the fundamental immovable layer is the TOC, and above that is a movable article that you can push to the right, and above that is menu drawer than you can pull over from the left. Confusing, especially since the article should be the fundamental thing. The solution I propose is to make *both* the TOC and the menu into drawer, and have the TOC be the right-hand drawer while the menu is the left-hand drawer (as now), and the article is the immovable bottom layer. For an app that does things like this, see Quasseldroid, which I think works out quite nicely. I also suggest that the drawers have a larger region that can be grabbed, which is a feature that Quasseldroid has. For users with cases that extend above the plane of the screen, it can be difficult to actually initiative a swipe from the edge. Here's how Quasseldroid implemented that: https://github.com/sandsmark/QuasselDroid/commit/cd7a842fe4da8f1f2bcebc6521c26e6a3e057274
So, I briefly played around with this kind of configuration, and I've found it to be significantly more usable. 1) I myself have been noticing that I accidentally drag out the main menu, when I really meant to drag the ToC. 2) I have also noticed that I sometimes accidentally make the ToC appear when scrolling the article itself. 3) Best of all, this would solve the (serious) issue of horizontal scrolling within the article, for free! (https://bugzilla.wikimedia.org/show_bug.cgi?id=63526) Can we get the PM's opinions on this?
Last I heard, the redesign work that's currently being done for iOS reserves swiping left and right for forwards and backwards navigation. Android redesign is to come afterwards, and we probably want to keep the experience consistent between the platforms, so we can revisit this issue when we begin the Android design overhaul.
(In reply to Dan Garry from comment #2) > Last I heard, the redesign work that's currently being done for iOS reserves > swiping left and right for forwards and backwards navigation. Android > redesign is to come afterwards, and we probably want to keep the experience > consistent between the platforms, so we can revisit this issue when we begin > the Android design overhaul. So implementing 'forward' in android is going to be painful - the system gives us a 'backstack' by default, and we just use that, but 'forwards' would require us to implement our own thing. We had a discussion about this about a month or two ago, and decided to not do 'forward' on Android.
Also note that the Android app has no specific back button in the UI, since it is always part of the system UI itself. Plus I don't know of any app in Android that uses swipe left / right for 'back / forward' (I just checked Chrome), so perhaps we should let iOS have it, and just let Android be with the system back button?
(In reply to Yuvi Panda from comment #4) > Also note that the Android app has no specific back button in the UI, since > it is always part of the system UI itself. Plus I don't know of any app in > Android that uses swipe left / right for 'back / forward' (I just checked > Chrome), so perhaps we should let iOS have it, and just let Android be with > the system back button? Consistency between the apps was my default answer, but nothing's set in stone as far as I'm concerned; it may be that the swipe for forwards behaviour just doesn't make sense on Android, and that's okay. Stuff like this is part of the reason why we're separating the iOS and Android redesign into separate phases, so that we're sure that both platforms end up with designs that make sense for them. :-) We'll revisit in a sprint or two when we get to looking at Android design.
(In reply to Dan Garry from comment #5) > (In reply to Yuvi Panda from comment #4) > > Also note that the Android app has no specific back button in the UI, since > > it is always part of the system UI itself. Plus I don't know of any app in > > Android that uses swipe left / right for 'back / forward' (I just checked > > Chrome), so perhaps we should let iOS have it, and just let Android be with > > the system back button? > > Consistency between the apps was my default answer, but nothing's set in > stone as far as I'm concerned; it may be that the swipe for forwards > behaviour just doesn't make sense on Android, and that's okay. > > Stuff like this is part of the reason why we're separating the iOS and > Android redesign into separate phases, so that we're sure that both > platforms end up with designs that make sense for them. :-) > > We'll revisit in a sprint or two when we get to looking at Android design. Much of the reason I brought this up is that it gives us a very inexpensive fix for the horizontal-scrolling issue which, to me, is currently a showstopper. Would it make sense to just implement it this way right now, then have further design discussions in 1-2 sprints, but at least have the scrolling issue resolved?
(In reply to Dmitry Brant from comment #6) > Much of the reason I brought this up is that it gives us a very inexpensive > fix for the horizontal-scrolling issue which, to me, is currently a > showstopper. Would it make sense to just implement it this way right now, > then have further design discussions in 1-2 sprints, but at least have the > scrolling issue resolved? Yeah, seems like a reasonably low effort thing to do that'll fix that really annoying bug for a while.
(In reply to Yuvi Panda from comment #7) > (In reply to Dmitry Brant from comment #6) > > Much of the reason I brought this up is that it gives us a very inexpensive > > fix for the horizontal-scrolling issue which, to me, is currently a > > showstopper. Would it make sense to just implement it this way right now, > > then have further design discussions in 1-2 sprints, but at least have the > > scrolling issue resolved? > > Yeah, seems like a reasonably low effort thing to do that'll fix that really > annoying bug for a while. In that case, go for it. :-)
Change 131920 had a related patch set uploaded by Dbrant: Changed ToC to be a sliding drawer from the right edge. https://gerrit.wikimedia.org/r/131920
Change 131920 merged by jenkins-bot: Changed ToC to be a sliding drawer from the right edge. https://gerrit.wikimedia.org/r/131920
Nice! I think this is a big improvement. I hope this drawers UI sticks around. I've broken out the suggestion for increasing the grabbable area for the drawers as bug 65004.
