Page MenuHomePhabricator

History: adjust touch selection states for elements in view
Open, LowPublic

Description

Currently, there's some mismatch between the touch selection states for elements in the History view. This leads the user to believe that some elements that are tappable here aren't and vice versa.

  1. Add "touch down" selection state for individual revisions in the list. Similar to the Compare and back buttons, would be beneficial to add a "touch down" selection state (perhaps reducing the element's alpha like those navigation bar elements) to indicate the revisions are tappable.

history_selection_state.gif (732×372 px, 746 KB)

  1. There's currently no functionality in tapping individual revisions in the bottom revision comparison bar, so perhaps we can remove the touch selection state here.

history_revision_selection.gif (732×372 px, 859 KB)


Proposed design solution

Would it be possible to 'pulse' the corresponding revision on tap by gently increasing the fill saturation and then returning it to its normal state? This way users will be able to tell that the item that they tapped on is related to one of the selected revisions.

Blue tapped on defaultBlue tapped on darkOrange tapped on defaultOrange tapped on dark
On tap flash color - Blue selected on Default.png (1×750 px, 143 KB)
On tap flash color - Blue selected on Default (1).png (1×750 px, 142 KB)
On tap flash color - Orange selected on Default.png (1×750 px, 143 KB)
On tap flash color - Orange selected on Black mode.png (1×750 px, 143 KB)
https://zpl.io/2vwALQJhttps://zpl.io/2ZemYdGhttps://zpl.io/amo7KJ3https://zpl.io/aBLdonk
Design details

For default
Change background fill color to #FFDAA6 (Orange) and #CADCFF (Blue) in the toolbar and the list view
If possible ease in/out of color change.

For other themes
Change background fill to the same colors but with increased opacity to 35% (vs 20%)
If possible ease in/out of color change.

For Article as a Living Document
This same highlight should apply (let's use the blue color) when the reader taps through to History via the 'veiw changes' button on the modal in the experiment.

Event Timeline

We should put focus on the associated tapped revision, especially if the revision is currently visible.

We might want to prioritize this slightly as we will want this for transitions (tapping on 'view changes') for the Article as a Living Document work.

LGoto moved this task from Product Backlog to Garage on the Wikipedia-iOS-App-Backlog board.