Differences

This shows you the differences between two versions of the page.

--- proj [2017/02/08 16:19] – bil
+++ proj [2018/02/27 15:49] (current) – bil
@@ Line 1: / Line 1: @@
 **EECS 2311 Project**
-This term's project is to develop software for a hardware device used to help kids read Braille.
+<html><!--
-The hardware device will have a number of Braille cells, as well as a number of physical buttons.
+  To be posted.
-The system presents Braille characters/words to the user who then responds by pressing buttons.
+--></html>
-You can get a sample usage scenario for the system {{:adventure_on_the_high_seas.pdf|here}}.
-The hardware will be under development this term as well, so our first task will be to develop a...
+Treasure Box Braille (TBB) is a device that helps kids learn how to read Braille.
+TBB presents Braille characters/words to the user who then responds by pressing buttons.
+Educators can load different scenarios to teach different letters and keep the kids entertained.
-**Simulator**
+We will write a piece of software to help educators create these scenarios. We will call it the Authoring App. The Authoring app will provide facilities to
+  * Create the flow of the scenario (ask questions, receive answers)
+  * Record audio
+  * Save the scenario in the appropriate format
+  * Test the scenario using the provided software
-A piece of software that simulates the behaviour of the hardware device
+**Important requirement**: The Authoring App must be usable by visually-impaired users
-Has a user interface similar to that of the device
+Since there are not enough TBBs for each group (and also because they are expensive and hard to replace), we provide software that simulates the TBB.
+This way, as an educator is preparing a scenario with your authoring app, they can try it out to see if it works. See the Week 1 slides (click on Course Outline) for instructions on how to get the starter software.
-Is fully tested to behave as the hardware device
+The starter software contains example scenarios that you can run to get a feel for what this system does.
-Presents an API that the rest of the system will use to communicate with it
+{{:startersoftwaredesign.pdf|Click here}} for a UML diagram of the starter software.
-**Simulator API**
+{{:scenarioformat.pdf|Click here}} for a description of the file format for scenarios.
-The most critical part of the Simulator is the API it will present to the Player and Authoring app
+**New requirement (added on Feb 27, 2018)**
-This API must be able to be duplicated by the hardware device (its firmware will include a firmware wrapper)
+Your system must log all actions the user takes and keep count of how many times each feature is accessed
-API must be described in detail with Javadoc
+Based on the log data, add keyboard shortcuts to the most frequently used features. Such features should be easy to access with a mouse as well
-The best simulator API from all submissions will be chosen going forward
-**Simulator Submission Details**
-Rubric posted under Evaluation
-Four grade components
-  - Requirements document
-  - Testing document
-  - Simulator API
-  - Implementation
-**Simulator Submission Process**
-. Create a .zip or .jar that contains the following:
-  * All grade components from the previous slide including the code
-  * A README.txt that
-    * Explains the contents of the zip file
-    * Describes how to access the API in HTML
-    * Provides a link to your github repository
-. Email the zip file to bil@cse.yorku.ca by 11:59pm on Feb 7
-  * Only one email per team
-  * Include your team number in the subject
-. Each student must also send me a private email with an assessment of their teammates’ contributions