User Experience

To add the value for game theory and interface design, some elements for user experience and engagements are considered when developing LessonPlan 2.0. These elements will include for example:

  1. Simplicity and speed of loading and navigation. By designing a simple landing page, the browser will load the page for the user very quickly.
  2. Use of customized and representative logo and brand for LessonPlan 2.0.
  3. Progress bar for the percentage of completion of reviews and engagement in module.
  4. Using eye-tracking technique and following F shape style [1], the main navigation for ratings, review, courses are set on the first horizontal line of F. The main contents will be on the left side on the main panel as users spend 69% of their time of the left side of a page [2]
  5. Each time a user complete a review, he/she will get a score. When scores gets to certain level, a batch will be awarded to the user.
  6. Using RSS and letting the students subscribe for fees.
  7. Search box at the start with drop down list for registered courses.

By doing so, we ensure user engagement with rich experience in LessonPlan 2.0. Some of these elements are illustrated clearly in mockup figures.

———–

[1] Nielson Jakob, “F-Shaped Pattern For Reading Web Content”: http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/, Apr 17, 2006 [Apr. 29, 2015].

[2] Porter, Joshua, “Testing the Three-Click Rule”: http://www.uie.com/articles/getting_confidence/, Apr 16, 2003 [Apr. 29, 2015]

Main User (Student) Use Case Diagram v1.0

One of the main feature of a system is the interactivity between it and its users. The interaction is illustrated by using use case diagram. Here we represent the main actor of the system where the entire system is mostly used and interacted with by this user, student actor.

The diagram shows how the student will interact with module review social network and what actions he/she will perform. The other actors are not included in this version of use case diagram because at this point their interactivity with the system is very limited at this stage. These actors are the lecturer who can comment on review or reply on a comment. The system which analyze the student input as preferences and generate a suggestions or a list of suitable module based on student grade, pre-set preferences, rating and difficulty level of a module.

UseCase

Entity Relation Diagram

Entity Relation Diagram is used to illustrate a unified view of a system data [1]. This entity relation diagram shows the main entities in LessonPlan application and how these entities relate to each others. By ensuring the correct entities data types and relation, we enforce the integrity of the database. The relationship between two tables is ensured by referencing its primary key like userid in Module_Feedback table which reference the user id who provided that feedback. If a user id does not exists in user table, it can not be stored in any other table which reference it. This is to enforce the referential integrity in database. To enforce the entity integrity, a primary key in each table has been identified. These primary key might be single attribute like userid in users table or composite primary key (consists of multiple attributes together) like mode_program table.

In ERD, U stands for unique in that table and N stands for nullable (can be null). To ensure that an email address is not used by two or more users, the attribute constraint is set to be unique. Same for school name, module name and program name as we can not have the same name which represent two schools, modules or program. The grade in user table is set nullable so the user will have the ability to choose between giving it or not.

These tables represents only LessonPlan database without the integration with university database in which the system can query from using remote procedure calls.

ModuleReview

 

———-

[1] Chen, P. P. S. (1976).The entity-relationship model toward a unified view of data. ACM Transactions on DatabaseSystems (TODS), l(1), 9-39.

Class Diagram v1.0

The class diagram of LessonPlan 2.0 social network illustrate the structure of this application by illustrating the classes and their attributes and operations.

LessonPlan 2.0 project consists of multiple classes in which some of them depend on others. The main class User is a generalization for both students and lecturer/module leaders. Both of them (student class and lecturer class) have something in common which is represented in User class. The other attributes and operations that distinguish student from lecturer are set in student class, same for lecturer.

The dependencies between classes are represented with doted arrows. Each class represent class name, number of attributes which set to be private by assigning – sign before them, and public constructors and operations with plus + sign before them.

Social Network Class Diagram

System Architecture Design

LessonPlan 2.0 system is built from different parts and components. As the size of the system will increase over time, these components should be separated from each other for more maintainability and scalability. When dealing with software architecture and design, it is very critical to get the architecture right in order to prevent system disaster. Also, when an engineer understand the software architecture and organization, he/she ca make correct choices between design alternatives [1].

After looking at different architecture choices and alternatives, Model-View-Architecture has been adopted for the proposed system.The reason for choosing this architecture/pattern for the software design is to separate the concerns. Also, since most of web development frameworks and languages offers mature implementation of MVC, it will be easier for developer to adopt it and build on it in future.

Model in module review system consists of entity classes which deals with the database. These models notify the view (web pages) when a change on the data has been made. The controller takes the request and process all the application logic.

The system might need to get some data from university student records database. This could be done using remote procedure calls from module review database to student records database. Module description pages will be fetched from university using RDF and XML.

Here is the abstract software architecture of module review system using MVC:

Social MVC Diagram——————

[1] Garlan, D., & Shaw, M. (1994). An introduction to software architecture. Carnegie Mellon University