Page MenuHomePhabricator

As a user I want to be able to search in different languages easily
Closed, ResolvedPublic3 Story Points

Description

As a user I should be able to see search results in different languages side by side.

We are going to show 3 languages by default and a more button which opens the traditional language picker.
The spec for deciding which 3 languages is pending. for now if we can get languages from iOS or keyboard settings that would work.

  • Event Timeline

    Etonkovidova raised the priority of this task from to Needs Triage.
    Etonkovidova updated the task description. (Show Details)
    Etonkovidova added a subscriber: Etonkovidova.
    Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 12 2015, 6:19 PM
    Deskana triaged this task as Normal priority.Mar 16 2015, 9:55 PM
    Deskana moved this task from Needs Triage to Product Backlog on the Wikipedia-iOS-App-Backlog board.
    Deskana set Security to None.
    Deskana added a subscriber: Deskana.
    Fjalapeno reopened this task as Open.May 4 2015, 5:34 PM

    Repurposed for an iOS specific card.

    Related to: T87154

    Fjalapeno updated the task description. (Show Details)May 4 2015, 7:42 PM
    Fjalapeno added a subscriber: Vibhabamba.
    Deskana removed a subscriber: Deskana.May 4 2015, 7:43 PM

    Do not start until after hackathon - waiting for the initial Android implementation

    Fjalapeno renamed this task from Search in different languages: clearer indication that a user is searching in language specific Wiki? to As a user I want to be able to search in different languages easily.Jul 5 2015, 11:12 PM
    Nirzar claimed this task.Oct 7 2015, 11:28 PM
    Nirzar added a subscriber: JMinor.EditedNov 3 2015, 10:02 PM

    Here are two options for switching language while searching.
    (ignore the cancel button, that was something i was experimenting with)

    but there will be horizontal scroll of languages to choose from.


    This one uses the tab control for the content area below. so it is well connected to search results


    this one reuses the "autosuggest bar" for our languages so is in alignment with iOS. but it is connected to keyboard more than the search results

    Both have horizontal scroll of list of languages to choose from. obviously there shouldn't be a zero results case for this. if the article doesn't exist in language x then language x shouldn't be part of this horizontal list.

    The order of this list based on the user preferences for languages and also the existence of this feature is for multi lingual users. that's another question for us. how to determine if the user is multi lingual

    @JMinor

    @Nirzar @JMinor
    The horizontal scrolling list should be limited to around 6-7ish and then a "More" button that will open a modal list - sometimes there can be over 100 languages!

    First design is easier to see but I prefer 2nd design. Location is out of the way but still easily accessible.

    @JMinor let's go with Variation 1 because the keyboard conflict might come up in the usability test.
    should I move it to needs acceptance?

    Will move. I like 2 better visually, but think 1 makes more "sense" in terms of how those elements are used in the OS.

    @Nirzar @JMinor i recommend re-evaluating this picker design before moving forward.

    Looking at the proposed design, the following issues stand out:

    1. Scrolling to the language you want is pretty difficult. You can only see a few at a time and since you are limited by the width of the phone you may need to scroll very far to get to the language @KHammerstein mentioned.
    2. On version one, the language picker is cramped between 2 common actions - tapping the search bar and tapping the first result - this will result in accidental taps.
    3. On version two, the language picker is cramped between 2 other common actions - tapping a result and the keyboard. Additionally not depicted is the suggestion bar that is above the keyboard since iOS 7 which cramps area even more.
    4. (A more minor point) In both versions it takes up vertical space that would otherwise be used to display an additional result.

    Compare this to the existing language picker:

    1. There are no issues with efficiently finding a language, either by scrolling or by searching.
    2. There are no issues with tap area - if a user wants to change the language, we use the entire screen and provide the appropriate amount of room to perform the action.
    3. It is already built. (In fact we just built it a few months ago - it was the last feature we added to the legacy app)
    4. We could incorporate it in about an hour by simply adding the language button to the search bar.
    5. This language picker uses the newly developed design language of Wikipedia for selecting languages.

    If we want to test out new language picker UX, then seems like something we should do with prototypes.

    Since we have a working, modern styled implementation with all the advantages listed above, and we are on a tight schedule, it seems more pragmatic to make the minor tweaks to get it working, and invest the time we would spend on developing a new solution on higher priority work.

    Thanks @Fjalapeno for the thoughtful feedback.

    I'll let @Nirzar address specific tradeoffs, but just want to be clear this is just a couple proposed solutions. I'd be glad to use the existing language picker if we can find a good affordance and indicator within the current search bar. We're trying to move design alternatives/discussions earlier in the process so we can consider multiple alternatives as a group rather than water-falling from spec->mock->build, but doing that over phab ain't easy...

    @Fjalapeno hey...

    i think there is a misunderstanding with this. this picker is not supposed to replace the current language picker. this interface is just supposed to expose the current language picker modal window.

    Here's the model that i am trying to propose.

    you have a result set when you search something. you want to give a way for the user to browse multiple result sets.
    in our case multiple result sets are "different languages"

    In case of instagram here > the multiple result sets are "people, hashtags,photos"

    In iTunes app here > the multiple result sets are "different kinds of content" books, songs ,video

    one more example of browsing result sets

    this is very similar to the android implementation we have where you get a "EN" button next search which let's you go to the traditional language picker. the only difference is i am exposing some languages upfront. this improves visibility and encourages people to use this feature. (same hamburger menu vs. tabbar case)

    There can be a more button in that stack which will show you the traditional language picker.

    Does this explanation help?

    Nirzar updated the task description. (Show Details)Nov 6 2015, 10:42 PM

    @JMinor @Fjalapeno after last discussion of being sticky or not. i updated the treatment to make sure the language bar looks sticky and doesn't scroll with the results

    Sorry about this change. I should have taken care of that detail earlier.

    @Nirzar

    In addition to having to deal with long lang names better (so the buttons don't appear to bleed together) we'll need to figure out how to handle mixed script language names, because it is trickier to just truncate these without potentially losing too much meaning, and these have the additional problem of looking like 2 separate languages if the button has no defined border...

    Checked with 5.0.0.519 on iPad mini iOS 8.2

    • three languages that are displayed - they were the languages between which I switched during reading articles or changing wiki search lang
    • the language toolbar is sticky -does not scroll down
    • after viewing what was found in a different language and performing some search later - the preferred language returns to the wiki app search lang

    JMinor closed this task as Resolved.Dec 1 2015, 6:35 PM

    Some follow-up to do here with picker and details of language ordering, but basic feature is in place and functional.