...
One of the challenges we faced after paper prototyping was the realization that in our original concept's on-screen keyboard was simply not comfortable or efficient. While such keyboads may be efficient for mobile devices and tablet PCs, we were forced to consider alternative solutions. Ultimately, we decided to use an RFID reader to grab information from the user which would allow us to populate the email field when adding a poster as well as confirm a user's identity when sending reminders and attempting to delete a poster. This Of course, this solution required not only the acquisition of a suitable RFID reader but also the implementation of a websocket server built on a mechanism for the RFID reader code in order to relay supply information from the RFID reader to the frontend application which was running in a browser .
- the actual board was not functional until the week before GR5 was due. It was missing a crucial connecting cable to allow the smart board to communicate with the computer. After several tens of hours of conversations with Customer Service and three sets of incorrect cables, we finally got the board working. So resolution, fit to big screen don't happen very well.
It is also important to point out that the board's touchscreen was not as responsive as we hoped and this impacted the usability of the system somewhat. Another board-specific implementation detail is that the board does not support multi-touch so we abandoned the idea of supporting multiple users working with the board simultaneously.
and consequently unable to receive information from system-specific input devices. The first attempted solution to this problem leveraged javascript in order to enable it to talk to the Django server in order to communicate indirectly to the application through the backend, however this failed. A subsequent attempt was able to run at the Django server, but the single-threadedness of the Django development server implementation meant that waiting on RFID events would block content service and vice versa. Clearly not suitable. Finally, the implementation of a websocket server built on the RFID reader code was developed in order to relay information from the RFID reader directly to the frontend independent of Django. The complexity of this interaction meant that the working implementation was only available a week before GR5, thus limiting our ability to take further advantage of its capabilities.
Likewise, our dependence on the SmartBoard hardware in order to provide touch input lead to over 30 hours of technical phone support from SMART, and several additional components either purchased from SMART or mailed to us from support technicians who were unable to diagnose the problems further without exhausting the slew of troubleshooting techniques which require their hardware. The final working connection with the board was facilitated by a proprietary serial-to-USB cable which SMART does not sell via their online store and was only obtained after exhausting all other connection capabilities available on their website. Consequently, the working touch solution was only available days before the completion of GR5.
A side-effect of this problem was the need to completely resize our interface prior to demo since we had all been developing on machines with significantly higher resolution or different aspect ratios than the SmartBoard. It also meant that we could not customize our application to the specific touch facilities of the hardware. Specifically, out interface assumes that the touch hardware will relay touch information reliably while in reality the SmartBoard was neither as responsive nor as accurate as we would have hoped. Had we know this, we could have provided larger click regions for visible buttons, altered our spacing, and created more feedback so that the perceptual fusion was a bit stronger. Further, the use of optical touch meant that we were forced to rely on only a single input point which precluded our former use cases for allowing multiple users to interact with the board as well as those which considered gestures- rfid. we had to explore several ways to get rfid working with javascript and enable it to talk to the django server. we had to make three prototypes, two of which failed before getting a viable one. the working prototype came together the week before GR5, limiting our ability to take further advantage of it.
Evaluation
The ideal user test would have been conducted by moving the board to a part of the building with high human traffic and the test conducted with people who were attracted to the board in the first place. We however did not have that luxury because the board was fixed in place at the group space of a research group. We however managed to conduct a test that was very revealing and helpful.
...