PuReWidgets toolkit
Upcoming SlideShare
Loading in...5
×
 

PuReWidgets toolkit

on

  • 643 views

A presentation about the initial version of the PuReWidgets toolkit for interactive public display applications.

A presentation about the initial version of the PuReWidgets toolkit for interactive public display applications.

Statistics

Views

Total Views
643
Views on SlideShare
643
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    PuReWidgets toolkit PuReWidgets toolkit Presentation Transcript

    • The  PuReWidgets  toolkit  for   interac6ve  public  display   applica6ons   Jorge  C.  S.  Cardoso   jorgecardoso@ieee.org     Ubicomp@UMinho     May  30,  2012   1  
    • Content  •  Mo6va6on  •  PuReWidgets  features  •  Architecture  •  Applica6on  models  •  Programming  library  overview  •  HelloWorld   2  
    • Mo6va6on  Complexity  of  incorpora6ng  interac6ve  features  in  public  display  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  
    • Mo6va6on  We  can  solve  all  those  ques6ons  for  ad  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  
    • Toolkit  •  The  toolkit  should  provide  a  consistent  model   for  user  interac6on  and  applica6on   development   –  But  s6ll  allow  some  diversity  in  solu6ons   5  
    • PuReWidgets  •  PuReWidgets  tries  to  solve  these  problems.  •  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  
    • PuReWidgets  Widget-­‐based  toolkit.    •  A  widget  represents  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  
    • Features  Mul6ple,  extensible,  controls.      •  Allows  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  
    • Features  Independence  of  input  mechanisms  and  modali6es.    •  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  
    • Features  Automa6cally  generated  graphical  interfaces.    •  Provide  a  richer  interac6on  for  desktop  and   mobile  devices.  •  PuReWidgets  generates  web-­‐based  interfaces   for  each  applica6on.    •  It  also  generates  QR  codes  for  each   applica6ons  feature     10  
    • Features  Asynchronous  interac6on.    •  Allows  applica6ons  to  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  
    • Features  Concurrent  interac6on.    •  Allows  various  users  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  
    • Features  Graphical  affordances.    •  Allows  users  to  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  
    • Features  Server  &  client  libraries.    •  Programmers  can  choose  to  use  just  the   server,  just  the  client,  or  both  libraries   together.  •  Allows  developers  to  choose  the  best   applica6on  model.   14  
    • PuReWidgets  Architecture   15  
    • Interac6on  services  •  PuReWidgets  service   –  Keeps  informa6on  about  every  widget   –  Generates  graphical  interfaces  for  desktop,  mobile,  touch   plaporms     •  These  allow  anonymous  interac6ons,  but  they  generate  persistent   cookie-­‐based  random  ids.   –  Generates  QR  codes  for  every  widget   –  Generates  unique  textural  reference  codes  for  data-­‐based   interac6ons  (SMS,  BT  naming,  OBEX,  etc.)  •  IO  infrastructure   –  (from  Instant  places)   –  Provides  low-­‐level  data-­‐based  interac6on   16  
    • PuReWidgets  library  •  Provides  an  object-­‐oriented  library  of  widgets  •  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  
    • Local  applica6on  model   18  
    • Local  applica6on  model  •  Applica6on  logic  on  the  public  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  
    • Remote  applica6on  model   20  
    • Remote  applica6on  model  •  Applica6on  logic  on  the  server  •  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  
    • PuReWidgets  Implementa6on  •  Google  Appengine  (server)  •  Google  Web  Toolkit  –  GWT   (client)  •  Overview  of  the  library   22  
    • Using  PuReWidgets  •  Hello  World  applica6on  (local  model)  •  Video   23  
    • Ini6al  Evalua6on/Development   process  •  Two  applica6ons  developed   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  
    • Ini6al  Evalua6on/Development   process  •  Con6nuous  refinement   –  Develop  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  
    • Summary  •  PuReWidgets  facilitates  applica6on   development   –  Provides  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  
    • The  end   27