applica6ons. Too many things to answer when designing the interac6on for a public display applica6on: • What controls can we use to offer interac6ve features to users? – No standard interac6ve controls for public displays • What interac6on mechanisms can be used to provide those features? – Various possible interac6on mechanisms (SMS, BT naming, OBEX, Email, IM, mobile app, desktop, QR codes, touch, etc.) – Different loca6ons may have different interac6on resources • How will those features work? – Desktop interac6on paradigm does not generally apply – Applica6ons may not always be visible • How can the applica6on react to different users? – The interac6on environment is mul6-‐user – We need to iden6fy/differen6ate users • How can users tell what they can do with the applica6on? – Where are the features presented? 3
hoc applica6ons, but • This means wasted effort in developing applica6ons – Programmers must deal with issues extraneous to the main applica6on logic • Will certainly lead to inconsistencies in the interac6on model – Each solu6on will behave slightly differently – Will confuse users We need a programming toolkit for interac6ve public display applica6ons! 4
• To make sure it covers a wide range of applica6ons, we looked at various interac6ve public display systems to learn – General requirements – Types of controls – Types of input mechanisms 6
an interac6ve feature. • Is represented by class in an object-‐oriented programming model. • Applica6ons instan6ate widgets, define a callback, and receive interac6on event through the callback • Main features – Mul6ple, extensible, controls – Independence of input mechanisms and modali6es – Automa6cally generated graphical interfaces – Asynchronous interac6on – Concurrent interac6on – Graphical affordances – Server & client libraries 7
developers to create rich interac6ve applica6ons. Controls can be extended with custom func6onality. • We studied various interac6ve display systems to define a set of basic interac6ve controls, common to the majority of applica6ons: • Ac6on bugon – Trigger an ac6on in the applica6on, e.g., play a video • Op6on selec6on – Selects among a set of op6ons, e.g., to vote • Text entry – Sends text to the applica6on, e.g., a comment, tag, search keyword • Download – Receives a media file from the applica6on, e.g., download poster • Upload – Uploads a media file to the applica6on, e.g., a photo to be displayed • Check-‐in – Says “I’m here” 8
• Allows developers to focus on the core applica6on func6onality and not on the low-‐level interac6on details. • Allows applica6ons to work in heterogeneous loca6ons, with different mechanism • Interac6on can be accomplished with various mechanisms (SMS, Bluetooth naming, QR codes, and automa6cally generated graphical interfaces). 9
a richer interac6on for desktop and mobile devices. • PuReWidgets generates web-‐based interfaces for each applica6on. • It also generates QR codes for each applica6on's feature 10
receive input events that were generated when the applica6on was not listening. • PuReWidgets provides a persistent input queue for each applica6on • Applica6ons can request past input at any 6me 11
to interact at the same 6me, while providing applica6ons with iden6ty informa6on that allows them to differen6ate users. • Every input event carries a user id (if available) – Where possible, anonymous interac6ons are s6ll “iden6fied” (more on this later) 12
immediately recognize interac6ve features and input feedback. • Controls have an op6onal graphical representa6on that can be used on the public display interface. – Applica6ons may not show the features on the public display, but they will s6ll be available • Input feedback is also (op6onally) displayed on the public display. 13
• Hides the communica6on details with the PuReWidgets service • Provides other features, unrelated to interac6on, such as – Applica6on “place-‐aware” storage • PuReWidgets provides a name-‐value server datastore for easy storage of place-‐specific seqngs/state – Skeleton admin interface for place-‐owners • To configure place-‐specific seqngs 17
display (player) – Subject to the schedule 6mings • May not be able to react (or update data structures) immediately when user interacts – But will eventually (when it is displayed again) • When displayed, the toolkit periodically asks the service for input events – And triggers the appropriate widget event 19
• Can react (or update data structures) immediately to user input – Even if not on the public display, the reac6on can be visible on other channels • The toolkit periodically asks the service for input events – And triggers the appropriate widget event 21
so far (ignore the “graphic design”, please) – Youtube player, media intensive, complex graphical components (several panels that change over 6me), local applica6on model – Everybody votes, based on display owner created content, simpler graphical component, combines remote and local applica6on models 24
interac6ve public display applica6ons – Gain more insight about the difficul6es – Refine the toolkit to address the iden6fied problems – Refactor the applica6ons to include the toolkit changes 25
ready-‐to-‐use interac6ve controls – Integrates various input mechanisms via an I/O infrastructure – Generates applica6on interfaces for desktop, mobile, and QR codes – Provides client and server applica6on development models 26
jorgecardoso
langstat
ymorita613
hargon24
nami_ogawa
haraduka
ryou0634
yuyay
kentosasaki
0x1shu
hf149
sshimizu2006
kuri8ive
garrettdimon
productmarketing
paulrobertlloyd
michaelherold
ammeep
caitiem20
rasmusluckow
mza
denniskardys
moore
addyosmani
csswizardry
