Page History

...

HAAG also features a mobile interface that is automatically loaded when the user logs in from a smartphone or tablet device.: 

...

• Improved consistency across dialogs: Based on a somewhat misguided guideline, we had implemented some actions of our dialogs using hyperlinks (e.g., 'Cancel'), and authors others using buttons (e.g., 'Save'). Our users complained, and we got rid of the links and adopted buttons for all dialog actions.
• Combined similar actions: Our users complained that the interface had similar actions (e.g., 'Create assignment' vs. 'Create multiple assignments') and that added some confusion, so we unified them into a single action ('Add assignments').
• Use attribute names consistent with the real world: In Ruby on Rails, it is common to name timestamp attributes using the suffix '_at". This surfaced to the interface and the as a field labeled 'Due at'. The evaluators requested it to be changed to 'Due aton'. A similar problem happened with our implementation of a 'Class' object; because 'class' is a reserved word in Ruby, we named our structure 'Course', and it surfaced to the UI. Both issues were fixed.
• Added information about HAAG on the login screen: Some evaluators were concerned that it was not possible to know what the application does, so we added a short explanation on the landing page.
• Implemented missing features: We implemented the missing features from GR4, most of which were picked by the evaluators: allowing allow unsubscribing from a class, implementing implement undo for marking assignment as completed, and allowing the creation of allow creating private assignments.

Implementation

...

Rails applications are structured according to a model-view-controller (MVC) pattern, and are expected to adhere to a series of guidelines. This "convention over configuration" philosophy benefits the designer by ensuring that if the guidelines are followed the all low-level details of the application will be handled automatically. This allowed us to have the first features running in a short time.

These two characteristics (MVC architecture and convention over configuration) greatly contributed to the implementation of the mobile version. In Rails, by registering a mime type 'mobile' and naming the views accordingly (e.g., 'edit.mobile.erb'), the framework will render the corresponding view when the application is accessed from a mobile device. This enabled the mobile version to be implemented with the addition of only 120 lines of code (7% of the application total).

One particular issue that required deviating from 'The Rails Way' is validation. Because we wanted to avoid full page reloads in order to enhance user experience, we implemented many input forms as modal dialogs. These dialogs are loaded inside a 'div', using jQuery UI methods. When a user sees a modal dialog on top of another page, this is actually the result of two distinct page loads. Being essentially stateless (unless enough hacks are provided), the server cannot re-generate this same view with a single page reload. For this reason, it is not possible to display error messages on a dialog, if we striclty adhere to Rails conventions. 

The solution adopted was live validation with AJAX requets. Whenever an input field changes, a round trip to the server is performed, and if the field contents are invalid they are highlighted in red. This added significant complexity, but from the user viewpoint it was probably worth it: in the one case where we faild to implement this live validation, an evaluator classified this as both a major problem (lack of feedback) and a minor one (inconsistent layout). These issues were fixed in the final implementation.

Evaluation

We found three undergraduates to participate in user tests. One has a calendar with all of her assignments for the entire year, one makes a list for each upcoming week, and one just keeps everything in his head. We managed to test someone who matched each of our original user scenarios.

...