[Scopes] [golang] Search fails in subdepartments

[Michał Karnicki]

(Please also see comment 14 relating to this issue in go scopes.)

Take any scope with departments. Pick a unique result from any department other than the "root" department (say, the second or last one). Search for that item in the scope.

What should happen?
I should be able to find that item within the department I'm viewing.

What actually happens?
I (might, depending on the amount of other matching results) see the result when I input the first letter. However, when I continue typing (second, and further letters) the department is reset and the search actually happens within the root department (department in search is reset to "").

------ UX Comment ------

As per @jamesjosephmulholland last comment - the desired behaviour is that searches should apply to the currently selected department beyond the first letter entered into the search field.

For further information please see Filter widgets in Scopes spec: https://docs.google.com/document/d/1xWNpO3UUdmVak0NZ63yaDTF8Il0P_UF96Y2eOiBVBz0/edit

[Kyle Nitzsche (knitzsche)]

I confirm that this happens one of my scope that uses departments.

[Michal Hruby (mhr3)]

Adding ubuntu-ux task, as this is by design.

[Michi Henning (michihenning)]

Removing unity-scopes-api because it looks like a shell issue (if any).

[Mike Nagle (mikenagle)]

I can confirm this is by design. The related UX issue you describe will be fixed once we have filters.

[Kyle Nitzsche (knitzsche)]

It does not yet make sense to me that it is by design and if so why.

If it is by design, I don't see a straightforward way to search for results in a department other than the root dept, which seems like a severe limitation.

Here's an example that illustrates based on a scope I am writing now. It provides public transport alerts from various RSS feeds for different areas.

It picks the best feed for the user's location and makes that the root department, and then it provides other relevant feeds as departments.

For example, the root department may be Barcelona feed. Other departments may be a Madrid feed and a Catalunya feed.

So on launch, Barcelona results show, and searching works, returning matching results in the Barcelona feed.

Suppose the user wants to check the Catalonia transport alerts, so they pick the Catalonia department and Catalonia results display. Maybe there are 100 results and they want to find a particular one with search.

HERE's the PROBLEM:
the first letter entered in the search applies to the current department (Catalonia). However, starting with the second letter entered, the search applies to the root department, in this case Barcelona. This prevents the user from finding any results in Catalonia.

Is this by design?

[Kyle Nitzsche (knitzsche)]

Another example:

I wrote a BBC scope that uses departments. The root department is News, and there are many subdepartments, like World, Business, Nature, etc.

So, assume the user opens the Nature department and wants to find the article about "honey bees". They enter 'h', and only Nature articles with 'h' display, which seems correct. The PROBLEM: then they add 'o' (second letter in 'honey'), but now the honey be article does not display, instead only articles in News (the root department) display. Again, they cannot search for an article in a department other than root.

[Michał Karnicki (karni)]

I agree with Kyle here, it makes no sense to me. We'd like to know the reasoning and advised solution -- and if that uses filters, will we get those for RTM or are they post-RTM? If post-RTM, then we clearly need to fix the designed behavior (also, why the second and not the first letter starts the search in the root dept?) Thanks!

[James Mulholland (jamesmulholland)]

I cannot speak to my predecessors reasoning (or find any evidence in the documentation) to support that this is 'by design'.
I am also unclear as to what he meant by 'The related UX issue you describe will be fixed once we have filters' as the filters we currently have in Amazon, Ebay, etc. do not appear to address this issue.

I tested this just now by going to the Amazon scope, choosing the Books department. Starting a search and entering the first letter resulted in books being shown, while entering a second letter appeared to result in the root department being searched.

I agree with Kyle and Michał's take on this problem:
Searches should apply to the currently selected department beyond the first letter entered into the search field.

[Kyle Nitzsche (knitzsche)]

This is fixed committed but I am still unable to search the current non-root department. The search is performed on the root/surfacing department.

phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 60
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2015-07-08 14:20:18
version version: 60
version ubuntu: 20150708
version device: 20150529-8e13c5f
version custom: 20150528-722-29-15-vivid

[Kyle Nitzsche (knitzsche)]

Sorry, my last comment was incorrect. I can search strings with multiple letters in my agg scopes (like News) that have multiple departments from any department.

To be clear, here is what *works*.

News has several depts, including Headlines, Sports, Finance.

Suppose there is a result in Sports mentioning Tiger Woods.

If I am in any department and search for "Woods", the search succeeds:
* The department selector is not displayed
* The Tiger Woods result displays
* All other child scope search results display

On dismissing the search, the root department displays.

So all looks good.

com.canonical.scopes.news 3.3.8
phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 446
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en-proposed
last update: 2015-07-09 17:10:22
version version: 446
version ubuntu: 20150708.1
version device: 20150529-8e13c5f
version custom: 20150709-813-29-20-vivid

[Kyle Nitzsche (knitzsche)]

I added go-unityscopes because this bug appears in a go scope I've written in which I am unable to search the non-root department when the query string is 2 or more letters long. In such cases, the search is performed on the root department.

[Kyle Nitzsche (knitzsche)]

set to status New in savilerow for tracking

[Yuan-Chen Cheng (ycheng-twn)]

@kyle, if this only happen in go scope ? let's either modify the subject or create a new issue for it.

[Kyle Nitzsche (knitzsche)]

@yc. it used to happen in c++ scopes but it was fixed. Now I see it also happens in go scopes.

For example: launch the Yelp scope (a golang scope). Navigate to a sub department and notice a string in one of the results. Search for that string:

Result:

* focus switches to root department
* search fails to find the result

[Kyle Nitzsche (knitzsche)]

I will reopen this against UX since it is a UX problem for go scopes.

[Kyle Nitzsche (knitzsche)]

Please note that this inability to search in subdepartments of golang scopes is a notable deficiency for users.

Can someone from UX or elsewhere please indicate they have seen this bug? thanks.

[Paty Davila (dizzypaty)]

@knitzsche, I can confirm I've seen this bug and commented on it. And here's the latest design spec that describe the default behaviour for searching and filtering capabilities within scopes:
https://docs.google.com/document/d/1xWNpO3UUdmVak0NZ63yaDTF8Il0P_UF96Y2eOiBVBz0/edit#heading=h.7mxnfoxz2x47

As mentioned before, the search should be applied within the currently selected department / category, beyond the first letter entered into the search field. In general, the desired behaviour is as it follows:

Searching and filtering journey (annotated wireframes available in the spec):

- On tap of the search icon, the search field expands from the right to cover the whole header. The user has entered search mode.

- The search bar is on focus and contains a the cue text (“Search around you…”). OSK is present and a ‘Cancel’ text button is placed on the left that will allow the user to exit Search mode.

- User can select from search history or from one of the categories items available in the ‘Search panel’ (current annotation widget).

- At the same time, a “keyword brick” is generated and placed inside the search field. Content updates on the background to match the searching criteria. The Keyword brick can always be removed by tapping on the ‘X’ icon on the right hand side of the search field.

- User can tap on the search field or on the "keyword brick" to bring the ‘Search panel’ back. Also, a ‘Filters’ icon appears on the rightmost side if the search field.

- The panel shows the selected category matching with the ‘keyword brink’ inside the search field. User can type more additional -text- keywords to narrow down the search within the selected category.

- On tap of the search field the OSK reacts and user can start typing the search query.

- Content updates on the background to match the searching criteria.

- Below the search bar, a sub header displays the number of available results and a ‘View’ icon that let you switch the content between grid and list view. (TBC)

- On tap of the ‘Filters’ icon, a popover appears on top of the content, displaying all the available filters.

- User starts interacting with the filter widgets.

Please let me know if you have any questions or anything that you'd like to discuss : )

[Kyle Nitzsche (knitzsche)]

Hi Paty.

Thanks for the info. This seems to confirm that the issue is simply that the golang unityscopes v2 api [2] does not perform searches in the current department (although c++ api does)

https://code.launchpad.net/~unity-team/go-unityscopes/v2

[Marcus Tomlinson (marcustomlinson)]

James, could you confirm that this is not a Go bindings specific issue? Not sure how it is that a C++ scope would work and a Go scope would not? If this was a global fix, shouldn't all scopes be working regardless of language used?

[Marcus Tomlinson (marcustomlinson)]

This bug should be fixed as part of a global fix that will be resolved by addressing bug #1471914.

Therefore, I am marking this as a duplicate of bug #1471914.