Link
Stina Nylander Swedish Institute of Computer Science, Box 1263, SE-16429 Kista, Sweden
Markus Bylund Swedish Institute of Computer Science, Box 1263, SE-16429 Kista, Sweden
Magnus Boman The Royal Institute of Technology, Forum 100, SE-164 40 Kista, Sweden
Personal and Ubiquitous Computing archive
Volume 8 , Issue 1 (February 2004) table of contents
Pages: 42 - 46
Year of Publication: 2004
ISSN:1617-4909
Abstract: When services providing real-time information are accessible from mobile devices, functionality is often restricted and no adaptation of the user interface to the mobile device is attempted. Mobile access to real-time information requires designs for multi-device access and automated facilities for the adaptation of user interfaces. We present TapBroker, a push update service that provides mobile and stationary access to information on autonomous agents trading stocks. TapBroker is developed for the Ubiquitous Interactor system and is accessible from Java Swing user interfaces and Web user interfaces on desktop computers, and from a Java Awt user interface on mobile phones. New user interfaces can easily be added without changes in the service logic.
My Discussion:
A fascinating paper. Its first premisse for connected service is the quite solid thought that customization for the device has to happen -- ok, nothing new there, although, for example, the makers of the Opera browser would say that writing HTML with the old tools is just fine as long as the hTML client does something smart with it. The second one is that this customization has to be automated; none of that writing seven sites/UIs for different devices and modalities in all these languages. Start with one UI description and make it run appropriatly everyhwre. This is achieved by describing all interaction at a very high level with eight meta-actions start, stop, (for services or programs) create, destroy, (for entities like calendar entries) input, output, (get input not in the UI, show stuff) select, modify (select from some alternatives, change an existing entity). From these 'Interaction Acts' a Ui described in a document from an XML called ISD, which is shipped together with a visual customization form -- which can include branding -- to run on a general UI engine for this system on the target device.
An example is given for a UI to a push-based stock-broker service that can be interacted with as an HTML page, a Swing application, or an AWT applet on a smartphone. Alas, here is where the paper starts letting down: the three interfaces do not look fundamentally different, and there is no discussion on how the difference in networking affects how the UI should act.
Stina Nylander Swedish Institute of Computer Science, Box 1263, SE-16429 Kista, Sweden
Markus Bylund Swedish Institute of Computer Science, Box 1263, SE-16429 Kista, Sweden
Magnus Boman The Royal Institute of Technology, Forum 100, SE-164 40 Kista, Sweden
Personal and Ubiquitous Computing archive
Volume 8 , Issue 1 (February 2004) table of contents
Pages: 42 - 46
Year of Publication: 2004
ISSN:1617-4909
Abstract: When services providing real-time information are accessible from mobile devices, functionality is often restricted and no adaptation of the user interface to the mobile device is attempted. Mobile access to real-time information requires designs for multi-device access and automated facilities for the adaptation of user interfaces. We present TapBroker, a push update service that provides mobile and stationary access to information on autonomous agents trading stocks. TapBroker is developed for the Ubiquitous Interactor system and is accessible from Java Swing user interfaces and Web user interfaces on desktop computers, and from a Java Awt user interface on mobile phones. New user interfaces can easily be added without changes in the service logic.
My Discussion:
A fascinating paper. Its first premisse for connected service is the quite solid thought that customization for the device has to happen -- ok, nothing new there, although, for example, the makers of the Opera browser would say that writing HTML with the old tools is just fine as long as the hTML client does something smart with it. The second one is that this customization has to be automated; none of that writing seven sites/UIs for different devices and modalities in all these languages. Start with one UI description and make it run appropriatly everyhwre. This is achieved by describing all interaction at a very high level with eight meta-actions start, stop, (for services or programs) create, destroy, (for entities like calendar entries) input, output, (get input not in the UI, show stuff) select, modify (select from some alternatives, change an existing entity). From these 'Interaction Acts' a Ui described in a document from an XML called ISD, which is shipped together with a visual customization form -- which can include branding -- to run on a general UI engine for this system on the target device.
An example is given for a UI to a push-based stock-broker service that can be interacted with as an HTML page, a Swing application, or an AWT applet on a smartphone. Alas, here is where the paper starts letting down: the three interfaces do not look fundamentally different, and there is no discussion on how the difference in networking affects how the UI should act.
# posted by Unknown @ 2:11 PM
Comments:
Post a Comment
