Modernizing ‘Dear Abbey’

1. Modernizing ‘Dear Abbey’ Group 6

2. Overall Design Purpose • Provides users a way to seek advice without having to be identified • Allows people to communicate feelings they might not want to if they were being identified

3. Basic Design Hierarchy

4. Login • Here you can log in, and will be notified whether your username or password is incorrect when looking in the database

5. Registration • Register yourself as a new user by providing your username and password • Must provide a security question in case a user forgets their password • When user type a username and press the ‘Test If Already Exist’, the website checks in the database to match them. If the username already exist, the system would notify user to try another one and at the same time password disappears to protect user’s privacy. • All User information is stored in a table named Table and use Sqldatasource to connect them.

6. Forgot Password • On the Forget Password page, you can retrieve your password by providing the correct username and answering the security question correctly.

7. Home page • Will be welcomed to the home page with a simple history of what the purpose of the website is

8. Design: Sending Messages • User types message into text box • Categorizes the message so that they can get a response from someone who enjoys responding to those types of messages • Also has miscellaneous in case any of the categories do not meet their criteria, acts almost like a random message

9. Design: Sending Messages (cont’d) • When message is sent to ‘Messages’ table in database: • Globally Unique Identifier [GUID] is generated for each message • The sender is identified as the ‘originator’ which will never be known to the replier • Timestamp is generated for the submission time • Allows a Last-in-first-out response, giving the oldest message in the database the priority

10. Design: Replying to a Message • User selects a category from the drop down menu and receives the message with highest priority in the database matching it • They can then respond to the message anonymously, or recast it for somebody else to respond to

11. Design: Recasting a Message • In the case that they “recast” the bottle, the message will go back into the database and its priority will be set back to what it was originally • This ensures that the user who cast the message will receive a timely response • Recast message IDs and the user who recast them are saved in another table, ensuring that a user will not receive the same message that they have ‘recast’ again

12. Design: Message Cast History • Each user is able to view their Message Cast History • This provides the user the ability to view each message that they have cast, the time it was cast, as well as whether it has been responded to • If it has received a response, the response will be displayed below it as well as the date it was responded to • If there has been no response, it will simply display “Reply still pending.”

13. Design: Reply History • This will display the user response history, which is similar to the Message Cast History • Each message that the user has replied to will be displayed here along with the response that they have sent

14. Design: DataTables Message Cast Table The design of the tables are mainly focused around the structure of messages and its replies. We distinguished between the initial messages and replies conceptually since a message can have many replies All of these tables track basic information such as the ID, author and time stamp Reply Message Table

15. Design: DataTables • The recast table was an addition to the table to carry out the recast functionality. This table keeps track of all the message ID’s that a user has gotten but does not want to answer. This aids in what messages user can receive as well Recast Table Tracker

16. Design: DataTables Query Insert Recast Get Message Cast Message Message History Reply Recast Table Tracker Message Cast Table Reply Message Table