Design 1
Image |
Description |
---|---|
|
The home page. Let's you find a student by year, course, and skills. Supports OR's for requirements. |
|
Results page for a search. Brief info about students who matched your requirements. Names are clickable for a student page. |
|
Lets you view information about a student. Includes courses they've taken, skills (not necessarily programming languages), previous work/urop/position experience, and some relevant documents like resumes or unofficial transcripts (provided by the student!) |
Design 2
Image |
Description |
---|---|
|
This is my stretch. This is a physical interface for our device. It is a series of cards (as shown in the image.) At the top of each card are holes that align with a skill/course set. The cards stack on each other. To find students with a specific attribute, you would then slide a pin into the slot in question and pull out cards. The cards removed lack the attribute in question, thus the remaining pile only contains valid candidates. |
Design 3
Image |
Description |
---|---|
|
The home page. The user sees a list of postings. Ones that are theirs would be marked in a different color. (Login system not depicted.) Ones that are theirs also include reply information. If it was not theirs, it would have an "Apply" link for candidates to apply. |
|
User can make a post. Includes ability to find more students, give an e-mail subject, and e-mail body. Student's emails are never exposed for security reasons. |
|
When trying to find students, you get this form. It lets you search by a series of classes and skills as tags to find the best candidates. |
|
This is the view replies page. It also doubles as the search results page (swap "View Reply" with "Add to List" or a checkbox for multiple selection support.) |