DotNetNuke Module - Trip Planner (.Net)

**DotNetNuke Module Introduction - What is "Trip Planner"** The trip planner DotNetNuke module is supposed to provide an easy request form for travelers allowing them to specify dates and type of travel packages types they are interested in. The returned result will show all the packages /promotions that are currently available for bookings and travel in the time period the user specified and within at least one of the package types the user defined. The user will then have the ability to view more details of the promotion or book directly, which maps out to third party booking engine. Thus in its simplicity this module will allow an admin to load a "package" with certain attributes and allow a consumer to make a search based on their preferences the system will then filter the existing packages and display all the matches. The consumer can now view some information and/or link out to third party site for booking of trave. ## Deliverables See attadhed file for details requirements. **Trip Planner Introduction** The trip planner DotNetNuke module is supposed to provide an easy request form for travelers allowing them to specify dates and type of travel packages types they are interested in. The returned result will show all the packages that are currently available for bookings and travel in the time period the user specified and within at least one of the package types the user defined. The user will then have the ability to view more details of the package or book directly, which maps out to third party booking engine. Thus in its simplicity this module will allow an admin to load a "package" with certain attributes and allow a consumer to make a search based on their preferences, the system will then filter the existing packages and display all the matches. The consumer can now view some information and/or link out to third party site for booking of travel. **High Level Overview** The system will be a three part module (at least) with an admin system that will enable the user to define what package types will exist (e.g. Honeymoon, Golf, Spa...etc) as well as add specific packages (Description of a travel package) by the following attributes: images (1-n), description, URL to booking engine, attributes a, b , c, ...n. Each of the promotions will be associated with at least one package type. Each promotion will have booking start and end date as well as travel start and end date. When the end user submits a search the current date is used to make sure it falls within the range of a promotion's "Booked" start and end date in order for that promotion to show. The dates the user enters will be the travel dates. Further restrictions will also be applied such as minimum/max number of nights, airline restriction, specific hotel, car rental.... (do not misunderstand us, this has nothing to do with inventory management, this is just describing what the promotion that is created in 3rd party system includes). Furthermore, the admin module will enable the admin to customize the look and feel of the consumer module by templates using tokens for the specific attributes that exist - possible to allow for customized tokens as well (please review Ventrian's property agent as using that system with a customized skin might work - Ventrian's model provides you with the source code. ([login to view URL]). The consumer module's look and feel is completely dependent on the templates defined in the admin module - it will include an initial screen with dates selection (start and end dates), number of passengers (adults, children (if children then ages)), a sub section underneath the dates, or to the right hand side - The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 2 the template will dictate that - with the different package types will be displayed with checkboxes in alphabetical order or in the order defined by a template. The admin will have the option to define what categories are pre-selected (probably in the module settings?). The user will have the option to bypass any of the settings, thus there will be some button or link stating "show me all" or allow the user to only select some of the categories thus show all for that category independent on the dates or vice versa. The search should use Ajax or similar technology and remain on the same page within the same modules - or separate page?. Once results are returned the previously shown sections will be hidden and a new section will show all the packages that match the search criteria. The layout of this will be indicated by the templates and some of the settings in the module, such as how many should be shown prior to show pager. The user will now be able to do multiple things: Additional Information: the user will be able to click some section of the module to either go to different page or pop up a layer to display further information. Book: the user will be able to click book now. If the user did specify dates and number of travelers this has been saved in the session (or similar place..) so we would append this to the actual search which takes the user to third party site - at that point the "job" is done. Filter: An additional module (Similar to what you can find under [login to view URL] - trip planner) with Ajax driven filter controls which are in reality the same as the user initially used to search, thus Dates, travelers, and package types - the package types and search is pre-populated with the search criteria. If we could also use some of the search criteria that would be great to further filter using some Ajax control to scale e.g. 5 star properties to 1 star property with a "glider" - e.g. [login to view URL] type. There should be a tracking mechanism in place defining the number of times a promotion has been viewed, clicked to book etc. There might be some synergies between what we are developing and the Ventrian's property agent, please go ahead and review that module to see if we can tailor it to fit our needs. The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 3 **Main Trip Planner Module** 1.0 As shown in figure 1, the Main Trip Planner Module (MTP) request/search section will consist of 2 consumer facing sections; 1.1 Date and passenger section; this section includes fields for the user to input the start date, end date, Number of adults, and number of children. Table 1 defines the actual fields and its settings 1.2 Category and filtering section; this section includes fields for the user to specify certain categories and other filtering mechanisms, i.e. point of interest. Figure 1. Example derived from Beavercreek.com. Note: in the initial version we will not have the adults/children section. Table 1. MTP Page 1 fields **Field Name Type Value Size/Caracteristics** Departure_lbl Label Departure Date: N/A Return_date Label Return Date: N/A Departure_lbl Text box 10 Return_txt Text box 10 Hotel_lbl Label Accommodations: N/A Hotel_dd Drop Down Box Populated with Hotelier list defined in admin module N/A - dynamic Price_lbl Label Price Range: N/A Price_dd Drop Down Box Populated with Price range list defined in Admin module N/A - dynamic Packages_txt Label Package types: N/A Packages_Checkbox Checkbox list Populated with packages types defined N/A - dynamic The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 4 in admin module. Preferred_txt Label Princeville Recommended Only: N/A Preferred_Checkbox Checkbox Yes: N/A 2.0 Date and Travelers Section 2.1 The date fields will be empty by default 2.1.1 If the user clicks the text box for start date (or end date) a calendar will be shown similar to figure 2 (also can be viewed on [login to view URL] [login to view URL] trip/lodging/[login to view URL] 2.1.2 If the user clicks the Calendar icon (image) the same behavior as in 2.1.1 will be in effect. Figure 2. Calendar "drop down" 2.1.3 The departure and return date fields will initially be empty. The fields will require the format MM/DD/YYYY. 2.1.4 The departure and return calendars will not allow the user to click any dates prior to Today(). The dates will still show, but not be clickable - follow [login to view URL] model. 2.2 Traveler section, the default for Adults is 1 and "-" for children (same as 0) 2.2.1 The range for adults is 1 - 7. 2.2.2 The range for children is 0 - 6. 2.2.3 If the user selects one child or more a new section will expand (as on [login to view URL]) or a new input field in new "window" will appear (as on [login to view URL]). This will ask for the child's age, "<2, 3, 4, 5,?. 17" will be the selection. 2.2.4 If the user selects "<2" and the package types includes selection for Air, a new section will show under neat the age asking "Seat" or "Lap". This is to determine if the child will get their own seat on the flight (we might want to do same implementation as for [login to view URL] with pop up layer?). 2.2.5 *Note: we will be using same system as* *[login to view URL]* *for usage with 3**rd* *party so* *all the form validations and post attributes needs to stay the same as on* *[login to view URL]**.* The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 5 3.0 Category section. As shown in figure 1, the category section includes filtering options for the packages available. The number of categories and/or the type of fields used (drop down, checkboxes) depends on what the administrator created in the Admin module. The logic will be the same though as all fields created will just be filtering. All of the sections can be disabled by the admin at any point in time. 3.1 There will be a section that allows the user to specify what hotel they are interested in, this will be a selection such as "All, St Regis, Wyndham?." This is derived from the information specified in the admin module. 3.2 There will be a section that allows the user to specify what price range they are interested in; all, Budget, Value Add, Moderate, Luxury, Extreme. This is derived from the information specified in the admin module. 3.3 There will be a section that allows the user to specify what type of package they are interested in; e.g. Romantic, Golfing, SPA.. This is derived from the information specified in the admin module. 3.4 There will be a section Which the user can expand to define further details, where the user can select what specific package types they do want - e.g. Air/Car/Hotel (default), Air/Car, Air/Hotel, Car/Hotel, Hotel Only, Activities Only. This section will also allow the user to type in their departure airport. This is derived from the information specified in the admin module. 4.0 Help section; there will be a help or "?" icon for the entire page that will open up a layer on top of the page and provide some help content to the user. This content should be customizable via settings or file in the module. Potentially we should have a help for each major section on the page, so one for Dates, one for Travelers and one for categories? 5.0 Error handling at submission time 5.1 Invalid dates, an error message will show above the text on the MTP indicating the inaccurate fields. 5.2 The system will check all fields prior to display the actual error message, thus there could be n number of errors. The format will be the following: 5.2.1 Header: "Please correct the following invalid data:"\ 5.2.2 Content: One line for each of the invalid data items in the order they appear: * Departure Date- date format must be MM/DD/YYYY.* Return Date - date format mst be MM/DD/YYYY. 5.2.3 The max number of travelers is 7, if this is exceededdan error message will show up: * Travelers - The number of travelers must not exceed 7 5.3 Departure Airport, if an air inclusive package has been 6.0 In the module settings (only enabled to administrators and hosts) the user will be able to define various settings: 6.1 Should the date and category section show or is this only showing the packageg list? The intent with this is to enable sub page categories, i.e. a honeymoon page that shows all the honeymoon packages from the gecko. 6.2 What is the default category the list should show (this setting is only available if 6.1 is no. 6.3 What Admin module is this connected to (just in case there are multiple different within a site?) 7.0 Filtering System. The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 6 7.1 Each of the packages that have been added to the system (via admin section) will be associated with 1 Hotelier (if hotel is included), 1 price range, and n number of package types. 7.2 When the user clicks the search button/link the request data should be stored in the session to be used at a later time. The data will be used to query all active packages in the system. The following will be verified - only sections that are enabled will be used to query/filter the packages, thus if the admin specificed that the supplier/hotel section is not enabled then this will not be used to query - or we just preset it to "All"?: **7.2.1 NOTE: The best approach might be to a) grab all packages that are available for the** **currentDate() and then filter the packages based on the selection once on the next** **page. This way we do not need to re-query the database every time the user makes an** **e.g. date change etc?** 7.2.2 CurrentDate() falls in the range of the Package booked start and end date 7.2.3 Departure and Return date falls in the range of the package Travel dates 7.2.4 The package includes the hotel/supplier the user selected, if all no check is necessary. 7.2.5 The package includes the Price range the user selected. 7.2.6 The package includes at least one of the hoteliers the user selected 7.2.7 The package includes at least one of the categories the user selected 7.2.8 The package is in the range of the rating. 7.2.9 The package is a Princeville pick - if that is requested 8.0 List View of the Main Module (shown in Figure 3 (example from [login to view URL])- this is the view that is shown once the user has a)selected and submitted the dates and categories on the first page or if the settings (see Admin module) allows to bypass that section shows all the packages for n number of categories. 8.1 The package list comprises of the actual list where the packages are shown and the filter/sort section that in theory should be a separate module (similar to [login to view URL]). 8.2 As shown in Figure 3, the search, sort and filter items on the right hand side should (?) be a separate module - see Sub Trip Planner Module Section for more details on that . 8.3 The use will be able to sort the results by: Package names A-Z, ratings High-Low and Low to High, Price Range High - Low and Low to High, [login to view URL] preferred/recommendations. 8.4 The look and feel of the main content is defined by the template for the list view as described in the Admin Module. 8.5 The number of packages shown will be set in the settings of the module. 8.6 As shown in Figure 2a the user will be able to define the number of results in the pages; the selection will be 10, 20, 30, all 8.7 As shown in Figure 2a the system will provide some paging functionality. 8.7.1 There will be a previous link (only show if the current page is >1, if clicking it will move the user back to the previous page (not necessarily the current page - 1) 8.7.2 There will be a Next link (only show if there are more pages (thus more products than currently is shown. 8.7.3 The number of pages will show as 1 2 3 4 5?Last, thus only 5 numbers and then a link to last page or if reversed the last 5 pages and a First link. The Resort Group, LLC | Trip Planner Brief Functional Requirement Draft 7 Figure 2b. Paging 9.0 Main module Admin Settings - The admin Settings for the list view will enable the user to make the following configurations: 9.1 Number of packages prior to paging. 9.2 Default sort (same list as previously defined) 9.3 Templates - All templates are driven by so called Tokens. All attributes specified in the admin module will be available as token e.g. "[DEPARTURE_DATE]", this follows same functionality as Ventrian's Property Agent. 9.3.1 Use the DNN built in HTML editor similar to Ventrian's property agent to handle this. 9.4 Date, Traveler and Category Section Templates 9.4.1 The template for this is completely defined by the HTML the user enters. There are already certain predefined tokens available for Departure date text, Departure date text box and calendar, Return date text, Returned date text box and calendar, Categories - how to display them, Price range text, price range Drop down box, hotelier text, hotelier drop down box. 9.5 List view Template, 9.5.1 Should be using the built in WYSIWYG DNN HTML editor. There are already certain ...///see more in attached... * * *This broadcast message was sent to all bidders on Friday Sep 24, 2010 3:42:51 AM: Aloha all, more detailed specifications have been added to this project. Please advice on any alteration in bid and time. Also, this is DNN module so you will need to show proof of DNN module development and if you have done work wiht Ventrian's Property Agent module that is a plus as we might reuse that code base as the foundation. Thanks Erland