write more views

1 files changed, 24 insertions, 28 deletions

diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md
index 0f0087c..00e2a43 100644
--- a/docs/DesignDocument.md
+++ b/docs/DesignDocument.md
@@ -26,10 +26,10 @@ sleek web application which manages tournaments.
  
 # Non-Functional Requirements
 
-1.	Security: - Because Project Leaguer servers may store sensitive user information like name, email, statistics, user-name, profile, etc. it is an important non-functional requirement that such data is well secured from both accidental exposure and intentional tampering. Even so, the System may not be responsible for the theft of user information or even alterations made to the database from a source different from that of Leaguer.
-2.	Backup: - The Leaguer system provides a user with a database of user information and is updated and stored, which is functional. In contrast, the non-functional requirement of leaguer is its ability to back up all the information of the user when the user chooses to suspend or delete record or even when the user happens to disconnect from the server.
-3.	Platform Compatibility: - A non-functional requirement for the system is to be able to run on multiple platforms. Primarily a web based application, Leaguer may not be able to install into embedded gaming devices and special operation systems that do not run the interface that Leaguer was initially built on.
-4.  Response Time: - Even though the "Model 2" architecture tends to scale well for medium/large applications and data sets, it is still important to keep the response time of the system in mind. Using efficient data structures, short time complexity algorithms, and minimizing network overhead whenever possible will help to keep the response time of the system reasonable even for large data sets or complex statists or scoring schemes.
+1. Security: - Because Project Leaguer servers may store sensitive user information like name, email, statistics, user-name, profile, etc. it is an important non-functional requirement that such data is well secured from both accidental exposure and intentional tampering. Even so, the System may not be responsible for the theft of user information or even alterations made to the database from a source different from that of Leaguer.
+2. Backup: - The Leaguer system provides a user with a database of user information and is updated and stored, which is functional. In contrast, the non-functional requirement of leaguer is its ability to back up all the information of the user when the user chooses to suspend or delete record or even when the user happens to disconnect from the server.
+3. Platform Compatibility: - A non-functional requirement for the system is to be able to run on multiple platforms. Primarily a web based application, Leaguer may not be able to install into embedded gaming devices and special operation systems that do not run the interface that Leaguer was initially built on.
+4. Response Time: - Even though the "Model 2" architecture tends to scale well for medium/large applications and data sets, it is still important to keep the response time of the system in mind. Using efficient data structures, short time complexity algorithms, and minimizing network overhead whenever possible will help to keep the response time of the system reasonable even for large data sets or complex statists or scoring schemes.
 
 
 # Design Outlines
@@ -151,7 +151,9 @@ layouts/application.html (abstract)
     to `LoginController#login()`, and the button causes a GET to
     `UserController#new()`.  If a user is logged in, it displays a
     logout button that causes a POST to `LoginController#logout()`.
-    TODO: alerts, search
+    It may contain an alert box of recent alerts submitted by a
+    tournament host.  It contains a searc form that is POSTed to
+    `SearchController#show_results`.
 
 common/permission_denied.html
   : A generic page for when a user attempts to do something for which
@@ -162,12 +164,10 @@ common/invalid.html
     when not logged in).
 
 main/homepage.html
-  : This page has 3 basic options. Visually simple – two large buttons
-    on a white screen, and a search bar above them. The search bar
-    will cause a POST request to the search controller. Log in (which
-    will cause a POST to the login controller) and “Go to Tournament”
-    in which you enter a tournament title. This interacts with the
-    Homepage Controller.
+  : This page is visually simple.  In addition to the basic functions
+    of `layouts/application`, this page has a “Go to Tournament” text
+    area, in which you enter a tournament title, and will take you to
+    the relevent tournament page.
 
 main/edit.html
   : This page is a form for editing the server-wide configuration,
@@ -178,25 +178,20 @@ search/results.html
     triggers a GET request to the relevent controller method.
 
 messages/new_alert.html
-  : This shows the user that a new message is available for view. 
-  	Clicking on the notification should cause a GET to the 
-    show_private controller and take the user to his/her messages. 
-	new_alert should interact with the Main controller's 
-    show_homepage to display the notification.
+  : This is a form for a host to submit a new system-wide alert.  The
+    form is POSTed to `MessagesController#post_alert()`.
 
 messages/private.html
-  : This page is used to handle user private messaging.  It should 
-  	display a list of private message and which user the private 
-    messages are communicating with.  Clicking on a message should
-    trigger a GET to show_private and display the message. A field
-    box for entering a message should be present.  When posting a 
-    message a POST should be sent to Message's post_private and 
-    then a POST to post_alert confirming that it was sent.  A 
-    new_alert should then be sent to the recieving user.
-    
+  : This page is used to handle user private messaging.  It both
+    displays private messages, and contains a form for sending a new
+    private message.  Nes messages are POSTed to
+    `MessageController#post_private()`
 
 tournaments/index.html
-  : TODO: list of tournaments
+  : Shows a list of tournaments.  Clicking on any of them causes the
+    browser GET that tournament via `TournamentController#show()`.  If
+    the user is authorized, it also contains a button that causes the
+    browser to GET `TournamentsController#new()`.
 
 tournaments/show.html
   : Shows the information for a single tournament.  If the user is
@@ -218,10 +213,11 @@ tournaments/edit.html
     `TournamentsController#update()`.
 
 matches/index.html
-  : TODO: list of matches
+  : Shows a list of matches.  Clicking on any of them causes the
+    browser GET that match via `MatchesController#show()`.
 
 matches/show.html
-  : Shows an individual match; q display of both teams. Each team's
+  : Shows an individual match; a display of both teams. Each team's
     players are clickable which causes a GET for the player's profile
     HTML (`UsersController#show()`).  A link above both teams will GET
     the tournament the match belongs to