CQC Client: Wish ListCQC Client: Wish List
The items on this page would be nice to have some day. But most require changes to the RIVA protocol.
Currently, when the client connects, the server always treats it as a brand new connection, and puts the user at the top level of the template. So any time a connection gets dropped due to spotty cell phone service, the user gets booted back to the beginning -- very annoying. I believe that Dean is considering an enhancement to the protocol to fix this problem. I will modify the client to support this change when it is available.
The RIVA protocol provides a very clean boundary between the client, which doesn't know anything about the template, and only processes basic drawing commands and user screen touches, and the server, which has all the user interface smarts. That's a clever idea, but it leads to problems when used over a slow connection like a cell phone.
For instance, one iPhone user designed a template that highlights buttons as the user holds a finger down on them -- ordinarily an excellent way to give feedback to the user that they are touching in the right place. But when used on a cell phone connection, it's too slow to work. The button doesn't get highlighted until after the user would ordinarily have taken the finger off of it. You have to hold your finger down for a second or two to get the highlighting, then wait another second or two after removing the finger for the highlighting to disappear. That renders the whole scheme useless as a user interface cue, and it's annoying to boot.
There's nothing the client can currently do to ameliorate the problem, because the client knows nothing about what a "button" is. All it knows is how to draw rectangles, put text in particular places, fill an area with blue, and so on. The button is a higher-level construct managed entirely on the server.
I think this is a serious enough shortcoming that we should consider punching a few artfully chosen holes in RIVA's dividing wall between client and server. The server could send hints about which areas on the screen were buttons, and clients running on slow connections (e.g. the iPhone) could use this information to automatically highlight the area when pressed. Other clients would be free to ignore these hints if desired.
I realize that this represents a major shift in the RIVA design. However, I daresay that anyone who attempts to use a RIVA client over a slow connection for any period of time will begin to see the wisdom of such a change.
Even without cues from the server, there are a few things the client could implement independently, but having some hints would make things better. For instance, swipe gestures will transmit cursor motion hot keys. If the template is the kind that displays a scrolling list (for instance, a list of CDs or movies), swiping up and down will probably scroll through the list. An iPhone user would expect the list to scroll visually, but currently the page stays unchanged on the screen until the new page arrives and replaces it. Not the world's best interface.
The client knows when the gesture has been made, so in theory it could unilaterally begin to scroll the page, to give some feedback to the user that a new page will be appearing. However, this only works if up/down swipes always scroll a list everywhere in the template. Otherwise, even static one-page displays will get scrolled, which would be annoying. So once again, a hint from the server that swipes in some directions will currently cause scrolling, while others will not, would improve the user interface experience greatly.
Currently, only fonts that are installed on the iPhone can be used in templates. It seems like it wouldn't take much to extend the RIVA protocol to support the downloading of custom fonts (e.g. special fonts containing button icons and so on). There's already a mechanism for downloading images, and there's no reason it couldn't be used for fonts as well. When the client encounters a font it doesn't recognize, it sends a request to the image server, asking for an image path of the form "Font::TheFontName". All the image server would have to do is grab the font file and send it as a blob of opaque data back to the client, where the client would deal with it appropriately.
In the meantime, Rob Gutmann has gotten permission to use the Transports font in our application, and I have bundled it into the new release. However, it uses a new feature of the iPhone OS which is currently available only on the iPad, so Transports is not yet available for the iPhone and iPod Touch. When Apple gets around to releasing version 3.2 (or newer) of the OS for those devices, they will be able to use Transports.
I believe that the iPhone has voice recognition capabilities. So all we need to do is turn on the voice recognition, and send hotkey messages for each different command. However, there aren't currently enough hotkeys defined for this to work very well. There are only 50 or so hotkeys, and many are already used by the iPhone for orientation and shake motions, or specifically defined as navigation and media keys.
If that's all that will ever be available, I can try to shoehorn a few voice commands into unused hotkeys. But it would be better if there were hundreds of available hotkeys, or an alternate RIVA command message that transmitted an arbitrary 4-byte integer or, even better, a string, which could then be interpreted by the template code.
The new version supports image caching, which will hopefully lessen the annoyance of waiting for images to load. But it would still be nice to speed this up. The RIVA protocol only allows one connection at a time to the image server port, and a single image must be completely fetched and acknowledged before a fetch of the next one is inititated. If the protocol were extended to allow either multiple connections or multiple requests per connection (so that data for the next image would begin transmission right after the current one, rather than waiting for the round-trip delay of client acknowledgement), performance could be improved.