Changes between Initial Version and Version 1 of BluePrint/SaveSearch_Sub


Ignore:
Timestamp:
05/10/11 18:58:39 (11 years ago)
Author:
Pratyush Nigam
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/SaveSearch_Sub

    v1 v1  
     1== Save Search & Subscription ==
     2
     3----
     4
     5
     6Searches and Saving them-[[BR]][[BR]]
     7
     8http://eden.sahanafoundation.org/wiki/Projects/Advanced/SaveSearch
     9[[BR]][[BR]]
     10 
     11The tentative idea is described in the lines to follow.[[BR]]
     12 
     13In saving a search, we can add the following functionalities -[[BR]]
     14
     15i)                    How to Save your Search[[BR]]
     16ii)                  Revisiting a Saved Search[[BR]]
     17iii)                Deletion of a Saved Search[[BR]][[BR]]
     18
     19 
     20Data Model
     21 
     22The proposed data model for fulfilling the purpose is as follows -
     23 
     24                Search(Entity)
     25User_id
     26Search_criteria
     27Datetime
     28
     29
     30 
     31Key attributes – User_id, Search_criteria
     32Other attribute(s) (may vary) – Datetime
     33 
     34The 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 (auth_user.id 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/savesearch.py 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.
     35 
     36However, 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.
     37 
     38UI layout
     39 
     40i)                    Widget on search results page –
     41 
     42The 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/search.py. 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.
     43 
     44 
     45 
     46ii)                  Review of Saved Searches –
     47 
     48A 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.
     49 
     50 
     51 
     52Subscription-
     53 
     54http://eden.sahanafoundation.org/wiki/Projects/Advanced/Subscription
     55 
     56After going through the subscription models implemented in various websites like the DRR Portal by Sahana-Eden, Yahoo Directories , Google Groups , StumbleUpon , Scrobbler API by last.fm and the ones implemented in my college IIIT-Hyderabad , a suitable subscription model which would look as described in the lines that follow.
     57 
     58 
     59Data Model
     60 
     61Subscribed_search (entity)
     62Search_id
     63Last_updated_datetime
     64
     65
     66 
     67                        Key Attributes – Search_id (Foreign Keys)
     68 
     69 
     70Subscription_mode (entity)
     71User_id
     72SMS_sub
     73Twitter_sub
     74Email_sub
     75Type_email_sub
     76
     77
     78 
     79                        Key Attributes – User_id(Foreign Key)
     80 
     81 
     82                The Search_id attribute in Subscribed_search (entity), is a foreign key referenced from the Search.id 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/subscribe.py 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).
     83 
     84The User_id attribute in the Subscription_mode (entity) is a foreign key referenced from the auth_user entity (auth_user.id 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.
     85 
     86 
     87 
     88UI for Subscription
     89 
     90The 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.
     91 
     92UI for Updated Subscription
     93 
     94There 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.
     95 
     96There 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 -
     97 
     98     Fig. 1 – Mock UI for Widget
     99       
     100
     101
     102
     103
     104
     105
     106
     107
     108Fig. 2 – Mock UI for Subscription Update
     109
     110                Fig. 3 – Mock UI for Review of Saved Searches and Subscription