Gnome:Project Plans

From Notes

Jump to: navigation, search

Contents

Project Plans

June 8, 2010

We are considering making a general, modular interface for defining separate modes within Dasher. Our inspiration for this endeavor is a result of the fact that when we sat down to think about where a "Training Mode" would sit in relation to the core dasher code, we couldn't immediately determine what we would do. There was no simple interface for extending Dasher's business logic.
Our early, early architectural ideas are similar to the current mode of abstraction Dasher uses to support platform-specific code. There are multiple interfaces that platform-specific code must define. The code that handles linking visual events to Dasher's event management system is defined already, but each platform module defines its own visual representation. The same goes for input logic, as this is platform-specific as well.
We are planning to refactor out and encapsulate Dasher's core business logic (This being defined as any part of Dasher that is not specific to any one mode.) and then defining an interface that any developers looking to add new business functionality (Scoring for a game mode or spell-checking, for example.) would adhere to. The goal is to create a sort of module-based system where the user can select bits of functionality to add to Dasher. This would make the task of implementing game mode FAR easier and allow us to adhere to good coding practices and not clutter up the rest of the code with game-related conditionals and branches.


June 10, 2010

Today we put more thought into the idea of training/game mode being able to tell a user where to move to type a letter in a provided text string. For example, say the string provided was "Strawberry laserlight bean curd" and the user has already typed "Strawberry las", we would find the location of the node in the list of children of the "s" node that represents the character "e", draw an arrow to that location (be it currently visible or not) to alert the user to the direction in which they should move.
If the user makes a mistake and starts to proceed down an incorrect path, they will be required to back out and proceed anew. We haven't officially decided on what kind of alert to draw here, but the obvious choices could be drawing an arrow that simply points in the opposite direction from which the user is moving, or drawing an arrow to the last node before they made a mistake.
We are currently in talks with Patrick as to whether something like this should be implemented as an Input filter or not. From the looks of the other input filters, it will provide all the facilities we need to decorate the screen, query the model and score the user.
What we have yet to think about is difficulty of phrase, making game mode work with other input modes or the overall modularity of the system.

June 17, 2010

We are now implementing game mode as a separate module that hooks into Dasher's core functionality using similar mechanisms to InputFilter. We are also creating an abstraction layer for the words in training texts, such that the source of a text (a file, an online source, a word generator, etc.) would not affect the higher level logic of game mode.
Personal tools
NSF K-12