bIoTope D5.1 interaction patterns report (5) -...

DELIVERABLE

ThisprojecthasreceivedfinancialsupportfromtheEuropeanUnionHorizon2020Programmeundergrantagreementno.688203.

D5.1IoTInteractionPatternsReport

ProjectAcronym: bIoTopeProjecttitle: BuildinganIoTOpenInnovationEcosystemforConnectedSmartObjectsGrantAgreementNo. 688203Website: www.bIoTope-project.orgVersion: 1.0Date: 21September2016ResponsiblePartner: FraunhoferContributingPartners: AALTO,EPFL,CSIRO,eccenca,OpenDataSoft,CTDisseminationLevel: Public X

Confidential–onlyconsortiummembersandEuropeanCommissionServices


©688203bIoTopeProjectPartners 2 21September2016

RevisionHistory

Revision Date Author Organization Description

0.1 26/08/2016 ChristianMader Fraunhofer Initialdraft

0.2 30/08/2016 ChristianMader Fraunhofer Consolidateddraft

0.3 06/09/2016 ChristianMader,KristianBäckström

Fraunhofer,ControlThings

Revieweddraft,addedcomments

andcontributionsofKristian

0.4 09/09/2016 ChristianMader,AnnetteWeiland

Fraunhofer,eccenca addedAnnete’scommentsandcontributions

0.5 16/09/2916 ChristianMader,SimoneParrotta

Fraunhofer,Holonix AddressedSimone’scomments,fixed

typos1.0 21/09/2016 ChristianMader FinalFormatting&

PolishingFinalVersion

Everyefforthasbeenmadetoensurethatallstatementsandinformationcontainedhereinareaccurate,

howeverthebIoTopeProjectPartnersacceptnoliabilityforanyerrororomissioninthesame.



TableofContents

1. Introduction................................................................................................................................................6

1.1. ObjectivesinWP5...............................................................................................................................6

1.2. ObjectivesinTask5.A..........................................................................................................................6

1.3. ContentofthisDocument...................................................................................................................6

2. ProblemDefinition......................................................................................................................................7

2.1. DiverseDeviceClassesandInteractionMethods................................................................................7

2.2. DiverseDataFormats..........................................................................................................................7

3. Approach.....................................................................................................................................................8

4. CityUseCases..............................................................................................................................................8

4.1. Brussels–CapitalRegion.....................................................................................................................8

4.1.1. IoTobjectsandservices.............................................................................................................10

4.2. FVH–ForumViriumHelsinki.............................................................................................................11


4.3. GreaterLyon......................................................................................................................................12


5. ThematicalUseCases................................................................................................................................14

5.1. SmartMobility...................................................................................................................................14


5.2. SmartBuildingandEquipment..........................................................................................................15


5.3. SmartAirQuality...............................................................................................................................17


6. PilotUseCaseInteractionCommonalities................................................................................................19

6.1. InteractionPatterns..........................................................................................................................19

6.2. IoTObjectsandServices....................................................................................................................19

6.3. UserInteractionElements.................................................................................................................20

6.4. Actors................................................................................................................................................20

7. ReusableInteractionPatternsandRelatedWork.....................................................................................21

7.1. PracticabilityofUserInterfaces........................................................................................................21

7.2. ServiceInteraction.............................................................................................................................22

7.2.1. GeneralInteractionMethodswithIoTSystemsandObjects....................................................22

7.2.2. PervasiveandUbiquitousComputing.......................................................................................23

7.2.3. AutomotiveUserInterfaces......................................................................................................23

7.2.4. Interfacesforgeographicinformationsystems.........................................................................24

7.2.5. Interactingwithschedulesandcalendars.................................................................................25



7.2.6. Interactionwithhouseholdappliancesandhomeautomationsystems..................................25

7.2.7. Usinge-commerceandpaymentservices.................................................................................26

7.2.8. Interfacesofservicecatalogues................................................................................................26

7.3. ServiceCompositionEditors..............................................................................................................26

7.3.1. UnifiedViews..............................................................................................................................27

7.3.2. SparqlFilterFlow.........................................................................................................................27

8. MethodsforIoTObjectsDataProcessingandIntegration.......................................................................29

8.1. IoTObjectandServiceInteroperabilitybyControlledVocabularies.................................................29

9. SemanticIntegrationofIoTObjects..........................................................................................................31

10. ConclusionandFutureWork.................................................................................................................31

11. References.............................................................................................................................................32

ListofTables

Table1:InteractionSituationsforBrusselsCapitalRegionUseCase.................................................................8Table2:InteractionSituationsforForumViriumHelsinkiUseCase.................................................................11Table3:InteractionSituationsforGreaterLyonUseCase...............................................................................12Table4:InteractionSituationsforSmartMobilityUseCase............................................................................14Table5:InteractionSituationsforSmartBuildingandEquipmentUseCase...................................................15Table6:InteractionSituationsforSmartAirQualityUseCase.........................................................................17

ListofFigures

Figure1IndicationofuserneighborhoodinSugarUI.......................................................................................21Figure2MapvisualizationusingtheUbermobileapplication.........................................................................24Figure3GraphicalservicepipleinecompositioninUnifiedViews.....................................................................27Figure4GraphicalrepresentationofasimpleSPARQLqueryinSparqlFilterFlow...........................................28Figure5GraphicalrepresentationofaSPARQLquerywhichinvolvesmultipleproperties.............................28Figure6VoCol'ssupportforthevocabularydevelopmentlifecycle.................................................................30Figure7VoCol'sinteractiveontologyvisualizationfeature..............................................................................30Figure8ArchitectureforusingsemanticdescriptionsforintegratingIoTservices..........................................31



ExecutiveSummary

ThebIoTopeprojectlaysthefoundationforcreatingopeninnovationecosystemssupportingtheInternetofThings(IoT)byprovidingaplatformthatenablescompaniestoeasilycreatenewIoTsystemsandtorapidlyharness available information using advanced Systems-of-Systems (SoS) capabilities for connected smartobjects.Theprojectwilldevelopthreelargescalepilotsinsmartcitiestoprovidesocial,technicalandbusinessproofs-of-conceptofthebIoTopeenabledSoSecosystems. ThisdeliverablebuildsonDeliverable2.1whichcoversthebIoTopepilotusecases.WhilethegoalofD2.1wastoidentifyrequirementsinordertoworktowardsacommonarchitectureandimplementationapproach,inthisdeliverablewefocusonuserinteraction(UI)withtheIoTservicesandobjectsthatwereidentifiedbythepilotusecases.Wethereforerevisiteachusecaseandextract“interactionsituations”,i.e.,waystomakeuseof theproposedsystemfromauser’sperspective.The identified interactionsituationsallowustodeducemoreabstract“interactionpatterns”andtoidentifyasetofIoTservicesandobjectsinvolvedaswellastheUIinterfaceelementsthatshouldbeutilized inthe implementationofthepilots.WefurthermoreprovideanoverviewonexistingworkinthefieldofUIwiththeidentifiedIoTobjectsunderthementionedsituations.



1. Introduction

1.1. ObjectivesinWP5

TheobjectivesofWorkPackage5areto: • identifyanddescribeIoTinteractionpatternsandIoTobjectsthatareapplicableinbIoTopepilots, • provide intuitive, user-friendly graphic tool that allows developers and non-programmers to

composeandassembleXaaScomponentsandservicesinavisualmanner, • develop customizable UI widgets including a multitude of features (e.g., equipment status

indicators,alarms,graphsofsensorvalues,statisticsontraffic...)thatcanbeusedforcomposingpersonalizeddashboardsinwebbrowsers,smartphonesandotherdevices,and

• developcontext-sensitiveend-userdashboardsthatcanself-adaptthelayout,contentsandotherpropertiesofthedashboardaccordingtotheuser’sorobject’slocation,profile,surroundingandbehavior,possibleevenlearningfromuserbehavior.

1.2. ObjectivesinTask5.AIn this deliverable, we focus on Task 5.A, the “Identification of IoT Interaction Patterns and ServiceComposition”.Thistask isdedicatedtoananalysisof the instancesofexplicit interactionwiththe IoTandSmartConnectedObjects.BasedonthebIoTopepilotusecases,thistaskidentifiesanddifferentiatesbetweendifferenttypesofIoTobjectsandrecognizestheheterogenicnatureoftheirimplementation(NFC,RFID,2D-codes,RFMemoryTags,embeddedsystems,sensornetworks...).Itfurthermoretakesintoaccountcurrentinteractionmethods forbuildings,machines,haptic interfaces,especially inmobiledevices, andadvancedformsofintuitivephysicalinterfacesasforinstancebytheUbiquitousComputingparadigm.OnthebasisoftheanalysisofinteractionsituationswiththeIoT,thistaskidentifiesanddescribesinteractionpatternsthatareapplicabletothedifferentbIoTopepilots. BecausebIoTope software componentswill support standardizedOpenAPIs,notablyO-MIandO-DF, it ispossible to represent them in a generic way as “function blocks” with inputs and outputs that can beconnectedtogetherwithoutprogramming.Thissignifiesthatnew,assembledcomponentsandservicescanbeconfiguredalsobynon-programmers,includingservicesthatconnectvariousinputsourcesandeventstosuitable actions, possibly passing by one or several “processing blocks”, thereby making it possible toimplementtheidentifiedinteractionpatterns(D5.1),withoutprogramming.Suchtoolsexistinmanyplatformsanddomains (automationsystems, JavaBeanscompositioneditors...).Basedon the recognized interactionpatternsandproposedsolutionsinexistingpublications,thistaskwillnotdevelopsucheditorsfromscratch;ratheritaimstomakeuseofexistingsolutions.WepresenttwooftheminthispaperwhichwethinkwouldmatchwellwithtechnologiesandimplementationapproachesoutlinedinWP3andWP4.Wethereforeseethis deliverable also as a resource to be consulted by the contributors to the more technology- andimplementation-focusedwork packages to get amore in-depth understanding on pilot requirements andpotential(existing)approachesforaddressingthem.

1.3. ContentofthisDocument

Thisdocumentisstructuredasfollows:afterprovidinganintroductiontotheworkpackagesgoalandtheroleofthisdeliverable,wecovertheproblemsencounteredinIoTsystemsandhowtheyarerelatedtothegoalsofWP5.InSection3wedescribetheapproachthisdeliverableusesforidentifyinginteractionpatternsforbIoTope.Section4and5coverthebIoTopepilotusecasesindetailandSection7coversrelatedworkonhowthesepatternsmayberealizedinanimplementation.Section8and9coverapproachesfordataintegrationtaking into account theworkpackage’s goal of outlining approaches for integrating andorchestrating IoTobjectsandservices.



2. ProblemDefinition

ThegoalofanIoTecosystemsuchasbIoTopeistoprovideaplatformtointegratemultipleIoTobjectssothattheirservicesareusablefollowingclearlydefined,agreed-uponprotocols.AnIoTobjectisadatasourceordataconsumer(orboth)thatprovidesservicesorinvokeservicesofotherIoTobjects.IoTobjectscancoverawidevarietyofcomplexity:theycan,forexample,beimplementedasanetwork-awaresensorthatmeasuresandprovidestemperaturedataor,towardstheotherendofcomplexity,asasmartfridgewhichisawareofthestatusoftheproductsitcontains,sothatitcanautomaticallyrestockitself,basedontheowner’sneedandthegoalofminimizingwasteoffood.

2.1. DiverseDeviceClassesandInteractionMethods

This diversity of device classes has beenmade possible in recent years by improvements in connectivitytechnologies.SmallercheaperdeviceswithlowpowerconsumptionandimprovedcommunicationstandardssuchasNFC,5Gmobilenetworking,Bluetoothv5 leadto integrationofconnectivityfeatures intomultipleclasses of deviceswith awide range of functionality: simple buttons that can be placed somewhere andcommunicateviaWi-Fi,lampswithconfigurablecolortemperature,airqualitysensors,doorbells,speakers,webcamsandmanymore. These IoT objects all provide their own user interfaces and interaction paradigms. They are eitherimplementedphysically(abuttoncanbepressed,apersoncanapproachaproximitysensor)orassoftware(colortemperatureoflightbulbsormusicstreamsforspeakersareconfiguredviasmartphoneapp).Currently,manydevicegroups,orevendevicesfromasinglevendor,requireproprietaryappswhichareproblematicintwo different ways. First, from an interaction point of view, these apps, despite working within the UIframeworkofthedevice’soperatingsystem,usetheirownwayofinteractingwiththeuser.Secondly,deviceinteractionislimitedbecauseoneappusuallycontrolsdevicesofonlyonevendor.Thisledtodevelopmentofverticalsolutionswitheachdeviceclassrequiringtheirownapp,whichtheusermustknowofandinstallinadvanceinordertomakeuseofthedevice.WethereforeidentifylackofaccessibilityandpredictabilityasproblemsincurrentIoTobjectssystemsaspeopleneedtoknowhowtoaccessadeviceorifinteractionmayhasalreadytakenplaceandwhatinformationhasorwillbeexchanged. Inthisworkpackagetask,wetacklethisproblembyidentifyingcommonalitiesbetweenuserinteractionswithIoTobjectsandsetthemintocontexttoreusablepatternsthatmaysupportthedevelopmentofunifiedUImethods.

2.2. DiverseDataFormats

SimilartotheverticalsolutionsforUI,verticalsolutionsfordataformatshavebeendevelopedthatmakeitdifficult (development of custom data conversion routines) or impossible (proprietary closed format) tointerchangedatabetweenIoTobjects.WiththestandardsOpenDataFormat(O-DF)1andtheOpenMessagingInterface(O-MI)2,XML-baseddatastructureshavebeendefinedbytheOpenGrouptodescribeIoTobjectsandtheirproperties(O-DF)inordertofacilitateexchangeofinformation(O-MI). OntheWeb,semantictechnologiesbasedontheResourceDescriptionFramework(RDF)3havegainedtractionforestablishinganinteroperabilitylayerbetweenservices:usingLinkedDatavocabulariesthatareexpressedas RDF, a common language can be established that allows for the formalization of a data model thatintegrates data fromvarious devices anddomains. In this deliverablewepresent an environment for thecreationandcurationofsuchdatamodelsthatcanbeusedinconjunctionwithexistingstandardssuchasO-DFandO-MI.

1https://www2.opengroup.org/ogsys/catalog/C14A2https://www2.opengroup.org/ogsys/catalog/C14B3https://www.w3.org/RDF/



3. ApproachOurapproachforidentifyinginteractionpatternsisbuiltonthepilotusecasedescriptionswhichhavebeenconsolidatedinDeliverable2.1ofthebIoTopeproject.D2.1reviewsthreecityusecasesandthreethematicusecasesbasedondescriptionsprovidedbytheusecaseowners.Itextractsrequirementsscenariosanduserstoriesfromthemaswellasprovidinganoverviewonthearchitecture. BasedontheworkdoneinD2.1,foreachusecasedescriptionweaskedtheusecaseownerstoidentifyalistof interactionsituations, togetherwith the IoTobjects supposed tobe involved in this situation.With theprospectofDeliverable5.4 (Identificationof aUIwidget library) inmind,wealsoasked for identifyingUIobjectsthataremostlikelytobeutilizedinperformingtheparticularinteractionsituation.WefurthermorecapturedtheinvolvedstakeholdersforeachinteractionwhichwillgiveanindicationonthelevelorexpertisewecanassumewhenusingtheIoTsystem. Foreachusecaseweprovidedtabulartemplatesintendedtobefilledinbytheusecaseowners.BasedontheirfeedbackwewereabletoidentifyabstractinteractionpatternsthatareoutlinedinSection6. Ourcontributionssummarizedinthisdeliverablethereforeencompassthe

1. identificationoftypicalIoTinteractionsituationsforeachusecase,2. identificationofreusableIoTUIcomponentsforcontrollingspecifictypesofIoTobjects,3. extractionofgeneralizedinteractionpatterns,4. reviewandidentificationofcurrentandproposedinteractionmethods,and5. proposingamethodforrepresentingandintegratingdataconsumedandpublishedbyIoTobjects

Thisdeliverablereportsonthefoundationsthatareoffutureimportanceforthetasksinthisworkpackage.In ourworkwe address challenges encounteredwith current IoT technologies from theuser perspective,takingintoaccountvariouslevelsofexpertise.Ononesideisthe“end-user”whowantstoaccessinformationthat isacertainviewondatacollectedbyapotentially largenumberofdevices thatarepartofacertainecosystem.Theusermustbepresentedalltheinformationheneeds,inalogicalandvisuallyappealingway.In a similar way, interaction should be done in an easy and straightforward way,making use of existinginteractionparadigmswithbothsoftwareandhardwaresystems. OntheoppositesideoftheIoTsystemsuserspectrumwefind“expertusers”thatareconfrontedwiththetask of collecting, analyzing and providing the data available in an IoT ecosystem. The challenge is toorchestrateapotentiallylargenumberofIoTdeviceswhichprovidediversekindsofdata(frombothcontentandformatperspective)andconnectthemsothatnewinsightscanbeinferredfromthedata.Thisreliesonthe availability of graphical tools that allow to compose services from the underlying data-providingcomponents. Inthisdeliverable,weaddresstheneedsofthetwousergroupsfromauserinterfacepointofviewandhow(connectionsbetween)dataproducedbyIoTdevicescanbeutilized.

4. CityUseCases

4.1. Brussels–CapitalRegionTable1:InteractionSituationsforBrusselsCapitalRegionUseCase

InteractionSituation InvolvedIoTObjects UIelement(hardwareorsoftware)

Actor(s)

Controltrafficlights/signsaccordingtocurrent/predictedsituation

Smartphones, legacytraffic light system,trafficinfodatabase

Map indicatingroutes,increase/decreasetime interval forcertainlights

Trafficplanner



Detectchildren’slocation Smartphones, schoolschedules,cellphoneservice data, bikesensors, city Wi-Finetwork,GPStags

- Students, Cellphone networkproviders

Supportgroupbuildingforcommutingchildren

Smartphones, schoolinfodisplay,Website

Neighborhoodwidget(children),Uber-like Mapshowing locationsof other parents(for parents), tostate (recurring)pickuprequests

Students,Parents, Schoolscheduleplanners

Parentannouncesindividualdrop-off/pick-upofchildrenat/fromschool

Smartphone, trafficinfodatabase

Button, Map(indicating bestroute), Parking slotassignment(forsafechilddisembarking)

Parents

Provideoverviewofparkingspots Smartphone, trafficinfo database,dedicated navigationdevices, parkingsensors

Map (indicatingspots + additionalinfoonclick)

Parents, Otherdrivers

Notifyoncongestioneventsorwhendetourrequired

Smartphone, trafficinfo database, cellphone (SMS),dedicated navigationdevices

Map (indicatingnew route), Speechoutput, display“lost” time whenstayingonroute

Parents,Emergencyvehicledrivers

Collecttrafficflowinvolvingchildren Trafficinfodatabase,(see also children’slocation)

Map indicatingchildren location(and number) pluscontrollable trafficlightsources(statuschangeableonclick)

Trafficplanner

Show/accept/rejectprivacydisclaimer Smartphone,Website

Checkbox/Button,List of checkboxesfor fine-grainedcontrol

Parents

Retrievemapindicatingbusytrafficareas

Smartphone,Website, traffic infodatabase, dedicatednavigationdevices

Map indicatingstreets or districtswithheavytraffic.

Parents,Students,Emergencyvehicle drivers,Otherdrivers

Notifynavigationdevicesondangersaroundschools

Smartphone,dedicated navigationdevices, schoolschedules

Speech output,notification todevices; differentfor adults andchildren. HUD/dash

Students,Parents,Emergencyvehicle drivers,Otherdrivers



screen notificationincar

Provide/Influencechildren’sroutestoschool/home

Smartphone, cellphone (SMS), schoolinfodisplay

Speech output,street signs (publicdisplay) output,augmented reality,geocaching-likechallenge

Students, Trafficplanner

Displayshoplocation/informationtochildren'sdevices

Smartphone, cellphone (SMS), shopcontractor database,trafficinfodatabase

augmented reality,geocaching-likechallenge

Shop contractor,Students

Announcebegin/endofroadblockages Smartphone, trafficinfo database,dedicated navigationdevices

Info item withcurrent location(when on site) andbuttons (start/endof blockage), sliderindicatingseverance ofblockage (e.g., notraffic at all, onlyemergency canpass,…)

Constructionworkers

Guidetoclosestfreeparkingspace Smartphone, trafficinfo database,dedicated navigationdevices (see alsoProvide overview ofparkingspots)

Map with updatedroute

Parents, Otherdrivers, Trafficplanner

Computeroutebyprovidingdestinationschoolandtypeoftransportation

Smartphone, trafficinfodatabase,schoolschedule, dedicatednavigationdevices

Map with route(parent), Speechoutputturn-by-turnnavigation forchildren

Students,Parents

Switchbetweentypesofinformation(layers)amapshows

Smartphone,Website, dedicatednavigationdevices

Listwithlayerlabels Parents,Emergencyvehicle drivers,ConstructionWorkers, Trafficplanners

Enter/Updatestudentandparentinformationforregisteringatthesystem

Website Avatar selection(for children),Forms

Parents

Registershopandspecialoffers Website Form Shopcontractor

4.1.1. IoTobjectsandservicesForthisusecasewecanthereforeidentifythefollowingservicesandobjects:

• Trafficinformationdatabase:acentralstoreoftrafficinformationwiththecapabilitytocontainbothcommerciallyprovideddataaswellasopentrafficdataanduser-provideddatafromwithin



thebIoTopecontext(e.g.,pickingupchildren,reportingfree/occupiedparkingspace,orroutesassigned to and taken by children). Additional input for this database is provided by parkingsensorsinstalledthroughoutthecity.

• Dedicatednavigationdevices:thesearenon-smartphones,thatworkwithcloseddatasourcesprovidedbyspecializedvendors(e.g.,TomTom,Garmin,…).ThepossibilitytocontributetothesedatasourcesfromthesideofbIoTopeasadatasupplierisnotclearyet.

• In-dashnavigationdevices:likeBMWnavigationsolution• Mapserviceinterface:pushestrafficinformationtothird-partyservicesmentionedabove(e.g.,

google maps, TomTom) so that all drivers and device users can retrieve use case relatedinformation.

• Shopcontractordatabase:providesalistofshopsthatparticipateintheusecasetogetherwithadditionalinformation(e.g.,locationandtheproductstheysell).

• Schoolschedules:eachschoolpublishesatimetablesothatitispossibletofindoutabouteventsthatinfluencetrafficconditions,suchasteachinghours,breaks,orholidays.

• Smartphones: are used in the context of this use case for the creation and display of routeinformation. Depending on the target group (parents or children) different apps followingdifferent strategies for obtaining and presenting the data are required (e.g., gamification,distraction-freeuse,…).

• Website:actsasameanstoenterandmaintainpreferencesoftheusecaseparticipant.Foreachstudent,parentscanenterbasicinformationsuchasfrequentroutes,contactmethodforpushnotifications and the like. It alsoprovides an interface to configurewhat information childrenshouldbeabletoreceive.

4.2. FVH–ForumViriumHelsinkiTable2:InteractionSituationsforForumViriumHelsinkiUseCase


Actor

Addnewchargingstationbyfillingincharacteristics,geolocationtobetestedandapprovedbysystemadmin/removechargingstation

Smartphone,Website,geolocationservice, statusservice

Form Charging stationowners, Systemadministrators

Findchargingstationsinthenearestarea

Smartphone, Cardashboard,website

Map with chargingstations

Drivers

Receivenotificationaboutstatusofbatteries

Dashboard,smartphone

Dashboardwarnings,smartphonemessage

Drivers

Selectthestationandreceivednavigationalternativesandstationcharacteristic


Map with chargingstations and routesand pop-up for thestationdescription

Drivers

Payfortheservice Smartphone,website External UI,Message withaccesscode

Drivers

Announcesystemreconfiguration(notifycarnavigationonnewchargingstation)


Maps with theroutesandchargingstations

Drivers

Performadmintasks,likeremovefacilityfromsystem,add/removepaymentmechanisms,audit

Smartphone,website Maps, lists, adminUI

Systemadministrators



4.2.1. IoTobjectsandservicesInadditiontotheobjectsandservicesoftheprevioususecasewecanidentify:

• Payment service: Providedbyapaymentprovider toperformmonetary transactions (e.g., forelectricalpowerconsumptionatchargingstations)

• Car dashboard: In-car UI, maybe with enhanced display capabilities (e.g., display instead ofmechanicalspeedometersortouchscreenatcenterstack)

• Carback-end:Systemthatcontrolscarsettings,e.g.,seatpositions,cabintemperature,chassistuning)

• Chargingstationdatabase:containsinformationfromchargingstationprovidersaswellasfromopendatasources(e.g.openchargemaporpublicdatafromcities).

4.3. GreaterLyonTable3:InteractionSituationsforGreaterLyonUseCase


Actor

Shownearestavailablebottlebank Bottle bank fullnesssensor, Smartphone,Website, Dataplatform

Mapwiththenearestavailablebottlebankaroundtheuser’slocation.Otherbottlebankslocationandavailabilitycanbedisplayedonuserdemand.

Citizen

Showbestbottlecollectionroutetodrivers

Trucknavigationdevice,Dataplatform

Mapandtextualroadmap

Truckdriver

Reportfullbank Smartphone,Website,Dataplatform

Bottlebanksmap:buttonandcommenttoindicateafullbottlebank.Alternativefunction:readingoftheNFCtagofthefullbottlebank.

Citizen

Reportingnon-operationalbank Smartphone,Website,Dataplatform

Bottlebanksmap:buttonandcommenttoindicateanon-operationalbottlebank.Alternativefunction:readingoftheNFCtagofthefullbottlebank.

Citizen



Checkbottlebankfunctions Bottlebanksensors,Smartphoneortablet

Listofthebottlebankswithfunctionsdefaults(i.e.:norecentinformation,abnormalormissingvalues).Linktothelocationonamap.

Wastemanagementdepartment

Showlocationsofallbottlebanks Bottlebanklocalizationsensor,Website,Smartphone,Dataplatform

Map Citizen, Wastemanagementdepartment

Showbottlebanksstatus(remainingcapacity,...)

Bottlebanksensors,Dataplatform

Mapandtextualpropertiesforeachbottlebank

Wastemanagementdepartment,Tourmanager

Showbottlebankschedule(whenwillitbeemptied)

Bottlebanksensors,Dataplatform

Mapofthebottlebanksandtextualpropertiesforeachbottlebank.


Collect/entertruckcapacitydata Truckspecificdevice

Parametersadministrationinterface


Preparerouteforspecificguidancesystem

Bottlebanksensors,Dataplatform(predictiveandcontextualdata),Trucknavigationdevice

Buttontolaunchtheroutecalculationfromthetrucklocalization

Tour manager,truckdriver

Reportanomalies(route,containers,...)

TrucknavigationdeviceorApponsmartphone

Choiceofabottlebank:bylocalizationonamap,byID,byNFCtag.Choiceofananomaly(listoricons)

TruckDriver

Scanbottlebank'sNFCtag Smartphoneorspecifictruckdevice

Displayofthebottlebankcharacteristics

Truck Driver,Wastemanagementdepartment

Plantruckroutesinadvance Bottlebanksensors,

DataplatformSelectionoftrucksdeparturelocations

Tour manager,Waste



(predictiveandcontextualdata)

onamap.Buttontolaunchtheroutespropositions

managementdepartment

Automaticallyupdateroadmap Trucknavigationdevice,Bottlebanksensors,Dataplatform(context,roadevents)

Displayofanalertincaseofeventormajorchanging

Truckdriver

Reportclimateconditions/healthtipstocitizens

Temperatureandhumiditysensors,Dataplatform,Smartphone

Displayinformationandalerts

Citizen

Trigger/Indicatetreewatering Allsensors

Displayofawateringproposition(timeslots,waterdebit,duration).Buttontovalidateandschedulewatering.

Trees andlandscapeunit

Citizenreportsclimateperception Smartphone Choiceoftemperatureandhumidityperceptionlevels:checkboxes,icons…

Citizen

4.3.1. IoTobjectsandservicesInadditiontotheobjectsandservicesoftheprevioususecaseswecanidentify:

• Dataplatform:Databaserunbythemunicipalitythatholdsinfrastructureinformation,e.g.,bottlebanklocation

• Sensors:Network-awaresensorsthatcanbeinstalledinpublicspaces/devicesandreportcertaintypesofinformationsuchascontainerfullness,temperature,humidity

5. ThematicalUseCases

5.1. SmartMobilityTable4:InteractionSituationsforSmartMobilityUseCase


Actor

Supplypersonalpreferences Car, ConnectedDrive(BMW back-endsystem)

Cars’ on-boardsystem(Navigation)

Driver



Displaypotentialmatchingchargingstations

Car, ConnectedDrive(BMW back-endsystem)

Cars’ on-boardsystem(Navigation),mobile(application,on-timenotificationandoptions)

Car

Enterdestination Car Mobile(application), Cars’on-board system(Navigation)

Driver

Retrievedestination(e.g.fromcalendar)

Car,mobiledevice Car telemetrysystem and mobileapplication

Car

Indicateroute Car, ConnectedDrive(BMW back-endsystem)


Car

Displaydangerstodriver(children,...) Car, ConnectedDrive(BMW back-endsystem)


Car

Indicateroutechanges/alternatives(basedontrafficetc.)

Car,ConnectedDrive,database for trafficinformation,


Car

Preparecar Car, Smart Home,MobileDevice

Mobile(application), Cars’on-board system(Navigation), smarthome interface(button/display)

Driver/Car(manualbydriveror autonomousbycar)


• Cartelemetryandmobileconnectivity:built-intelecommunicationdevicesusingpublicnetworksfortransferringsensordatainproprietary,encryptedformatstoensureprivacy.

5.2. SmartBuildingandEquipmentTable5:InteractionSituationsforSmartBuildingandEquipmentUseCase


Actor

Homeuserpublishesownparkingslot(withpoweroutlet)asanavailableserviceonIoTBnBservicecatalogue

Smarthomemobileapp,IoTBnBservicecatalogue

Position(eitheraddressormapcoordinates),descriptionoftheparkingslotfeaturesandthepoweroutlet,calendartimespan(s)forthe

Homeuser



availability,photouploadfeature

TouristdiscoverstheavailableparkingslotsviaIoTBnBservicecatalogue

Smartparkingmobileapp,IoTBnBservicecatalogue

Mapofdiscoveredavailableservices,(foreacha)servicedescriptionaccordingtotheattributesabove.Filtersaccordingtoarea,compatibility(sockettype,etc.).Rankingsettingsforsortingresults.

Tourist/cardriver

Confirmingaservicepurchase Smarthomemobileapp,Smartparkingmobileapp

Confirmbutton,possiblypaymentsolution(TBD)

Homeuser,cardriver

Enduserrequestsremoteassistanceforproblempinpointing

Airhandlingunit,end-userapp,remoteassistanceUI

Requestassistancemenuitem(withinend-userapp)

Enduser

Servicetechnicianreceivesarequestforproblempinpointing

Airhandlingunit,enduserapp,manufacturerapp

Notificationabouttherequest(perhapsviaemail,orpushnotification),withattached“remoteassistanceinvitationtoken”

Servicetechnician

Servicetechnicianpinpointstheproblem


Abilitytologtimeseriesofanyendpoint,andcontrolallvaluesoftheairhandlingunit

Servicetechnician

Servicetechnicianpinpointstheproblem


Abilitytologtimeseriesofanyendpoint,andcontrolallvaluesoftheairhandlingunit

Servicetechnician

Enduserchecksthecurrentairquality Airhandlingunit,Externalairqualitysensor,(possiblyenduserapp?)

Airqualityvieweronsmartphoneapp

Enduser

Enduserupgradestheairhandlingunitfirmware

Enduserapp,manufacturerwebapp,airhandlingunit

Enduserappmenuitemforupgradingfirmware(listofavailablefirmware)

Enduser




• IoTBnBservicecatalog:abIoTope-specificcatalog forpublication, lookupanddiscoveryof IoTserviceswithelectronicbillingsupport.

• Airhandlingunit:Acentralairconditionerstationthathandlestheair(e.g.,heats,cools,de/humidifies)thatissuppliedintothebuildings

5.3. SmartAirQualityTable6:InteractionSituationsforSmartAirQualityUseCase


Actor

Subscribetoplatform Smartphone,Tablet Web tool providingregistration,subscription andmanagementinterface

Citizens, PublicServices, Privateorganizations

Buildheatmap Smartphone,Tablet,IoT air pollutionsensorskit(IAPS)

App for mobiledevices.A web tool withvisualizationinterface.Compute andstorage.Interface on IoTsensor tocommunicate withCompute andstorage


Shareheatmap Smartphone,Tablet App for mobiledevices and webtool to managesharingsubscriptions,rightsetc.


Notifyonheatmapupdate Smartphone, Tablet,IAPS

App for mobiledevices fornotificationdeliveryNotification viaEmail/SMSCompute andstorage to processnotificationsinreal-timeProcessing on IAPSfor distributedpublishsubscribe




Notifyifpollutionexceedsthreshold Smartphone, Tablet,IAPS

App for mobiledevices fornotificationdeliveryNotification viaEmail/SMSCompute andstorage to processnotificationsinreal-timeProcessing on IAPSfor distributedpublishsubscribe


Displayreal-timeanalytics,visualization,routing,prediction

Smartphone,Tablet App for mobiledevices forvisualization ofalternativeroutesWeb tool withinterface forplanning andpredictionCompute andstorage for routeprediction andcomputation


Definepollutionthreshold Smartphone,Tablet A feature in theapplication (mobileand web tool) todefine

· Boundaries(Asboundedareas)

· Providepreferences


Restrictheatmapgenerationtospecificarea

Smartphone, Tablet,IAPS

A feature in theapplication (mobileandweb) to definesecurityandprivacypreferences of theend-user



• IoTairpollutionsensorskit(IAPS)



6. PilotUseCaseInteractionCommonalities

Fromtheuser-interactionpointofview,wewereabletoidentifycommoninteractionpatterns,reusableIoTobjects/services,UIelementsandactorsacrossthepilotusecases.Thesearelistedinthissection.Itwillbesubjectof futureworkandcooperationwithotherworkpackages tomapthepattern toUIelementsandservices and actors with the goal of establishing a unified framework that is able to fulfill the use casesrequirements.

6.1. InteractionPatternsBasedontheinteractionsituationsfromthevarioususecasesweinferredthefollowinginteractionpatterns:

InteractionPattern LocationentryRoutedisplayRouteanddirectionsnotificationSearchnearbyplacesforspecificservicesandtheirstatesShow(specific)nearbyservicesPresentationofroutingalternativesStatusindicationofgeographicentityDomonetarytransactionsEditpreferencesdataReceiveeventstatusupdateReceiveupdateofservicestatusavailabilityPresentservicesandtheircharacteristicsPreferenceentrymaintenanceManualservicecapabilitiesadjustmentsShowandeditscheduleReportaservicestateReportaconditionAreadisplay

6.2. IoTObjectsandServicesObjectsandServices

TrafficinformationdatabaseDedicatednavigationdevicesGeolocationserviceShopcontractordatabaseSchoolschedulesSmartphonesPreferencesWebsiteCardashboardCarbackendCartelemetryandmobileconnectivitySensors(e.g.,containerfullness,temperature,humidity)IoTBnBservicecatalogAirhandlingunit



6.3. UserInteractionElements

UserInteractionElementsRouteindicator(e.g.,map-based)RoutechangeindicatorRouteplanning(e.g.,map-basedsuggestionswithtime/costoptimization)Directionsindicator(e.g.,turn-by-turn)Locationindicator(e.g.,map-based,list-based,withpossibilityforadditionalinfo)Locationspecifier(withpossibilityforadditionalinfo)Areaspecifier(for,e.g.,parkingslots)Areaindicator(e.g.,heavy-trafficdistricts,heatmaps)withfilteringoptionTimeintervalselectorTimedifferenceindicator(e.g.,losttimebecauseoftrafficjam)NeighborhoodoverviewindicatorSpeechoutputCalendarplanningStandardformcontrols(e.g.,lists,checkboxes,textinput)forpreferencesmanagementHUD/dashboardscreen(3D)notifications/warningsStreetsignsTrafficlightsAugmentedreality(smartphone/carcameraoverlay)Avatarselector(e.g.,childreninterface)Devicestatusindicator(e.g.,operational,full)Devicestatusspecifier(e.g.,operational)Airqualityviewer

6.4. ActorsActors

TrafficplannerStudentsCellphonenetworkprovidersParentsSchoolscheduleplannersEmergencyvehicledriversTruckdriversOtherDriversShopcontractorConstructionworkersChargingstationownersSystemadministratorsCitizenWastemanagementdepartmentTourmanagerTreesandlandscapeunitTouristPublicServicesHomeuser



ServicetechnicianPrivateOrganizations

7. ReusableInteractionPatternsandRelatedWork

7.1. PracticabilityofUserInterfacesFrom the interactionpatternsof theuse casesprovidedabove,awide spectrumofpotentialusersof IoTobjectscanbeidentified.InthetargetedusergroupofaproposedIoTecosystemwhichcoverstheusecasesarepeopleofvariousage(e.g.,children,students,elderly),peoplewithdisabilities(e.g.,illiterates,physicallyor mentally impaired) and individuals with specific background and knowledge (e.g., drivers, ITadministrators).GooduserinterfacedesignmusttakeintoaccountthespecificrequirementsofthesegroupssothattheyhaveaccesstoasmanyIoTobjectsaspossible. TheBrusselsusecase,forinstance,defineschildrenasoneofthemainactors.Theyshouldhaveaccesstoserviceswhichimprovetheirsafetywhennotincompanyofanadult.Whilethereissubstantialresearchontheinterfacedesignoneducationaltools,workongenericuserinterfacesforcomputersystemstargetedatchildren is scarce. In the course of theOne Laptop Per Child initiative, human interface guidelines4weredevelopedaswellasanimplementationfollowingtheseguidelines,theSugarUI5.Withaccessibilityasoneofitskeydesignprinciples,ittakesintoaccountchildrenfromdifferentcultures,ageanddisabilities(e.g.,colorvision). It is centered around the concept of “activities”, supporting social aspects such as building ofcommunities. Focusingonilliterateandsemiliterateusers,[Medhi2006]argueforatext-freeortext-avoidingdesignwithasemi-abstractorphotorealisticdesignofgraphics.FollowinganethnographicdesignapproachinteractingwithinhabitantsofBangaloreslums,Medhietal.proposeUIdesignsfortwoapplicationssupportingjobsearchfordomesticlaborersandprovidingagenericmapthatcouldbeusedfornavigatingacity.

Figure1IndicationofuserneighborhoodinSugarUI

4http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines5http://wiki.laptop.org/go/Sugar_Instructions



7.2. ServiceInteractionThe challenge for user interfaces to address each individual’s requirement is orthogonal to meeting therequirementsofthespecificdomainsthatshouldbesupported.WithintheusecasesofthebIoTopeprojectwehaveidentifiedeightdomainswhereprovisionofadequateinteractionmethodsiskeyforawideuptakeof thedeveloped technologies. Thedomainsare covered in the sectionsbelow,whereweprovideabriefcoverageoftherelatedworkineachofthesefieldsandoutlinehowtheyarerelevanttotheusecasesdefinedwithinthebIoTopeproject.WehighlightcontributionsofhighrelevanceforthebIoTopeprojectinboldfontfacesothatthisdocumentcanalsoserveasaguideonrelatedworkforotherworkpackages.However,theseareasintersecteachotherandareondifferentlevelsofabstraction.Forinstance,acarcanbeseenasanIoTdevice and therefore would belong to both of the groups “General Interaction Methods” as well as“AutomotiveUserInterfaces”.

7.2.1. GeneralInteractionMethodswithIoTSystemsandObjectsBrolletal.[Broll2009]characterizetheIoTasconnectingdigitalresourcestotherealworldby,e.g.,real-worldgivingobjectsanidentity(e.g.,byRFIDorNFCtechnologies)sothattheycanprovideadditionalservices.Theyfocusonmobileinteractionwithsuch“taggedobjects”andtheirevolutiontomulti-taggedobjectswhichcanserveasphysicalUIs(e.g.posterwithmultipleRFIDtags).TheauthorsproposethePerciframeworkwhichsupportsphysicalmobileinteractionbyassociatingtaggedobjectswithSemanticWebservicesandcreationofUIsfromtheservicedescriptions.TheframeworkcontainsanAbstractWidgetTypeModelwhichisusedforlinkingserviceparameterswithUIelementsandconstitutesanapproachforpotentialadoptionwithinthebIoTopeproject’sUI-relatedcontributionsandfollow-updeliverables,suchasthe2Dand3Dwidgetlibrary.Brolletal.alsopresentaprototypicalimplementationthatmakesuseofPercibyprovidingtwosmartposters.They demonstrate the interaction techniques touching (NFC), pointing (e.g., barcode), and direct input(numericidentifiers).Thefunctionalityofthetagsisdividedintoactionandinformationitemswhichallowstoimplementacollect&dropinteractionpattern.Anexemplaryusecaseforthispatternis,tocollectdataitems(suchasmovieticketsrepresentedbytagsonaposter)andsendthemtoapaymentservicealtogether.Intheirevaluationtheauthorspointoutdifficultiesoftheuserswiththeinteractionmethods,causedbyalackofunderstandingoftheinteractionworkflowandignoredinstructionsprovidedattheposters. AwaytodealwiththelackofknowledgeorinteractionwithIoTobjectsisprovidedbyKranzetal.[Kranz2010]who focus on embedded interaction with IoT systems by building sensing technology into well-known,everydaytools.Theseare,e.g.,likekitchenutilitiestogatherinformationaboutwhichmealsareprepared,clothesequippedwithtouchdevices,bikehelmets,andaddedsensorstosportsdevicesandroomoccupationindicators. The authors advocate for integrating additional interaction opportunities in existing artifactsbecauseusersalreadyknowhowtousethem(e.g.,knifesorroomstatusindicators).InadditiontheynotethatadditionalcapabilitiesoftheseIoTdevicesmust,despitenotinfluencing“traditional”behavior,bevisibletotheusersothatshecanmakeuseoftheaddedvalue.Kranzetal.identifytheinteractionpatternsofimplicituse of an IoT object where a user focuses on a primary goal without paying attention to its enhancedcapabilities.ExplicituseontheotherhandmeansthatusersareawarethattheyinteractwithacomputersystemwhenusingaspecificIoTdevice.ItisnoticedthatmuchlargernumberofrelevantcontextsemergeinanIoTecosystemwhichmustbeaccessibleforanIoTdevicethaninmostcontextawareapplicationsthatfocusonjustoneperson.Besidestheserequirements,theauthorsinfertendesignguidelineswhichshouldbeconsidered in user interaction components of the bIoTope ecosystem. Among them are, e.g., to provide“informationwhenandwhereit’suseful”,using“Specializedcomponents”forspecifictasksinsteadofall-in-onedevices,prevent“Accidentaluse”anddealwiththe“invisibilitydilemma”(usersmustbeabletouseIoTobjectsastheyusedtobutalsobeawareoftheiradditionalvalue). CoveringthearchitectureofIoTsystems,Kortuemetal.[Kortuem2010]definesmartobjects(IoTobjects)asautonomous objects that carry chunks of application logic. They distinguish three types of smart objects:activity-aware objects, policy-aware objects (which can interpret events with respect to organizational



policies),andprocess-awareobjects (“understands”organizationalprocesses).Forconnect IoTobjects theauthorsdescribeapeer-to-peer(P2P)reasoningalgorithmusinglocalrulebasesforcollocatedsmartobjects.ThoughofinterestforservicecompositiontasksaddressedbybIoTope,theauthorspointoutperformanceandsecurityconcernswhicharenotaddressedbythisalgorithm.

7.2.2. PervasiveandUbiquitousComputingTheresearchfieldsofpervasiveandubiquitouscomputingfacesimilarchallengesthantheIoT.Theycoversmart devices that are invisible for the user and interconnected to one another. This imposes some corecharacteristicsofHCIinteractionslikehiddenandimplicitinteraction,task-focused,situationadaptiveness(i.e. context-awareness), multimodal interaction, natural interaction (using, e.g., gestures or speech)[Bashir2014, Landay2003]. Substantial work for interaction patterns has been performed by Löwgren[Löwgren2007] who proposes nine patterns of “embodied interaction” (i.e. “the intersection of tangibleinterfacesandsocialcomputing”,capturingtheconnectionofthematerialworldanditsdigitalrepresentation)like linkingvirtual informationtopositions inthematerialworld,ormaterialobjects’qualities influenceinteractionqualities.Theworkof[Wilde2010]providesanexcellentoverviewonworkcoveringinteractionpatternsinubiquitouscomputingareassuchasmobilesystemsorintelligentenvironments. [Chung2004] propose 45 pre-patterns for ubiquitous computing, divided into four groups (ubiquitouscomputing genres, physical-virtual spaces, developing successful privacy, anddesigning fluid interactions).TheseactuallycovermostoftheusecaserequirementsandgoalsofbIoTopeonathematiclevelsuchas“FindaFriend”,“FindaPlace”,“Notifier”or“SmartHomes”.InbIoTopewecanadoptthesepatternsandconnectthemwiththeimplementedservicesandIoTobjectstoworktowardsreusablecomponents.

7.2.3. AutomotiveUserInterfaces

Besidesthemoregenerallyapplicablepatternswedescribedandreferencedinthesectionabove,researchpapers have been published on applying them in the automotive sector. This is an important source ofinformationforthebIoTopeusecases,especiallythosecoveringsmartmobility. Forinstance,Pfleglingetal.[Pfleging2012]combinespeechandgestureinteractiontoovercomeproblemsofaccessingcomplexfunctionalityasadriver.Asinteractionmethodstheyidentifyspeech,gesturesandgazeinteraction(asalreadycoveredby[Alpern2003])assuitableto(incombination)overcomecurrentlimitationsofin-carUIsthatrelyonmenus,knobsandbuttons.Usingtheseinteractionmethods,theauthorsoutlinefourdesigngoalsthatshouldbeaddressed:minimizingtheeffortforlearningandremembering,maximizingthevisibilityofcommandoptions,providingfine-grainedopportunitiesforinteraction,andsupportforsimpleundoofactions. [Kern_DesignSpace2009] introduce a design space for driver-based automotive user interfaces, coveringcontrolsandtheirplacementondashboards.Itcanbeusedtoclassifyandcompareuserinterfacesofdifferentcarsandalternativesetups.Theydistinguishbetweeninputmodalities(suchasbuttonsorpedals)andoutputmodalities(suchasanalogspeedometersormultifunctionaldisplays)andclassifypositionarrangements(suchaswindshield,dashboardorcenterstack).ThisdesignspaceisusefulwithinthebIoTopeprojectsinmultipleways.ItcanbeusedasclassificationandlocationtaxonomyforIoTobjectsandusedtonurture,ground,andcompare new emerging ideas for interface elements. In another research publication, Kern et al.[Kern_Writing2009]investigatetheinputmethodofhandwrittentextwhiledriving.Theycoverthequestionoflocationoftheinputdevices,thevisualfeedbackandtheimpactondrivingbehavior. Anotherinteractionmethodwithin-carinformationsystemsistoutilizeaugmentedrealityvisualizationascoveredbyTönnisetal.[Tönnis2005].Thetechnologycanbeusedtoassistdriversindrivingtasksbyproviding,e.g., collision warnings and using 2D visualization methods (indicating arrows, bird-eye view) and 3Dvisualizationobjectsdirectlywithinthedriver’sfieldofview.TheseUIcomponentsshouldberevisitedasthe



bIoTopeusecasesandtheirimplementationprogressestofindoutiftheycouldbebeneficialfortoimplementtherequirements.

7.2.4. InterfacesforgeographicinformationsystemsInteractingwithgeographicinformationsystemsisakeyscenarioformostoftheusecasesinthebIoTopeproject. We therefore reviewed existing work in the field of user interfaces to these systems and whatinteractionproblemsexistandhowtheycanbeaddressed.Thegoalistocollectmethodsthatgobeyondmapdisplayandnavigationsolutionsofferedby,e.g.,GooglemapsorUber(seefigurebelow).SolutionsdevelopedwithinthebIoTopeusecasesshouldbeindependentofactualmapprovidersandofferanovelexperienceontopofthesemaps.AnexemplaryusecasewouldbetoaddatimedimensiontoamapsothatuserscantrackwhatIoTobjectspopulatedaplacewithinacertaintimeframeinthepastor,basedonpredictionmodel,willdosointhefuture.

Figure2MapvisualizationusingtheUbermobileapplication

Forinteractingwithgeographicinformationsystems,augmentedrealityhasbeenproposedinanumberofpublications. One early approachwas presented byHöllerer et al. [Höllerer1999],who describe amobileaugmentedrealitysystemforuseinoutdoorenvironmentsthatcanhelpnavigation.Theyuseaheadmounteddisplayincombinationwithhead-trackingandpen-basedinputtechniques.Waypointsandroutedirectionsaredisplayedasanoverlayoftheuser’sfieldofview.ThisapproachwasalsotakenupbytheinfamousGoogleGlass6butwasreceivedcritically(“glassholes”).DespitehavingstalledtheGlassproject,Googleiseagertoreuse the technology and research for other projects. Therefore, augmented realitywill potentially proveusefulforemploymentinanumberofbIoTopeusecases.Especiallyusecaseswheredistractionshouldbeavoided(e.g.,commutingchildren,drivers)theapproachisworthconsideringandthankstotheavailabilityofGoogle Glass, scientific publications are available which investigate the technology’s capabilities (e.g.,[Sawyer2014]) Another approach for an interface with geospatial information with focus on emergencymanagement isprovided by Rauschert et al. [Rauschert2002]. They propose a collaborative multi-user interface that issupportedbyvoiceandgesturerecognition.Sincepublicationofthiswork,speechrecognitionhasbecomeatechnologythatisfitforeverydayuse(thankstoGoogle’sspeechAPIsordigitalspeech-controlledassistantssuchasApple’sSiri).Also,collaborationfeaturesforgeospatialinformationhasseenwideacceptancewithmobileapplicationsthatallowindividualstosharetheirlocationorcollaborativelyeditstreetmapsorroutes

6https://developers.google.com/glass/



forcyclingandhiking.SuchinteractionpatternsandmethodsareworthconsideringwithinbIoTopeusecaseshandlingroadblockagesincombinationwithemergencyvehiclerouteplanning. Krügeretal. [Krüger2004]cameupwithanapproachofcombiningmultipleuser interfaces fornavigationservices,suchasdesktoprouteplannerandmobile-basedsolutions.Krüger’sapproachfocusesonconnectingtheseuserinterfacessothattravelplanninginformationispassedonbetweenvariousdevicesautomatically,integratinguser interfacesforthreedifferentcontexts (athome, incar,onfoot).Whileathomeplanningfunctionsaremoreimportant,in-carapplicationshouldfocusongivingclearandtimelydirectionsandonfootthe map type must switch to in-house navigation when entering a building. Krüger’s prototypicalimplementationoftheirapproachusesalsospeechsynthesisandrecognitionasinputmethods.

7.2.5. InteractingwithschedulesandcalendarsInteractingwith schedules for planning purposes like, e.g., starting cleaningwork after a public event orcontrollingtraffic lightsandroadsignat theendofaschoolday, isacentral taskwehaveextractedfromreviewingthebIoTopeusecases. Kozieroketal.[Kozierok1993]proposeaLearningInterfaceAgenttohelpinschedulinggroupmeetings.Theirmethodology involvesmachine learning by observing theuser’s actions and receiving direct input. Asweexpectplanning taskespecially in smart cityenvironmentswill get increasingly complex,machine learningapproachesforeventsthatanticipateactionsandhelptosuggestdecisionsseemfeasibleinasemi-automatedsetupswithhumansintheloop. WorkoncalendarinterfaceshasbeenperformedbyHundetal.[Hund2014],suggestingalternativeviewstothosegrid-basedrepresentationderivedfrompapercalendars.ForbIoTope,especiallywiththeprospectofcreatingawidgetlibraryforIoTsystems,thisworkcanserveasreferenceforanimprovedcalendarwidget.Huangetal.[Huang2016]proposeavisualizationmethodforthedisplayofpersonal(health)datawithinacalendarview.Suchamash-uppromisestobeusefulformonitoringIoTdevices,e.g.,powerconsumptionorair qualitymetrics. In combination it can, for instance, be valuable for planningworkouts in the personalcalendarandatthesametimesee(forecasts)ofairquality.Thisway,userscanperceivebothinformationdimensionatthesametimewhicheasesfurtherdecisions,e.g.,topostponetheworkouttoadaywithbetterairquality. AsimilarapproachisintroducedbyMennickenetal.[Mennicken2016],whoarguetointegratesmarthomeinformationinacalendarviewincombinationwithatouch-basedinteractionmethod.Weconsidersuchavisualization method as highly relevant for uptake as a complementary approach to other interactionmethods.

7.2.6. InteractionwithhouseholdappliancesandhomeautomationsystemsForcontrollinghouseholdappliances,Derthicketal.[Derthick2013]proposetoreplacehouseholdappliance’sUIsbyaWiFiaccesspointandmovecontrol facilities to thesmartphonethat runsaproposed frameworkbased on Web technologies. This approach follows previous suggestions for device auto-discovery anddelegationofuser interfaces tootherdevices.However, theworkoutlines theneedandadvantage foradevice-spanning, standardized solution, which is also in line with the bIoTope project’s goals. UtilizingsmartphonefordisplayinghouseholdapplianceUIsisalsoproposedbySrivastavaetal.[Srivastava2016].LikeDerthick,theauthorsalsonotebetterintegrationwithothersystemsasanadvantageofofsuchsolution.TheproposedUImakesuseofstandardAndroidUIcomponents.WebelievethatusingthesecomponentswithIoTobjectinterfacesisanaturalchoice,butatthesametimestandardized,machine-usableinterfacesmustbeprovidedtocompletelyleveragethepotentialofsmartdevicesandenablethemforusagewithinanIoTecosystem.



7.2.7. Usinge-commerceandpaymentservices

Acrucial factor for the successof an IoTecosystem is that itmustprovidemeans touse IoTdevices in aprofitableway.This involves theability todeploy secureand trusted services thatprovideaneasy touseinterfaceforperformingpayments. Egger[Egger2001]providesuggestionsandguidelinesforgoodUIpropertiesofe-commercesystemslike,e.g.,using trusted branding, minimize the click stream or provide information on the company background.Furthermore,Kimetal.[Kim2002]studiedfeaturesofcyberstoreuserinterfacesandidentifiedaspectsthatsuccessfulshopsmustbecommunicatedtotheUI(suchas,e.g.,guaranteeofon-timedelivery,hassle-freereturn).Focusingonmobilee-commerce,Leeetal. [Lee2003]proposesevendesignelements(7Cs) form-commercecustomerinterfaces:Context,Content,Community,Customization,Communication,Connection,Commercewhichtheydescribeindetail.Thesedimensionsshouldbealsotakenintoaccountwhendesigningservice interactionswith devices frombIoTope use cases, such as, e.g., charging station interfaceswith apaymentoption.

7.2.8. InterfacesofservicecataloguesFromthebIoTopeusecaseswecanextracttherequirementthatusersneedtoselectspecificservicesfromalistofavailableservices.Forinstance,ifadriverarrivesinatownandthecar’sbatteryisinacriticalstate,heshouldbeabletoselectfromalistofchargingstations,thathavedifferentfeatures(e.g.,lowprices,additionalcapabilities likeattachedcarcleaningfacilitiesorminimarket).Thisselectionprocesscanbesupportedbypre-filteringservicesbasedontheuser’spreferencesandpresentation inameaningfulway(e.g., ifuser isdriving,thedistanceandarrivaltimeattheservice,orifallservicesareclosetotheusertheyarerankedbydescendingprice). Althoughanextensiveamountofrelatedworkfordescribingwebservicesinastandardizedwayexists,andserviceselectionmethodshavebeenpublished[Balke2003,Maximilien2004],workoninteractingwithservicecataloguesfromanend-userperspectiveisscarce. Balkeetal. [Balke2003]proposeanalgorithmforselectingservices that take intoaccountahumanuser’sperspectiveandpreference.Itbuildsonakeyword-basedsearchforfindingservicesforaspecificgoalandtheavailabilityofapersonaluserprofile.InputparametersdistinguishedbyBalkeetal.arehardconstraints(i.e.,servicedescriptionpropertiesdescribingthefunctionalityofaservice)andsoftconstraints(e.g.,auser’spreferredwayoftravelling).Theauthorsargueforexploitingtheinformationinthepersonaluserprofiletosupporttheproblemofdecompositionofservices,i.e.findingservicessuitabletofulfillataskwithinacertaindecisionspace(e.g.,decidebetweentrainorairplane).AlthoughtheauthorsdonotproposesolutionsforUIinteractions,certainaspectsoftheirapproachareimportantforfindinginteractionpatternswithbIoTopeusecases.Thediscoveryofavailableservicescanbeautomatizedtoalargedegree,thankstodevelopmentslikeUPnPorBonjour.However,forselectingtheservicethatfitsbesttotheuser’srequirements,apersonalizedpreferencesdatabase for single interaction situationsmust bemaintained. For instance, if the interactionsituationwithaservice is“organizeabusinesstripfromAtoB”,thispreferencesdatabasewouldneedtoincludeinformationlike“preferredmeansoftransportationistrain”.

7.3. ServiceCompositionEditorsAswewilldescribeinthesection“SemanticIntegrationofIoTObjects”inthispaper,awayofhandlingIoTservices (which could be implemented as bIoTope software components) is to look at them as “functionblocks”withformallydefinedinputsandoutputs.TheinterfacemethodsanddataformatsfortheseinputsandoutputsareyetsubjectofdiscussionbutusingstandardsolutionssuchasO-MI,O-DFincombinationwithRDFhasbeenprovensuccessfulinnumerousdataintegrationprojectsandindustrysolutions.Inthefollowing,weintroducetwoexemplaryapproachesthatprovideaninterfaceandinteractionmethodsforperforming



servicecompositioninagraphicalway.BothsolutionsbuildonsemantictechnologieslikeRDFandSPARQLtoenableintegrationofawidevarietyofheterogenousdatasources.

7.3.1. UnifiedViewsUnifiedViews7isanExtract-Transform-Load(ETL)toolthattreatsdatasources,processorsanddatasinksasfunction blocks that can be organized in a graphicalway. Each blockmay provide input and output dataendpointsthatcanbeinterconnectedbytheUnifiedViewsuser.ThefunctionblocksarecalledDataProcessingUnits(DPUs)andencapsulatethebusinesslogicof,e.g.,conversion,enrichmentoranalysistasks.AlibraryofDPUs is available and some commonly useful DPUs are also contained in the UnifiedViews distributionpackage.UnifiedViews is available fordownloadunder anopen-source licenseonline8. Itsdevelopment isdrivenbyaconsortiumofacademicandindustrypartners:CharlesUniversityPrague9,EEA10,SemanticWebCompany11,PragueUniversityofEconomics12,Semantica13,andTenforce14.

Figure3GraphicalservicepipleinecompositioninUnifiedViews

7.3.2. SparqlFilterFlowSparqlFilterFlowprovidesavisualinterfaceforthecompositionofSPARQLqueries.Itisbasedontheintuitiveandempiricallywell-founded filter/flowmodel thathasbeenextended to address theunique specifics ofSPARQLandRDF. In contrast to relatedwork,no structured text input is requiredbut thequeries canbecreatedentirelywithgraphicalelements.TheworkisdescribedindetailbyHaagetal.[Haag2014]andademoisavailableonline15.Thefiguresbelowillustratehowafilter/flowrepresentationofaSPARQLquerycanlooklike.Theleftsideshowsaquerythatformalizesthecondition“retrieveallbookswithatleastoneauthorwhohaswonanawardandatleastoneauthorwhoselanguageisEnglish”.Anotherqueryisrepresentedbytheright-handsideofthefigure.ItretrievesdataaboutislandsprovidedbyDBpedia,filteredbyvariouscriteriasuchasareaorpopulation.

7http://unifiedviews.eu/8https://github.com/UnifiedViews9http://www.cuni.cz/10http://www.eea.sk/en 11http://www.semantic-web.at12http://www.vse.cz/13http://semantica.cz/en14http://www.tenforce.com15http://sparql.visualdataweb.org/



Figure4GraphicalrepresentationofasimpleSPARQLqueryinSparqlFilterFlow

Figure5GraphicalrepresentationofaSPARQLquerywhichinvolvesmultipleproperties



In the context of bIoTope, the filter/flow visualization and interaction approach could prove useful fororchestratingIoTobjects.Thepeer-to-peerapproachusinglocalrulebasesmentionedby[Kortuem2010]forconnectionsmartobjectsreliesonestablishingandconnectinglocalrulebases.Thereforefilter/flowcouldbeusefulforbothconstructingsuchrulebasesaswellastointerconnectdevicesthatprovidethem.

8. MethodsforIoTObjectsDataProcessingandIntegration

BecauseIoTobjectsarediverseinnatureandprovideandconsumedataindifferentdomains,formatsandrepresentations, it isrequiredtoutilizethehelpofframeworksfortamingthiscomplexity.This isasimilarproblemthanintegratingmultipledatasourcesinenterprisesetups,whereabstractionfromconcretedatarepresentationtosemanticmodelsisaprovenapproach.UtilizingsemantictechnologiesintheIoTdomainfor linking real-world objects with additional, web-based functionality, has already been proposed by[Broll2009] with themeans of semantic web services. They express service descriptions using controlledvocabularieswhichcaninturnbeusedtogenerateUIs.Forcreatingthesevocabularies,thedesignpatternsinubiquitouscomputingby[Chung2004]canconstituteanexcellentstartingpoint,aswellasthetaxonomyforin-carinterfacesinthedesignspaceprovidedby[Kern_DesignSpace2009]. Inthissection,wethereforegiveanoverviewontheVoColtoolwhichisintendedforthedevelopmentofsuchvocabulariesthatcanbeusedtodescribeIoTobjectsandservicesinastandard,interoperable,andextensiblewayusingSemanticWebtechnologies. ItcanthereforeserveasframeworkformaintainingIoTinteractionvocabulariesandtoexpressandmodelIoTinteractionpatterns.

8.1. IoTObjectandServiceInteroperabilitybyControlledVocabulariesVoCol (http://eis.iai.uni-bonn.de/Projects/VoCol.html) isanonlinecollaborativedevelopmentenvironmentforvocabularies.Itintegratesanumberoftools&servicesfordifferentaspectsofvocabularydevelopment,such as authoring, validation and publication. VoCol’s vocabulary development capabilities are centeredaround the git version control system,which iswidely used in the software development domain. VoColleveragesgit’scapabilitiesandthereforefullysupportsteamcollaborationandproductionworkflowsthrough,e.g.,branchingandmergingofvocabularies.Itsupportstheround-tripbetween

• vocabularydevelopment,• formulationofcompetencyquestions(expressedinSPARQL),and• vocabularytestingwithexampledata

andthereforeactsasacomprehensivevocabularycurationenvironment.Ontheleftsideofthepicturebelow,thesinglestepsofthevocabularylifecyclearedepicted.Itresemblesthedevelopmentlifecycleofsoftwaresystems,whereintegrateddevelopmentenvironmentsareusedtosupportthesinglesteps.Inasimilarway,VoColisanintegrateddevelopmentenvironmentforvocabularies,bringingtogetherbothlifecycleprocessesandtheiroutput,asindicatedontherighthandsideofthefigurebelow.



Figure6VoCol'ssupportforthevocabularydevelopmentlifecycle

The vocabulary modeling process has as output the final vocabulary, the population process generates(instance)dataandthetestingprocesshasthegoaltoproducequeriesthatcanberunagainstthevocabulary.VoCol is capableof supportingall theartifactscreatedby theseprocesses.Basedon theseoutputs, it canautomaticallyperformstepsthatareneededtoactuallymakeusethedevelopedvocabularies,whicharethegeneration of documentation, visualization, and machine-readable publication. The VoCol environmentthereforeactsasabridgebetweenconceptualmodels(expressedasvocabularies)andexecutablecode. VoColisavailableunderanopen-sourcelicenseonline16.BeingimplementedasaWeb-application,itcanbeeitherusedinon-premiseenvironmentsordeliveredfollowingtheSoftwareasaService(Saas)model.Thisisgraphicalrepresentationofanexemplaryvocabulary,shownwithVoCol’svisualizationfeature.Itisaread-onlyviewonthecomponents(e.g.,classes,properties,literals)definedinthevocabularyandsupportsinteractivedraggingofthenodes,zooming,andadjustmentofthelevelofshowndetails.

Figure7VoCol'sinteractiveontologyvisualizationfeature

16https://github.com/vocol/vocol



9. SemanticIntegrationofIoTObjects

SemanticVocabulariesthatexpressthefunctionalityofIoTobjectsandthedatatheyprovide.ThisallowsformodulardevelopmentofIoTserviceswhichrelyontheinputofvariousdatasources(IoTobjects)andpublishtheprocesseddatainastandardizedformat,accompaniedwithmetadata,describing,e.g.,theprovideroftheservice,licensingissuesandusedalgorithms.Basedonthisinformation,IoTservicescanbecombinedinanymeaningfulway. ThefigurebelowgivesanoverviewonhowsuchanIoTintegrationarchitecturecouldlooklike.AccesstoIoTobjects is performed by “Custom Containers” on the left side of the figure. In the example, a containerretrievesdatafromaRDBMSbutthiscouldalsobereplacedbyanyIoTobjectasdatasource,suchasanairquality sensororevenmultiple IoTdevices.TheCustomContainer formsan IoT servicewhichexposes itsfunctionalityusingthe“SemanticLayer”whichutilizesSemanticWebvocabulariesthatareeitheravailableontheWeborhavebeendevelopedusingtheVoColtool.Ontherighthandsideofthefigure,theconfigurationarchitectureisindicated,whichshouldnotbediscussedindetailhere.However,configurationisimportanttoorchestrate the data flow between the IoT services in the custom containers and therefore enables theimplementationofspecificinteractionpatternsamongIoTservices.

Figure8ArchitectureforusingsemanticdescriptionsforintegratingIoTservices

10. ConclusionandFutureWork

InthisdeliverablewerevisitedthebIoTopepilotusecasesfromauser-centeredperspective.Weidentifiedcommonuser interactionsituationsandextractedgeneral interactionpatterns fromthem. Inaddition,weidentifiedagroupofproposedIoTservicesthatsupporttheimplementationoftheusecasesandUIelementsthatshouldbeusedtointeractwiththeseservices.FortheidentifiedIoTserviceswereviewedrelatedworktofindoutaboutthecurrentstate-of-theartofinteractionmethodsandexistingsolutionsforeffectiveUI.We also provided an outlook how data from heterogeneous devices may be integrated and provideimplementationsuggestionsandrelatedworkonservice-compositionframeworksthatsupportthistask. OurnextstepswillbetospecifyincooperationwiththeworkpackagepartnershowconcreterepresentationsoftheidentifiedUIelementscanlooklikewithrespecttotheservicesthatareusingthemandthetargetaudience(i.e.theidentifiedactors)thatoperatethem.WethereforeseethisdeliverableasabasisforconductingconsecutivetasksinWP5andalsoasareferenceforotherworkpackageregardingrequirementsspecificationandimplementationoftheidentifiedbIoTopepilotusecases.



11. References

Shneiderman,B.(2004),'Designingforfun:howcanwedesignuserinterfacestobemorefun?',Interactions11(5),48-50. Druin,A.,1999.Thedesignofchildren'stechnology.SanFrancisco:MorganKaufmannPublishers. Kranz,M.;Holleis,P.&Schmidt,A. (2010), 'Embedded interaction: Interactingwiththe internetof things',InternetComputing,IEEE14(2),46--53. Broll,G.;Rukzio,E.;Paolucci,M.;Wagner,M.;Schmidt,A.&Hussmann,H.(2009), 'Perci:Pervasiveserviceinteractionwiththeinternetofthings',InternetComputing,IEEE13(6),74--81. Kortuem,G.;Kawsar,F.;Sundramoorthy,V.&Fitton,D.(2010),'SmartObjectsasBuildingBlocksfortheInternetofThings.',IEEEInternetComputing14(1),44-51. Wilde,A.G.,Bruegger,P.&Hirsbrunner,B.,2010.AnoverviewofHuman-ComputerInteractionpatternsinpervasivesystems.UserScienceandEngineeringiUSEr2010InternationalConferenceon,p.145-150. Chung,E.S.;Hong,J.I.;Lin,J.;Prabaker,M.K.;Landay,J.A.&Liu,A.L.(2004),Developmentandevaluationofemergingdesignpatternsforubiquitouscomputing.,inDavidBenyon;PaulMoody;DanGruen&IreneMcAra-McWilliam,ed.,'ConferenceonDesigningInteractiveSystems',ACM,,pp.233-242. Landay,J.A.&Borriello,G.(2003),'DesignPatternsforUbiquitousComputing.',IEEEComputer36(8),93-95. Bashir,R.N.etal.,2014.HumanComputerInteraction(HCI)inUbiquitousComputing.InternationalJournalofInnovationandAppliedStudies,9(2),p.534-540. Kern,D.&Schmidt,A.(2009),Designspacefordriver-basedautomotiveuserinterfaces,in'Proceedingsofthe1stInternationalConferenceonAutomotiveUserInterfacesandInteractiveVehicularApplications',pp.3--10. Gil-Castiñeira,F.J.;Chaves-Dieguez,D.&González-Castaño,F.J.(2009),'Integrationofnomadicdeviceswithautomotiveuserinterfaces.',IEEETrans.ConsumerElectronics55(1),34-41. Alpern,M.&Minardo,K.(2003),Developingacargestureinterfaceforuseasasecondarytask.,inGilbertCockton&PanuKorhonen,ed.,'CHIExtendedAbstracts',ACM,,pp.932-933. Tönnis,M.;Sandor,C.;Lange,C.&Bubb,H.(2005),ExperimentalEvaluationofanAugmentedRealityVisualizationforDirectingaCarDriver'sAttention.,in'ISMAR',IEEEComputerSociety,,pp.56-59. Kern,D.;Schmidt,A.;Arnsmann,J.;Appelmann,T.;Pararasasegaran,N.&Piepiera,B.(2009),Writingtoyourcar:handwrittentextinputwhiledriving,in'CHI'09ExtendedAbstractsonHumanFactorsinComputingSystems',pp.4705--4710. Pfleging,B.;Schneegass,S.&Schmidt,A.(2012),Multimodalinteractioninthecar:combiningspeechandgesturesonthesteeringwheel,in'Proceedingsofthe4thInternationalConferenceonAutomotiveUserInterfacesandInteractiveVehicularApplications',pp.155--162. Höllerer,T.;Feiner,S.;Terauchi,T.;Rashid,G.&Hallaway,D.(1999),'ExploringMARS:developingindoorandoutdooruserinterfacestoamobileaugmentedrealitysystem.',Computers&Graphics23(6),779-785.



Medhi,I.;Sagar,A.&Toyama,K.(2006),Text-FreeUserInterfacesforIlliterateandSemi-LiterateUsers.,inKentaroToyama,ed.,'ICTD',IEEE,,pp.72-82. Rauschert,I.;Agrawal,P.;Sharma,R.;Fuhrmann,S.;Brewer,I.&MacEachren,A.M.(2002),Designingahuman-centered,multimodalGISinterfacetosupportemergencymanagement.,inAgnèsVoisard&Shu-ChingChen,ed.,'ACM-GIS',ACM,,pp.119-124. Hund,P.M.;Dowell,J.&Mueller,K.(2014),'Representationoftimeindigitalcalendars:Anargumentforaunified,continuousandmulti-granularcalendarview.',Int.J.Hum.-Comput.Stud.72(1),1-11. Derthick,K.;Scott,J.;Villar,N.&Winkler,C.(2013),Exploringsmartphone-basedwebuserinterfacesforappliances.,inMichaelRohs;AlbrechtSchmidt;DanielAshbrook&EnricoRukzio,ed.,'MobileHCI',ACM,,pp.227-236. Kozierok,R.&Maes,P.(1993),Alearninginterfaceagentforschedulingmeetings.,in'IUI',pp.81-88. Huang,D.,Tory,M.andBartram,L.,AFieldStudyofOn-CalendarVisualizations. Mennicken,S.;Kim,D.&Huang,E.M.(2016),IntegratingtheSmartHomeintotheDigitalCalendar.,inJofishKaye;AllisonDruin;CliffLampe;DanMorris&JuanPabloHourcade,ed.,'CHI',ACM,,pp.5958-5969. Srivastava,A.andSingh,K.M.,2016.ASmartHomeAutomationSystemUsingAndroidPhone.InternationalJournalofScientificResearch,4(10). Egger,F.N.,2001,June.Affectivedesignofe-commerceuserinterfaces:Howtomaximiseperceivedtrustworthiness.InProc.Intl.Conf.AffectiveHumanFactorsDesign(pp.317-324). Lee,Y.E.&Benbasat,I.(2003),'Interfacedesignformobilecommerce',CommunicationsoftheACM46(12),52. Kim,E.B.&Eom,S.B.(2002),'Designingeffectivecyberstoreuserinterface.',IndustrialManagementandDataSystems102(5),241-251. Balke,W.-T.&Wagner,M.(2003),TowardsPersonalizedSelectionofWebServices.,in'WWW(AlternatePaperTracks)'. Krüger,A.;Butz,A.;Müller,C.;Stahl,C.;Wasinger,R.;Steinberg,K.-E.&Dirschl,A.(2004),Theconnecteduserinterface:realizingapersonalsituatednavigationservice,in'Proceedingsofthe9thinternationalconferenceonIntelligentuserinterfaces',ACM,NewYork,NY,USA,pp.161--168. Löwgren,J.,2007.Inspirationalpatternsforembodiedinteraction.Knowledge,Technology&Policy,20(3),pp.165-177. Haag,F.,Lohmann,S.,Bold,S.andErtl,T.,2014,May.VisualSPARQLqueryingbasedonextendedfilter/flowgraphs.InProceedingsofthe2014InternationalWorkingConferenceonAdvancedVisualInterfaces(pp.305-312).ACM. Maximilien,E.M.&Singh,M.P.(2004), 'AFrameworkandOntologyforDynamicWebServicesSelection.',IEEEInternetComputing8(5),84-93.Sawyer,B.D.;Finomore,V.S.;Calvo,A.A.&Hancock,P.A.(2014),'GoogleGlass:ADriverDistractionCauseorCure?',HumanFactors56(7),1307-1321.

bIoTope D5.1 interaction patterns report (5) -...

Documents

Transcript of bIoTope D5.1 interaction patterns report (5) -...