Chronology: [Capture the gist of who said what, in what order. A transcript isn't necessary, but it's useful to capture the important points made by speakers as they happen]


Birgit: We have two different projects, but one common issue - how is the search results page designed. This session is an introduction to the projects and a discussion to what are the pain points for designing that page 

Dan: One issue we're dealing with is balancing the needs of the mass of basic readers/users, but also having a page for more complex editors search needs, such as searching for text within templates. We do believe its possible, but its a challenge.


B: Wikimedia Germany has been using the wishlist approach and workshops around specific topics to discuss & prioritize technical needs. Raymond, Lea (Productmanager), and I were talking about search as a topic. Search is super powerful, but people don't know about it. Held a workshop to gather feedback to discover common concerns. Many people didn't know about search keywords. They can't just be listed on a subpage somewhere. (B shows photo of workboard from search workshop. It shows groups of post it notes categories for keywords and search mapping -like things wikidata might handle)

we we had many ideas for how an advanced search filed might work. 


B: Getting to adavanced search is a bit hidden or indirect now. So one thing we sketched out was ideas for how to get to the advanced search page/fields. (B is sharing photos of ideas for how an advanced search interface might work from the workshop) one idea: there are lots of overlap between namespaces. Maybe a search that allows you to search "internal" namespaces (Project, User, etc) 


D: for example I didn't even know there was a "gadget defition talk" namespace

[Sidebar TheDJ: its not actually being used yet]


B: On german wikipedia (prototype), next to the search field, there is a gear which shows you the adavanced search options. Its not all search options, but the most common things like "in title" and other fields so you don't have to know the keywords and can learn what keywords are available.


B: the advanced search interface should be easy to understand and discover in the interface. 


DJ: the advanced search as it is now acts like an entirely new search (when searching by namespace). Perhaps it should be more like a filter and not an entirely new query. 


B: [follow-up question for DJ about his use case]


D: the way namespace is presented today is kind of weird. Do people know what a "namespace" is? Is there a better way to display this? A lot of user interface that might not make sense. 


DJ: most of my searches are not for the article but for the "project" spaces around the content (template talk, etc). Would be nice to have a "content" or "project" (or similar) groups of namesapces so I don't have to select each everytime I'm looking for something outside the content spaces


D: what if we had a filter interface, with options to search those internal items. 

B: One use case was a researcher who wanted to be able to search in certain categories or topic areas. Many of the needs can be adressed with those keywords, and people were excited to find out about the existing search keywords and what they could do, they just didn't know about it.

D: Yes, and currently the help page linked here doesn't really even get into keywords or advanced search. You have to scan pages of text and then at the end it says "Help with Cirrus Search".

B: And thats another very technical term, who knows "Cirrus search"? 

D: We can make the docs better, but having to have a long help doc is a sign that UI is too hard to use and complex


D: one thing we're looking at is exposing people to content from other projects. You search in English Wikipedia, and see results from other English language projects. We want to increase more awareness and participation in these projects.  [Dan shares the UI ideas and testing pages on MediaWiki.org

* https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements

* https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements/Testing


D: how will we expose this with balance between casual and experienced users?


JoshM: One suggestion would be to think of a continuum of complexity from simple keywords to our current keyword driven super edvanced search. It seems like power readers and editors might meet in the middle ground where form driven search (like Birgit presented) as a middle ground where there is some complexity but you get more assitance or guidance. 


ChrisK: One, sort of troll-y question: why segregate content in search at all? Why not just put all the content into a single bucket and let the "best result" be the best result across any project or namespace?


D: how do we know what people are looking for when they type something in? Is it content. They are after or project-related. (DJ gave the example of typing "Reliable Sources" into English Wikipedia. There is a hat note referring the Wikipedia policy on the content article)


ErikB: Any massive changes to ranking would require massive amounts of testing.


Leila: [Preface that this is a naive question] Why is search on Wikipedia not better than google? Our data is more structured and predictable, so it seems we should be able to do even better than general web search.


ErikB: A lot of it is resources. We have 3 people. 


Birgit: This is an interesting question, but lets focus on user experience of search page today. Lets talk after about the google question.


Amir: what about searches for pages with similar titles?


DJ: show links in disambiguation pages in results?


D: showing images in results is helpful in directing folks to the information they are looking for. 


JM: disambiguation pages were created before modern search engines were around. It's not duplicated elsewhere because it's not needed. 


D: searching disamb pages is tricky. They are not structured nor do they always have a helpful description...structured data would be nice. i hope they go away, because they are no longer useful. 

Maybe we could leverage Wikidata here... 


D: Any examples of good search interfaces or ideas we should be aware of?


Chris: Duck Duck Go provides a sort of disambiguation like presentation in their results: https://duckduckgo.com/?q=serendipity&t=ipad&iax=1&ia=meanings


Julien: There are some specific ways we can improve search: one is to have a cleaner/better training set. second we're dealing with a bit of mess on the UX, and we should be able to identify some small improvements to reduce confusion. In particular there are many ways to reach search, and they behave differently, which makes it even more confusing. Consistancy in the entry to search and search paths makes it hard for the user. For example google shows you the results page as auto-complete goes, whereas for us, some autocompletes take you to articles directly, while others take them to search results page. As the user I'm not sure how to get where I want. Reducing the confusion and having a simple workflow will be more effective than improving ranking and results. Adding more results will only make this more confusing.


D: This is why testing and data are important. We wouldn't add results if it reduces user satisfaction.  We do somewhat start in the "middle" of the search flow, and its worth reconsidering the entry points.


Amir: on hebrew wiki, a user made a user script that inserted search help into the Special:search. It had to be turned off for performance reasons, but it saw a lot of traffic.


????: There is a lot of unused white space on the right. Also one simple idea would be to disabiguate namespaces by using specialized color backgrounds or visual distinct.

Thomas PT: What about more natural language type search, especially using WikiData?


D: We're resource limited, so we'd love to see that but it would be a massive/expensive goal.