[Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)

Simon Schampijer simon at schampijer.de
Wed Aug 29 07:41:40 EDT 2012


On 08/28/2012 05:53 PM, Gary Martin wrote:
> Hi Simon,
>
> On 28 Aug 2012, at 14:12, Simon Schampijer <simon at schampijer.de> wrote:
>
>> On 08/28/2012 02:14 PM, Manuel Quiñones wrote:
>>> So now the filtering is shared between the three views.  I think this
>>> is worth noting in the commit message.
>>
>> Thanks for the review and catching this! I did note it in the commit message before pushing.
>>
>> Gary, we did discuss the following:
>>
>> There seem to be three options how the search now that we have a search entry in each view could work:
>>
>> - if you did a search in View A and then switch to View B the entry will be cleared leaving you with no search applied in B
>>
>> - if you did a search in View A and then switch to View B the search from A will be applied to B (behavior which landed in 0.97.2)
>>
>> - if you did a search in View A and then switch to View B the search from A will not be applied in B, if you switch back to A the search you did before in A has been cached and is still applied (behavior before 0.97.2)
>
> Thanks for raising this change! I'll need to give it some more though and test the patches.
>
> My gut reaction so far would be for the clearing behaviour,

You can use the attached patch to test that behavior. I think I like 
that behavior as well. Preferred over caching, as you say it may lead to 
unexpected behaviors.

second choice would be the caching behaviour. My reasons against the 
0.97.2 behaviour change would be that different views contain dissimilar 
enough objects that a search in one is not often useful in another (e.g. 
searching for a buddy or access point, and switching to home), and that 
will drop the user in an unexpected UI state. A reason for clearing the 
search when switching views is that it prevents issues for novice users 
who leave a query in place unintentionally, and return to find a view in 
an unexpected state without realising they need to clear the old search 
query manually. Though so far, caching previous search queries in a view 
is just what we've been doing in the shell. FWIW: home list view is the 
worst offender as it shows a blank white canvas when a query has no 
matches, should really behave like the Journal with the 'No matching 
entries' UI. The 0.97.2 change may well lead to an increase in "my icons 
are all grey/gone" type support reports, especially from young users who 
may randomly press keys and generate a shel query without realising it.
>

Thanks Gary, good catch about the needed feedback in the list view, 
filed as [1] (feel free to add there wordings/icon to use etc). Once the 
shell port is done, it should be straight forward to add.

Btw, re Activity list view. We said at one point that the date displayed 
in the list has not much meaning (at least at the moment). Did we have 
an idea for a replacement?

Thanks,
    Simon

[1] http://bugs.sugarlabs.org/ticket/3838
-------------- next part --------------
A non-text attachment was scrubbed...
Name: view_toolbar_search_behavior.patch
Type: text/x-patch
Size: 1093 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120829/ab716491/attachment-0001.bin>


More information about the Sugar-devel mailing list