The following is a personal project I’ve been working on with the intent to stimulate ideas among the QuickBase developer and user community, and to share some resources that I found helpful. My hope is that what’s here could help spark out-of-the-box ideas for solutions to meet your company’s particular need or challenge. We’ll walk through a use case and some of the challenges I faced as a developer in this particular project. However, this concept is not a QuickBase product and I’m not planning to support the current demo code.
Consider this use case:
Mary runs the customer support group of a SaaS company and likes to always be aware of when customers are having issues. Her team stores support cases in a QuickBase table, and uses a report to track all unresolved cases. Before going to the Patriots game on Sunday afternoon, Mary downloaded a new mobile applet for her Android to help keep her abreast of the support queue.
When there was a lull in the game at Gillette Stadium, Mary ran the mobile applet to retrieve the QuickBase support queue report. Instead of displaying the report in the browser, the phone read aloud: “The number of Open Cases is 22.” At that moment the crowd went wild, and it was too noisy to hear the audio. No problem, a dial gauge appeared (see adjacent) to display the urgency of her support queue by how many open cases there are. Mary could see that her support queue was in the orange zone. She would have preferred green, but at least it wasn’t red. Mary could also read the same text statement that was read out aloud by the phone. There were more cases than normal, but Mary was able to decide on the spot that it was not urgent enough to leave the game.
The mobile applet:
This is a native Android application, not a web application. Currently, it does allow a user to pick the QuickBase app/report that he or she wants to run. If there is another iteration of code, I’ll have that choice be remembered as the default report to run when the mobile applet is next started. One hurdle I ran into is that QuickBase apps require app tokens by default, so if app token is not turned off for the chosen app, the mobile applet detects that error condition and asks the user to enter the app token (and then stores it locally).
As a developer, what were some of the challenges I encountered?
There was, of course, a learning curve with the Android SDK and framework. It wasn’t insignificant, but very doable for anyone with experience using analogous frameworks, such as Adobe’s Flex. I had known that a big hurdle was the dial gauge component but fortunately someone did share his code a few months ago as open source, and I was able to tweak it sufficiently to use in this demo prototype. I’m hoping to extend its functionality, and then contribute the code back into open source. You can find the source code here; also check out the blog post of the first contributor of the software for some code walk-through and insight.
The text-to-speech feature turned out not to be a major difficulty, mainly because of the available Android TextToSpeech class, as well as a short but good developer guide here.
For some time, I had wondered about a better way for web applications to fit the smart phone’s screen size than simply re-laying out their web browser outputs. Customizing web pages to display on a phone browser is not necessarily trivial, and is also an additional maintenance task. While the trade-off is worthwhile in many cases, the user experience is usually somewhat compromised as a result.
Rather than rely on a phone’s browser, I was trying to find a way to exploit the incredible native functionalities in smart phones for a subset of QuickBase mobile users who might require only summary data out of a report. This version of a show ‘n tell dashboard is my initial attempt to demo data visualization and audio output on the amazingly powerful Android platform.