@schoenbaechler Let's talk about a design for this.

Relevant to this are some old designs for the same issue on iOS:
T141874

Added to my list! How about we chat about in our 1:1 today @Charlotte?

Excellent! Some light commentary to kick things off:

[When searching in “My lists“ and "History"]
When users tap the search field (active search input), the view that’s displayed remains the same as in the current release of the app. The search, once users type a search term, behaves exactly the same across “Explore“, “My lists“ and “History“.

This will not be easy to accomplish. The current Search interface (i.e. the interface that we will be enhancing) is a separate activity that must be launched separately, and will no longer be integrated directly into the "My lists" and "History" sections. It would be much simpler to launch this activity, perhaps with a transition animation.

The “Article is open in tab and saved in reading list“ might be confusing. Do we really need to show both indicators or should we just show and prioritize the “Article is open in tab“ (switch to open tab) or “Saved in lists“ (bookmark) icon in that case?

I would agree that we don't need a separate "tab+list" icon, when we can just prioritize one or the other.

Should we think about introducing an “All“ option in the when users have set multiple languages? If we do that, we could further streamline the search across the app.

I'm not sure what benefit this would add. If the new Search interface will search through all open tabs and reading lists, then it doesn't matter what language they're in. It will match the search results regardless of language.

Just chatted with @Pginer-WMF about it, here’s his feedback:

General:

• It makes a lot of sense to list open tabs in the search
• Mentions to be aware of the use cases of the search and lists, e.g. by:
  • Doing user research sessions
  • Talk to users that use lists a lot
  • Contact users that use lists with a standardized questionnaire
  • Usability testing, once something has been drafted
  • Analysis of zero results

Design:

• MB information for list items isn’t necessarily needed in search view. Space could optionally be used to indicate what the element is, e.g.: “5 articles in reading list“ {Robin agrees)
• “Article is open in tab and saved in reading list" icon is not necessarily needed, just showing the bookmark icon is sufficient
• Use description to explain the icon on the left, e.g. by labelling it “Switch to this tab“ (similar to Chrome).
  • Robin: maybe use a different color to indicate it as a hint and to not mistake it for the description; also if users know their tabs, they probably don’t need the description.
• His expectation when searching in “My lists“ is: To search his list - if the global search is not in the way, then it’s fine to also show results there.
  • Robin: Worthing exploring is using the empty state, e.g. by saying: didn’t find it in your reading list? Search Wikipedia instead (and then users would be redirected to the global search)

Thanks Robin for updating the detail of this ticket, that's amazing!

Just have an idea that maybe we can have a filter feature that allows users to toggle on/off places they don't want to search.

For example, if the users like to search only the Wikipedia article and dont't want to see any other articles or lists, they can use the filter feature to toggle them off.

But it might bring out a question that what is the default behaviors for the "My lists" and "History" pages if having the filter feature.

Hey @cooltey @Charlotte @Dbrant & @Sharvaniharan, I’ve updated the task’s description and adapted the scope of this project.

After the conversations from last week and a re-evaluation of the actual state, I suggest to go with a simplified approach for improving the search in “My lists“. Why? Because a change of this scale needs research and data in the first place. The overhauled design suggestion in the task’s description bases on the initial idea, is future proof and reduces the scope of this task to “My lists“, as it was initially intended. With that said, I’m looking forward to discuss these related ideas that we’d like to pursue and create separate tasks for it.

Happy to talk it through in tomorrow’s story prioritization meeting.

Hey @schoenbaechler - thanks for updating this. Answers to your questions:

The “Article is open in tab and saved in reading list“ might be confusing. Do we really need to show both indicators or should we just show and prioritize the “Article is open in tab“ (switch to open tab) or “Saved in lists“ (bookmark) icon in that case?

Let's remove the indicators altogether. As we discussed over Hangouts, users are unlikely to understand these indicators without them being explained. @Dbrant
can show you how we are already indicating that an article is redirected - and I think we can use the same thing to indicate whether a user has an article in lists, or open in a tab, etc.

Do we really need an indicator for open tabs or should we just list them first? Not displaying it would reduce clutter.

No need for the indicator

Should we think about introducing an “All“ option in the when users have set multiple languages? If we do that, we could further streamline the search across the app.

This adds a great deal of overhead to the search queries, so for now let's stick to searching in the user's main language. We should also show the language change icon in all search views so that the user is able to switch languages if they wish.

Should we consider an icon to indicate lists or is the tile view sufficient? There’s a material design icon for bookmarks (plural).

The tile view seems sufficient - and we can do some internal testing that will tell us whether that assumption is correct or not.

We can also remove items 1 and 5 from the hierarchy above - except in the case of search from History, in which case obviously the articles in the user's history should be included in results.

@Dbrant and I just talked about the this task and he mentioned that introducing tabs in the list view will probably cause the highest implementation costs.

Rita stated that the demand for a “My articles“ view was a minor piece of feedback from the “Android reading list with sync usability test (T186273 | Slides). Since we’re keeping the existing paradigm where users are selecting a list first, I suggest to not consider an additional “My articles“ tab. Updated the task’s description and mocks accordingly.

CC: @Charlotte @cooltey @Sharvaniharan

Hierarchy of results:

1. List names
2. Titles of articles saved to lists

Changelog:

• Added missing more icon to F28013717 (@cooltey)
• Updated the designs with treatment of long list names F28016713 (@Sharvaniharan)
• Removed tabs in mock F28016715 (@Sharvaniharan)
• Increase touch target and design of list indicators F28016713 (@Charlotte)
• Removed bottom nav from screen F28013738 (@Dbrant)
• Added screens to Zeplin
• Put all relevant information into the three subtasks.

Changelog:

• Introducing chips for lists that are horizontally scrollable, as discussed with @Dbrant @Sharvaniharan and @cooltey. This means the separate view for lists when tapping on a list name within an article result item won’t be needed anymore.
• Deemphasized the style of the chips since it’s a secondary/tertiary action of the search
• Removed images from the tasks to maintain a single source of truth. All designs are now split up by ticket on Zeplin:
  • Search in “My lists“ | T214504
  • Search in “My lists“ | T214505
  • Search in “My lists“ | T214506

CC: @Charlotte

Cheers @schoenbaechler - if this is now ready for work to be done, you can put it in the "ready for dev" column.

It is indeed @Charlotte, thanks for the nudge! 🚀