Reception desks at our University building entrances have numerous peak activity moments during the day. Classes, exams or massive activities are basically what cause these peaks. Before a blink of an eye, a long queue will be formed in front of an overwhelmed person behind the desk. The person will check through the room reservations report and other sources to quickly and kindly answer all requests. At the same time the phone will probably ring, adding some more tension to the moment. After witnessing these moments several times and some brainstorming back with our development team we came up with an idea to divert requests from the desk. So the question arose: could we speak to our SAP system? Could we develop some solution where people could talk to and get quick answers and instructions? We came up with the following proposal and worked on a proof of concept. The solution would have the following components:
1. an Android tablet attached to a wall or standing on an alternate desk
2. a native app for quick response to events
3. a voice-to-text solution/component
4. a webservice to complete the text search and answer
Getting a tablet was easy, we had one for testing purposes available, stored in a nearby building and got hold of it.
We hadn't been developing native mobile apps but had been fiddling around a couple of years ago with MIT's App Inventor online development tool. Worked great for simple and as simple apps. The IDE offers the object SpeechRecognizer to recognize voice and return a text of what it "listens" to, and it also offers an object to consume a webservice, as well as typical components for textboxes, buttons, labels, grids, etc.
While part of the team focused on developing the webservice, another worked on the native app. The webservice logic was quite simple, getting a text as an input parameter, then searching for matching events/courses happening "today" and returning the list of events names and the rooms occupied by them. We had to be careful here with two things:
i) abreviations used on the course names (some people can get really creative with names and the standard field for names in SAP isn't very long; and we found different abreviations for the same word)
ii) special characters used in the Spanish language
For abreviations we worked with a synonym pool and solved a great deal of the exceptions we came across during testing. The special characters was a little easier to deal with, so both aspects were attended.
MIT's App Inventor helped us get a solution in a very short time. Being an online tool, it requires no installation, just a registration process to use the tool. Screens are created dragging and dropping objects and our screen was very simple. Although the following printscreen shows the logo streched, the component's properties will let the image adapt to the screen size of your device.
Logic handling (equivalent to programming code) is very intuitive thanks to a "Blocks" tool where you build your sequence of commands and logic decisions with blocks which connect as puzzle pieces.
After some days of development we connected the app with the ERP using the webservice and were able to get first impressions of the solution. We focused on time response -critic for the success of the service-, where we were looking to get a response for the user in no more than 2 seconds. Long time responses would be a a good reason for failure. Lab testing after some finetuning was successful on this aspect. We also tested for words with abreviations and Spanish special characters and ended with very little error rate.
Next step was testing the app at the reception desk of our own building -coincidentally the building with the most traffic-. The wifi network availble there isn't the same as on our lab and it has some more hops on the network to get the ERP, but time response was still reasonably good and we eventually gave a thumbs up to the second level test and thus raising everybody's exitement. By that time, everyone at the recepcion desk was aware of the PoC we were working on and were even more exited than us about the outcome.
Third level testing was the final one, doing it at peak traffic moments, and just a couple of steps away from the reception desk. A variable appeared we hadn't taken into account up until that moment. The bustle of so many people talking and walking in the hall was such, that the microphone wasn't able to distinguish our words. We raised our voices and still had no luck. Shouting at the tablet didn't seem like a friendly idea so we decided to skip it. We were advised some tablets allow for microphone sensibility adjustment but we couldn't find where it could be done.
Unfortunately the PoC failed for an unexpected variable so we decided to freeze the project for some time. On the other hand, it triggered some other ideas that were successful (to be shared in future posts) and truth is, we had quite some fun developing and testing it.
