Admin Module Detailed Design
#Account Management
##Over riding requirements of account management.
If a school should choose to have a local installation of the application, it will require some level of systems administration support to get the application installed, and running. Once the application is running however, no direct technical support should be required. We will also offer an option where the application can be run directly from a Jackson Laboratory server, which would enable a class room to create their own "Lab", within the public instance.
###Software as modular as possible
The functionality should be something that can easily be plugged into any web application using the same underlying development framework (java/gwt), and with basic config instructions “just work”. Do not hardcode any knowledge of the Drake Genetics application.
Specifically anyone with network access to the DrakeGenetics Web application should be able to create a user account.
When a user comes to the DrakeGenetics Web application home page, they should be presented with a link to “register” for an account, and fields to enter their username and password to log in. If they choose to register, they will be taken to a page that allows them to enter their email and a new password (twice), and a button to submit request to register. If the email address does not already exist in the system, the user will be sent an email, with a link to allow them to confirm that they registered. Upon confirmation they will be able to log into the application.
If the email address already exists in the database the user will be taken to an error page with a message similar to:
"An account for this address already exists. If this is your address you can log in (link to login page) or reset your password (link to reset page)"
The page for resetting a user's password via email is mentioned below.
There are two password change scenarios. One is that they remember their current password and just want a new one. This would be done after logging into the system, at which point they would go to a screen for administering their account. This page would provide "Change Password" section where they can once again enter the new password twice to reset it.
The other option is when they have forgotten their password and so must reset it via email. The user would follow a link that would send them an email stating that a request has been made to change their password. If they indeed want to change their password, the would follow a link in the email that would take them back to the application, to a page where they enter their new password twice. Something like a "have you forgotten your password" or "reset your password via email" link could be provided on the login page.
When a user logs into the application, they should provide their name, so the teacher can identify the students they will be advising/testing. We could also provide a "screen name" that the user can be known by within the game, but this is not a high priority requirement.
A "laboratory" is basically a classroom. It's the shared group context in which the game is played. It only makes sense for a teacher to create a laboratory, but it simplifies the account management workflow and does no harm to allow any user to create a laboratory. For instance, if a student creates a laboratory they automatically become "Advisor" for that lab and are pretty much all powerful within the context of that laboratory... but they will have no students.
#####Typically 1-to-1 Classroom to Laboratory
So as stated above, while all users CAN create a Laboratory, not all users should. Typically a teacher will create a laboratory, and then invite students from a given class to join the laboratory.
#####Communication will be within Laboratory
The only communication outside the context of a Laboratory will be the action of inviting students to join a lab, or requesting inclusion in a Lab.
#####Users can request to join your Laboratory
When a user creates their account, their should be a list of available Laboratories to join. They should be able to select the Laboratory they want to join and send a request. The creator of the Laboratory will be notified via email that someone has requested to join their Lab. The owner of the Lab should then be able to go to an admin page that lists all users requesting to join. It should be as easy as a button click for the owner to select the requests they want to accept (through check boxes) and then a button to accept all of them.
This should make the teachers life easier, as they then just need to create a Laboratory, and provide the students with instructions for creating accounts and then the name of the Laboratory they want to join.
###Roles
This is the teacher. An advisor has all the capabilities of a "Scientist" within their own session of the game. So if an Advisor wants to keep their own notebook, breeding pen, etc... for example to be able to publish example results to students, they should be able to.
Once a new Laboratory has been created, this user automatically is given the role of "Advisor" for that Laboratory. As stated before, while any user could create a Laboratory and become it's Advisor, typically this will be the classroom teacher.
This is the student, or any user that has created an account and not yet created a Laboratory and become an Advistor.
-
Lab create
- Any user/Scientist
-
Request to join Lab
- Student
-
Accept request to join Lab
- Advisor
-
Lab acct remove
- Advisor
-
Reporting
- Advisor
-
Read from notebook
- Advisor/Scientist
-
Write to notebook
- Scientist
-
Comment on notebook
- *Advisor/Scientist *
-
Perform Experiments
- Scientist
-
View exp results
- Advisor/Scientist
-
Publish notebook entry
- Scientist
As mentioned under the Advisor section, an advisor has the capabilities of a Scientist, so an advisor may keep their own notebook for example. An Advisor is the only user that can look at and comment on other users' notebooks and experimental results. The Publish notebook entry is not a hard requirement for the current release, but it makes sense to provide the action at this time.
There will be several screens or views that represent the account management interface. At times I may refer to the screens or views as pages, but this is not any indication of bias as to whether the interface should be HTML based or designed as a stand alone web application with all functionality residing in the application that happens to reside in a web page. That is a design detail that has not yet been resolved.
This is the interface the user first comes to when they enter the address of the application into their web browser. This page should have two distinct components associated with the Account management module:
- Registration Panel
- Mini Login Panel
This login could fit into a home page or main application panel as seen in the mockup below.
This will be nothing more than a text link "register" that would take the user to a registration page/interface for creating a new account.
This page is a smaller version of the standard login page/interface, where there are just 3 components, which all appear horizontally in line.
- email text box
- password text box
- login button
Once the button is clicked, the user will be authenticated. If authentication is successful, the user will be taken to the main page of the interface. Failure to authenticate can be because of two reasons:
- User entered an invalid password - In which case the user will be taken to the Login page/interface with a message in red that they entered the wrong password and should try again. There should be a link on the page for the user to follow in case the forgot their password. DOW: Should be consider implementing a "lock-out" if they fail to get their password right after 3 tries (extra logic to store in the server), followed by an email to the user account, giving the user a chance to reset their password?
- User's email address is invalid - In which case the user will be taken to the Login page/interface with a message in red that they entered an invalid email address and should try again. There should be a link on the page for the user to follow so that they can Register if they have not yet done so.
This is the interface page or screen that the user will come to when they have clicked on the link in the Registration Panel. This page will be very similar to the Login Page/Interface. This page will consist of four components displayed vertically within the interface.
- email text box
- password text box
- confirm password text box
- register button
Once the user fills out this form and clicks the register button, the first thing the application will do is confirm that the two passwords entered are the same. If they are not, a message in red will be returned warning that the passwords don't match. The user will be given the option to re-enter them.
Once the passwords match the application will first confirm that the email address used does not already exist in the system. If it does, the user will be returned to a Login screen, with a message that the email address has already been used, and that they may log in. There should be a link to allow them to recover their password if they have forgotten it.
If the email address has not yet been used, an entry will be entered in the data base with the new email address and password. However, the entry will be flagged in the database as "Not Confirmed". An email will be sent to the user's email address, letting them know that they need to follow a link to confirm that they created the account. Once the user follows this link, the email will be marked as confirmed in the database, and the user will be able to log in and use the application.
The confirmation link should take the user to the login page, with a message thanking them for registering and asking them to now log in.
This is the main page for logging into the application. The main components of this page will include the following components displayed vertically on the page:
- text box for email address
- text box for password
- login button
The page should also provide links for assistance if they have forgotten their password, or registering if they have not already done so. The interface should also provide a space above the components in the interface for various warning messages to be displayed, as detailed in the previous sections (invalid password, invalid email address, etc...).
Upon clicking the login button, the application will go to the server and confirm that the email address and password are valid. If they are the user will be taken to the home page so they can begin using the application. If either the email address or password are incorrect, the behavior will be the same as the Mini Login Panel above.
If a user forgets their password and clicks the link on the Login Page, they will be taken to a page requesting their email address with a button "recover password". Upon clicking the button an email will be sent to them, and in the content of the email will be a link back to the application for recovering their password.
Upon following this link they will return to the application to a page with two password fields and a "Reset Password" button. Once they have entered the password twice, they will be logged into the application and their password will be changed. Failure to accurately enter the same password twice will have the same behavior as the Login page.
When a user logs into the system for the first time, they will be taken to the account management screen. Before the user can proceed with using the application, they need to identify themselves so the advisor will know which scientists should be part of their laboratory. Therefore the User Name field is required before the user can proceed. The Screen Name field on the other hand is optional, and by default, if not filled in, will be the same as the User Name. The account management interface is where a user will go to do things like:
- Identify themselves with User Name (required).
- Create an in game persona with Screen Name (optional).
- Reset their password.
- Join an existing laboratory (Necessary to play the game).
- Create their own laboratory (Something that should generally be done by a teacher)
- Accept user requests to join their laboratory (disabled unless the user has a laboratory).
As mentioned before the User Name field is required for the user to proceed in the interface. Until the user fills this in, the admin module should essentially be modal and not allow them to proceed to another screen without this information. This should be the name that is visible to an advisor when they are accepting requests to join their laboratory or when they are viewing a scientists status (notebook, lab results) or administering a test.
The screen name is the name that will be used for the user to identify themselves within the game. When intra-lab communication is implemented, it is this name that other scientists will see.
The password reset functionality should simply require that the two passwords entered are the same. DOW: Do we want to lay in any additional requirements on the content of a password? (for example: 8 characters, at least one number and one capital letter)
The standard use case for creating and joining laboratories should be as follows:
- A teacher creates their own account
- The teacher creates their own laboratory and becomes and Advisor
- The teacher provides the students the laboratory name (email, verbally)
- Students create their own accounts and identify themselves by name
- Student goes to the "Request to join" field and select a laboratory of the appropriate name.
- The teacher goes to the "Manage requests" section, and selects the students who are valid members of their class room (DOW: should probably be a select all option).
- The teacher selects "Accept" (DOW: probably need a way to deny users as well)
- The student should now see what laboratory the belong to.
DOW: Additional functionality we should discuss adding:
- Some sort of tab format for Labs so that one teacher can have multiple labs.
- A way for an advisor to see all of the members of a given laboratory (this could be the same mechanism used to go view a students status)
- A way for an advisor to remove a scientist from a given laboratory.
- Do we need a way to remove a scientist from the application as a whole? If so, I don't think it should be an advisor... if it work a student would just need to create a lab, become an advisor and then start removing other scientists from the application. KSS to my thinking barring a user from the application completely is an application administrator's task. Hopefully the lab-level controls that we provide to the advisers will be sufficient so that banning at the application level is very rare.
KSS: Misc other notes/ideas
- Not something we need for this phase of development but here is an idea that may be useful. For locally deployed instances allow application administrator to restrict account email addresses to specific endings. Eg: only allow accounts for email addresses ending in "@ellenville-hs.edu" to be created. I actually wonder if there will be any interest at all in creating local instances so this is probably very low priority
- One unique aspect of our sign-up use case is that it is likely to only take place for a closed period of time ... say 1 or 2 weeks. So one thing we could add which might help control SPAM or other unwanted sign-up requests is to give the adviser a toggle button: "lab open for registration"/"lab closed for registration"
- This is general feedback which does not require a specific action or response: it occurred to me that AJAX web-apps like facebook and github both have very similar "user group" requirements to our application
- anyone with network access and an email address can create an account
- those users can then create organizations (github) or groups (facebook) in which the account that created the group has group-administrative privileges.
- users that join the group can communicate within the context of that group
The reason I bring this up is that I think we can borrow heavily from their design decisions. One example: in both cases each group has its own separate administration interface which is not connected to the users own account administration. Of course time pressures will dictate some of our implementation decisions, but in any case I think these web apps are good example implementations.
The account manage panel would likely live under an "Account" menu item, which when selected would result in seeing the panel as part of the application page/interface, as seen below.
