Sensorial’Org

This screen is self-explanatory. It allows the instructor to edit information about a student. (Right now, the instructor is able to edit the user’s student number and/or username. Whether or nor there are circumstances in which this should be allowed is still up in the air.) Although it’s not shown, the user is given an error message on failure and a confirmation on success (after they have been redirected back to the Manage User’s view).

Notice “Manage Users” is the main heading as opposed to “Edit Student”. That is because “Edit User” is a subpage/subaction of “Manage Users”. Since there are no breadcrumbs*, I still want to give the user an indication of the page hierarchy.

Labels are floated to the left of each field because, again, they complement each other. They “finish” each other; putting them side by side reinforces that relationship visually.

* I chose to implement a sidebar as opposed to breadcrumbs because it doubles as a site-map when I lay out the depths of each branch. With breadcrumbs, you’re given the path of how you got to a page, but there is no way of visiting its siblings without backtracking. What I didn’t implement, but should have, is indication of which page or section of the system I’m at; something simple like highlighting the page link on the sidebar.

I don’t know how useful the sidebar actually is considering only the instructor will have as much controls and functions, but it proved to be extremely handy for me as I was navigating the system to test different inputs and check the resulting behaviour.

For each assignment, there is a rubric. The instructor is able add an arbitrary number of criteria, and for each criterion, there’s four levels under which the submission can fall. The name of the criterion, its weight, its description, the label of each level, and its comment are all editable fields. After all the criteria has been defined, the instructor may rearrange the order of them by dragging and dropping them in the right place; this ordering will persist when it’s time for the TAs to mark them.

In the old interface, the choice of the tab colours were sort of counter-intuitive; the active tab is gray whereas the other tabs and the background of the content area are white. You want the section that’s associated with the active tab to be connected. This can be done by getting rid of the line that divides the tab and the content, or (preferably and) setting the colours of active tab and the background of the content area to be same. Think of an old-fashion folder: when you open it, the tab and the backing is seamless. The tabs as it were, goes against convention and disrupts flow and continuity.

I didn’t like how the background of each collapsed criterion is the same colour as the header. It puts the criteria on the same level as the heading visually, when semantically they are beneath it.

The location of the “Add Criterion” is also slightly awkward.

I do, however, like how each rubric level takes on the background colour of the active criterion. It creates a connection between the otherwise disjoint boxes.

In the new interface, I sort of inverted the tab colours. It was important to keep the background white (because (a) I don’t know what kind of content will be there in the future, and all the core styles has already been introduced into the system to work with a white background (b) white is the expected default of a professional web site), so I made white the colour of the active tab as well; however, because the main content area was also white, there will be no distinction between the tabbed content area with the rest of the screen. The other tabs would also seem to float in the middle of nowhere. By wrapping the whole tabbed component in a gray box that’s already been introduced in other sections of the site, we solve that problem and manage to keep the look and feel consistent with the rest of the system.

Little “+” icons suggest expandable items. Little “-” icons to indicate collapsible item has yet to be implemented.

The “Add Criterion” link was moved to the right of the heading to be consistent with the “Delete” link of each criterion. It differentiate it from the header, I gave it a style of its own.

The colour connection between the criterion and the rubric levels was kept.

Alternative row colours FTW.

There are some issues with the width of the Criteria and Level boxes. Ideally, they would take up all of the horizontal real estate but there are some floating problems that are yet to be corrected.

This screen was by far the most fun. This is known as the Grader’s View. It’s the screen on which TAs would spend the most time. On this screen, the TA would flip through each submission file of a group, read through the code, add one-time/reusable categorized annotations to the code, add overall comments of the submission, and assign a level to each of the criterion.

The layout of the core components was pretty much fixed because the workflow of it worked in the first version (see image on the right): coding/comments went on the left and the rubric/marks on the right so that the TA could refer to the criteria when he’s assigning marks; rubric items need to be collapsible because there can be a large list of criteria; ability to navigate between students without going back to the Navigate View (a list of all students and their submission).

The new version kept what worked and added a few new luxuries: syntax highlighting <3333, automatic status changes (from unmarked to partial after the TA makes his first annotation), autosaving, the ability to adjust font sizes, the ability to print the code, and adjustable widths of the coding and rubric panes (if you drag the red bar left, the coding pane shrinks; if you drag it right, the coding pane expands).

When I was in first and second year, I used the first version of OLM. I see pretty much the same thing as the TA minus a few menus (save changes, marking status, annotation categories), and even then I felt the layout was very cluttered and suffocating. Being involved with the new version, I now understand why all these elements were there, but there must be a way to make it feel more spacious even with all these necessities. Think interior design and how certain things can trick the brain into seeing a room to be bigger than it really is.

The new version was already a vast improvement from the first. By automating some of the task, we were able to get rid of some menus. But all the different colours and the placement of certain elements still made everything feel a little chaotic and jarring. Navigation between students was floated to the top right. Marks and submission files were crowded to the left. The same problem with the tabs. The coding toolbar (view plain, print, A+, A-, etc) was disjointed from the line numbers even though it affects it. The lack of distinction between different rubric levels.

Amanda Manarin and I worked on the redesign together. So that we didn’t step on each other, I worked on the tabs on the left and she worked on the tabs on the right. Amazingly enough, everything fell into place rather nicely.

For cohesion and organization, I kept the number of colours to a minimum and grouped all the related information together. Got rid of the red and the green, and continued with the gray, blue and orange scheme. Brought in the new tab component design and used it for both the coding and marks pane so that the page comes together as a whole, but the gray boxes also work to separate the two distinct components. All the information related to submissions (Next, Current, Previous submission; Status) fits together, but is independent to the files that is being marked. At the same time, all submission is associated with the current assignment. Having said that, it doesn’t belong with the global navigations (as seen in the first version of OLM) nor does it belong beside with assignment title, but it naturally falls between the assignment heading and the files to be marked. Similarly, the coding toolbar is moved from “within” the code to outside of it; it’s global to the code and lies within the coding pane.

Some miscellaneous screens: The Log In and the TA to Groups mapping.

I was working on the TA to Groups Assignment view during the code sprint. This interface allows the instructor to assign groups to TAs who will then be responsible for marking submissions of that group. The number beside each TA indicates how many groups have been assigned to them.

Initially, we wanted to colour-code the groups: each TA would be given a colour, and once the group has been assigned a TA, the group will take on the TA’s colour. In theory, this is a great idea because it visualizes the distribution of work. When it came to implementation, it became more of a challenge. A course can have as much as 20 TAs; how can we pick a range of colours that’s easy on the eyes and distinguishable? What if a group is assigned to more than one TA? To simplify the work, we decided a number next to each TA’s name would suffice, and to see who was assigned to who, we would implement togglers.