Version 2 (modified by Pratyush Nigam, 13 years ago) ( diff )


Save Search & Subscription

Searches and Saving them-

The tentative idea is described in the lines to follow.
In saving a search, we can add the following functionalities -

i) How to Save your Search
ii) Revisiting a Saved Search
iii) Deletion of a Saved Search

Data Model The proposed data model for fulfilling the purpose is as follows -


User_id Search_criteria Datetime

Key attributes – User_id, Search_criteria Other attribute(s) (may vary) – Datetime The search can be saved by sending them into the database. Usage of the web2py cache will also be employed . The User_id attribute, one of the key attribute here is a foreign key that will referenced from the auth_user entity ( attribute preferably) from the already made databases. This and related database and tables that may come up as the project progresses will be implemented in the /models/ file although there will be a few lines of code that would be added in the S3Search module (they won’t affect the code’s working) in order to store the search criteria/filters(put in use by the user to search his query) in the database later thereby saving the search if the user clicks on the save button. One prerequisite of the saving the search is that the user should be signed in to save his search result/query and also the number of recent searches that a particular user saves will be limited and when it exceeds that fixed limit, the least recent can then be deleted (this justifies the datetime attribute). The Search_criteria field will store the query and the filters that the user will employ for searching his query. However, this description just outlines the data model because I am still in the process of going through the S3Search module from which the following data model is going to gather the data. Presently, the idea is to add some lines to the S3Search module which won't affect the functioning of S3Search module in any but take out the data like the search criteria, user_id and datetime to store in savesearch database table. UI layout i) Widget on search results page – The widget for saving the search will appear on the search results page, basically it will be a button which asks the user the particular search must be saved. The user thus gets the option of saving the search, which if he/she uses will get saved in the database specified above using a function savesearch() in /controllers/ Suitable adjustments for facilitating this function will be made via /views/search/save.html (tentatively). A very similar example for it can be viewed by clicking here. ii) Review of Saved Searches – A user interface would be made to view the searches that were made in the past. The user will have the option of reviewing the updated search results and delete the queries made in the past and other features that might get included as the project progresses. Subscription- After going through the subscription models implemented in various websites like the DRR Portal by Sahana-Eden, Yahoo Directories , Google Groups , StumbleUpon , Scrobbler API by and the ones implemented in my college IIIT-Hyderabad , a suitable subscription model which would look as described in the lines that follow. Data Model Subscribed_search (entity) Search_id Last_updated_datetime

Key Attributes – Search_id (Foreign Keys)

Subscription_mode (entity) User_id SMS_sub Twitter_sub Email_sub Type_email_sub

Key Attributes – User_id(Foreign Key)

The Search_id attribute in Subscribed_search (entity), is a foreign key referenced from the field(which get formed and is unique) of the Search table given in the data model for save search. This and related database and tables that may come up as the project progresses will be implemented in the /models/ file. The Last_Updated_datetime attribute is taken in order to store the last time the user was sent the notification of update and so that the update can be made. The interval between the two notifications can be done on hourly/daily/weekly basis with the help of web2py cron and jenkins continous integration tool (thereby implementing the feature of customizing the frequency of notification).

The User_id attribute in the Subscription_mode (entity) is a foreign key referenced from the auth_user entity ( attribute preferably) from the already made databases. The SMS_sub , twitter_sub and email_sub will have yes/no option for the user tell which mode of the notfication they will prefer (this will be implemented with the help of messaging module present in the sahana-eden software, would have to look into the email-styling aspect). The type_email_sub will specify the frequency of notification through email. However, this description just outlines the data model because this data model depends a lot on the save search data model for retrieval of the data. So, there are bound to be some modifications as the job of designing proceeds. UI for Subscription The UI for subscribing to the saved searches can be implemented that the user would use for reviewing his saved searches. The saved searches will be ordered according to a particular field and there will be a subscribe button for each saved search listed there which the user can click on to subscribe to that saved search. Same page will also show the option for unsubscribing to a particular subscribed saved search. A very similar example for it can be viewed by clicking here. UI for Updated Subscription There will be a separate UI for the user to view the updation for his subscribed searches. This model can be based on something like google reader where the user will click on the subscribed saved searches and then would be able to see the updates on the UI. This model is a tentative one and can be modifed in future to allow more usability. A very similar example for it can be viewed by clicking here. There will be options to subscribe to different modes such as e-mail, sms, twitter etc apart from the UI provided for updated subscription. The mode of subscription will be user-preferred and it will be implemented by using the messaging module present in the sahana-eden software. The emails can be sent in two formats i.e. html or plaintext out of which plaintext seems to be a better option at this moment because it depends upon the user’s agent (end system) on how it displays the html content(which might differ from the desired form). Mock-ups for UI’s can be found below - Fig. 1 – Mock UI for Widget

Fig. 2 – Mock UI for Subscription Update

Fig. 3 – Mock UI for Review of Saved Searches and Subscription

Attachments (4)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.