Page 1

Ethics Reviewer Technical Achievements and Implementation Details Hosting the application When collecting the requirements, the client asked if it would be possible to have the application run from the browser, without having to download a zip file and running an executable or installing anything. The client also wanted to have a stand-alone local copy of the application in case the internet connection went down, so that they could still run the session using the software. We looked to see if there was a way to create a Java application and have it run from the browser and discovered Java Web Start to be a candidate solution. We did some research into Java Web Start to find out that it requires the application to be packed as a jar file, signed and then a jnlp file is created to download the jar file into a temp folder on the local machine and run, all from the click of a single link. After testing this process with an example program we agreed with that client that this would be possible and saw no problem in doing so. At the later stages of development we decided to test hosting the application on a server and using Java Web Start to run it. In doing so, however, we learnt that when packaging resources into a jar file the resources in the jar file could not be referenced using a relative file path, but required input streams instead to access the resources. Our entire application had been utilizing file paths and so a lot of the code needed to be changed. At that point we made the decision to focus on completing the application to create a full working near-deployable demo for the deadline, and work on changing the code so it could be used with Java Web Start in a future update, to the client’s approval. Our current solution is to host the application on a server and create a link on a webpage where the user can download a zip file containing all of the required referenced resources and run the executable jar in the zip file to run the program. Back-end Design A major aspect of the system relied heavily on a database. This included the session information, the lecturer accounts for login, the responses entered by users and the particular grouping of the responses. All requirements had been surpassed with a high quality design. The database also played a key part in the implemented messaging system, all responses would appear interactively on the lecturers screen in order for him to group them effectively. This meant storing the response, the question number and for what the event the response was regarding. The lecturer would then group and store the new groups within the database in order for students to view his analysis on their ends. The back-end was implemented use SQL Server and his held on Windows Azure. We complied heavily with ensuring the database was normalized to BCNF to control data redundancy and ensure data consistency. Within Java we made use of a utility package, which handled connection to the database. The controller package interacted with the database directly when the application was inserting and querying. The view packages never came in contact with the database unless they went through the controllers.

UI Design and Screen flow The two most iconic features of the user interface of the Ethics Reviewer application is he timeline view and the segregated lecturer and student client. Timeline View From very early on, Dr. Moorhead, our client, I formed us that he would like the case study to have a timeline view. He explained that he often followed the case study chronologically and would appreciate having the stimuli organized by their time of occurrence. To implement this timeline feature we began looking for good timeline visualization libraries in java. After a good amount of testing we found a library called TimeFlow which best represented our needs. The library allows for the easy creation and deletion timeline nodes. To fit the needs of the application, we modified the timeline and the library. We created a timeline for the Leveson inquiry in order to match the structure of the case study that out client would be giving. Additionally, we also restricted certain features in the API that wouldn’t be relevant to our project. Apart from restricting certain features, we also implemented others to make the timeline view more useful. For example, we implemented the search bar at the top which allows the lecturer to filter through the nodes in the timeline. We also implemented a hover feature that displays information about a certain node based when the cursor is hovering over it. We spent a good period of time editing the functionality of the TimeFlow API to suit our particular screen flow. The main feature that needed implementing is the clickable nodes on the timeline. Luckily the time flow API has a class called AbstractVisualization built specifically to allow for a unique screen flow when a timeline node was clicked. We used this class to link the TimeFlow UI with the screens we created for the Leveson Inquiry case study. In designing the user interface we followed a clear bottom-up pattern. We devoted the first period of time to learning about the TimeFlow API. After learning and customizing the library to our liking, we then moved on to creating the linked screens. We knew that the timeline view was a key requirement for our client, thus we places that as a ‘must-have’ requirement during our proof of concept. Student and Lecturer Client Another key requirement for our application was the separation between the student and the lecturer view. This portion was important as it made sure that the lecturer (our client) had full control over the application and the students could only see what he showed them. A lot of the functionality regarding the different sessions and the different users was built in the controller package. The controller and the session’s packages together make up the back end of the program. The classes in these packages interact with the various user interfaces and based on the current user, loads a certain interface. The lecturer interface was designed such that the lecturer had the ability to  Teach multiple classes

 Organize stimuli  Ask questions  Collate answers  Categorize responses  Analyze class responses  Compare responses In order to facilitate these activities we needed to design a specific screen flow for the lecturer. Our design philosophy was to use the least number of screens possible while providing information in a concise manner. Wherever possible we made the effort to create intuitive ways for the lecturer to interact with the system. For example, to allow the lecturer to easily categorize the responses, we set up a drag and drop system. In this system, the lecturer simply drags the answers to the category and the answer will turn a different color to confirm that it has been categorized. The student interface was designed to allow students to  Access all stimuli  Respond to questions  View responses of the class  Visualize class responses Designing the student client also required a similar design philosophy. Since the students were the learners in this situation we made sure to design an interface that would facilitate their learning. To do this we made sure that no screen has too many details on it and that the student could view the stimuli properly. Students do not have the ability to categorize responses like the lecturer, which is why we implemented a separate student graph screen which only allows them to view the graphs created by the lecturer. Multimedia The multimedia integration for the Ethics Reviewer application is also a feature that is highly important to its function. Our client told us that the majority of his stimuli will be in the form of videos. Thus our task became finding a good video streaming APi in java. After doing extrnsive research we realized that the existing java video API’s were all quite outdated. Additionally the required the videos to be placed in the downloadable file which would make the program file quite large. In the end, in order to minimize the size of the file and allow maximum video customizability we decided to host it on YouTube. We then implemented a native browser within java to play the video using the DJ native swing library. We agreed that this would be the best solution as it allowed the user to adjust the volume and video quality as they wished. Response Analysis The response analysis is another key portion of our application. The response analysis portion allows the lecturer to view and categorized the student’s responses in real time. This categorized information should then be viewable in different forms such a bar chart, a pie chart and a grouping screen.

The real time response view was implemented as a messaging system that pulls information from an SQL server. When a lecturer categorizes a certain response that information is sent to the SQL database. This information is the downloaded and used by the application along with the Jfeechart library to create the necessary graphs. We chose the Jfreechart library because the design of the chart was highly customizable. JFreeChart also allows lots of changes to be made to the constructor and thus allows different forms of data to be passed. This made it very easy to pass the data from the SQL database, perform some calculations then pass on to Jfreechart. JFreeChart also allows identical charts to be created with identical data. Thus, when creating the student view we simply needed to pull the information from the server and it would draw the identical graph. The graph package contains all the classes that help create and store the graph information. There are separate classes for both students and lecturer graph to allow for the pulling and pushing action on the database.

Ethics reviewer technical achievements and implementation details  
Ethics reviewer technical achievements and implementation details