Re: Implementing Saved Searches

[Scott Gray]

Inline, thanks again for your comments Bruno.

On 1/12/2009, at 10:21 PM, Bruno Busco wrote:

Hi Scott,
inline

2009/12/1 Scott Gray <scott.g...@hotwaxmedia.com>:

Hi Bruno,

Thanks for sharing your thoughts, comments inline.

On 1/12/2009, at 7:30 PM, Bruno Busco wrote:

Hi Scott,
this is on my list also.

This is how I did imagine it:

**UI:
In the search options screenlet of the FindScreenDecorator:

user?  I placed it in the form widget itself for a couple of reasons:

preference and styled on a per form basis

text box to allow a name to be entered and saved.

the form target

partially completed form

This is interesting, how do you plan on presenting the drop-down to the * So that it can be positioned within the form according to the developers * Because of the dual behavior I had envisaged for the form, i.e. it is a drop down initially but if a new search is performed then it switches to a * The list of saved searches to populate the drop-down list is dependent on * The new form element could also be used in the future to save a draft of a

Agreed. Having it in the form widget sounds good to me.

- a drop-down apperars if one or more saved search are available for
that search. If the user selects one of the options all the search
fields get populated automatically.

And the search results are presented at the same time right?

Shouldn't the user be able to change some of the values in the fields
before running the search?

In this case it would be better to only fill the fields and then press "search".

I guess that could be possible but it would be more difficult to implement we'd either need to send all of the parameters out for each saved search when we render the form or do an ajax call to get the parameters plus we'd need javascript to populate the form fields. I had planned on just triggering a submit when the selection in the drop- down changes (this is what SugarCRM do, not that I consider that a justification). I had been considering that in the majority of cases the saved search will meet the users needs without modification. Either way this will be possible regardless of the implementation but if I am doing the implementation I would prefer to leave it out and then we can add it later and perhaps even make it configurable in the form widget xsd.

Not yet defined how to let the user delete a saved search.

link is now present next to the drop down.

Yeah I haven't done that either, I was thinking perhaps a delete link could be presented once the user performs the search to be deleted. So the user would select a search from the drop-down, the search is performed, a delete

May be we could think to a "My saved searches" screen where the user
sees all his saved searches and can edit their names, delete (or even
share them at a later stage).

That sounds like a good idea to me.

- "Save this search" button is shown to let the user save the actual
content of the search fileds.

Agreed

- A name field allows to set a name for the search the user is going

search.

to save. This is what will be displayed on the drop-down to select the

new search is performed.

Agreed, the plan for me was to switch the drop-down out for a text box if a

Agreed. This is great!

- There should be the possibility to share saved search in same way
letting them being visible by all users.

the list would quickly become too long for a drop-down to be useful.

I think this is nice to have but a little complicated because who are we sharing it with? I doubt we'd want to share them organization wide because Because of the complications I had planned on leaving this until someone actually needed the functionality or someone else felt like working on it.

Agreed. Lets start simple for now.

- All this is only available if the user is logged in. No search save

is possible for not logger users.

Agreed

**Code:

idea.
Every search screen should have a unique key that will be used to
store a preference.

Adrian suggested to use userPreferences for this and I think it is a good

would the name and value consist of?

I did read this suggestion but I didn't feel that a single key- value pair was a good fit for the amount of information that needs to be stored. What

Agreed. This seems to complex to fit in there...

Great, if you have time please do review the entities, I'd like to get as many eyes on them as possible since they tend to be difficult to re- factor down the road.

I am using the userPreferences to store the screenlet collapsed status

also, I did not commit yet but I will do soon. In this case the
screenlet-id is used as key.

unique key and a single value.

This makes sense for a UserPreference record because it is naturally a

Additionally, I would like to use a saved search to automatically run a report periodically. To do this I need to pass the saved search as a

parameter to a service.

things in mind.

+1 I see a few potential uses for persisted forms/requests, saving drafts, creating reports, possibly even the most recently viewed items feature that we've talked about before. I tried to create the data model with these

Thank you very much for sharing all this!
-Bruno

2009/12/1 Scott Gray <scott.g...@hotwaxmedia.com>:

We've discussed in passing a couple of times now the possibility of
allowing

perform

some implementation notes for feedback from the community.


that).

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

users to save their searches/finds in order to allow them to quickly the search again in the future. I'd like to get this implemented in the very near future and since there have been a few different ideas thrown around about how that might be achieved, I've gone ahead and put together No code has been written and opinions of any nature would be greatly appreciated, since it's not a major feature I'd rather only wait a day or two before getting stuck in (unless of any conversations take longer than

smime.p7s
Description: S/MIME cryptographic signature