kfqqfë=w=k~íìê~ä=fåíéê~åíáçå=qéåüåáèìéë=áå=q~ääéíçé= fåíéêñ~åéë

kfqqfë=W=k~íìê~ä=fåíÉê~Åíáçå=qÉÅÜåáèìÉë=áå=q~ÄäÉíçé= fåíÉêÑ~ÅÉë

tçìíÉê=dêçÉåÉîÉäÇ éêçãçíçê=W mêçÑK=ÇêK=h~êáå=`lkfku

=

báåÇîÉêÜ~åÇÉäáåÖ=îççêÖÉÇê~ÖÉå=íçí=ÜÉí=ÄÉâçãÉå=î~å=ÇÉ=Öê~~Ç= j~ëíÉê=áå=ÇÉ=áåÑçêã~íáÅ~=Üìã~åJÅçãéìíÉê=áåíÉê~Åíáçå

Introductie

Bedrijven laten zeer regelmatig verschillende schetsen ontwerpen om een nieuw product samen te stellen. Veel schema’s zijn dagelijkse revisies die snel op papier getekend worden door enkele technici. Deze schetsen worden doorgenomen door andere werknemers, die op hun beurt eventueel annotaties aanbrengen om de volgende revisie te verbeteren. Het ontwerpen van de finale versie evolueert zo van primitieve schets naar een collaboratieve onderneming om het product vorm te geven. Eenvoudige schema’s worden ook vaak samen opgesteld tijdens brainstorm sessies in vergaderingen. Het schetsen op papier brengt een aantal grote nadelen met zich mee. Nieuwe prototype iteraties vereisen een nieuw blad papier, en het oude schema kan niet op een eenvoudige wijze hersteld worden. Collaboratie vereist grotendeels het schetsen om beurten, tenzij elke deelnemer over een persoonlijke kopie van het schema beschikt. Individueel aangebrachte annotaties dienen achteraf manueel samengevoegd te worden. Bij vergissingen kan inkt ook zeer moeilijk efficiënt uitgewist worden. Moderne digitale tafels kunnen een flexibel alternatief bieden voor het collaboratief ontwerpen van snelle schetsen en interfaces. Deze tabletop interfaces bieden een aantal zeer aantrekkelijke voordelen aan. Deelnemers kunnen eenvoudiger aantekeningen maken en beheren, zonder de schets zelf te be¨ınvloeden. Vorige schema revisies kunnen worden opgeslagen en hersteld. Er kan gebruik gemaakt worden van natuurlijke interactie technieken

i

om het schetsen op tabletop interfaces verder te ondersteunen. Deze thesis bestudeert een aantal apart onderzochte technieken om het collaboratief werken op een tabletop display device te vereenvoudigen. Verschillende voorgestelde concepten worden samengebracht tot een grote complete interactieve applicatie. Het gezamelijk ontwerpen van een prototype aan een digitale tafel wordt hiermee gerealiseerd. Deze applicatie behoudt de originele manier van werken op papier, zoals het efficiënt schetsen en gebruik maken van metaforen. Daarnaast biedt deze oplossing vele flexibele voordelen van een tabletop interface zoals het opslaan van sessies en het toekennen van gebruikersrechten.

Trefwoorden Tabletop Interfaces, Digitale Tafel, Collaboratief werken, User Interface, Sketching, Natuurlijke Interactie, Viewports, Territoria

Voorwoord

De volgende personen zou ik graag willen bedanken voor hun bijdrage die ze verleenden bij de realisatie van deze thesis. Prof. Dr. Karin Coninx en begeleider Peter Vandoren, voor het aanbrengen van correcties aan deze thesistekst. Begeleider Prof. Dr. Kris Luyten, voor het helpen opstellen van een structuur in verband met het thesis onderzoek, en het opstellen van de basis thesis layout. Ik zou graag mijn oprechte dankbaarheid willen uitdrukken aan Kristien Thoelen voor er altijd voor me te zijn wanneer nodig. Ook mijn ouders en familie, om het mogelijk te maken om deze richting te kunnen volgen. Mijn mede studenten, voor de schooljaren samen door te brengen en het deelnemen aan het testplan. Mijn vrienden en kennissen, om voor de nodige afleiding te zorgen. Dank aan mijn vaste project partners Rob Van Roey en Jan Meksens voor het mee werken aan de opnames van de video.

iii

Inhoudsopgave

Lijst van figuren

I

viii

Bevindingen Literatuurstudie

1 Inleiding

1 2

1.1

Collaboratieve Conflicten . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Natuurlijke Collaboratie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2.1

5

Collaboratief Sketchen . . . . . . . . . . . . . . . . . . . . . . . . .

2 Tabletop Collaboratie Onderzoek

7

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Territorium Afbakening op Tabletop Interfaces . . . . . . . . . . . . . . . .

7

2.3

Work Flows: Doorgeven en Interageren . . . . . . . . . . . . . . . . . . . .

9

2.4

Cutouts: Flexibel Workspace beheer . . . . . . . . . . . . . . . . . . . . . .

11

2.5

Interaction for Tabletop Computing Envoirnments . . . . . . . . . . . . . .

13

2.6

Group Dynamics en Tabletop Interface ontwerp . . . . . . . . . . . . . . .

15

2.6.1

Multi-user Coördinatie . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.6.2

Collaboratie en Coördinatie . . . . . . . . . . . . . . . . . . . . . .

17

Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.7

iv

3 Sketch-gebaseerd Onderzoek 3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.2

Sketch-based Interfaces: early processing . . . . . . . . . . . . . . . . . . .

20

3.2.1

Van Stroke tot Scribble . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.2.2

Opbouw herkenningsprincipe . . . . . . . . . . . . . . . . . . . . . .

21

3.3

Specifieke Sketch-gebaseerde Interfaces . . . . . . . . . . . . . . . . . . . .

22

3.4

Flow Menus in combinatie met sketching . . . . . . . . . . . . . . . . . . .

24

3.4.1

Ontwerp en Opbouw . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.4.2

Integratie met Sketching . . . . . . . . . . . . . . . . . . . . . . . .

26

Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.5

II

19

Opgestelde Software Architectuur

28

4 Gebruikte Technologie

29

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2

Tabletop Interface opstelling . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.3

Single Display Groupware Toolkit . . . . . . . . . . . . . . . . . . . . . . .

31

4.3.1

Algemene Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.3.2

Basis Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.3.3

Event Handling in eigen Formulieren . . . . . . . . . . . . . . . . .

36

CALI: Library voor Caligrafische Interfaces . . . . . . . . . . . . . . . . . .

37

4.4.1

Interne Verbindingsstructuur . . . . . . . . . . . . . . . . . . . . . .

38

4.4.2

Vormen H¨ıerarchie . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.4.3

Het Gesture Recognizing verloop . . . . . . . . . . . . . . . . . . .

43

4.4.4

Importeren en Exporteren van Gestures

45

4.4

. . . . . . . . . . . . . . .

5 Collaboratie op Tabletop Interfaces

47

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.2

Viewports als Persoonlijke Territoria . . . . . . . . . . . . . . . . . . . . .

47

5.2.1

Viewport Componenten . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2.2

Implementatie Cutout Componenten . . . . . . . . . . . . . . . . .

51

5.2.3

Opdeling in Persoonlijke Workspaces . . . . . . . . . . . . . . . . .

55

Afhandelen van Gebruikersrechten . . . . . . . . . . . . . . . . . . . . . . .

57

5.3

5.3.1

Rechten van de Deelnemers . . . . . . . . . . . . . . . . . . . . . .

57

5.3.2

Weergave van de Rechten . . . . . . . . . . . . . . . . . . . . . . .

58

5.4

Belangrijke gebruikte Metaforen . . . . . . . . . . . . . . . . . . . . . . . .

59

5.5

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6 Ondersteunende Interactie technieken

62

6.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.2

Context-gevoelig Flow Menu . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.2.1

Toegankelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.2.2

Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.2.3

Opbouw en Structuur . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.2.4

Activatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

Rechtstreekse Data Input . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.3.1

Het Virtueel Toetsenbord . . . . . . . . . . . . . . . . . . . . . . .

67

6.3.2

Het handschrift Bord . . . . . . . . . . . . . . . . . . . . . . . . . .

68

Transformaties van de persoonlijke Viewports . . . . . . . . . . . . . . . .

70

6.4.1

De “Slingshot” metafoor . . . . . . . . . . . . . . . . . . . . . . . .

70

6.4.2

De “Sleep” beweging . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.4.3

Viewports roteren . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

Interageren met Gestures . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

6.5.1

Het selecteren en verplaatsen van gestures . . . . . . . . . . . . . .

74

6.5.2

De juiste Gestures identificeren . . . . . . . . . . . . . . . . . . . .

75

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

6.3

6.4

6.5

6.6

III

Conclusie

7 Testplan Analyse 7.1

7.2

77 78

Vragenlijst Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

7.1.1

Analyse Individueel Deel . . . . . . . . . . . . . . . . . . . . . . . .

79

7.1.2

Analyse Collaboratief Deel . . . . . . . . . . . . . . . . . . . . . . .

80

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

8 Algemeen Besluit

82

9 Toekomstig Werk

85

A Gebruikte Afkortingen

87

B Testplan Vragenlijst

88

B.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

B.1.1 De test opdeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

B.1.2 Kennismaking met de Tabletop Interface . . . . . . . . . . . . . . .

89

B.2 Collaboratief schetsen: Opdrachten . . . . . . . . . . . . . . . . . . . . . .

89

B.2.1 Individueel Deel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

B.2.2 Collaboratief Deel . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

B.3 Post-Test Vragenlijsten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

B.3.1 Individueel Deel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

B.3.2 Collaboratief Deel . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

B.3.3 Algemene feedback . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

Bibliografie

94

Lijst van figuren

1.1

Een Meeting rond de tafel. . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2

De digitale interactieve tafel opstelling. . . . . . . . . . . . . . . . . . . . .

5

1.3

JavaSketchIt [16]: een UI Sketch voorbeeldprogramma. . . . . . . . . . . .

6

2.1

Terrein afbakening [1] op Tabletop Interfaces. . . . . . . . . . . . . . . . .

8

2.2

Een workflow [10] geeft componenten aan gebruikers door. . . . . . . . . .

10

2.3

Cutouts [13] maken verschillende Viewports van een geheel. . . . . . . . . .

13

2.4

De selectie taak hiërarchie opgesteld in [33]. . . . . . . . . . . . . . . . . .

14

2.5

Virtueel selecteren van objecten met “extended raycasting” [33]. . . . . . .

15

2.6

Multi-user coördinatie [12]: papier-gebaseerde interactie. . . . . . . . . . .

16

3.1

Een textbox en combobox sketchen. . . . . . . . . . . . . . . . . . . . . . .

20

3.2

Basisstappen van een Sketch herkenning algoritme. . . . . . . . . . . . . .

22

3.3

Een door de gebruiker ontworpen scrollbar [34] via gestures. . . . . . . . .

23

3.4

Een klassiek UI menu component met submenu’s. . . . . . . . . . . . . . .

25

3.5

Mogelijke Flow menu [37] Activatie gestures . . . . . . . . . . . . . . . . .

26

4.1

De MicroTouch ClearTek II [30] drukgevoelige platen werking. . . . . . . .

30

4.2

De TouchWare tabletop interface met projector rechts. . . . . . . . . . . .

31

4.3

Een eenvoudig SDGToolkit [26] sketch formulier. . . . . . . . . . . . . . . .

33

4.4

De Single Display Groupware Toolkit flow. . . . . . . . . . . . . . . . . . .

35

viii

4.5

Een typische SDGToolkit Event-gebaseerde applicatie. . . . . . . . . . . .

36

4.6

De algemene CALI klasse h¨ıerarchie. . . . . . . . . . . . . . . . . . . . . .

40

4.7

Mogelijke commando’s: Tap, Cross, WavyLine, Circle. . . . . . . . . . . . .

41

4.8

Methodes toegankelijk in Shape . . . . . . . . . . . . . . . . . . . . . . . .

41

4.9

Initialisatie van de recognizer objecten. . . . . . . . . . . . . . . . . . . . .

43

4.10 Het onMouseDown event. . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.11 Het onMouseMove event. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.12 Het onMouseUp event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.13 Het onTimeTriggered timer Event. . . . . . . . . . . . . . . . . . . . . . .

45

4.14 Het importeren van de sessie. . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.1

Het viewports systeem met het Referentie schema in het centrum. . . . . .

49

5.2

De Viewport titlebar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.3

De observer die de “observable” clients verwittigt. . . . . . . . . . . . . . .

52

5.4

De Viewport Observer flow. . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.5

De verschillende BoxComponent status mogelijkheden. . . . . . . . . . . .

54

5.6

De algemene Programma Architectuur. . . . . . . . . . . . . . . . . . . . .

56

5.7

De voorzitter geeft zijn rechten af via het Flow Menu. . . . . . . . . . . . .

59

5.8

Na het selecteren van een object verschijnen er handvaten. . . . . . . . . .

60

6.1

Het flow menu met een actief item en een icon in het midden. . . . . . . .

65

6.2

De belangrijkste uitvoerbare taken via het menu. . . . . . . . . . . . . . .

66

6.3

Het virtueel toetsenbord, 180 graden geroteerd. . . . . . . . . . . . . . . .

68

6.4

Gesture vormen om cijfers of letters te vormen, afgeleid van Palm Graffiti [21]. 69

6.5

Het vormen van een “N” opgedeeld in een 3x3 rooster. . . . . . . . . . . .

70

6.6

De Slingshot metafoor: de gebruiker sleept naar linksboven. . . . . . . . .

71

6.7

Het roteren van de Viewport via sleep bewegingen. . . . . . . . . . . . . .

73

6.8

Het roteren van een Graphics object. . . . . . . . . . . . . . . . . . . . . .

74

6.9

Het selecteren van een gesture. . . . . . . . . . . . . . . . . . . . . . . . . .

74

6.10 Meerdere vormen werden herkend door CALI. . . . . . . . . . . . . . . . .

76

8.1

Foto’s genomen tijdens de testplan opdrachten . . . . . . . . . . . . . . . .

83

9.1

Van collaboratief sketchen naar afgewerkte User Interface. . . . . . . . . .

86

Deel I Bevindingen Literatuurstudie

1

HOOFDSTUK

1

Inleiding

Digitale tafels [30] zijn een goed voorbeeld van het intelligente meubilair uit de omgeving van de nabije toekomst. Deze tafels zijn voorzien van een ingewerkt touch-sensitive display [31] en kunnen gebruikt worden voor visualisatie en interactie. Het zou zonde zijn om in dergelijke nieuwe omgevingen nog met muis en keyboard te werken. De tafels nodigen immers uit tot een meer natuurlijke interactie. Ook wanneer men met verschillende personen samen wil werken aan een onderdeel met behulp van de digitale tafel komen natuurlijke interactie technieken aan de pas. Het is voor een gebruiker veel eenvoudiger om dagelijks een select aantal metaforen te hanteren dan over te schakelen op bijvoorbeeld toetsenbord en muis.

1.1

Collaboratieve Conflicten

Veel vergaderingen worden rond een tafel gehouden (figuur 1.1). Meerdere personen willen inspraak hebben op het algemeen eventueel nieuw productschema. Deze personen debatteren en discussiëren over enkele design aspecten en maken enkele test ontwerpen voor het besproken product. Dit is de traditionele werkwijze van het tot stand brengen van een collaboratief ontwerp. Dankzij deze efficiënte manier van werken kan er intu¨ıtief en snel aan een schema gewerkt worden, wordt het algemeen overzicht goed bewaard en is het idee 2

1.1. COLLABORATIEVE CONFLICTEN

3

aanpasbaar. Er treden hierbij echter ook enkele niet triviale problemen op: • Wie mag welk schema op papier precies aanpassen, en wie mag er niets aan wijzigen? (Gebruikersrechten, manueel) • Hoe worden de sketches opgeslaan? Dit moet later nog eens extra verwerkt worden! (Verwerking, manueel) • Personen tegenover elkaar moeten constant schema’s roteren om een goed zicht op de situatie te verkrijgen • Hoe houden we rekening met eventuele bijkomende personen? • Wat gebeurt er wanneer een deel van het schema mislukt? Het hele schema moet dan hertekend worden! • ...

Figuur 1.1: Een Meeting rond de tafel.

Natuurlijke Interactie Technieken op Tabletop Interfaces

1.2. NATUURLIJKE COLLABORATIE

4

Door het invoeren van een digitale interactieve tafel in plaats van de klassieke vergadertafel kan men bijna alle negatieve aspecten van deze collaboratieve ontwerpfase wegwerken. Viewports [13] worden automatisch geroteerd afhankelijk van de positie van de deelnemer, verschillende gebruikersniveau’s kunnen op een eenvoudige manier in rekening worden gebracht, het automatisch opslaan van de werkruimte wordt doorgevoerd, enzovoort . . . Het is natuurlijk de bedoeling om de voordelen van werken met schetsen rond de tafel (snel, overzicht, aanpasbaarheid) op deze manier te behouden en zelfs actief te ondersteunen.

1.2

Natuurlijke Collaboratie

De nadruk van zulke meetings ligt op twee aspecten: eenerzijds is er het collaboratieve aspect. Verschillende personen werken actief samen aan een groter geheel. Het schema of de sketch wordt samen ontworpen, iedereen kan zijn inbreng op een zeer specifiek deel uitvoeren. Wanneer de sketch bijvoorbeeld bestaat uit verschillende A4 bladen worden delen doorgegeven, aangepast, en teruggelegd. Wanneer we de klassieke tafel vervangen door een interactieve moet deze nadruk op samenwerking zeker in acht genomen worden! Anderzijds is er het natuurlijke interactie aspect. Tijdens de vergadering worden enkel de ruwe delen van een nieuw idee uit de doeken gedaan, en concreet omgevormd in sketch of schema vorm. Deze sketch wordt volledig manueel getekend, wat als voordeel heeft dat het snel aanpasbaar is en iedereen er aan kan mee werken. Traditioneel wordt er pen en papier gebruikt om dit uit te voeren. Wanneer we de klassieke tafel vervangen door een interactieve moet deze nadruk op natuurlijke interactie ook in achting genomen worden. Het is zeker niet de bedoeling om over te schakelen op andere metaforen of interactie technieken. Dankzij de overschakeling naar een digitale tafel (figuur 1.2) ontworpen gegevens

2

1

is het onnodig om de

nog eens verder om te zetten naar een digitale versie om in late-

re ontwikkelfases te gaan verfijnen. Immers, het schema wordt rechtstreeks op de tafel ingegeven en kan daardoor direct opgeslagen, aangepast en verder bijgewerkt worden. 1 2

De foto beeldt een Legacy ClearTek Capacitive TouchWare Touchscreen van 3M af. Het gedeeltelijk ontworpen schema van de vergadering



5

Figuur 1.2: De digitale interactieve tafel opstelling.

Deze methode werkt veel flexibeler: aanpassingen moeten niet eerst manueel bijgestuurd worden en er kan bijvoorbeeld tijdens de vergadering zelf gebruik gemaakt worden van een “undo” functie. Hoofdstuk 4.2 bevat een gedetailleerde beschrijving van de gebruikte tabletop opstelling.

1.2.1

Collaboratief Sketchen

User Interface Sketching [14, 17, 15] (figuur 1.3) wordt door de loop van deze thesis gebruikt als concreet voorbeeld van een collaboratieve actie op de tabletop. Hierbij moet men extra rekening houden met verschillende gebruikersrechten tijdens het sketchen: wie mag aan welk component werken, en wie niet? Dit wordt op papier door de participanten zelf bepaald. Op de digitale tafel kan men zo bijvoorbeeld specifieke componenten toekennen aan gebruikers. Als tweede bijkomend probleem moet er efficiënt omgesprongen worden met de gegeven ruimte. Een sketch kan immers behoorlijk complex en groot worden. Hoe laat men dan gebruikers toe om op niet direct bereikbare plaatsen van de sketch te werken?



6

Als laatste aandachtspunt moet er een integraal systeem voorzien worden dat de specifieke positionering van gebruikers in rekening brengt. De globale sketch kan bijvoorbeeld 180◦ graden geroteerd zijn voor iemand, terwijl de persoon tegenover deze geen last heeft van dit probleem. Rotatie afhankelijkheid is een algemeen bijkomend probleem bij digitale tafels, zeker wanneer men met meerdere personen aan eenzelfde tafel samenwerkt. De User Interface moet verschillende gebruikerstaken verder ondersteunen, rekening houdend met gestures [14, 34] als belangrijkste interactie techniek. Elementen activeren zoals een menu oproepen mag zeker niet als hinderlijk beschouwd worden. Het zou interessant zijn om taken door middel van gestures uit te kunnen voeren. Dit minimaliseert immers de tijd die nodig is om over te schakelen tussen het schetsen zelf, en de interactie met de User Interface.

Figuur 1.3: JavaSketchIt [16]: een UI Sketch voorbeeldprogramma.


HOOFDSTUK

2

Tabletop Collaboratie Onderzoek

2.1

Inleiding

Er werd door een groot aantal academische onderzoekscentra over heel de wereld reeds uitgebreid navorsing gevoerd omtrent digitale tafels. Er werden verschillende nieuwe natuurlijke interactie technieken ontworpen speciaal voor tabletop interfaces. Ook de positie van de gebruiker rondom de tafel en het gebruik van “persoonlijke plaats” op de tafel zelf werd intensief onderzocht. De meeste studies gaan gepaard met een uitgebreide eindgebruiker evaluatie. Hieronder volgt een overzicht van de belangrijkste studies, elk met een eigen conclusie of de voorgelegde concepten al dan niet bruikbaar zijn binnen de context van deze thesis.

2.2

Territorium Afbakening op Tabletop Interfaces

De universiteit van Calgary [1, 9] heeft onderzoek gevoerd rond territoria op tabletop interfaces. Enkele vragen die men zich stelden waren bijvoorbeeld “welke plek gebruikt iemand het meeste?”, “Op welke manier wordt redundante data geplaatst zodat er toch nog plaats vrij is?”. Stel dat enkele personen samen aan een bouwplan aan het werken zijn. Traditioneel gezien deelt men de tafel op in x gelijke delen, waarbij x het aantal aanwezige 7

2.2. TERRITORIUM AFBAKENING OP TABLETOP INTERFACES

8

personen is. Elke persoon gebruikt voor persoonlijke plandelen de ruimte die direct voor hun ligt het meeste. Ruimte in het midden wordt meestal beschouwd als publiek terrein, waar het geheel geplaatst wordt. Overgebleven ruimte op de tafel wordt over het algemeen gebruikt als opslagplaats. Daar worden tijdelijk objecten neergelegd die niet actief gebruikt worden, om een overzicht te behouden.

Figuur 2.1: Terrein afbakening [1] op Tabletop Interfaces.

Men ziet duidelijk drie verschillende territoria op de tafel verschijnen met elk zijn eigen specifieke functie: • Persoonlijke ruimte: Deze ruimte bevindt zich vlak voor de gebruiker zelf en is het makkelijkst toegankelijk door deze gebruiker. Door een eigen persoonlijk territorium op te stellen kan deze persoon snel subcomponenten individueel ontwikkelen die later toegevoegd kunnen worden aan het globale deel. Wanneer een component niet voldoet aan de vereisten van de gebruiker wordt het simpelweg verwijderd. • Globale ruimte voor de hele groep: Deze ruimte wordt gebruikt door de hele groep en moet zich dus ergens bevinden zodat het toegankelijk is voor iedereen (meestal in het midden van de tafel zelf). De globale ruimte wordt gehanteerd om de individuele Natuurlijke Interactie Technieken op Tabletop Interfaces

2.3. WORK FLOWS: DOORGEVEN EN INTERAGEREN

9

puzzelstukjes samen te plakken tot een groot geheel. Daarnaast wordt de ruimte ook gebruikt om andere personen te helpen in het opzetten van hun persoonlijk plan. • Tijdelijke opslagruimte: Deze ruimte wordt gebruikt om componenten tijdelijk op te slaan, waar later in de persoonlijke ruimte verder aan gewerkt wordt of direct naar de globale ruimte verhuisd kan worden. Afhankelijk van het aantal actieve deelnemers verkleint of vergroot de opslagruimte en wordt de globale ruimte minder of meer gebruikt. De verschillende territoria worden weergegeven in figuur 2.1. Het is dus zeer belangrijk om op te merken dat er zowel persoonlijke ruimte nodig is om subcomponenten individueel te kunnen ontwikkelen, als een globale ruimte waar alle puzzelstukjes samen kunnen komen. Dankzij deze persoonlijke ruimtes kunnen meerdere gebruikers individueel op hetzelfde tijdstip aan een ander component werken dat later samen gebracht wordt. Op een klassieke tafel met pen en papier splitsen gebruikers zelf de ruimte op afhankelijk van de situatie. Dit indelen moet dus een dynamisch gedrag kunnen vertonen. Immers, halfweg het globaal sketchplan kan een nieuwe gebruiker deelnemen en ook componenten toevoegen, aanpassen en verwijderen (als deze daarvoor over voldoende rechten beschikt). Uit dit onderzoek kan men concluderen dat er zeker een makkelijk toegankelijke en persoonlijke ruimte vereist is vlak voor de positie van de gebruiker. Daarnaast is er een globaal deel nodig waar iedereen eenvoudig wijzigingen aan kan brengen. Dit brengt wel een probleem met zich mee: hoe worden componenten op een efficiënte wijze doorgegeven?

2.3

Work Flows: Doorgeven en Interageren

Het principe van Interface Currents [11, 10] of Workflows elimineert het “componenten doorgeven” probleem. Een current of workflow is een UI 1 container component dat op een dynamische manier objecten kan laten “vloeien” op het scherm.

2

Wanneer men bijvoor-

beeld een workflow aanlegt, kan deze objecten van een positie naar de andere verhuizen. 1 2

User Interface De term “flow” komt van stroming zoals in een gesloten rivier


2.3. WORK FLOWS: DOORGEVEN EN INTERAGEREN

10

Deze workflows zijn constant actief en functioneren precies als een band in een fabriek of een stroming in een sushi bar: goederen worden afgegeven en doorgevoerd. Dit concept kan verder worden uitgediept door de gebruiker de richting van de stroming te laten bepalen wanneer hij actief een object wenst te verzenden naar een bepaalde persoon. Door workflows te combineren met tabletop interfaces kan men ook de snelheid van de stroming aangeven door middel van gestures [12]. Daarnaast zijn workflows ook dynamisch van vorm: een holle rechothoek, een volle circel, . . . Dit alles hangt af van de grootte van het object dat verzonden moet worden en uiteraard van de deelnemer positie rondom de interactieve tafel.

Figuur 2.2: Een workflow [10] geeft componenten aan gebruikers door.

Figuur 2.2 bevat drie workflows: een aan de rand van de tafel die objecten tot bij elke gebruiker brengt en twee cirkels in het midden waaruit de gebruiker objecten kan selecteren. Het overbrengen van objecten van de ene naar de andere workflow is ook mogelijk. De grootste cirkel wordt in dit voorbeeld gebruikt als object storage. Het is immers niet de bedoeling om de gebruiker te overstelpen van objecten die voorbij “zwemmen”. In deze concrete studie [10] over workflows werd ook een usability test uitgevoerd. Gebruikers moeten op een zo efficiënt mogelijke manier foto’s sorteren in verschillende workflows. De algemene Foto workflow werd door de meeste gebruikers direct vooraan geplaatst (bij de persoonlijke territoria) zodat deze toegeankelijk is voor iedereen. De verschillende Natuurlijke Interactie Technieken op Tabletop Interfaces

2.4. CUTOUTS: FLEXIBEL WORKSPACE BEHEER

11

foto’s in andere flows geplaatst, zoals op figuur 2.2. Wanneer nodig kunnen deze flows aangepast worden afhankelijk van bepaalde ge¨ımplementeerde controlepunten aan de zichtbare rand van de flow.

3

Workflow interactie technieken worden uitbundig besproken in [11]. Currents kunnen door gebruikers dynamisch van grootte aangepast worden door de rand te manipuleren in verschillende richtingen. Een current is op meerdere specifieke plaatsen manipuleerbaar: 1. De kant: Deze biedt de mogelijkheid om de workflow te vergroten of te verkleinen. De current kan ook vervormd worden op deze manier! 2. De stroom: Binnenin de workflow zelf bevindt zich de objectenstroom. De stroom manipuleren resulteert in een aanpassing van de snelheid waarmee objecten doorgegeven worden. 3. De stroominhoud: Objecten zelf die zich in de stroom laten voort bewegen kunnen toegevoegd of weggehaald worden. Hoe kunnen deze workflows nu van toepassing zijn binnen dit masterproef domein? Het moet bijvoorbeeld mogelijk zijn voor een bepaalde persoon om een component te schetsen voor iemand anders, en deze dan door te kunnen geven. Workflows kunnen dit component dan veilig afleveren. Maar hier moet ook rekening gehouden worden met territoria (hoofdstuk 2.2): workflows vereisen veel extra plaats op zulke tafels, zeker in combinatie met collaboratief schetsen! Zelfs met dynamische workflows wordt de tafel dan te druk.

2.4

Cutouts: Flexibel Workspace beheer

Cutouts [13] zijn aparte “viewport”

4

containers voor elke gebruiker die op een unieke

manier geplaatst en gepositioneerd zijn. Gebruikers kunnen deze containers roteren, schaleren, en bovenal pannen 5 . De viewports zijn namelijk een kopie van een deel van de 3

Zichtbaar op figuur 2.2 in de vorm van licht opgevende punten Het woord “viewport” zal doorheen deze thesis gebruikt worden als een synoniem voor cutout. 5 Een deel van het geheel selecteren, meestal met behulp van een bounding rectangle 4


2.4. CUTOUTS: FLEXIBEL WORKSPACE BEHEER

12

globale schets (het globale territorium). Zo’n viewport kopiëert niet, maar refereert. Wanneer deze container ontstaat, laat het een referentie van het origineel object zien waarop de gebruiker kan interageren. Wanneer deze de viewport manipuleert, wordt het originele object automatisch ook aangepast. Dit concept brengt enkele grote voordelen met zich mee. • Toegankelijkheid: Gebruikers die te ver af zitten moeten enkel een referentie aanmaken en kunnen hun eigen cutout verslepen naar hun persoonlijk territorium. Vanaf daar kan men dan het globaal schema manipuleren zonder afstandsparameters in rekening te brengen. • Persoonlijkheid: Elke individuele gebruiker kan zijn eigen cutout personaliseren. Dit wordt gedaan door middel van een aantal variabelen. Cutouts kunnen in- en uitzoomen op het referentie object, cutouts kunnen zonder problemen geroteerd worden voor gebruikers die tegenover andere gebruikers zitten. Dit alles verandert het refernetie object op geen enkele manier! • Dynamiek: Cutouts maken zeer efficiënt gebruik van de grootte van de interactieve tafel. Wanneer nieuwe personen deel wensen te nemen maakt deze simpelweg een nieuwe cutout aan en plaatst ze naar wens tussen de rest in. Andere personen kunnen hun viewports verkleinen of verplaatsen indien nodig. De persoonlijkheid factor draagt nog een extra voordeel met zich mee: het wordt zo eenvoudig om aan te geven welke persoon welk deel van de globale sketch ontworpen heeft. Men kan eventueel een unieke kleur voorzien. Cutouts kunnen zo ook gekoppeld worden aan gebruikersprofielen en verschillende aanpasbare gebruikersrechten. Figuur 2.3 toont twee personen met meerdere cutouts en een referentie object onderaan. Helaas bevat dit systeem ook enkele nadelen. Wanneer mogen manipulatie acties permament worden doorgevoerd op het globaal object? Dit probleem kan verholpen worden door een extra cutout te voorzien voor een persoon die dient als test materiaal. Een andere oplossing is een eindige Undo stack voorzien. Het grooste probleem bestaat uit het opletten met het overschijven van elkaars werk. Stel dat twee personen een viewport maken aan de linkerkant van de globale schets. Beide Natuurlijke Interactie Technieken op Tabletop Interfaces

2.5. INTERACTION FOR TABLETOP COMPUTING ENVOIRNMENTS

13

Figuur 2.3: Cutouts [13] maken verschillende Viewports van een geheel.

cutouts overlappen elkaar gedeeltelijk. Wanneer beide personen tegelijkertijd proberen te schetsen wordt het werk van een van beiden onherroepelijk overschreven. Dit probleem is op te lossen door het invoeren van een rechten systeem in de vorm van een teller. Gebruikers met een hogere teller mogen delen van gebruikers met een lagere teller overschrijven, maar niet andersom. Voor de duidelijkheid worden de huidige viewports als rechthoeken getekend op het globaal object, zodat het eenvoudig waarneembaar is wie welk deel overlapt.

2.5

Interaction for Tabletop Computing Envoirnments

Mensen interageren met computers door middel van klassieke hardware input apparaten zoals een toetsenbord en een muis. Met behulp van een interactieve tabletop device wordt het mogelijk om verschillende metaforen toe te passen die object selectie en manipulatie ook mogelijk maken. [33]. Het onderzoekscentrum in Korea [33] nam ook augmented tabletop interaction onder de loep. Hierbij combineert men reële objecten met de drukgevoelige digitale tafel om zo


2.5. INTERACTION FOR TABLETOP COMPUTING ENVOIRNMENTS

14

Figuur 2.4: De selectie taak hiërarchie opgesteld in [33].

met virtuele objecten te kunnen interageren. Door bijvoorbeeld een mok op de tafel te verplaatsen, verplaatst men in de virtueel opgebouwde wereld ook een object dat de mok representeert. Door middel van verschillende sensoren en projectoren wordt dit proces vastgelegd. Dit principe valt echter buiten het bereik van deze thesis. Verschillende uit te voeren taken kunnen hiërarchisch worden opgebouwd. Het bewegen van een icon op het virtueel bureaublad wordt normaal geraliseerd door eerst het object te selecteren en het dan te manipuleren (verplaatsen). Selectie, manipulatie en het ingeven van een commando zijn drie basis taken die samen complexe subtaken kunnen vormen afhankelijk van het applicatie type. Elke taak zelf is opgesplitst in 2D of 3D space (Zie figuur 2.4). Er zijn verschillende technieken aanwezig om op een tabletop interface bijvoorbeeld 2D selectie toe te passen. Men kan gebruik maken van een virtuele ray die de hand verlengt en intersecteert met het gewenste object, dat vervolgens geselecteerd wordt (Figuur 2.5 beeldt dit af). Dit vereist echter speciaal aangepaste hardware. De meest voorkomende selectie techniek is het “tappen” van het scherm, en zo direct interageren met het gewenste object. Dit is echter niet bruikbaar wanneer het object buiten het bereik van de gebruiker ligt. Om dit probleem gedeeltelijk op te lossen, kan er binnen het territorium (Zie hoofdstuk 2.2) van elke gebruiker een referentiëel overzicht aangemaakt worden van de hele tafel. Wanneer iemand een object wenst te selecteren dat buiten zijn persoonlijk gebied ligt, kan dit door Natuurlijke Interactie Technieken op Tabletop Interfaces

2.6. GROUP DYNAMICS EN TABLETOP INTERFACE ONTWERP

15

middel van deze referentie die dynamisch in- en uitzoomt om plaats te besparen.

Figuur 2.5: Virtueel selecteren van objecten met “ extended raycasting” [33].

Het onbereikbaarheidsprobleem is ook van toepassing wanneer men een object wenst te verplaatsen 6 , na de selectie taak. Het object doorgeven aan een volgende persoon die het op de correcte locatie aflevert is een mogelijkheid. Een andere is gebruik maken van de “slingshot” [3] metafoor. Zodra men het object wilt verplaatsen verschijnt er een kopie die de bestemming aangeeft. Hoe verder men van de bronpositie af beweegt, hoe sneller het object verschoven zal worden. Op deze manier worden toch nog alle kanten van de tafel bereikt, zonder dat de gebruiker zich fysiek moet verplaatsen. Dit concept wordt uitvoerig besproken in hoofdstuk 6.4.1.

2.6

Group Dynamics en Tabletop Interface ontwerp

Verschillende dagelijkse activiteiten die plaats nemen zijn deel van een groter, samenhangender geheel. Kleine taken zoals het verplaatsen van stoelen, het versnipperen van papier of het verhuizen van een tafel vereisen meestal een goed gecoördineerde samenwerking met enkele personen. De universiteit van Stanford [12] onderzocht hoe tabletop interfaces zouden kunnen reageren op gebruikers sociale dyamics. Dit onderzoek werd nader opgesplitst in vier projecten: 6

Object positionering valt onder de taak object manipulatie Natuurlijke Interactie Technieken op Tabletop Interfaces


16

1. Multi-User Coördinatie policies 2. Het Coöperatief tekenen van gestures 3. Educatieve tabletop interfaces 4. Gedeelde interfaces voor sociale vaardigheden op te bouwen

2.6.1

¨ Multi-user Coordinatie

Deze “Multi-user coördination” technieken bestaan uit het omzeilen van conflicten die het resultaat zijn van een “scheur” in het sociale netwerk. Deze omzeiling zorgt ervoor dat de gebruiker niet onderbroken wordt en zich kan concentreren op de taak zelf. Concreet betekent dit het succesvol vertalen van dagdagelijkse metaforen naar de digitale tafel. Wanneer twee gebruikers bijvoorbeeld uiteinden van een object vasthouden en men van elkaar weg beweegt, ontstaan er twee aparte objecten die ieder de helft van het origineel zijn. Deze metafoor is afkomstig van het scheuren van papier. Er kan zo ook een duplicaat aangemaakt worden door het object voor beide personen in het midden te manipuleren. Deze twee voorbeelden maken het mogelijk om snel een doel te bereiken zonder een andere gebruiker te storen door hem bijvoorbeeld te vragen een object expliciet te kopiëren. Figuur 2.6 beeldt dit verder uit.

(a) Papier manipuleren op twee plaatsen

(b) Gevolg: Het papier scheurt af

Figuur 2.6: Multi-user co¨ ordinatie [12]: papier-gebaseerde interactie.



2.6.2

17

¨ Collaboratie en Coordinatie

Gedeelde coördinatie regels kunnen heel efficiënt gecombineerd worden met het indelen van gebruikersterritoria (hoofdstuk 2.2). Gebruikers kunnen privé documenten zichtbaar maken voor anderen door dit object van hun persoonlijk territorium te verplaatsen naar de publieke ruimte van de tabletop in het midden. Een object kan zo bijvoorbeeld enkel gescheurd worden wanneer het toegankelijk is voor iedereen. Gestures kunnen ook collaboratief worden uitgevoerd. Het aantal ondernemende gebruikers hangt af van het aantal parameters van de taak. Een lijn tekenen kan bijvoorbeeld door twee personen gerealiseerd worden: persoon 1 tekent de gesture vorm en persoon 2 duidt met twee vingers de dikte van de te tekenen lijn aan. Eventueel kan een derde persoon de vorm enigszins be¨ınvloeden door horizontaal open af te bewegen. Natuurlijk zijn zulke coöperatieve acties moeilijk toepasbaar wanneer men van verschillende gebruikers op eenzelfde tijdstip input verwacht maar deze niet elkaar mogen be¨ınvloeden. Het werken met een viewport (hoofdstuk 2.4) is zo’n voorbeeld. Het gebruik van deze collaboratieve aspecten op tabletop interfaces wordt meestal aangemoedigd om de groepssfeer van gebruikers rond de tafel zelf te versterken. Sommige gestures, zoals het afsluiten van het programma, zorgen ervoor dat alle personen als een groep zich beter bewust zijn van de verschillende systeem commando’s en de gevolgen daarvan. Coöperatieve gestures kunnen ook toegepast worden om minder toegankelijke plaatsen binnen bereik van alle gebruikers te leggen. Tijdens een evaluatie van het programma CollabDraw [12] werden de volgende belangrijke punten aan het licht gebracht: • De noodzaak om technieken te ontwikkelen die voorkomen per ongeluk collaboratieve gesture commando’s op te roepen • De impact van timing bij gesture design • Het potentiëel gevaar om coöperatieve gestures te gebruiken om veel voorkomende systeem commando’s op te roepen Het is dus belangrijk om op te merken dat men verwarring omtrent gesture symbolen en het uitvoeren van hun respectievelijk commando dient te vermijden. Een alternatieve Natuurlijke Interactie Technieken op Tabletop Interfaces

2.7. SAMENVATTING

18

mogelijkheid geven om taken uit te voeren is daarom zeker noodzakelijk. Verwarring kan ook op verschillende niveau’s optreden: omtrent de vorm van de gesture die interfereert met een andere gesture, de lengte of de manier waarop men de gesture afrondt, . . .

2.7

Samenvatting

Veel academische onderzoeken omtrent tabletop interfaces leggen de nadruk op collaboratie. De digitale tafel kan ofwel impliciet opgedeeld worden in persoonlijke ruimten zoals de flexibele cutouts in hoofdstuk 2.4. Langs de andere kant kan men de tafel ook opsplitsen in expliciet vastgelegde delen (Voor meer info, zie hoofdstuk 2.2) waarbij er een publiek toegankelijk territorium in het centrum aanwezig is, met aan de kanten persoonlijke ruimte en opslag plaats. Hoe men de digitale tafel ook opdeelt, er is nood aan een scheiding van verschillende delen. Een gelijkaardige oplossing bestaat uit het gebruik maken van stromingen zoals uitgelegd in hoofdstuk 2.3. Door met elkaar te ruilen en objecten te verschuiven van territoria kunnen deze aangepast, doorgegeven, gekopiëerd, . . . worden door andere gebruikers. Het voorbeeld van figuur 2.6 in hoofdstuk 2.5 maakt dit duidelijker. Algemene interactie technieken met de tabletop interface dienen afhankelijk van de tabletop hardware nauwgezet onderzocht te worden. Een ray-casting arm-verlengend algoritme zoals weergegeven op figuur 2.5 kan onmogelijk op een drukgevoelige tafel met projector gebruikt worden zonder de aanwezigheid van enige extra hardware. Hoe groter de tabletop, hoe belangrijker het “bereik” probleem wordt: gebruikers moeten in principe toegang hebben tot alle objecten op de tafel waarvoor zij rechten hebben. Wanneer men een object naar een uithoek van de tafel wenst te verplaatsen die niet direct bereikbaar is dient een plaatsvervangende techniek ontwikkeld te worden. Collaborativiteit speelt hier ook vaak een relevante rol. Een probleem dat niet voorkomt op SMART Boards [32] maar wel op digitale tafels, is het “rotatie” probleem. Voor gebruikers die tegenover andere gebruikers plaats nemen, moeten hun persoonlijke objecten relatief ten opzichte van hun positie geroteerd worden. Individuele pop-up menu’s evenzeer.


HOOFDSTUK

3

Sketch-gebaseerd Onderzoek

3.1

Inleiding

Er zweven enorm veel varianten rond van sketch herkenning algoritmes en principes. Veel onderzoek omtrent UI sketching werd reeds gevoerd, maar slechts weinigen spitsen zich toe op het integraal gebruik maken van extra hardware. Tabletop interfaces, GroupWare [32] systemen en digitale tekenbladen zijn veel geschikter om eenvoudig schetsen op te ontwerpen dan via klassieke input methoden zoals toetsenbord en muis. Deze apparaten beschikken meestal over een aantal unieke eigenschappen, waardoor het gebruik van klassieke UI componenten om gebruikerstaken te ondersteunen minder goed gecombineerd kan worden met het schetsen zelf. Een aantal onderzoeken behandelen de opbouw van gesture recognizers met betrekking tot UI sketching. Andere onderzoeken helpen het collaboratief schetsen op deze devices te vergemakkelijken, en bestuderen hoe de verschillende gebruikerstaken verder ondersteund kunnen worden.

19

3.2. SKETCH-BASED INTERFACES: EARLY PROCESSING

3.2

20

Sketch-based Interfaces: early processing

Zoals reeds aangehaald in hoofdstuk 2.1 is hetgebruik van natuurlijke en intu¨ıtieve interactiemetaforen van vitaal belang op Tabletop Interfaces. Sketch-gebaseerde interactie [34, 14] speelt hierin ook een zeer relevante rol. Gebruikers kunnen dankzij sketching eenvoudig aangemaakte objecten selecteren, verplaatsen, verwijderen, enzovoort. . . Door bijvoorbeeld een kruis te vormen boven op eender welk ouder element geeft de gebruiker aan dit element te wensen verwijderen. Dit werkt op exact dezelfde manier als schetsen op een papier. Objecten selecteren kan gerealiseerd worden door deze te omcirkelen. Sketching elementen kunnen tevens ook naadloos ge¨ıntegreerd worden met andere natuurlijke interactie technieken. Concreet naar User Interface sketching toe werd er reeds intensief onderzoek gevoerd.

3.2.1

Van Stroke tot Scribble

Een van de belangrijkste problemen van het UI Sketching domein is het succesvol converteren van een sequentie natuurlijke “strokes” naar het doelobject. Een stroke is een collectie van niet onderbroken punten, gevormd door muis events. Hierbij spelen verschillende parameters een rol: de snelheid waarmee strokes gecreëerd worden en het aantal opeenvolgende strokes (Een “Scribble”) dat slechts een enkel object dient te vormen. Een TextBox kan bijvoorbeeld gevormd worden door een rechthoek te tekenen en daarna een streep in die rechthoek te trekken, die dienst doet als tekst metafoor. Deze sequentie uitbreiden met een omgekeerde driehoek rechts of links van deze streep impliceert dan weer de ComboBox control, zoals aangegeven in figuur 3.1.

Figuur 3.1: Een textbox en combobox sketchen.

Door dit herkenningsprincipe omzeilt men het gebruik van klassieke menu’s en User Interface componenten om acties uit te voeren. Door op dezelfde natuurlijke manier te interageren als op een vroege mock-up vermijdt men ook het omzetten van deze mock-up op papier naar een vroeg User Interface ontwerp op de computer via standaard UI toolkit Natuurlijke Interactie Technieken op Tabletop Interfaces

3.2. SKETCH-BASED INTERFACES: EARLY PROCESSING

21

designers als Microsoft’s Visual Basic Designer [22]. Het is niet de bedoeling om gebruikers te limiteren tot een beperkt aantal patronen. Dit herkennings algoritme moet bijvoorbeeld zowel in staat zijn om een cirkel te herkennen door met de klok mee te tekenen, of tegen de klok in. Het moet ook mogelijk zijn om een vorm te tekenen zonder de “pen” 1 op te lichten. Op deze manier produceert men een Sketching Interface die veel natuurlijker aanvoelt dan de alternatieve restrictieve toolkits [17]. De nadruk ligt immers op de vorm van het eindobject, niet op de manier waar het op getekend werd. Een bijkomend probleem is noise rating. Omdat vroege sketch ontwerpen vaak in een ruwe en onafgewerkte staat zijn is het zeer moeilijk om de precieze vorm van het gesketchte object te bepalen. Objecten kunnen tevens van vorm zowel delen van curves als rechte lijnen bevatten!

3.2.2

Opbouw herkenningsprincipe

[14] stelt een geavanceerd sketch herkenningssysteem voor dat uit drie concrete delen bestaat: • approximation: De eerste stap analyseert de gevormde strokes die samen een Scribble vormen. Deze analyse bestaat uit het ontdekken van de basiselementen van de strokes: welke stukken stellen rechte lijnen voor? Welke stukken zijn curves? Dankzij approximatie verkrijgt men zowel een compacter als abstracter beeld van de gevormde scribble. • beautification: Na deze approximatie verandert het algoritme de output van de scribble om de gevormde lijnen ook daadwerkelijk tussen slechts twee punten te laten lopen, en de curves uit te vloeien. Deze stap verandert geen vorm, maar maakt ze slechts representabeler. • basic recognition: Deze compacter gevormde output dient als input voor de laatste stap, het herkennen van de vorm op zich. Deze herkenning zorgt er bijvoorbeeld voor dat het systeem vier apart verbonden lijnen herkent als een rechthoek. Figuur 3.2 beeldt deze stappen uit. 1

In dit geval de mouseUp event handler Natuurlijke Interactie Technieken op Tabletop Interfaces

3.3. SPECIFIEKE SKETCH-GEBASEERDE INTERFACES

22

Figuur 3.2: Basisstappen van een Sketch herkenning algoritme.

Approximatie werkt met extrema’s van “curvature” en snelheidsgrafieken. Dankzij het uitbuiten van de interactieve manier van het sketching principe wordt de kans op succesvolle herkenning op het einde van het algoritme aanzienlijk vergroot. Men houdt hier zowel rekening met de stroke richtingen als de snelheid waarmee ze getrokken worden. Het Average Base Filtering principe met een bepaalde threshold wordt toegepast om redundante noise data zoveel mogelijk te reduceren. Het herkennen van de objecten zelf wordt door middel van templates gerealiseerd. Dit maakt het toevoegen van nieuwe objecten veel eenvoudiger. Uit een concrete gebruikerstest bleek dat deze methode van werken veel eenvoudiger en efficiënter werkt voor het merendeel van de eindgebruikers (zowel personen die bekend zijn met informatica aspecten als complete leken). Dankzij de verschillende stappen wordt het sketchen van objecten intu¨ıtiever: het herkennings algoritme is minder strikt dan andere bekende algoritmes. De doorslaggevende factor voor deze gebruikers was het kunnen sketchen van verschillende objecten zonder te moeten switchen naar klassieke WIMP 2 [18] tools.

3.3

Specifieke Sketch-gebaseerde Interfaces

Het ontwerpen door middel van sketch-gebaseerde technieken brengt enkele nadelen met zich mee. Zo is de gebruiker constant aan het interageren met het systeem door middel van gestures in plaats van klassieke User Interface componenten zoals een Checkbox of een Button. Wanneer men iets uit een menu wenst te selecteren of er een dialoog venster 2

Window Icon Mouse Pointer


3.3. SPECIFIEKE SKETCH-GEBASEERDE INTERFACES

23

verschijnt moet men telkens overschakelen naar interactie met klassieke componenten. Deze overschakeling vertraagt de gebruiker aanzienlijk. De Carnegie Mellon Universiteit uit Pittsburgh [34] ontworp hierdoor een specifieke sketch-gebaseerde interface waarbij de personen die simpele mechanische systemen sketchen ook door middel van diezelfde sketches commando’s kunnen uitvoeren en andere taken kunnen vervullen. De nadruk ligt hier op de gebruikers interactie. Wanneer deze merkt dat er een plaatsgebrek optreedt, volstaat het door zelf een scrollbar na te tekenen! Deze scrollbar kan nadat de gesture recognizer alle gestures verwerkt heeft worden gebruikt, en gedraagt zich net zoals een klassieke UI scrollbar. Figuur 3.3 toont zo’n zelf getekende scrollbar.

Figuur 3.3: Een door de gebruiker ontworpen scrollbar [34] via gestures.

Figuur 3.3 toont in principe drie belangrijke componenten. Linksboven worden er knoppen geplaatst die eenvoudig bereikbaar zijn en veelvuldig gebruikt worden. Op deze manier is het niet meer nodig om door verschillende menu’s te lopen. Het grootste deel van het scherm wordt voorzien om de eigenlijke sketch te tekenen, en aan de rechterkant heeft men zopas een scrollbar getekend. Ook de dialoog menu’s worden volledig herzien: het is nu mogelijk om door middel van sketch-gebaseerde dialoog boxen te interageren met het systeem. Een Textbox wordt vervangen door een plaats waar de gebruiker een getal of een woord kan tekenen dat daarna


3.4. FLOW MENUS IN COMBINATIE MET SKETCHING

24

herkent wordt via de gesture recognizer. Een streep trekken over een label betekent een aanpassing van die weergegeven waarde, enzovoort . . . Het eigenlijke schema dat men dient te modelleren kan op twee verschillende manieren getoond worden. De standaard manier toont hoe de gestures getekend werden, maar verandert er niets verder aan. Intern worden de gestures natuurlijk wel correct opgeslaan, volgens herkende coördinaten. Een tweede manier is het bekijken van een “mooie” versie van het schema: de gestures worden afgebeeld na de beautification stap (zie hoofdstuk 3.2). Achter de schermen herkent de gesture recognizer de verschillende getekende patronen in enkele stappen. Het recognizer principe uitgelegd in [34] is ruwweg dezelfde als in [14] beschreven in hoofdstuk 3.2. 1. recognition: De eerste stap is het herkennen van individuele objecten die geplaatst zijn op het tekenoppervlak. Deze nog niet nader herkende objecten worden ook wel “symbolen” genoemd, dus stap 1 wordt herleid tot symbol recognition. 2. ink parsing: Het groeperen of clusteren van verschillende lijnen (strokes) die samen een groter object vormen zonder dat de gebruiker aanwijzingen moet geven. Dit is echter een zeer complex probleem en veel huidige systemen eisen dat de gebruiker toch expliciet aangeeft wanneer een volgende groep aangemaakt wordt door middel van pauzes tussen strokes of het inhouden van enkele knoppen. Complexe gesture recognizers kunnen verder geoptimaliseerd worden met behulp van training. Er zijn veel statistische leer technieken onderzocht om recognizers na enig verloop van tijd beter te laten presteren. Meestal wordt er door middel van een gewicht coëfficient en output van de vorige strokes gewerkt. Enkele voorbeelden van zulke technieken die hier niet verder behandeld zullen worden zijn het gebruik van neurale netwerken [35] en verschillende Data Mining classificatie algoritmes [36].

3.4

Flow Menus in combinatie met sketching

Zoals reeds aangehaald in hoofdstuk 3.3, werkt de combinatie van gesture interactiviteit met klassieke User Interface componenten alleen maar vertragend. Ook het gebruik van klassieke drop-down menu’s zoals in figuur 3.4 wordt afgewezen, om enkele logische redenen: Natuurlijke Interactie Technieken op Tabletop Interfaces


25

• Plaatsing: Menu’s bevinden zich bijna altijd bovenaan. Een tabletop interface dient menu’s voor alle gebruikers toegankelijk te maken, en pop-up menu’s voldoen niet. • Diepte: Sommige commando’s bevinden zich in niveau 3 of hoger. Het doorlopen van alle menu’s is ook een precies werkje, in tegenstelling tot grote gestures tekenen. • Menu item dimensies: Het selecteren van een standaard menu kan problemen veroorzaken vanwege de kleine grootte.

Figuur 3.4: Een klassiek UI menu component met submenu’s.

3.4.1

Ontwerp en Opbouw

In [37] werd een marking menu ontwikkeld dat toegankelijkheid en snelheid biedt op grote display oppervlakken zoals een tabletop of een SMART Board [32] 3 . Deze flow menu’s worden direct opgeroepen nadat een bepaalde gesture verwerkt wordt, zoals het tappen op de digitale tafel of het tekenen van een cirkel. Elke gebruiker beschikt over zijn eigen flow menu! Dit brengt veel voordelen met zich mee: • Rotatie afhankelijkheid: Zoals aangehaald in hoofdstuk 1.2 dienen alle individuele componenten rotatie afhankelijk gemaakt te worden, eveneens het flow menu. • Snelheid en efficiëntie: Meer dan een gebruiker kan tegerlijkertijd acties uitvoeren omdat er meer dan een menu aanwezig is. • Gebruikers rechten: Sommige menu’s kunnen een uitgebreider aantal taken bevatten, terwijl andere menu’s eeder beperkt zijn. 3

SMART Technologies; http://www.smartboard.nl



26

• Integratie met gestures: De gesture hoeft niet onderbroken te worden tussen de menu en de eigenlijke taak in.

(a) Een menu item selecteren

(b) De gesture om een submenu te selecteren

Figuur 3.5: Mogelijke Flow menu [37] Activatie gestures

Een flow menu wordt gepresenteerd als een radiaal menu dat onderverdeeld wordt in 8 octanten, gecentreerd rondom het middelpunt. Een menu item wordt geactiveerd door met behulp van gestures in het desbetreffende octant te bewegen. Daarna wordt de geselecteerde actie uitgevoerd of een submenu geactiveerd. In figuur 3.5 selecteert men het menu “item” (a), waarna het submenu verschijnt om een actie uit te voeren omtrent dit item (Highlight, move, zoom). (b) De “item” label blijft staan zodat het duidelijk is welk huidig submenu actief is. Terugkeren naar een vorig menu kan door naar het midden van het flow menu te bewegen.

3.4.2

Integratie met Sketching

Om het gesture concept nog verder te integreren met de flow menu’s kan ook een simpel Inputbox formulier vervangen worden door een flow menu. Overal rond de huidige menu worden symbolen geplaatst waar de gebruiker naar kan bewegen. Zodra de huidige muiscoördinaat een zekere threshold heeft bereikt, wordt dat symbool toegevoegd aan de totale input waarde. Een speciaal symbool staat voor “Backspace” en eventueel voor “Enter”. Een Enter commando kan ook worden ge¨ınterpreteerd als een timeout.


3.5. SAMENVATTING

27

Wanneer men een object verplaatst, kiest men in het flow menu voor root menu item “item...” en daarna “move”. Het object moet natuurlijk eerst geselecteerd worden om dit context-gevoelig menu op te kunnen roepen! Dankzij gesture integratie is het niet nodig om een pen of vinger op te heffen, terug naar het object te navigeren en daarna pas de verplaatsing toe te passen. Dit kan direct nadat de menu sluit gebeuren zonder enige onderbreking!

3.5

Samenvatting

Veel gesture recognizers bouwen op hetzelfde “scribble” principe. Het basis algoritme wordt zeer simpel gehouden om de performance niet negatief te be¨ınvloeden. Het bekomen resultaat is een hiërarchie van basisvormen. User Interface sketching werkt met hetzelfde basissysteem. Specifieke sketch-gebaseerde interfaces combineren de voordelen van het snel schetsen met het eigen ontworpen interactieve elementen, zonder de gebruiker te vertragen. Vooral wanneer men gebruikt wenst te maken van gestures op tabletop interfaces, dienen gestures en klassieke User Interface componenten zo weinig mogelijk met elkaar vermengd te worden. Gebruikers presteren minder goed door de interactie omschakeling en het werkt verwarrend. Er zijn veel alternatieven aanwezig, en klassieke drop-down menu’s kunnen bijvoorbeeld vervangen worden door flow menu’s zoals besproken in hoofdstuk 3.4.


Deel II Opgestelde Software Architectuur

28

HOOFDSTUK

4

Gebruikte Technologie

4.1

Inleiding

Om de probleemstelling van de introductie op een consistente manier op te lossen werd er gebruik gemaakt van een aantal bestaande technologieën. Hieronder volgt een korte beschrijving van elk gebruikt toolkit en framework. De applicatie werd volledig in C# [24] ontwikkeld in het .NET 2.0 [25] framework. Hiervoor werd als ontwikkelomgeving Microsoft Visual Studio 2005 [29] (VS) gebruikt. De interne verbindingsstructuur met de gesture recognizer library werd via MC++ 1 wrappers gerealiseerd. Deze library is geschreven in C++.

4.2

Tabletop Interface opstelling

De betreffende tabletop interface is een Legacy ClearTek Capacitive (CTC II) TouchWare (TW ) Touchscreen van 3M [30]. Dit touchscreen bestaat uit vier aparte aangestuurde panelen die elk door middel van de TW firmware driver in het systeem voorgesteld worden 1

Managed C++

29

4.2. TABLETOP INTERFACE OPSTELLING als een standaard USB

2

30

muis. Elk drukgevoelig paneel kan onafhankelijk van elkaar

aangeraakt worden. Dus zoals reeds aangehaald, kunnen maximaal vier personen tegelijk, elk op hun eigen paneel, interageren met de applicatie.

Figuur 4.1: De MicroTouch ClearTek II [30] drukgevoelige platen werking.

De TW drivers converteren de absolute coördinaten van elk paneel naar relatieve systeem coördinaten zodat het besturingssysteem (in dit geval Windows XP Service Pack 2 [23]) elk touchscreen paneel interpreteert als één muis. Deze geconverteerde coördinaten kunnen zo verder behandeld worden. Maar Windows kan slechts met een enkele muis tegelijk werken. Er is dus een systeem nodig dat alle gegenereerde muis events via de onderliggende laag opvangt en verschillende muis cursors aanmaakt en ze apart coördineert. Dit heeft te maken met de beperktheid van de gebruikte technologie. Er ligt een minimaal stroomveld op de tafel en het plaatsen van een geleid object of vinger onderbreekt deze keten, zoals in figuur 4.1. Zo kan de plaat de exacte coördinaat berekenen. Verschillende objecten per keer plaatsen doet zo niets anders dan de enkele coördinaat van positie be¨ınvloeden. 2

Universal Serial Bus


4.3. SINGLE DISPLAY GROUPWARE TOOLKIT

31

Figuur 4.2: De TouchWare tabletop interface met projector rechts.

De digitale tafel opstelling die doorheen deze thesis tekst gebruikt werd is zichtbaar op figuur 4.2. Deze is aangesloten op een computer die de software projecteerd op de 4 drukgevoelige platen, gelabeld van 1.A tot 1.D. Zoals zichtbaar in de figuur zijn de platen verdeeld in 4 gelijke delen, die elk afzonderlijk één enkel drukpunt tegelijkertijd kunnen registreren. Alle platen zijn via een snelle USB 2.0 Hub verbonden aan de computer (label 2), en geregistreerd als aparte muis cursors. De computer kan bestuurd worden door de drukgevoelige platen of door middel van klassieke input apparaten zoals toetsenbord en muis (label 4). Een projector (label 3) die verbonden is met deze computer, beeldt alle gegevens rechtstreeks af op een spiegel (niet zichtbaar op de foto) die zich direct onder de platen bevindt. Die spiegel projecteert op zijn beurt het beeld naar boven op de platen zelf.

4.3

Single Display Groupware Toolkit

Het Single Display Groupware Toolkit (SDGT) [26, 27] is een library geschreven in C# die het mogelijk maakt om zeer snel applicatie prototypes te ontwikkelen voor groupware



32

systemen zoals de drukgevoelige tabletop interface. SDGToolkit maakt het mogelijk om input events van het hele scherm op een efficiënte wijze op te vangen en verder te verwerken, zoals alle standaard MouseEventArgs events werken in C# zelf. Citaat van de SDGT website op http://grouplab.cpsc.ucalgary.ca/software/SDGT/: The SDG Toolkit is a framework for designing single display groupware applications. SDGT is a COM

3

object designed for managing multiple mice and

keyboards. The toolkit handles and delegates multiple input devices, and orientation parameters. SDGT is implemented as a .NET package.

4.3.1

Algemene Werkwijze

SDGT handelt automatisch alle verschillende muis en keyboard events af en delegeert deze met behulp van een uniek ID nummer verder door naar de code van de prototype programmeur. Op deze manier kan men eenvoudig specifiëren welke muis pointer afkomstig is van welke persoon. Pointers worden afhankelijk van enkele parameters gepersonaliseerd. Het gebruik van het SDG Toolkit biedt onder andere de volgende voordelen aan: • Automatische detectie van alle USB en seriële muizen en toetsenborden die aanwezig zijn in het systeem • Event-gebaseerde interfaces om muis bewegingen en button clicks te detecteren • Verschillende cursors met elk unieke parameters (zoals rotatie, veranderbare cursor icon, kleur, grootte, . . . ) zijn zichtbaar • X en Y coördinaten zijn relatief aan elk venster. Het afhandelen van verschillende toetsenborden tegelijk is dus ook aanwezig in SDGT, maar wordt voor deze thesis niet gebruikt. Input kan enkel via de 4 drukgevoelige platen van de tabletop interface verlopen, waar het SDG Toolkit 4 aparte USB muizen van creërt. 3

Component Object Model



33

Het SDG Toolkit biedt ook de mogelijkheid om eigen widgets aan te maken, afgeleid van enkele basis SDGT widgets, die eenvoudig kunnen omspringen met verschillende muis en keyboard input events. Figuur 4.3 beeldt een simpele sketch applicatie af waarin vier gepersonaliseerde cursors getoond worden met elk een unieke eigen rotatie waarde. Dit voorbeeld maakt het mogelijk om met verschillende personen tegelijkertijd een zeer eenvoudige schets te creëren.

Figuur 4.3: Een eenvoudig SDGToolkit [26] sketch formulier.

Dit toolkit werd ontwikkeld aan de universiteit van Calgary in Canada. Enkele voorbeelden van prototypes kan men terug vinden op de volgende website: http://grouplab.cpsc.ucalgary.ca/cookbook/ Er bestaan ook andere, maar enigszins minder toegankelijke toolkits om het ontwikkelen op groupware devices te vereenvoudigen, zoals DiamondSpin [28].

4.3.2

Basis Implementatie

Deze SDGToolkit Implementatie is gebaseerd op SDGToolkit versie 2.0.1.0 en werd aangepast om input apparaten die absolute coördinaten retourneren te ondersteunen, zoals de TouchWare [30] touchscreen varianties. De relatieve muis coördinaten zijn enkel van toepassing bij het gebruik van klassieke muizen, en niet bij de tabletop. Dit komt omdat de 3M TW tabletop interface hardwaNatuurlijke Interactie Technieken op Tabletop Interfaces

4.3. SINGLE DISPLAY GROUPWARE TOOLKIT rematig alle coördinaten absoluut doorstuurt. De Client TW software

34 4

verbergt dit voor

standaard Windows applicaties. Het SDG Toolkit basisprincipe is afgebeeld in figuur 4.4 en werkt als volgt: 1. Via Dynamic Library Loading worden alle muis events (bewegen, klikken, . . . ) opgevangen voordat deze verder gedelegeerd worden naar de C# client applicatie. Een standaard MouseMove event wordt dus nooit actief aangezien de events daarvoor worden opgevangen, verwerkt, en doorgevoerd via SDGT’s eigen event systeem. 2. De opgevangen coördinaten worden verwerkt. Dit wil zeggen alle absolute coördinaten zoals bij de TW tabletop worden geconverteerd naar relatieve coördinaten, afhankelijk van de venstergrootte en desktopgrootte. Dankzij de vorige stap bevatten de opgevangen events extra low-level hardware informatie, zoals een uniek USB of seriëel identifier nummer. Dit nummer representeert het later cursor nummer. 3. De kunstmatig aangemaakte cursor is een C# Form dat boven de Parent ligt, voor elk muisID. Op deze manier kan de look en feel eenvoudig aangepast worden. Nadat de coördinaten verwerkt zijn, worden deze cursors correct geherpositioneerd. De laatst bekende coördinaat wordt voor elk ID bijgehouden en geupdate naargelang de huidige positie. 4. Nieuwe eigen SDGT events worden klaargemaakt om doorgegeven te worden. Een typisch SdgMouseEvent object bevat bijvoorbeeld ook een ID veld. Het juiste type event wordt natuurlijk ook ingesteld. De standaard procedure is als volgt geordend: (a) OnMouseDown (b) OnMouseClick (c) OnMouseUp Aangezien het klik event geen èchte event voorstelt dient er bijgehouden te worden of de muis reeds ingehouden werd in het verleden. Wanneer ze losgelaten wordt, verstuurt het SDG Toolkit eerst een Click event. 4

Spijtig genoeg enkel ter beschikking gesteld voor Microsoft Windows! Natuurlijke Interactie Technieken op Tabletop Interfaces


35

5. Afhankelijk van de Z waarde van de Parent UI componenten worden de nieuwe vents doorgestuurd naar de eindcomponenten. Dit gebeurt op ongeveer dezelfde manier als de klassieke event callbacks: het object met de grootste Z waarde (die vanboven ligt dankzij een BringToFront() methode) waar de huidige cursor coördinaten mee overeen stemmen, krijgt het event doorgestuurd. Wanneer geen componenten zijn toegevoegd of de coördinaten niet overeenstemmen, krijgt het formulier zelf de events doorgestuurd. Deze controle wordt uitgevoerd met behulp van bounding volume checks.

Figuur 4.4: De Single Display Groupware Toolkit flow.

Het Parent formulier is een C# Form dat de SDGMouseManager instance bevat. Deze manager klasse is de belangrijkste klasse die alle bovenstaande principes afhandelt en beheert. Wanneer nieuwe componenten aan de parent worden toegevoegd, dient het toolkit zijn gelinkte componenten lijst te updaten om daarna events naar het juiste, eventueel nieuwe Natuurlijke Interactie Technieken op Tabletop Interfaces


36

component door ge sturen. Om het laatste punt sneller te laten verlopen worden de componenten gesorteerd op hun Z waarde apart van de Parent.Controls ArrayList bijgehouden.

4.3.3

Event Handling in eigen Formulieren

Naast de belangrijkste klasse manager zijn er een aantal andere essentiële klassen aanwezig. Een daarvan is de SdgMouse die één enkele muis cursor representeert. Het aantal opgeslagen SdgMouse instances in de manager

5

is afhankelijk van hoeveel low-level unieke identifiers

de manager zelf moet verwerken. Om de eigen SDGT events succesvol te kunnen opvangen dient men UserControls af ge leiden van de ISdgMouseWidget interface. Deze interface delegeert de specifieke SDGT events verder door en maakt het mogelijk om de control deze te laten afhandelen. Het is echter ook mogelijk om rechtstreeks af te leiden van een SdgUserControl, die op zijn beurt de interfaces reeds gedeeltelijk implementeert. Figuur 4.5 vat alle verschillende componenten van een typische SDGT-gebaseerde applicatie samen.

Figuur 4.5: Een typische SDGToolkit Event-gebaseerde applicatie.

Een uitgebreidere documentatie van SDGT over alle klassen, delegates, interfaces en enumerations is beschikbaar op de volgende website: http://grouplab.cpsc.ucalgary.ca/software/SDGT/Documentation/index.html 5

Een formulier bevat een instance van de manager dus het Mice veld moet daarlangs toegankelijk zijn! Natuurlijke Interactie Technieken op Tabletop Interfaces

4.4. CALI: LIBRARY VOOR CALIGRAFISCHE INTERFACES

37

Zoals reeds vermeld is het niet nodig de SdgKeyboard interfaces noch formulieren toe te passen binnen dit domein. Het hoofd formulier bevat een instance van SDGManager, waardoor alle cursor eigenschappen toegankelijk worden. Alle parameters worden per persoon zo consistent mogelijk gehouden: rotaties en kleuren worden van viewport naar FlowMenu tot aan de cursor zelf doorgevoerd. Dankzij de manager kunnen vier personen tegelijk op de TouchWare [30] tabletop interface tegelijk werken, aangezien elke drukgevoelige plaat één event per keer kan herkennen.

4.4

CALI: Library voor Caligrafische Interfaces

“CALI” [7] staat voor Calligraphic Library for Interfaces. CALI is een zeer uitgebreide open source C++ gesture recognizer library die tot 97% van de verwerkte gestures succesvol kan herkennen. CALI maakt ook een integraal deel uit van het JavaSketchIt [16] User Interface Sketching project. Citaat van de CALI Website op http://immi.inesc-id.pt/cali/index.html: CALI is a software library for the development of Calligraphic Interfaces (intelligent interfaces based on sketches and gesture interaction) centered mainly on a simple Shape Recognizer. This recognizer is a fast, simple and compact approach to identify Scribbles (multi-stroke geometric shapes) drawn with a stylus on a digitizing tablet. Our method combines temporal adjacency, Fuzzy Logic and geometric features to classify scribbles. De CALI gesture recognizer library werd ontwikkeld voor lichtgewicht User Interface sketching applicaties. CALI’s basisalogritme is eenvoudig en robuust, waardoor het in staat is om zeer snel gestures die bestaan uit verschillende strokes te herkennen. Het CALI concept is analoog aan het onderzoek in hoofdstuk 3.2.



4.4.1

38

Interne Verbindingsstructuur

De gesture recognizer wordt via MC++ met de rest van de ontwikkelde applicatie verbonden. Dit is nodig omdat CALI volledig in Unamanged C++ (UMC++) ontworpen werd, terwijl het SDG Toolkit en de rest van de applicatie in Managed C#

6

opgesteld is. Deze

techniek van Visual Studio [29] maakt het mogelijk om losstaande libraries en applicaties in verschillende programmeertalen zoals C# en C++ met elkaar te combineren. In Managed C++ is het mogelijk om C# instructies aan te roepen die gebruik maken van de .NET garbage collector. Om de compiler te laten weten dat een bepaalde klasse dient toegevoegd te worden aan het C# Assembly bestand, dient men gebruik te maken van de __gc

7

prefix.

Wanneer deze info in de Assembly code staat, kan C# de “wrapped” MC++ CALI klassen instantiëren. Helaas verschillen beide programmeertalen significant van elkaar 8 , waardoor problemen onmogelijk compleet vermeden kunnen worden. Daarom kopiëert de wrapper expliciet alle waarden van de C++ pointer velden. De CALI library bevat een ruim aantal klassen met als prefix “CI”. Deze klassen behoren tot de basis van CALI in UMC++ en doen het eigenlijke herkenningswerk. Er zijn maar een select aantal klassen nodig voor de Managed C# client om de vormen correct te kunnen verwerken. Deze klassen hebben als prefix “MCI”. Alle besproken klassen in de volgende alinea’s beschikken over een MC++ wrapper.

4.4.2

Vormen H¨ıerarchie

De schets technieken zelf komen overeen met het onderzoek uit hoofdstuk 3.2. Dit betekent dat elk symbool dat gebruikers schetsen doorgestuurd dient te worden naar de gesture recognizer. Een getekende lijn wordt een “stroke” genoemd. Een gesture kan uit verschillende strokes bestaan (bijvoorbeeld een kruis dat bestaat uit twee aparte lijnen). CALI herkent een aantal vormen die uit meerdere basisklassen bestaan. Die vormen worden door middel van een CISCribble klasse opgeslaan in een raw formaat: alle strokes 6

C# is altijd managed, want deze bevat een Garbage Collector ! “gc” staat voor garbage collect 8 Het gebruik van pointers, templates, generics, . . . 7



39

(CIStroke), die alle doorgegeven punten bevat. Deze gegevens zijn nodig voor de recognizer om de juiste vorm succesvol te kunnen herkennen. Via de scribble klasse kan men allerlei bewerkingen uitvoeren op alle punten van alle strokes. Het bepalen van de bounding volume is de belangrijkste bewerking. Dit wordt gerealiseerd door middel van een tussenbewerking: het berekenen van de convex omhullende. Daarna wordt er een C# System.Drawing.Rectangle object geretourneerd, dat alle strokes bevat. De bounding volume is een geroteerde rechthoek. Deze rechthoek bevat een Location (de linkerbovenhoek) en een Size (de totale rechthoekgrootte) veld. Daarom dient men dus eerst de kleinste en grooste x en y coördinaten van deze volume te achterhalen. Een opgeslagen punt heeft buiten zijn x en y coördinaten ook nog een uniek veld “time” dat bijhoudt wanneer dit punt in de stroke precies werd toegevoegd. Dankzij deze tijd waarde kan men de punten en strokes zelf op een eenvoudige manier sorteren. Deze drie velden worden opgeslaan in CIPoint. De hiërarchie van vormen is zichtbaar op figuur 4.6. Een CIGesture is de laagst toegankelijke klasse voor het managed C# systeem. Deze klasse bevat essentiële informatie over het gevormd symbool, zoals de naam, het type, de scribble instance en extra’s zoals features.

9

De gesture klasse bevat momenteel nog geen geoptimaliseerde gegevens over de herkende vorm. Daarom wordt er twee maal van CIGesture afgeleid. CICommand representeert een nog verder te verwerken commando dat de gebruiker wenst uit te voeren. Dit is dus geen concrete vorm! CIShape representeert een basis vorm, maar bevat nog geen concrete informatie over de vorm zelf. Deze klasse vormt een scheiding tussen de actuele vormen en CIGesture. Commands herkennen en verwerken Het volstaat om het naam veld van de afgeleide klasse aan te passen naar het command type. De commando’s worden later afhankelijk van deze eigenschap individueel verwerkt. 9

Features worden niet gebruikt en ook verder niet besproken.



40

Figuur 4.6: De algemene CALI klasse h¨ıerarchie.

Bij deze verwerking van alle commando’s wordt er ook gebruik gemaakt van bounding volumes, om te controleren op welke reeds geschetste vorm dit commando van toepassing is. De volgende commando’s kunnen herkend worden door de gesture recognizer van CALI (zie figuur 4.7): CICross: Wanneer twee strokes elkaar kruisen of één stroke een “X” vormt, bekomt men een kruis. Dit toont aan dat de persoon die dit commando geschetst heef een reeds Natuurlijke Interactie Technieken op Tabletop Interfaces


41

herkende vorm wenst te verwijderen. Het symbool dat intersecteert met de bounding volume van CICross dient verwijderd te worden. Indien dit meerdere symbolen zijn, wordt de laatst toegevoegde verwijderd. CIWavyLine: Dit commando stelt het doorkribbelen van iets voor. Het effect is hetzelfde als CICross. CITap: Wanneer er slechts één punt geregistreerd werd tijdens het schetsen, retourneert de gesture recognizer een CITap commando. Hiermee kunnen gebruikers binnen hun territorium een context-gevoelige menu oproepen.

Figuur 4.7: Mogelijke commando’s: Tap, Cross, WavyLine, Circle.

Meer commando’s dan de bovenstaande lijst zijn ge¨ıntegreerd in CALI (Delete, Move, Copy, . . . ) maar worden niet of anders toegepast voor deze thesis. Shape varianten CIShape implementeert enkele belangrijke functies, afgebeeld op figuur 4.8. virtual void draw(Graphics *g, Pen *pen) {}; virtual void drawRelativeTo(Graphics *g, Pen *pen, Point diff) {}; virtual void repositionStrokes(Point diff) {};

Figuur 4.8: Methodes toegankelijk in Shape

Dankzij de hiërarchie opgebouwd door overerving wordt het later in Managed C# space mogelijk om heel eenvoudig alle herkende vormen te tekenen op een UI Element naar keuze. repositionStrokes() wordt gebruikt om alle punten een bepaalde hoeveelheid op te schuiven, wanneer iemand de vorm wenst te verplaatsen. Natuurlijke Interactie Technieken op Tabletop Interfaces


42

CIShape bevat nog geen concrete gegevens over de vorm zelf, behalve over de rand: Dashed, Bold of Open. Aan de top van de hiërarchie staan de eigenlijke vormen die afgeleid zijn van deze shape klasse. Elke specifieke vorm implementeert de virtuele functies van CIShape, en bevat concrete coördinaten. Deze gegevens zijn reeds geopitmaliseerd en worden gebruikt om te tekenen. In principe bevat elke vorm dus twee sets van coördinaten: de raw strokes list van CIScribble, en een minimaal aantal high-level coördinaten die de exacte vorm beschrijven. De volgende vormen kunnen herkend worden door de gesture recognizer van CALI: CILine: Representeert een lijn, bestaande uit begin- en eindpunt. CITriangle: Representeert een driehoek, bestaande uit drie hoekpunten. CIRectangle: Representeert een rechthoek, bestaande uit vier hoekpunten; CIDiamond: Een “diamand” vorm is in essentie een geroteerde rechthoek. Deze worden ook op exact dezelfde manier opgeslaan en getekend. CICircle: Representeert een cirkel, bestaande uit een middelpunt en radius. CIEllipse: Representeert een ellips vorm, bestaande uit een polygoon. Het tekenen en herpositioneren wordt gedelegeerd naar de MCIPolygon instance. De polygoon klasse bevat een lijst met punten en enkele speciale properties zoals Perimeter en Area. In principe komt deze puntenlijst overeen met de puntenlijst van alle strokes in de scribble. Indien de opgeslagen punten van de scribble niet aan een van de bovenstaande vormen voldoen, wordt deze toch nog herkend als apart CIUnknown object. Deze “vorm” bevat geen extra coördinaten maar tekent rechtstreeks alle strokes uit. Dit werkt minder efficiënt, maar zo kunnen eigen vormen die de gebruiker wenst te schetsen toch nog opgeslagen en verwerkt worden.



43

Andere simplistische vormen zoals bijvoorbeeld een vijfhoek kunnen eenvoudig ingevoerd worden door middel van het hoekpunten systeem. Uitgebreidere vormen kunnen op dezelfde manier als de ellips ingevoerd worden.

4.4.3

Het Gesture Recognizing verloop

Om gebruikers tijd genoeg te geven om strokes bij te tekenen die samen een grote gesture vormen, maakt de gesture recognizer gebruik van een time-out die alle geschetste strokes samen voegt en tracht te herkennen aan de hand van de opgeslagen muiscoördinaten. Deze time-out wordt dynamisch herberekend tijdens het opslaan van de cursor positie. Zodra de vorm compleet is, start een C# Timer met als interval de pas berekende waarde. Wanneer deze timer afgaat wordt het eigenlijke gesture recognizing proces van CALI aangeroepen.

CIRecognizer *rec = new CIRecognizer(); CIStroke *stroke = NULL; CIScribble *scribble = NULL; bool moving = false;

Figuur 4.9: Initialisatie van de recognizer objecten.

De gesture recognizer wordt ge¨ınitialiseerd in figuur 4.9. Het volstaat om een CIRecognizer en scribble, stroke object aan te maken. Merk op dat dit voorbeeld geen Managed code bevat, het principe is exact hetzelfde. moving wordt gebruikt om aan te geven of er punten toegevoegd dienen te worden in de onMouseMove event in figuur 4.11. Wanneer de gebruiker op een UI element wenst te schetsen, triggert deze een MouseDown event. Hiermee weet het systeem dat een nieuwe stroke van start gaat. Het eerste punt wordt daar reeds aan toegevoegd. Tijdens het schetsen dienen alle cursor coördinaten simpelweg worden toegevoegd aan de huidige stroke. Dit kan enkel indien een MouseDown event de MouseMove voor ging. Natuurlijke Interactie Technieken op Tabletop Interfaces


44

Timer.Disable(); stroke = new CIStroke(); stroke.addPoint(event.X, event.Y, 0); moving = true;

Figuur 4.10: Het onMouseDown event.

if(moving) { stroke.addPoint(event.X, event.Y, getCurrentTime()); }

Figuur 4.11: Het onMouseMove event.

moving = false; if(scribble == NULL) { scribble = new CIScribble(); } scribble.addStroke(stroke); Timer.startAtInterval(scribble.getTimeOut());

Figuur 4.12: Het onMouseUp event.

Als de persoon met schetsen stopt, heft hij zijn cursor op en komt er een MouseUp event aan de pas. Hiermee voegen we de getekende stroke toe aan de huidige scribble. Omdat het mogelijk is dat een scribble bestaat uit meerdere strokes, wordt niet dadelijk de gesture recognizer aangeroepen! Een Timer wordt gestart die dit na een bepaald interval, berekend door de scribble, opstart. De gebruiker heeft tot deze timer afgaat de tijd om een nieuwe stroke aan te maken, die de timer terug tijdelijk uitschakelt. Wanneer deze timer dan toch afgaat, roept die recognize(scribble) aan. De recognizer verwerkt de geschetste scribble en retourneert een ArrayList van al dan niet herkende vormen en/of commando’s. Natuurlijke Interactie Technieken op Tabletop Interfaces


45

Timer.Disable(); ArrayList gestures = rec.recognize(scribble); scribble = NULL;

Figuur 4.13: Het onTimeTriggered timer Event.

Het zou kunnen dat de recognizer meerdere vormen retourneert, terwijl er maar één vorm geschetst werd! Zie hoofdstuk 6.5.2.

4.4.4

Importeren en Exporteren van Gestures

Het huidig werkblad kan ook opgeslagen worden naar enkele bestanden. Deze bestanden kunnen op eender welk moment terug ge¨ımporteerd worden om de laatst gekende sessie te herstellen. Elke scribble bevat een writeTo() en readFrom() methode die de raw gegevens wegschrijft naar of ophaalt van een bestand. Omdat alle vormen afgeleid zijn van CIGesture, en deze klasse een scribble bevat, dient men enkel over alle herkende vormen te lopen en de methodes aan te roepen. Het inlezen van deze gegevens is een minder eenvoudig proces, omdat het bestand enkel low-level informatie bevat. Een nieuw CIScribble object kan eenvoudig aangemaakt worden via readFrom(), maar hoe weet men welke high-level vorm tot deze scribble behoort? Er zijn twee mogelijke oplossingen: 1. Ofwel laten we deze scribble terug herkennen door de gesture recognizer. Dit is echter een zwaar proces dat enige tijd kan duren aangezien alle opgeslagen scribbles stuk voor stuk herkend zullen moeten worden. 2. Ofwel schrijven we in de writeTo() methode ook informatie over het symbool weg, zoals de naam en het type. Afhankelijk van dit type kan een nieuw symbool aangemaakt worden dat zijn eigen coördinaten afleid van de scribble. De tweede methode werkt veel efficiënter. Het proces is zichtbaar op figuur 4.14.



46

CIScribble *scribble = new CIScribble(); CIShape *shape; for(int i = 0; i < scribblesToRead; i++) { filestream >> name; switch(name) { case "Line": shape = new CILine(); break; case "Rectangle": shape = new CIRectangle(); break; ... } scribble->readFrom(filestream); shape->setUp(scribble); addToGestureList(shape); }

Figuur 4.14: Het importeren van de sessie.

Via setUp() instantiëert elke vorm automatisch hun eigen geoptimaliseerde coördinaten systeem via de doorgegeven scribble. Deze methode werd in CIShape gedeclareerd als virtuele functie, en in alle high-level vormen ge¨ımplementeerd.


HOOFDSTUK

5

Collaboratie op Tabletop Interfaces

5.1

Inleiding

Dit hoofdstuk beschrijft de algemene structuur en aanpak van de eindapplicatie verder in detail. Hier wordt ook uitgelegd waarom er voor een bepaald idee gekozen werd en niet voor een alternatief, maar toch besproken concept tijdens de literatuurstudie in hoofdstuk 2.1. Alle aparte relevante concepten en componenten worden hier samen gebracht om een globaal en overzichtelijk geheel te creëren. Zoals reeds geconcludeerd werd in hoofdstuk 2.7, zijn niet alle onderzochte technieken wel degelijk toepasbaar: er dient een goede trade-off gemaakt te worden. Afhankelijk van de beschikbare hardware zijn enkele concepten niet van toepassing. De gebruikte tabletop opstelling voor deze thesis werd reeds uitvoerig besproken in hoofdstuk 4.2.

5.2

Viewports als Persoonlijke Territoria

Om het collaboratief sketchen zo goed mogelijk te ondersteunen werd er gekozen voor een licht aangepast cutouts systeem zoals ge¨ıntroduceerd in hoofdstuk 2.4. Een cutout is een synoniem voor een unieke viewport voor elke deelnemer. Op deze manier kunnen gebruikers 47

5.2. VIEWPORTS ALS PERSOONLIJKE TERRITORIA

48

de viewports aanpassen naar hun wensen. Enkele wijzigbare parameters zijn de grootte (de zoom factor), de rotatie afhankelijkheid en de positie. Cutouts of viewports maken het ook mogelijk om eenvoudig en efficiënt gebruikersrechten op verschillende niveau’s te integreren. Dit komt omdat elke viewport uniek verbonden is aan elke gebruiker. Wanneer nieuwe gebruikers wensen deel te nemen aan een vergadering is het aanmaken van een nieuwe viewport slechts een kleinigheid. Elke viewport kan tevens dynamisch verplaatst worden. Voor een uitgebreide bespreking over het onderzocht cutout systeem compleet met vooren nadelen, zie hoofdstuk 2.4.

5.2.1

Viewport Componenten

Stel dat verschillende personen samen een schets wensen te ontwerpen. Elke persoon kan op deze manier een deel van de schets voor zich nemen. In figuur 5.1 is het centraal schema zichtbaar in het midden. Wanneer iemand een deel wenst te selecteren om daar een viewport van te creëren, volstaat het om een sleep beweging te maken zoals de klassieke selectie metafoor. Een aparte viewport wordt toegevoegd aan het hoofd formulier met dynamisch toegewezen rechten 1 . Daarna kan de gebruiker deze cutout verplaatsten naar zijn persoonlijke territoria en eventueel verder aanpassen. Nieuwe deelnemers dienen slechts deze procedure te herhalen. Natuurlijk is het mogelijk dat verschillende cutouts elkaar deels overlappen. Wanneer een overlapping optreedt, wordt er afhankelijk van de gebruikersrechten toegewezen welke gebruiker op het overlapte gebied mag schetsen. Deze overlapping is zichtbaar in figuur 5.1 gekleurde alpha-blended rechthoeken. Elke bewerking uitgevoerd door elke viewport wordt om beurten doorgedelegeerd naar het centraal schema. (Zie figuur 5.4) Op deze manier kunnen gebruikers die geen directe toegang hebben tot het centraal schema hun eigen viewport manipuleren en op deze manier uiteindelijk toch bijdragen tot het globaal schema. Deze gedelegeerde Events worden door het centraal schema verder verwerkt als gesture. 1

Dit wordt verder besproken in hoofdstuk 5.3



49

Figuur 5.1: Het viewports systeem met het Referentie schema in het centrum.

Daarna stuurt deze een bericht naar alle viewports om mee te delen dat er een aanpassing heeft plaatsgevonden. De viewports refreshen hun “view” op het globaal schema direct daarop volgend. Alle acties gebeuren dus real-time. Dit wordt gerealiseerd door middel van het behavioral Observer software engineering design pattern van “Gang of Four” [8]. Om het globaal overzicht te behouden en het centraal schema niet té onoverzichtelijk te maken, zijn alle aangemaakte viewport grenzen (boundaries) getekend op het schema zelf. Dit helpt nieuwkomers ook met het kiezen voor een nog gedeeltelijk beschikbaar stukje schema. De groene rand in figuur 5.1 stelt de “panning” zone voor van de viewport met groene rand rechts.



50

Viewport Titlebars Zoals zichtbaar in figuur 5.1, beschikt elke viewport over een eigen “titlebar handle” bovenaan. Deze titelbalk maakt het mogelijk om de viewports op een zeer eenvoudige manier te verplaatsen op dezelfde manier als in een Desktop Envoirnment zoals GNOME [4]. Op de titelbalk zelf staan een aantal knoppen die belangrijke of veel voorkomende taken eenvoudiger uitvoerbaar maken, zonder het menu te moeten activeren. De titelbalk bestaat uit een aantal basis componenten, zichtbaar in figuur 5.2. 1. Via de ruimte links voor de knoppen kunnen gebruikers de viewport verplaatsen. De sleep beweging begint vanaf hier, want slepen op de viewport zelf resulteert in het schetsen. 2. De eerste knop met het “pen” icoon stelt het annoteren op het globaal schema voor. Meer uitleg over annotaties is terug te vinden in hoofdstuk 5.2.2. 3. Met de tweede knop kunnen gebruikers eenvoudig gestures selecteren. Het selecteren van gestures wordt uitgebreid besproken in hoofdstuk 6.5.1. Deze knop bevat als icoon een hand om het selecteren te symboliseren. 4. De derde knop staat voor de mogelijkheid tot het roteren van de viewport. 5. Met de voorlaatste knop kan men de persoonlijke viewport “pannen” ten opzichte van het globaal schema. Hier wijzigt men de eigen werkplaats op het schema door op de viewport in verschillende richtingen te bewegen. 6. De rode kruis knop staat natuurlijk voor het sluiten van de viewport, en het verlaten van de collaboratieve actie. Alle reeds getekende gestures blijven wel bewaard op het schema zelf!

Figuur 5.2: De Viewport titlebar.



51

In figuur 5.2 werd een rood kadertje getekend rond de selectie knop. Dit betekent dat gebruikers momenteel gestures aan het selecteren zijn in plaats van het ontwerpen. Door nog eens te klikken op de knop wordt deze gedeactiveerd. Het is niet mogelijk om twee knoppen tegelijkertijd geactiveerd te hebben! Men kan geen annotaties maken, én gestures selecteren, aangezien beide acties gebruik maken van de viewport MouseEvent callbacks. Zie hoofdstuk 5.2.2.

5.2.2

Implementatie Cutout Componenten

Zoals reeds aangehaald worden de viewport componenten opgedeeld in persoonlijke territoria en een centraal, vastliggend, schema. Via dit schema kunnen gebruikers nieuwe viewport instances creëren, en via diezelfde viewports is het mogelijk om het schema op een onrechtstreekse wijze te manipuleren. Het Centraal Schema Het grootste deel van dit collaboratief systeem is het centraal schema, de klasse PanComponent. Deze klasse implementeert de interface Observer om enige veranderingen van de clients te kunnen verwerken. Dit component stelt het publiek toegankelijk werkblad van de collaboratieve taak voor. PanComponent bevat geen MCIRecognizer 2 instance, maar houdt wel alle reeds geschetste gestures bij in een sorteerbare ArrayList. De lijst kan gesorteerd worden op auteur (het rechten getal van hoofdstuk 5.3) of op toegevoegde tijd. Wanneer een client component een gesture herkent, laat deze via het observer patroon weten aan PanComponent dat dit symbool toegevoegd dient te worden aan de globale lijst. Daarna update deze op zijn beurt alle andere clients. Het observer patroon werkt dus eigenlijk indirect in twee richtingen. Het updaten werkt zoals figuur 5.3 aangeeft. Dit proces is ook zichtbaar in figuur 5.4. Bij het tekenen van vormen, voor het herkenningsproces, dienen alle tijdelijke punten die toegevoegd moeten worden aan de stroke ook opgeslaan worden in PanComponent. Op 2

Alle CALI klassen die hier aan de pas komen zijn MC++.



52

for (int i = 0; i < subjects.Count; i++) if (subjects[i] is IObservable && subject != subjects[i])) ((IObservable)subjects[i]).UpdateObservable();

Figuur 5.3: De observer die de “ observable” clients verwittigt.

deze manier is het mogelijk om real-time het globaal schema en de viewports te updaten. Elk punt bevat een speciaal veld owner dat bepaald van welke client dit punt komt. Zodra een specifieke client aan de observer een herkende gesture toevoegd, worden de tijdelijke punten van deze client uit de lijst verwijderd. Om dit proces snel te laten verlopen kan de lijst gesorteerd worden op eigenaar via de C# IObservable interface.

Figuur 5.4: De Viewport Observer flow.

De laatste taak van PanComponent is het delegeren van gevormde viewport rectangles. Wanneer een persoon wenst deel te nemen aan de collaboratieve actie, volstaat het om een deel van het globaal schema te selecteren met een sleep beweging.



53

Deze gevormde rechthoek wordt via een delegate als vent doorgegeven. Daarna kan een nieuw BoxComponent object aan het hoofdformulier worden toegevoegd. De individuele Client Viewports Een BoxComponent klasse representeert een individuele viewport op de tabletop interface. Deze klasse is afgeleid van een RotatableControl C# SdgUserControl dat het mogelijk maakt om de viewport eenvoudig te roteren relatief ten opzichte van de gebruiker. Het spreekt voor zich dat alle onderstaande events van het SDG Toolkit komen. Voor meer informatie over SDGT Event Handling, zie hoofdstuk 4.3.3. Alle aangemaakte BoxComponent klassen bevatten unieke instances van MCIRecognizer. Elke viewport implementeert het gesture recognizing verloop zoals besproken in 4.4.3. Wanneer een vorm succesvol herkend wordt, slaat de PanComponent klasse deze op in de lijst met geschetste gestures via de Notify() methode. Het viewport “box” component dient afhankelijk van een status parameter een aantal taken uit te voeren bij de muis events. De mogelijke status variabelen zijn opgesomd in figuur 5.5. De status staat standaard op NOT_MOVING. Dit betekent dat de viewport werkt zoals verwacht: een onMouseDown event start het gesture teken proces, en een onMouseUp event start de CALI gesture herkenningsfase. Maar stel dat de persoon die over de huidige viewport beschikt niet tevreden is met zijn relatieve viewport locatie ten opzichte van het globaal schema? De “view” kan altijd nog opgeschoven worden, binnen de grenzen van het globaal schema zelf. Dit pannen gebeurt wanneer de status op IS_MOVING staat. De READY_TO states houden mouseUp en mouseMove events gescheiden. De BoxComponent functionaliteit wordt tijdelijk uitgeschakeld wanneer de status als prefix “IS_” heeft. De mogelijkheid tot roteren is ook aanwezig dankzij de IS_ROTATING status. De RotatableControl basisklasse implementeert een poolcoördinatensysteem dat verder in detail wordt besproken in hoofdstuk 6.4.3.



54

public enum PanningState { READY_TO_MOVE = 1, READY_TO_ROTATE = 5, IS_MOVING = 2, IS_ROTATING = 4, IS_RESIZING = 6, NOT_MOVING = 3, GESTURE_SELECTING = 7, GESTURE_ANNOTATING = 8 };

Figuur 5.5: De verschillende BoxComponent status mogelijkheden.

De voorlaatste status, GESTURE_SELECTING, bepaalt of de door SDGT gegenereerde muis events het verplaatsen van een gesture voorstellen. Het selecteren en verplaatsen van gestures wordt uitbundig besproken in hoofdstuk 6.5.1. Ten slotte dient GESTURE_ANNOTATING als switch om de getekende gestures al dan niet direct door te geven naar de CALI Recognizer. Een “annotatie” is een snelle aantekening of tekst die geen specifieke vorm voorstelt, en dient als herinnering of algemene nota. Alle annotaties zijn dus per definitie van het type CIUnknown. Deze annotaties worden gevormd zodra de cursor wordt opgehoffen, zonder te hoeven wachten op het herkenningsproces. De lijndikte en kleur van de annotaties wordt aangepast en gepersonaliseerd om annotaties te kunnen scheiden van “mislukte” vormen die niet herkend worden door de recognizer zelf. Het beheren van de componenten De twee voorgaande klassen worden gebundeld in een DLL

3

bestand en kunnen zo een-

voudig met andere projecten worden samengesmolten. Een aantal “beheer” klassen zorgen ervoor dat het afhandelen en uitvoeren van methodes gescheiden blijven van de functionaliteit van het hoofdformulier zelf. 3

Dynamic Library Link



55

De BoxComponentHandler klasse representeert één enkele BoxComponent viewport. De handler verzorgt alle gedelegeerde events, menu aanvragen, enzovoort . . . De rotatie variabele wordt via BoxComponentHandler verdeeld over alle huidig actieve UI elementen, inclusief de SDGT cursors. De BoxContainer klasse houdt een ArrayList van BoxComponentHandler objecten bij, die het formulier dan onrechtstreeks kan aanroepen. Deze container bouwt de gepersonaliseerde menu’s op van elke viewport afhankelijk van de rechten (zie hoofdstuk 5.3). Via de container kunnen nieuwe viewports aangevraagd worden, of reeds bestaande viewports verwijderd worden. BoxContainer verzogt ook de correct delegatie van SdgMouseEvent objecten. Wanneer een extra formulier verschijnt dienen de muis events van het hoofdformulier doorgegeven te worden! De algemene programma architectuur is zichtbaar in figuur 5.6. Alle objecten worden via een hogere architectuur laag gecontroleerd en bestuurd. Het hoofdformulier bevat slechts een object van laag 3 omdat PanComponent een “Singleton” klasse is. Dankzij deze structuur hoeven het formulier en de component handlers zich geen zorgen te maken over enige CALI klassen: deze worden namelijk afgehandeld door BoxComponent zoals reeds besproken. Het is mogelijk dat objecten van dezelfde laag onderling gelinkt zijn met elkaar.

5.2.3

Opdeling in Persoonlijke Workspaces

Uit het onderzoek van hoofdstuk 2.2 leidt men af dat een correcte opdeling van de workspace( of het werkblad dat beschikbaar is), crutiaal kan zijn voor de collaboratie van verschillende personen. Deze workspace kan ofwel expliciet ofwel impliciet worden opgedeeld. Het expliciet opdelen van workspaces komt meestal automatisch voor bij het samen puzzelen of werken aan een maquette, zoals beschreven in [1]. Gebruikers wensen een expliciete opdeling om verwarring tussen puzzelstukjes die nog aan de puzzel toegevoegd moeten worden en andere delen 4

4

te vermijden.

Zoals bijvoorbeeld het sorteren van puzzelstukken per kleur rechts van de gebruiker zijn persoonlijke

opslagplaats



56

Figuur 5.6: De algemene Programma Architectuur.

Dit brengt natuurlijk de nodige nadelen met zich mee. Expliciet opgedeelde workspaces kunnen niet zo eenvoudig aangepast of verplaatst worden. Er treden ook problemen op wanneer nieuwe personen wensen deel te nemen aan de taak. Daarom voorzien cutouts een impliciete opdeling van workspaces. Alle viewports zelf stellen logischerwijze de persoonlijke territoria’s van gebruikers voor. Deze kunnen zeer eenvoudig verplaatst, gewijzigd of vernietigd worden. Het publiek toegankelijk deel van het schema ligt in het centrum en is zichtbaar voor iedereen. In principe is het zelfs mogelijk voor een persoon om met verschillende cutouts tegelijkertijd te werken: één als tijdelijke opslagplaats en één als persoonlijk territorium. Impliciete workspaces hebben zo ook hun nadelen. Het is bijvoorbeeld minder eenvoudig om objecten snel door te geven. Wanneer men met tangible objects [6] op tabletop interfaces werkt, kunnen die objecten over de tafel zelf doorgegeven worden. Virtuele objecten moeten in principe over de hele tafel heen schuiven, eerdat zij hun bestemming bereiken.


5.3. AFHANDELEN VAN GEBRUIKERSRECHTEN

57

Een tussen oplossing is via het Flow Menu geselecteerde objecten snel naar persoon x of y laten doorgeven. Het object slepen naar het publiek toegankelijk deel en de doelgebruiker het zelf laten ophalen is een andere mogelijkheid. Dit menu wordt in detail besproken in hoofdstuk 6.2.

5.3

Afhandelen van Gebruikersrechten

Dankzij het viewport systeem, is het eenvoudig om te bepalen welke deelnemer op welk deel van het schema al dan niet mag schetsen, aangezien elke gebruiker normaal gezien over exact èèn viewport component beschikt. Wanneer een klassieke vergadering plaats vindt zonder een tabletop interface, opent de voorzitter meestal de sessie. Die persoon beschikt ook over de “macht” om de vergadering op te schorten of compleet te beëindigen. De eerste gebruiker die een viewport aanmaakt via de klasse PanComponent beschikt dus over deze rechten. Elke gebruiker daarna beschikt over telkens minder rechten. De laatste gebruiker zal bij conflicten altijd zijn rechten moeten afstaan andere gebruikers. Deze rechten stellen in principe een getal voor dat gelinkt wordt samen met de BoxComponent cutout klasse. Een container klasse bevat alle handlers, en het hoofd formulier kan via deze container de belangrijkste functies oproepen. Hoe lager het getal, hoe meer rechten, met als laagste getal (waarmee men begint) een 0.

5.3.1

Rechten van de Deelnemers

Wat houdt dit nummer nu concreet in, welke rechten hebben gebruikers? Een kort overzicht: • De persoon met de hoogste rechten (de eerste deelnemer dus) kan expliciet het tot nu toe aangepaste werkblad opslaan. Er worden een aantal manieren voorzien om een bestandsnaam in te voeren. Voor meer informatie, zie hoofdstuk 6.3. • Diezelfde persoon kan ook een vorig aangemaakt werkblad terug herstellen, of importeren. Dit systeem werkt op dezelfde wijze.


5.3. AFHANDELEN VAN GEBRUIKERSRECHTEN

58

• Misschien wel het belangrijkste element: het al dan niet overschrijven van elkaars schetsen. Het is mogelijk dat verschillende personen hun gepande cutout gedeeltelijk of helemaal overlapt. Personen met de meeste rechten (en het laagste rechten getal) kunnen dan op dat deel toch tekenen. Dit wordt ook berekend door middel van een boundary check. De persoon met het minste rechten krijgt visuele feedback op zijn BoxComponent door het overlapte deel waar deze niet op kan schetsen in te kleuren met de persoonlijke kleur van de persoon met de meeste rechten. Zie figuur 5.1. • Doorgeven van rechten: De “voorzitter” kan indien gewenst zijn rechten afstaan en doorgeven aan andere aanwezige personen.

5

Hij neemt dan de rechten van de doel

deelnemer over. Wanneer deze voorzitter zijn viewport sluit en dus niet meer deelneemt aan de vergadering, wordt automatisch een nieuwe voorzitter verkozen. Dit is typisch de persoon die reeds over de tweede hoogste rechten beschikt. Het opslaan van het werkblad kan ook impliciet gebeuren! Er kan bijvoorbeeld een timer ingesteld worden om de sessie elke vijf minuten op te slaan. De tijdsspanne kan wederom aangepast worden door de voorzitter. Meer info over importeren en exporteren is terug te vinden in hoofdstuk 4.4.4.

5.3.2

Weergave van de Rechten

De meeste rechten van de gebruiker worden niet expliciet weergegeven. De voorzitter heeft bijvoorbeeld wel toegang tot een reeds extra functies, zoals het openen van een vorige sessie. Dit kan hij doen door middel van zijn gepersonaliseerde flow menu 6 , waar die optie wel aanwezig is, zoals in figuur 5.7. Andere personen met minder rechten beschikken over een flo wmenu met minder uitvoerbare taken. Het spreekt voor zich dat deze menu index af en toe opnieuw opgebouwd zal moeten worden. Dit wordt vernieuwd wanneer: 5

Identificatie van personen wordt gebaseerd op kleur en niet naam. Dit geeft extra visuele feedback en

vergemakkelijkt de taak voor de gebruiker. Zie het icoon in figuur 5.7. 6 Dit menu wordt in detail besproken in hoofdstuk 6.2


5.4. BELANGRIJKE GEBRUIKTE METAFOREN

59

Figuur 5.7: De voorzitter geeft zijn rechten af via het Flow Menu.

1. Een gebruiker zijn Viewport sluit en de collaboratieve actie verlaat. 2. Een gebruiker deelneemt en een Viewport aanmaakt. 3. De voorzitter zijn rechten afstaat aan iemand anders. In de meeste gevallen volstaat het om slechts de menu opbouw van de voorzitter te vernieuwen. Wanneer deze echter zijn rechten afstaat aan een ander persoon, moeten beide menu’s aangepast worden. Elke gevormde gesture bevat ook als parameter het gebruikersnummer van de auteur. Afhankelijk hiervan is het al dan niet mogelijk om gestures te verwijderen. Een persoon met een hoger toegangsrecht kan bijvoorbeeld gestures getekend door andere personen handmatig verwijderen. Dit kan op twee manieren gecontroleerd worden. Ofwel worden het aantal opties aanwezig in het Flow Menu beperkt, afhankelijk van de rechten van de gebruiker. Ofwel worden de getekende commando’s voor de gesture recognizer al dan niet uitgevoerd, afhankelijk van de rechten van de gebruiker.

5.4

Belangrijke gebruikte Metaforen

Metaforen die interactie manieren met de applicatie weten te mappen op het gebruik van objecten in het dagelijkse leven, helpen gebruikers deze interactie manieren eenvoudig te


5.4. BELANGRIJKE GEBRUIKTE METAFOREN

60

identificeren en herinneren. Het is dus zeker niet onbelangrijk om zo veel mogelijk gebruik te maken van metaforen waar nodig. Een kort overzicht van de belangrijkste gebruikte metaforen: • Selectie metafoor: Het omcirkelen van een gesture (zie boven). Dit metafoor wordt dagelijks toegepast in Desktop Envoirnments van besturingssystemen zoals GNOME [4]. Het aanklikken van de viewport 7 selecteert de viewport in bepaalde omstandigheden. Dit maakt het mogelijk om met een sleep beweging de viewport te verplaatsen. • Slingshot metafoor: een deel van de selectie metafoor. Het slepen van de viewport maakt het zo mogelijk om de cutout toch te kunnen slepen naar anders onbereikbare gebieden. Door de viewport naar beneden te slepen en verder weg te bewegen, wordt een “decoy” aangemaakt die het doel aanduidt, zoals een slingshot [3]. Voor meer uitleg zie hoofdstuk 6.4.1 en figuur 6.6. • “PickBox” metafoor: Na het selecteren van de viewport kan men deze slepen en zo verplaatsen zoals een klassiek UI Component. Andere acties worden tijdelijk onmogelijk gemaakt, anders wordt de gesture recognizer onnodig opgestart. Om aan te geven dat de cutout geselecteerd is, verschijnen er “handles” rond. Figuur 5.8 verduidelijkt dit verder.

Figuur 5.8: Na het selecteren van een object verschijnen er handvaten.

• Tekenen metafoor: Het eigenlijke schetsen dat door de gesture recognizer herkent wordt als een afgewerkte gesture. Dit tekenwerk wordt op exact dezelfde manier uitgevoerd als op papier, behalve op tabletop systemen met de vinger (die de cursor representeert). 7

Na het veranderen van de interactie manier in het Flow Menu. Zie hoofdstuk 6.4


5.5. CONCLUSIE

61

• Verwijder metafoor: Zoals bovenaan beschreven, een kruis tekenen (of een kribbel) verwijdert de onderliggende gesture. Op papier wordt dit ook enorm veel toegepast om snel aantekeningen of verbeteringen door te voeren. • Icon item metafoor: Afhankelijk van de herkenbare iconen die zichtbaar zijn in het midden van het flow menu kunnen gebruikers eenvoudig taken identificeren. Deze icons leggen de link naar de echte wereld door bijvoorbeeld een “schaar” symbool af te beelden om een gesture te knippen en een “lijmpot” om een gesture te plakken.

5.5

Conclusie

Dankzij de aard van het cutouts systeem is het mogelijk om de applicatie impliciet op te delen in verschillende territoria. Op deze manier houdt het programma rekening met de wensen van elke gebruiker, evenals potentiële nieuwe gebruikers. Viewports aanmaken, roteren of verplaatsen via verschillende metaforen is immers zeer eenvoudig. Iedereen die op hun persoonlijk territorium werkt, tekent een deel van de centrale schets. Alle bevestigde acties (zoals het schetsen van een gesture) worden doorgedelegeerd naar alle andere cutouts. Figuur 5.4 verduidelijkt de flow van dit Observer patroon. De systeem architectuur is zo opgebouwd dat de high-level User Interface geen toegang heeft tot de low-level CALI gesture klassen en vormen. Via enkele containers worden alle viewports verder afgehandeld, en hun eigen events verwerkt. Omdat elke persoon normaal gezien over één enkele cutout van het globaal schema beschikt, kan men op een efficiënte manier restricties opleggen door middel van het rechten systeem. De eerste persoon die een viewport aanmaakt wordt automatisch als “directeur” van de collaboratieve vergadering gepromoot. Deze kan indien gewenst zijn rechten afstaan en de huidige sessie opslaan of een vroegere status ophalen.


HOOFDSTUK

6

Ondersteunende Interactie technieken

6.1

Inleiding

Het cutout systeem dat voorgesteld werd in hoofdstuk 5.2 dient te beschikken over enkele eenvoudige manipulatie technieken. Interactie met een User Interface door middel van de drukgevoelige platen van het tabletop systeem werkt op een andere manier dan interactie met klassieke hardware zoals toetsenbord en muis. Daarom dienen enkele unieke concepten gebruikt te worden om deze interactie met het systeem en manipulatie van schetsen op een eenvoudige manier te laten verlopen. In dit hoofdstuk worden een aantal gebruikte interactie technieken uitbundig besproken.

6.2

Context-gevoelig Flow Menu

Dankzij het gekozen cutouts systeem wordt het mogelijk om individueel, elk op hun eigen deel, aan een schema te schetsen, en toch op deze manier samen te werken aan een groter geheel. Interageren met het systeem is op verschillende manieren mogelijk en wordt uitvoerig in detail besproken in hoofdstuk 6.2.4.

62

6.2. CONTEXT-GEVOELIG FLOW MENU

63

Naast het interageren met de viewport zelf (vergroten, verkleinen, verplaatsen, . . . ), kan elke gebruiker ook een “flow menu” oproepen. Deze menu’s helpen gebruikers naast het ingeven van schetsen via sketching om hun taken te verwezenlijken. Zoals bestudeerd in hoofdstuk 3.4 kunnen klassieke User Interface componenten slechts matig van enig nut zijn.

6.2.1

Toegankelijkheid

Dit Flow Menu vergemakkelijkt de toegankelijkheid van sommige taken. Flow Menu’s kunnen altijd opgeroepen worden door te klikken naast de persoonlijke viewport, of op de viewport zelf 1 . De menu is opgedeeld in acht gelijke delen en bevat onder andere de volgende basiscommando’s: 1. Rotatie afhankelijke coördinaat aanpassen: keuze tussen een set aantal graden of eigen invoer via een virtueel toetsenbord. Voor meer details, zie hoofdstuk 6.3. 2. Kleur aanpassen (de kleur wordt consistent doorgevoerd naar zowel het Flow Menu zelf als de viewport kader) 3. Wisselen van verplaatsingstechniek van de viewport (Zie hoofdstuk 6.4) 4. Importeren en exporteren commando’s indien genoeg gebruikersrechten 5. Wisselen tussen schetsen en selecteren van reeds geschetste vormen via sketching zelf 6. . . . Dankzij het Flow Menu zijn deze taken veel sneller toegankelijk dan via een klassieke pop-up menu, aangezien het flow menu gecentreerd rond het klikpunt verschijnt. Navigeren tussen submenu’s is zeer eenvoudig. Door met de cursor terug naar het centrum van de menu bewegen verlaagt men een niveau, tot op de root menu. Alle menu items beschikken over een duidelijk icoon dat de gebruiker helpt om de taak makkelijk te identificeren. Figuur 6.1 beeldt zo’n actief item af. 1

De recognizer herkent een klik als een “tap” commando



6.2.2

64

Visualisatie

De visualisatie van het flow menu werkt op ongeveer dezelfde wijze als de visualisatie van de artificiële cursors van het SDG Toolkit. De klasse FlowMenu is ook een afgeleide van Form. Om het menu ook eenvoudig te kunnen gebruiken in andere applicaties wordt er een onderscheid gemaakt tussen FlowMenu en een SDG Toolkit afhankelijke SdgFlowMenu, die de SDGT specifieke events verder kan afhandelen. Doordat de vorm van dit menu cirkelvormig is, wordt de rest van het formulier opgevuld met een “transparante” kleur, zodat het onderliggend hoofdformulier waar men op werkt nog gedeeltelijk zichtbaar is. Natuurlijk spreekt het voor zich dat de titelbar en taakbalk opties uitgeschakeld werden, om de indruk te wekken dat het menu boven het hoofdformulier “zweeft”.

6.2.3

Opbouw en Structuur

De opbouw van het flow menu zelf wordt met behulp van de C# MenuItem en MainMenu klassen gerealiseerd. In principe kunnen alle aparte menu’s een oneindig aantal submenu’s bevatten, maar dit wordt nooit verder toegepast dan diepte 2. Een MenuItem bevat een veld Items dat een array voorstelt van alle subitems, die op hun beurt ook MenuItem instances zijn. Deze menu items bevatten een aantal belangrijke parameter velden: • Text: Beschrijft de taak die de menu omvat. Dit wordt afgebeeld op alle flow menu octanten zelf. Zie figuur 6.1. • OnClick: Een pointer naar de EH

2

methode die geactiveerd wordt wanneer de

gebruiker deze menu item selecteert. • Tag: “Eigen” data die kan meegegeven worden met het item.

3

Deze tag wordt hier

gebruikt om een eigen MenuItemTag klasse mee te geven. Die bevat op zijn beurt: – Sender: Het object dat nodig is in de EH methode om de juiste waarden te manipuleren. De standaard C# sender is het MenuItem zelf! 2 3

Event Handler Tag werd bij .NET [25] versie 2.0 ingevoerd! Natuurlijke Interactie Technieken op Tabletop Interfaces


65

– Icon: Een Bitmap die bijhoudt welk icoon afgebeeld dient te worden wanneer de gebruiker zijn cursor over dit item plaatst. Het icoon wordt in het centrum van de cirkel getekend met behulp van Graphics.DrawImage(). In figuur 6.1 is zo’n icoon zichtbaar. Deze iconen geven de gebruiker een extra visuele feedback buiten de menu item label. De “cut” actie wordt bijvoorbeeld verduidelijkt met een schaar icoon. De standaard UI iconen worden zoveel mogelijk gehandhaafd.

Figuur 6.1: Het flow menu met een actief item en een icon in het midden.

De belangrijkste taken uitvoerbaar via het menu zijn zichtbaar in figuur 6.2.

6.2.4

4

Activatie

De submenu’s worden geactiveerd op twee manieren. Ofwel wordt een MouseDown event opgevangen 5 . Dan wordt het menu opgebouwd en getoond, en kan de gebruiker via de cursor een menu activeren. Als een menu item van de root menu een submenu is (en dus zelf nog menu items bevat), wordt deze automatisch geselecteerd en opgebouwd. Figuur 6.1 beeldt het submenu “color” af (linksboven in groen). 4 5

Menu’s aangeduid met een ster zijn enkel zichtbaar voor de persoon met de hoogste rechten. Deze events zijn vanzelfsprekend allen SDG Toolkit specifieke Events.



66

Session* |__ Import |__ Export |__ Give Rights To |__ [Viewport X] |__ Close... |__ [Viewport X] Selection |__ Clone Gesture |__ Delete Gesture |__ Move To |__ [Viewport X] Viewport |__ Color... |__ Rotate... |__ [X*Y Degrees] |__ Custom |__ Move... |__ Via Slingshot |__ Via Dragging |__ Close

Figuur 6.2: De belangrijkste uitvoerbare taken via het menu.

Een tweede manier is het “tappen” van de tabletop interface dat het menu activeert. Dit genereert ook een MouseUp event. Gebruikers die liever langzaam en accuraat door het menu willen navigeren kunnen deze optie selecteren. Hier wordt een menu item pas geactiveerd wanneer er op geklikt wordt, en niet wanneer de cursor losgelaten wordt of een submenu aangeraakt wordt.


6.3. RECHTSTREEKSE DATA INPUT

67

De kleur van elke flow menu is afhankelijk van de unieke

6

toegewezen persoonlijke

waarden die elke BoxComponent instance met zich mee draagt. De toegewezen kleur wordt ingesteld als basiskleur. Twee extra kleurencombinaties worden berekend die elk menuitem inkleuren wanneer men deze wenst te selecteren, en wanneer ze inactief zijn. Op die manier weet de gebruiker buiten de plaatsing van de cursor welke menuitem momenteel geactiveerd is.

6.3

Rechtstreekse Data Input

Naast het menu kunnen gebruikers ook rechtstreeks data ingeven wanneer nodig door middel van een virtueel toetsenbord en een handschrift bord. Op een tabletop interface kunnen gebruikers enkel interageren met de drukgevoelige platen zelf. Deze werken onder de motorkap op dezelfde manier als de muis. Bij het importeren of exporteren van het huidig werkblad dient iemand een bestandsnaam in te geven. Hoe kan men eenvoudig tekst en cijfer input voorzien zonder het klassiek toetsenbord? Dit probleem kan op twee verschillende manieren worden aangepakt.

6.3.1

Het Virtueel Toetsenbord

De eerste logische oplossing is het voorzien van een Virtueel toetsenbord dat direct op het actief venster zelf geprojecteerd wordt. Gebruikers kunnen zo indirect toch toetsen activeren en op deze manier tekst vormen. Het gebruikte virtueel toetsenbord werd ontwikkeld als onderdeel van de master Human Computer Interaction stage [19]. Het virtueel toetsenbord is een eigen UI component genaamd TouchControl. Om consistentie met andere componenten in de applicatie te behouden, werd dit component ook onderhevig gemaakt aan een bepaald aantal parameters. Het virtueel toetsenbord bevat de volgende features: • Toetsen worden opgelicht wanneer men er op drukt. Dit werkt positief voor gebruikers als visuele feedback. 6

RGB waarden zijn random toegekend van 0 tot 255, dit is zo goed als uniek.



68

• Zowel “querty” als “azerty” mode is aanwezig. Shift, Shift lock en andere functie toetsen zijn ook aanwezig. • Mogelijkheid tot roteren van het toetsenbord door middel van gestures. Dit wordt gerealiseerd door naar boven en beneden te slepen op de toetsen bord handles Dit rotatie systeem werkt op exact dezelfde manier als een BoxComponent vanuit hoofdstuk 5.2.2, aangezien het toetsenbord UI component ook afgeleid is van RotatableControl. Zie figuur 6.7. • Mogelijkheid tot vergroten en verkleinen van het toetsenbord door middel van gestures! Dit wordt gerealiseerd door naar links en rechts te slepen op de toetsen bord handles.

Figuur 6.3: Het virtueel toetsenbord, 180 graden geroteerd.

TouchControl werkt op dezelfde wijze als een SdgUserControl en maakt gebruik van het SDG Toolkit om de muis events verder te verwerken. Het toetsenbord kan ook eenvoudig verplaatst worden door middel van het “PickBox” metafoor zoals besproken in hoofdstuk 5.4.

6.3.2

Het handschrift Bord

Een tweede oplossing is het voorzien van een handschrift bord [19] dat gestures converteert naar letters en cijfers. Dit TouchDraw SdgUserControl component beschikt over dezelfde features als het virtueel toetsenbord. In deze klasse zit een aparte DrawLib recognizer klasse die alle coördinaten behandelt en een restultaat terug geeft. Het roteren gebeurt impliciet: de control zelf wordt niet mee geroteerd, in tegenstelling tot het toetsenbord. Natuurlijke Interactie Technieken op Tabletop Interfaces


69

Deze letters worden correct ge¨ınterpreteerd wanneer men “ondersteboven” letters vormt en het bord 180 graden geroteerd werd. Alle coördinaten worden door middel van een rotatie parameter aangepast en daarna pas doorgegeven aan andere klassen. Door de manier van interpreteren van deze aparte gesture recognizer, is het helaas niet mogelijk om tegelijk cijfers of letters in te geven. Er treden verschillende conflicten op: een “o” en een “0”, een “l” en een “1”, . . .

Figuur 6.4: Gesture vormen om cijfers of letters te vormen, afgeleid van Palm Graffiti [21].

Handschrift Herkenningsprincipe De basis werkwijze van de recognizer werd afgeleid van de Palm [21, 20] devices. Het systeem werkt als volgt: 1. Vang coördinaten op die door de gebruiker gegenereerd worden. 2. Verwerk de input gegevens verder in twee delen: (a) Voer de rotatie bewerkingen uit indien de rotatie factor aangepast werd (b) Normaliseer de coördinaten, zodat alle gegevens even groot of klein zijn. 3. Dankzij de normalisatie kunnen alle (x, y) koppels in een 3x3 rooster geplaatst worden, zoals in figuur 6.5. Hoe meer coördinaten ontvangen worden, hoe meer er in het rooster verschijnen. Verbindt alle gegevens en maak een grote vorm binnen dat rooster. 4. Controleer afhankelijk van een aantal set waarden met welke vorm dit symbool overeen komt. Het aantal mogelijke symbolen wordt afgebeeld in figuur 6.4.


6.4. TRANSFORMATIES VAN DE PERSOONLIJKE VIEWPORTS

70

Figuur 6.5: Het vormen van een “N” opgedeeld in een 3x3 rooster.

Afhankelijk van het type symbolen dat momenteel getekend wordt (cijfers of letters), wordt er met een ander set van waarden vergeleken. 5. Los enige ambigu¨ıteiten op en stuur het resultaat door. Gebruikers die moeite hebben met de handschrift herkenning kunnen zeer eenvoudig terug schakelen naar het virtueel toetsenbord, en vice versa.

6.4 6.4.1

Transformaties van de persoonlijke Viewports De “Slingshot” metafoor

Zoals reeds aangehaald, kan het voorkomen dat enkele hoeken van de tabletop tafel niet toegankelijk zijn voor bepaalde gebruikers. Wanneer zij hun territorium willen verplaatsen, zal dit in twee delen moeten gebeuren. Gebruikers kunnen opstaan en langs de vergadertafel lopen om zo delen door te geven, of aan andere gebruikers vragen hun deel door ge schuiven. Dit is echter vervelend en kan op een veel eenvoudigere manier gebeuren. Een “slingshot” [3] metafoor maakt het mogelijk om User Interface elementen weg te schieten naar bepaalde uithoeken van het werkblad. Hoe verder men weg beweegt van het bronobject, hoe verder het uiteindelijke doelobject zal geplaatst worden. Een katapult werkt ook zo: hoe meer men de elastiek opspant, hoe verder men schiet.



71

Figuur 6.6 beeldt dit proces af. Het zwart puntje representeert de beginpositie van de cursor voor de MouseDown event. De pijl duidt de richting aan waarin de persoon sleept. De cutout bovenaan blijft staan maar er wordt een rechthoekig element gevisualiseerd dat de uiteindelijke doelpositie verduidelijkt. Om de gebruiker niet te verwarren worden twee lijnen getekend die beide objecten met elkaar verbinden. Deze lijnen stellen de elastieken van de katapult voor. Het origineel object (in dit geval de persoonlijke cutout) wordt niet direct verplaatst. Er wordt eerst een dummy object aangemaakt om aan te geven waar de viewport zal landen wanneer de gebruiker de cursor los laat en de katapult dus laat schieten. Het is ook mogelijk om heel precieze plaatsen aan te geven door slechts miniem te bewegen rond het origineel object. Hoe verder men weg gaat, hoe minder accuraat maar hoe groter de afstand. Op deze manier vallen alle niet toegankelijke plaatsen toch binnen het bereikbaar gebied.

Figuur 6.6: De Slingshot metafoor: de gebruiker sleept naar linksboven.

Deze manier om te interageren met het systeem werd reeds uitgebreid onderzocht door verschillende onderzoekscentra [2]. Door gebruik te maken van een reeks slimme technieken en fysische krachten zoals in de échte wereld kunnen gebruikers objecten zeer eenvoudig manipuleren. Deze interactie manier wordt vaak “flicking” genoemd.



6.4.2

72

De “Sleep” beweging

Het verplaatsen van de viewports of de cutouts kan op verschillende manieren gebeuren. De standaard sleep beweging om een element op een formulier te verplaatsten werkt hier ook, nadat die optie geselecteerd werd in het flow menu. De slingshot metafoor is de standaard translatie wijze, omdat het meer voorkomt dat gebruikers hun territorium willen verplaatsen naar niet toegankelijke gebieden. Het slepen van een component wordt met behulp van de PickBox klasse gerealiseerd, die alle extra sleep events zelfstandig verwerkt. Figuur 5.8 in hoofdstuk 5.4 beeldt een label af dat verplaatst kan worden met behulp van een normale sleep beweging. Om de gebruiker van extra visuele feedback te voorzien werden zes punten aan de kant van het component voorzien van handles.

6.4.3

Viewports roteren

Viewports kunnen ook geroteerd worden afhankelijk van de gebruikers positie, zoals aangehaald in hoofdstuk 5.2.2. De RotatableControl basisklasse implementeert een poolcoördinaten systeem zodat elk afgeleid component eenvoudig 360◦ geroteerd kan worden. Wanneer de rotatie status actief is, kan men een aantal graden roteren door simpelweg open neer te bewegen. Figuur 6.7 beeldt dit systeem af. Het naar boven bewegen van de cursor resulteert in een rotatie naar rechts 7 . Naar beneden resulteert in een rotatie naar links. Het spreekt voor zich dat het tijdelijk onmogelijk is om gestures te vormen tijdens het roteren. De rotatie waarde RotationAngle dient eerst omgezet te worden naar radialen: θ=−

r∗π 180

Waarbij r de rotatie waarde in graden voorstelt. Deze θ waarde kan nu verder worden gebruikt. Alle opgevangen coördinaten worden via de volgende formule geroteerd:   R = P cos(θ) − P sin(θ) x x y R= Ry = Py cos(θ) + Px sin(θ) 7

Negatieve graden onder de X as Natuurlijke Interactie Technieken op Tabletop Interfaces


73

Waarbij Px en Py de originele punten coördinaten voorstellen en Rx , Ry de geroteerde. Wanneer men nu de viewport wenst te roteren, dient ook de grootte van het component aangepast te worden om alles correct te kunnen omvatten. Dit veroorzaakt veel problemen in C# aangezien het punt P (0, 0) de linkerbovenhoek van het scherm voorstelt.

Figuur 6.7: Het roteren van de Viewport via sleep bewegingen.

Om dit probleem te kunnen omzeilen, dienen we eerst alle controlepunten (linksboven, rechtsboven, linksbeneden, rechtsbeneden) van de Control te roteren via de bovenstaande formule. Daarna berekent het systeem de bounding volume van de resultaten. Indien dit punt de nieuwe grootte wordt, vallen sommige delen buiten het UI component! Stel dat een punt P (0, 10) geroteerd dient te worden met 20◦ via het C# assenstelsel. De x coördinaat wordt negatief en verdwijnt aan de linkerkant van de Y as! Dus buiten de grootste x en y waarden te zoeken om als nieuw volume te nemen, dienen de absolute waarden van de kleinste waarden daarbij opgeteld te worden. Figuur 6.7 beeldt het assenstelsel af. Het punt linksonder aan de viewport valt weg bij het tekenen indien de negatieve punten niet meegeteld worden. Om daarna de event coördinaten correct te kunnen verwerken, dienen deze getransleerd te worden met de gevonden “Offset”:


6.5. INTERAGEREN MET GESTURES

74

Matrix X = new Matrix(); X.RotateAt(RotationAngle, Center); X.Translate(OffsetRotatingPoint.X, OffsetRotatingPoint.Y); PaintEventArgs.Graphics.Transform = X;

Figuur 6.8: Het roteren van een Graphics object.

De laatste stap die in rekening gebracht dient te worden, is het ongewenst verschuiven van de viewport. Zodra de grootte verandert en de locatie identiek blijft, verplaatst het component zich ongewild. Des te groter de rotatie waarde, des te groter de sprong. Daarom wordt het oude middelpunt OldCenter bijgehouden. Het nieuwe viewport centrum wordt dan na de vorige stappen verplaatst naar het oude.

6.5 6.5.1

Interageren met Gestures Het selecteren en verplaatsen van gestures

Herkende gestures door de CALI gesture recognizer kunnen ook verplaatst worden. Een “selectie” optie dient activeerd te worden om het eigenlijke herkenningsproces over te slaan en gestures te selecteren. Er wordt nog altijd een scribble opgebouwd, bestaande uit een of meerdere strokes. In plaats van deze scribble door te geven aan de recognizer, hebben we nu enkel de bounding volume nodig om te bepalen welke gesture geselecteerd dient te worden. Dit gebeurt op dezelfde manier als het verwijderen van gestures met het CICross commando.

Figuur 6.9: Het selecteren van een gesture.


6.5. INTERAGEREN MET GESTURES

75

Figuur 6.9 beeldt het selecteringsproces af. De dikke inkt duidt de scribble aan die de selectie voorstelt. Het is niet nodig om een complete cirkel te vormen, een minimale stroke die intersecteert met de gewenste vorm volstaat! Daarna wordt er een “dummy” TextBox UI Control aangemaakt. Gebruikers kunnen deze verplaatsen door te slepen, zoals het slepen van de viewports in hoofdstuk 6.4.2. Zodra de cursor opgeheven wordt, verplaatst het symbool zich naar de eindpositie van deze dummy. Het verschil tussen de begin- en eindpositie wordt meegegeven aan de scribble die alle punten herpositioneerd door middel van de repositionStrokes() methode. Om de gebruiker duidelijk te maken dat men een bepaald symbool aan het verplaatsen is, wordt er op deze dummy het te verplaasen symbool afgebeeld via drawRelativeTo().

6.5.2

De juiste Gestures identificeren

In hoofdstuk 4.4.3 werd reeds vermeld dat de CALI gesture recognizer eventueel meer dan een symbool herkent dan nodig is. In dat geval wordt een ArrayList van gestures geretourneerd, waarin men een specifieke keuze zal moeten maken. Indien één van de herkende symbolen een commando is, krijgt dit commando voorrang! De taak gekoppeld aan dit commando wordt uitgevoerd en de rest van de herkende symbolen wordt genegeerd. Wanneer meerdere CIShape varianten worden herkend, dient de gebruiker die de schets gemaakt heeft een keuze te maken tussen deze vormen. Het zou immers kunnen dat de persoon geen exacte vorm heeft geschetst, of dat deze vorm niet duidelijk genoeg verschilt van andere herkenbare vormen. Een formulier verschijnt aan de cursor van deze gebruiker zodra de gesture recognizer een lijst retourneert. Hierop staan alle mogelijke keuzes afgebeeld, zoals in figuur 6.10. Door te klikken op één van de voorgestelde vormen bevestigt men de geschetste vorm en verdwijnt het formulier. Om extra visuele feedback te bieden, worden de vormen gemarkeerd zodra de cursor er over gaat. Een label met de specifieke vorm naam wordt dan ook zichtbaar gemaakt. Deze label wordt geroteerd afgedrukt op het actief icoon!


6.6. CONCLUSIE

76

Figuur 6.10: Meerdere vormen werden herkend door CALI.

De ruwe vorm onderaan in figuur 6.10 representeert de originele scribble die de gebruiker vormt door de cursor te bewegen. Men vraagt de gebruiker een keuze te maken omdat deze vorm classificeerbaar is onder verschillende CIShape afgeleiden. In dit geval werden zowel een diamant, cirkel en ellips vorm herkend. De figuur representeert een standaard viewport waar de rotatie waarde op 0 staat. Indien deze verschilt van de standaard waarde, wordt de label ook geroteerd met dezelfde waarde als het flow menu en de viewport zelf.

6.6

Conclusie

Uit de gebruikerstest van hoofdstuk 7 blijkt dat het gebruik van gestures en andere natuurlijke interactie technieken zijn zeer geschikt om collaboratieve schetsen verder te ondersteunen. De mogelijkheid om reeds geschetste delen te kunnen selecteren met een cirkel beweging vertraagt de gebruiker in geen enkele manier. Deze taak via (sub)menu items tot stand brengen tijdens het schetsen kan dan weer wel voor de nodige verwarring zorgen. Het speciaal ontwikkeld flow menu minimaliseert dit probleem op een aantal verschillende manieren. Het menu is direct oproepbaar binnen de persoonlijke territoria’s van gebruikers, en het werkt veel vlotter op een tabletop interface dan een klassieke Popup menu. Bovendien biedt het flow menu extra visuele feedback met behulp van icons die in het middelpunt van het menu verschijnen.


Deel III Conclusie

77

HOOFDSTUK

7

Testplan Analyse

Er werd een kort testplan opgesteld om de ge¨ımplementeerde natuurlijke interactie technieken te kunnen laten vergelijken met hun klassieke User Interface tegenhanger. De verschillende opdrachten en ingevulde vragen zelf zijn terug te vinden in appendix B. Een select aantal mede studenten vulden deze vragenlijst in na het uitvoeren van alle individuele en collaboratieve opdrachten. Er werd nauwgelet naagegaan of een aantal interactieve en collaboratieve taken tot een goed einde werden gebracht. Deelnemers die nog geen ervaring hebben met de tabletop opstelling leerden op een eenvoudige wijze te interageren met de drukgevoelige platen via een simpel tekenprogramma. Na enkele minuten tekenen werden de eigenlijke opdrachten uitgevoerd. Het is belangrijk om op te merken dat dit tekenprogramma geen enkele natuurlijke interactie techniek bevat, buiten het tekenen zelf.

7.1

Vragenlijst Resultaten

Antwoorden A tot E, van links naar rechts: 2 Zeer Akkoord

2 Akkoord 2 Soms 2 Niet Akkoord 2 Zeker Niet 78

7.1. VRAGENLIJST RESULTATEN

Vraag Nr.

79

Individueel Deel

Collaboratief Deel

A× B× C× D× E× A× B× C× D× E× {1}

0

4

{2}

7.1.1

1

0

0

n.v.t.

0

3

2

0

0

0

3

2

0

0

{3}

0

4

1

0

0

{4}

0

0

2

3

0

0

3

2

0

0

{5}

1

4

0

0

0

0

0

2

1

2

{6}

1

1

3

0

0

0

4

1

0

0

{7}

0

4

1

0

0

0

2

2

1

0

{8}

5

0

0

0

0

n.v.t.

n.v.t.

Analyse Individueel Deel

80% van de testpersonen hadden een goede eerste indruk van de applicatie. Als verklaring gaf men dat het idee om in een vergadering een gewone tafel te vervangen door een digitale versie een zeer goed concept is. Veel nadelen van het werken op papier kunnen hier immers mee vermeden worden. De geteste interactie technieken werken allen wel degelijk, maar bevatten een aantal grote beperkingen. Het grootste nadeel van het werken op de tabletop interface is de beperking tot slechts één drukgevoelige plaat per persoon. Die plaat kan ook slechts een drukpunt tegelijk opvangen, en de randen waarmee de platen met elkaar verbonden zijn werken uiterst gevoelig. Dit alles heeft als gevolg dat men tamelijk traag dient te bewegen om geen ongewenst resultaat te bekomen. Schetsen op papier gebeurt dan weer relatief snel. Dit is een grote hardwarematige beperking! Zie de tabletop opstelling in hoofdstuk 4.2. Wanneer de technologie het toestaat om met tien vingers tegelijk te interageren èn de kost is haalbaar [5], zal dit systeem veel aantrekkelijker klinken. De meeste deelnemers vonden het viewports concept besproken in hoofdstuk 5.2 eenvoudig te gebruiken. Zonder extra uitleg vergt het wat oefening om precies te weten wat er geselecteerd dient te worden op het centraal schema om een nieuwe viewport aan te maken. De ontwikkelde applicatie zelf bevat ook nog geen gebruiksvriendelijke hulp functie. Natuurlijke Interactie Technieken op Tabletop Interfaces

7.1. VRAGENLIJST RESULTATEN

80

Viewports verplaatsen via het slingshot systeem ging minder vlot dan verwacht. Zodra men aan de viewport titelbalk sleept, verwacht men dat deze control verplaatst wordt op de “normale” manier, zoals in een standaard Desktop Envoirnment. Naar onder bewegen om de viewport naar boven weg te doen schieten werkt dan zeer verwarrend. Na enkele minuten besloten enkele deelnemers dat het systeem wel handig is om lange afstanden te overbruggen, in tegenstelling tot het gewoon slepen van de control. Daarom dat beide interactie technieken aanwezig zijn, zodat de gebruiker zelf een keuze kan maken tussen een van beide technieken. Het flow menu ontving over het algemeen positieve commentaar, vooral omdat het toegankelijk is binnen ieders persoonlijk territorium. Een standaard DE applicatie bevat meestal een menu bovenaan links. Het flow menu wordt ook mee geroteerd en kan voor elke persoon verschillend zijn, naargelang de rechten. De iconen en de menu item tekst waren zeer duidelijk en bevatten genoeg visuele feedback om de taak succesvol te identificeren. Het schetsen van de verschillende vormen en het herkenningsproces van de CALI gesture recognizer verliepen zeer vlot. Zo goed als alle vormen worden herkend door CALI, zonder enige grote problemen. Alle testpersonen waren het ermee eens dat het gesture keuzescherm zeer duidelijk gestructureerd is. Om een annotatie te maken dient men eerst op het pen icoontje te drukken op de titelbalk. De taken gekoppeld aan deze knoppen waren niet voor alle personen even duidelijk. Dit komt vooral omdat de titelbalk zelf voor velen net iets te klein is (standaard 16x16 pixel icons). De vinger bedekt de knop volledig wanneer men deze probeert te activeren.

7.1.2

Analyse Collaboratief Deel

Bij het samen schetsen wanneer meerdere viewports actief zijn kwamen de hardwarematige beperkingen weer boven drijven. Het is namelijk zo dat alle punten tijdens het schetsen doorgedelegeerd worden naar alle andere active viewports. Voordat dit kan gebeuren, moeten alle cursor coördinaten geconverteerd worden van absoluut naar relatief. Deze processen samen met de beperkte toegelaten reactie snelheid van de drukgevoelige platen gaven niet altijd een positieve indruk. Deelnemers gaven als commentaar dat de cursor snelle bewegingen soms niet kan volgen. Bij het hercalibreren van de tabletop interface vlotte deze test een beetje beter. Het is een Natuurlijke Interactie Technieken op Tabletop Interfaces

7.2. CONCLUSIE

81

spijtige zaak dat de CTC hardware drivers geen transparante oplossing biedt om alle platen apart aan te spreken. Het gebruik van het SDG Toolkit zou onnodig geweest zijn moest dit wel het geval zijn, wat het hele omvormingsproces verder versnelt. Maar weinig testpersonen zouden in de toekomst graag af en toe de tabletop opstelling gebruiken tijdens vergaderingen in plaats van het schetsen op papier. Hoofdzakelijk komt dit door de relatieve trage werking van het geheel. De applicatie en het gesture herkenningsproces zelf werden wel zeer positief onthaald. Het handschrift bord om een viewport zelf te roteren werkte zeer goed. Gebruikers werden verrast door de mogelijkheid om zelf het aantal graden in te geven, naast het open af bewegen van de viewport en de “set” aantal waarden aanwezig in het flow menu. Het gebruik van het virtueel toetsenbord werd ook goed bevonden, omdat het indrukken van toetsen dan weer wel snel verwerkt kan worden. Er komen immers geen grote hoeveelheden MouseMove events aan de pas!

7.2

Conclusie

Het vormen van schetsen is een proces dat op papier relatief snel kan uitgevoerd worden. Schema’s worden zo snel gevormd als men zelf aangeeft. Bij veel tabletop interfaces geldt deze uitspraak niet. Het idee om collaboratief schetsen te digitaliseren via de vergadertafel valt niet onmiddelijk bij iedereen in de smaak omdat de test opstelling enkele grote hardwarematige beperkingen oplegt. Uit het testplan bleek dat de integratie van alle natuurlijke interactie technieken goed samen vallen. Het gebruik van gestures om diezelfde gestures te selecteren en verplaatsen werkt zeer efficiënt. Voor de meeste testpersonen bood het flow menu meer dan voldoende ondersteuning om de verschillende taken tot een goed einde te brengen. Enkele minder bekende interactie technieken werken de eerste keer verwarrend en onduidelijk, omdat men er zich niet direct aan verwacht. Digitale tafels zijn nog tamelijk experimenteel en duur. Verplaatsen via de “slingshot” metafoor ging na een aantal pogingen wel veel vlotter. Daarom is het belangrijk om de klassieke interactie manier optie te voorzien die de gebruikers gewoon zijn toe te passen. Het roteren van een viewport kan daarom op drie verschillende manieren gebeuren. Natuurlijke Interactie Technieken op Tabletop Interfaces

HOOFDSTUK

8

Algemeen Besluit

Veel onderzochte natuurlijke interactie technieken zijn toepasbaar voor een zeer specifiek domein. Andere concepten integreren veel eenvoudiger met elkaar. Het is bijvoorbeeld een niet meer dan logische stap om bij het ontwerpen van schetsen ook het gebruik van gestures toe te staan, om deze bijvoorbeeld te kunnen selecteren en verplaatsen. De gebruikerstest in hoofdstuk 7 wijst uit dat 4 van de 5 personen dit zeer intu¨ıtief vinden. Deze ondersteunende interactieve manieren zorgen ervoor dat gebruikers hun taken op een eenvoudige wijze kunnen uitvoeren zonder zich gehinderd te voelen door de ontworpen User Interface van de applicatie. Deze deelnemers zijn immers gewend om zonder de klassieke User Interface widgets te werken. Het is echter belangrijk om op te merken dat er verwarring kan ontstaan tijdens het schetsen zelf. Staat het gevormde symbool voor een specifieke actie, of kan men gewoon verder schetsen en dit symbool aan het globaal schema toevoegen? Om dit probleem te omzeilen werd extra visuele feedback naar de gebruiker toe voorzien in de vorm van de al dan niet actieve titelbalk knoppen in hoofdstuk 5.2.1. Zeer specifieke interactie technieken werken in het begin ook verwarrend voor de gebruikers. De beste optie is het voorzien van een alternatief zodat men een keuze kan maken

82

83

(a) Het flow menu op de Tabletop

(b) Vormen tekenen op de Tabletop

Figuur 8.1: Foto’s genomen tijdens de testplan opdrachten

tussen nieuwe en vertrouwde interactie techniek. De toevoeging van een persoonlijke rotatie afhankelijke Pie Menu zoals in hoofdstuk 6.2 op een digitale tafel werkt volgens het testplan bijvoorbeeld zeer goed. Via dit menu kunnen gebruikers afwisselen tussen het tekenen van commando’s en het vormen van gestures die een deel van het globaal schema uitmaken. Het menu staat ook toe om op een eenvoudige wijze acties uitvoeren zonder te stoten op enige vertraging door het overschakelen van natuurlijke interactie naar klassieke interactie. Alle waargenomen vertragingen werken immers negatief: het schetsen verloopt in het beste geval zo snel als op papier. Zoals eerder aangehaald vereist het collaboratief ontwerpen van een sketch tamelijk veel ruimte. Het gebruik van workflows om componenten te beheren is op deze manier niet aan te raden vanwege het plaatsgebrek. Iedere deelnemer moet immers over een persoonlijk deel van de globale sketch kunnen beschikken om niet op elkaars beurt te moeten wachten. Dit wordt met behulp van het onderzochte cutouts systeem gerealiseerd. Gebruikers kunnen met deze cutouts over de algemene sketch pannen, en hun eigen viewport “personaliseren” (vergroten, roteren, schaleren, . . . ) Deze cutouts functioneren ook als persoonlijke territoria. Alle territoria kunnen ook dynamisch verplaatst worden wanneer een nieuwe gebruiker wenst deel te nemen, of wanneer gebruikers wisselen van plaats.


84 Elk flow menu is gekoppeld is aan één persoonlijke viewport, zodat het menu ook gepersonaliseerd kan worden per gebruiker. Deelnemers krijgen een aantal rechten toegekend, zoals besproken in hoofdstuk 5.3. Deze rechten worden doorgevoerd naar het menu en de viewport zelf zodat er extra opties verschijnen zoals het opslaan van de huidige sessie. Personen die over minder rechten beschikken kunnen ook niet schetsen over anderen hun schema’s. Het gerealiseerde viewport systeem kan ook toegepast worden in andere domeinen, zoals het samen oplossen van een puzzel. Door alle verschillende concepten en technieken te integreren in het cutout systeem verkrijgt men een zeer robuust en eenvoudig te gebruiken collaboratieve applicatie. Helaas zijn de meeste tabletop systemen nog uiterst experimenteel. In de toekomst zullen oude vergadertafels zeker vervangen kunnen worden door nieuwe digitale tafels zodra de multitouch [5] systemen betaalbaar worden. De gebruikerstest wijst uit dat de grootste hinderpaal de snelheid is van de huidige tabletop opstelling uit hoofdstuk 4.2. Een schets of een mock-up van een architectuur wordt op papier immers zeer snel gerealiseerd.


HOOFDSTUK

9

Toekomstig Werk

Een aantal veel gebruikte technieken zouden verder afgestemd kunnen worden in de toekomst om een completer pakket te bekomen. Deze concepten zijn niet verder ge¨ımplementeerd omdat veel delen ver buiten het bereik van dit thesisonderwerp vallen. Enkele voorbeelden: 1. Er kan een extentie ontwikkeld worden voor de gebruikte gesture recognizer library, zodat deze meer concrete User Interface componenten herkent in plaats van algemene goniometrische vormen. Momenteel worden enkel basisvormen herkend (zie hoofdstuk 4.4.2). JavaSketchIt [16] maakt gebruik van dezelfde gesture recognizer, en breidt deze gedeeltelijk uit. Figuur 1.3 beeldt dit af. Een Image stelt een cirkel ge¨ıntersecteerd met driehoek voor, een ComboBox stelt een rechthoek met driehoek aan de kant voor, enzovoort . . . 2. Het importeren en exporteren van de sessie is momenteel reeds mogelijk. Wat echter nog bijkomend toegepast zou kunnen worden, is het exporteren koppelen aan het genereren van algemene User Interface code, afhankelijk van User Interface Toolkit. De gesketchte User Interface wordt op deze manier reeds omgezet naar beschrijvende code. Figuur 9.1 beeldt dit proces in stappen af:

85

86 (a) Gebruikers werken samen aan een schets via het systeem besproken in deze thesis. (b) De afgewerkte schets wordt geconverteerd naar uitvoerbare design code (c) Het eindproduct is een formulier met UI componenten geplaatst zoals aangegeven. Dit omzetten naar code valt echter buiten het doel van deze thesis. 3. Collaboratief sketchen wordt gerealiseerd door middel van het cutout systeem. Deze cutouts zijn ook handig bij andere collaboratieve taken, zoals het maken van een puzzel of het opstellen van een agenda. Om deze cutouts ook toegankelijk te maken voor andere applicaties kan dit systeem veralgemeend worden via een aparte interface. Dankzij die interface worden cutouts heel eenvoudig bruikbaar in andere ontwikkelingsomgevingen.

Figuur 9.1: Van collaboratief sketchen naar afgewerkte User Interface.


BIJLAGE

A

Gebruikte Afkortingen

CALI

Calligraphic Library for Interfaces

COM

Component Object Model

CTC

ClearTek Capacitive

DE

Desktop Envoirnment

DLL

Dynamic Library Linking

EH

Event Handler

GC

Garbage Collector

HWND

Handle to A Window

MC++

Managed C++

SDGT

Single Display Groupware Toolkit

TW

TouchWare

UI

User Interface

UMC++

Unmanaged C++

USB

Universal Serial Bus

VS

Visual Studio

WIMP

Window Icon Mouse Pointer

87

BIJLAGE

B

Testplan Vragenlijst

B.1

Inleiding

Dit testplan werd opgesteld om enkele collabroatieve en interactieve taken op de tabletop interface te analyseren. Hierbij vragen wij u om een aantal opeenvolgende eenvoudige taken tot een goed einde te brengen. Daarna wordt even een vragenlijst ingevult om de applicatie en de ge¨ıntegreerde concepten te evalueren. Alle testen worden uitgevoerd op de digitale tafel, opgesteld in het Expertise Centrum voor Digitale Media (EDM 1 ). Deze tafel beschikt over vier drukgevoelige platen die elk apart één enkel drukpunt tegelijk kunnen verwerken. Er kan dus maximum met 4 personen per sessie gewerkt worden. Het principe is vrijwel identiek aan een standaard muis: klikken, slepen en loslaten wordt enkel uitgevoerd door middel van de vinger als cursor. Meer info over de test opstelling is terug te vinden in hoofdstuk 4.2.

B.1.1

De test opdeling

Om u even te laten wennen aan deze technologie, werd dit testplan in twee delen opgesplitst. In het eerste deel test u de digitale tafel zelf aan de hand van een simpel collaboratief 1

http://edm.uhasselt.be

88

89 tekenprogramma. Dit programma bevat geen specifieke User Interface componenten, het dient enkel als soort van tekenbord om kennis te maken met de tabletop opstelling. In het tweede deel test u de ontwikkelde applicatie en de verschillende gemplementeerde interactie technieken. Hierbij wordt een onderscheiding gemaakt tussen de individuele opdrachten, en de collaboratieve taken. Gelieve alles dus in chronologische volgorde af te werken!

B.1.2

Kennismaking met de Tabletop Interface

Probeer samen met enkele mede testers een eenvoudige schets te maken met het simpel tekenprogramma. Op deze manier leert u te interageren met de digitale tafel. Schakel na twee minuten testen over naar de tweede test fase.

B.2

Collaboratief schetsen: Opdrachten

Lees vooraf eerst de algemene introductie in hoofdstuk om een beeld te vormen van het doel van dit thesis onderwerp. Zodra het programma is opgestart, verschijnt er een scherm dat een leeg centraal schema als enkel component bevat. Hieruit dient u een deel te selecteren, dat uw relatieve kijk op het schema voorstelt. Alle acties op dit geselecteerd stuk worden doorgedelegeerd naar het centraal schema. De persoonlijke container, of “viewport”, kan gepersonaliseerd worden via het flow menu. (rotatie afhankelijkheid, positie, grootte, . . . ) Alle vragen mogen luidop beantwoord worden. Na de opdrachten dient er enkel een korte vragenlijst ingevuld te worden. Bij onduidelijkheden mag u gerust om verdere uitleg vragen.

B.2.1

Individueel Deel

1. Maak een eigen viewport deel aan. Versleep dit component naar u toe met behulp van de “slingshot” metafoor. Is dit verplaatsingsconcept duidelijk? Werkt het eenvoudiger dan de klassieke sleep beweging? 2. Roteer uw persoonlijke viewport naar wens door middel van de titelbalk knoppen. Zijn de verschillende iconen op de titelbalk duidelijk? Is er voldoende visuele feedback


90 aanwezig? Roteer de viewport via het flow menu. Is het schetsen van een cijfer een eenvoudige manier om gegevens in te geven? 3. Schets enkele eenvoudige vormen, zoals een driehoek, lijn of rechthoek. Werden alle vormen direct herkend door de recognizer? Is het viewport concept duidelijk? 4. Schets enkele moeilijkere vormen, zoals een cirkel of een ellips. 5. Maak enkele annotaties op het schema naast de vorige vormen. Kan u de link leggen tussen het annoteren op papier en op de tabletop interface? 6. Selecteer een gevormd symbool via de titelbalk knop. Verplaats deze vorm naar een andere locatie. Werkt het selecteren van gestures efficint? Is er voldoende feedback aanwezig? Gelieve de individuele vragenlijst in te vullen voor verder te gaan naar het volgende deel.

B.2.2

Collaboratief Deel

1. Maak met enkele personen om de beurt een viewport aan. Versleep indien gewenst naar een andere locatie. Is het duidelijk wat er gebeurt met het globaal schema met de creatie van meerdere viewports? 2. Zorg ervoor dat elke persoon op juist één drukgevoelige plaat werkt (hardwarematige restrictie). Werk enkele minuten samen aan het globale schema.

Wat gebeurt er

wanneer twee viewports elkaar overlappen? 3. Laat de eerste deelnemer zijn rechten afstaan via het flow menu aan een persoon naar keuze. Is het duidelijk aan wie de rechten afgestaan worden? 4. “Pan” om de beurt de viewport relatief ten opzichte van het globaal schema. Zijn de weergegeven veranderingen duidelijk? 5. Laat de nieuwe voorzitter de huidige sessie opslaan naar een bestandsnaam naar keuze. Voldoet het virtueel toetsenbord hiervoor? Gelieve de collaboratieve vragenlijst in te vullen. Natuurlijke Interactie Technieken op Tabletop Interfaces

91

B.3

Post-Test Vragenlijsten

Kruis aan wat het beste past. Alle antwoorden variëren van links (positief) tot rechts (negatief). Er zijn 5 verschillende keuzes aanwezig.

B.3.1

Individueel Deel

1. Wat is uw indruk van de applicatie over het algemeen? 2 Zeer Goed

2 Goed

2 Goed noch Slecht 2 Niet Goed 2 Slecht

2. Verklaar zeer kort het bovenstaande gegeven antwoord.

3. Is het viewport concept duidelijk en eenvoudig te gebruiken? 2 Zeer Akkoord

2 Akkoord 2 Soms 2 Niet Akkoord 2 Zeker Niet

4. Vond u het verplaatsen van de viewport door middel van de “slingshot” metafoor eenvoudig uit te voeren om lange afstanden te overbruggen? 2 Zeer Akkoord


5. Bood het flow menu genoeg ondersteuning om alle taken tot een goed einde te brengen, in vergelijking met de klassieke menu’s van test fase 1? 2 Zeer Akkoord


6. Is de functie van de titelbalk iconen duidelijk terug te vinden? 2 Zeer Akkoord


7. Verliep het selecteren van gestures en het maken van annotaties vlot? 2 Zeer Akkoord


8. Indien van toepassing: tijdens het schetsen van een cirkel kan de recognizer soms geen duidelijk verschil maken tussen cirkels en ellipsen. Is het gesture keuze scherm duidelijk? Natuurlijke Interactie Technieken op Tabletop Interfaces

92 2 Zeer Akkoord

B.3.2


Collaboratief Deel

1. Werkt het viewports concept goed met meerdere deelnemers? Neem plaats bepaling, rotatie waarden en gebruikersrechten in achting! 2 Zeer Akkoord


2. Verliep het samen werken aan de globale schets even vlot als samen een schets ontwerpen op papier? 2 Zeer Akkoord


3. Verklaar zeer kort het bovenstaande gegeven antwoord.

4. Bevat de applicatie voldoende feedback naar de gebruiker toe? (Denk aan de titelbalk, het menu, . . . ) 2 Zeer Akkoord


5. Zou u in het vervolg tijdens vergaderingen op een tabletop interface willen werken in plaats van op papier, wetende dat deze manier zowel vooren nadelen met zich meebrengt? (opslaan van de sessie, indelen van gebruikersrechten, . . . ) 2 Zeer Akkoord


6. Integreren de handschrift en virtueel toetsenbord interacties goed met de rest van de applicatie? 2 Zeer Akkoord


7. Vindt u het gebruik van alle geteste interactie technieken samen met gestures een geschikte manier om het collaboratief schetsen voldoende te ondersteunen?


93

B.3.3

Algemene feedback

Algemene commentaar en opmerkingen over het programma en enkele geteste interactie technieken kan u in de onderstaande voorziene kader plaatsen.

Hartelijk bedankt voor uw deelname aan deze korte gebruikerstest!


Bibliografie

[1] Stacey D. Scott, M. Sheelagh, T. Carpendale, and Kori M. Inkpen. Territoriality in collaborative tabletop workspaces. In CSCW ’04: Proceedings of the 2004 ACM conference on Computer supported cooperative work, pages 294–303, New York, NY, USA, 2004. ACM Press. [2] Miguel A. Nacenta, Dzmitry Aliakseyeu, Sriram Subramanian, and Carl Gutwin. A comparison of techniques for multi-display reaching. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 371–380, New York, NY, USA, 2005. ACM Press. [3] Adrian Reetz, Carl Gutwin, Tadeusz Stach, Miguel Nacenta, and Sriram Subramanian. Superflick: a natural and efficient technique for long-distance object placement on digital tables. In GI ’06: Proceedings of the 2006 conference on Graphics interface, pages 163–170, Toronto, Ont., Canada, Canada, 2006. Canadian Information Processing Society. [4] Russell Dyer. The gnome 2 desktop environment. Linux J., 2003(108):7, 2003. [5] Jefferson Y. Han. Low-cost multi-touch sensing through frustrated total internal reflection. In UIST ’05: Proceedings of the 18th annual ACM symposium on User interface software and technology, pages 115–118, New York, NY, USA, 2005. ACM Press.

94

95 [6] Manuela Waldner, J. Hauber, J¨ urgen Zauner, Michael Haller, and Mark Billinghurst. Tangible tiles: design and evaluation of a tangible user interface in a collaborative tabletop setup. In OZCHI ’06: Proceedings of the 20th conference of the computerhuman interaction special interest group (CHISIG) of Australia on Computer-human interaction: design: activities, artefacts and environments, pages 151–158, New York, NY, USA, 2006. ACM Press. [7] M. Fonseca, C. Pimentel, and J. Jorge. Cali- an online scribble recognizer for calligraphic interfaces, 2002. [8] Tommi Mikkonen. Formalizing design patterns. In ICSE ’98: Proceedings of the 20th international conference on Software engineering, pages 115–124, Washington, DC, USA, 1998. IEEE Computer Society. [9] Stacey D. Scott. Territory-based interaction techniques for tabletop collaboration, November 2003. [10] Uta Hinrichs, Sheelagh Carpendale, and Stacey D. Scott. Evaluating the effects of fluid interface components on tabletop collaboration. In AVI ’06: Proceedings of the working conference on Advanced visual interfaces, pages 27–34, New York, NY, USA, 2006. ACM Press. [11] Uta Hinrichs, Sheelagh Carpendale, and Stacey D. Scott. Interface currents: supporting fluent face-to-face collaboration. In SIGGRAPH ’05: ACM SIGGRAPH 2005 Sketches, page 142, New York, NY, USA, 2005. ACM Press. [12] Meredith Ringel Morris, Anthony Cassanego, Andreas Paepcke, Terry Winograd, Ann Marie Piper, and Anqi Huang. Mediating group dynamics through tabletop interface design. IEEE Comput. Graph. Appl., 26(5):65–73, 2006. [13] David Pinelle, Tadeusz Stach, Jeff Dyck, and Carl Gutwin. Cutouts: Flexible workspace management for tabletop groupware. http://www.egr.unlv.edu/~pinelle/ pdf/cutouts-video-abstract.pdf, 2006. [14] Tevfik Metin Sezgin, Thomas Stahovich, and Randall Davis. Sketch based interfaces: early processing for sketch understanding. In PUI ’01: Proceedings of the 2001


96 workshop on Perceptive user interfaces, pages 1–8, New York, NY, USA, 2001. ACM Press. [15] Adrien Coyette, Stèphane Faulkner, Manuel Kolp, Quentin Limbourg, and Jean Vanderdonckt. Sketchixml: towards a multi-agent design tool for sketching user interfaces based on usixml. In TAMODIA ’04: Proceedings of the 3rd annual conference on Task models and diagrams, pages 75–82, New York, NY, USA, 2004. ACM Press. [16] A. Caetano, N. Goulart, M. Fonseca, and J. Jorge. Javasketchit: Issues in sketching the look of user interfaces, 2002. [17] Christine Alvarado. A natural sketching environmant: Bringing the computer into early stages of mechanical design. Master’s thesis, MIT, 2000. [18] Ashley George Taylor. ces.

Window,

icon,

menu,

pointing device interfa-

http://www-static.cc.gatech.edu/classes/cs6751_97_winter/Topics/

dialog-wimp/, 1997. [19] Wouter Groeneveld. Muti-user text input via een tabletop interface. http://www. jefklak.com/edm/stage.pdf, 2006. [20] Julien Couvreur. Pen stroke recognition with tabled pcs on .net. http://blog. monstuff.com/archives/000012.html, 2003. [21] Palm. Ways to enter data into a palm device: Graffiti writing software. http: //www.palm.com/us/products/input/, 2007. [22] Microsoft. Visual basic developer centre. http://msdn2.microsoft.com/en-us/ vbasic/default.aspx, 2007. [23] Microsoft.

Microsoft windows xp service pack 2.

http://www.microsoft.com/

windows/products/windowsxp/default.mspx, 2005. [24] Ecma International.

C# language specification 3th edition.

http://www.

ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf, 2005. [25] Microsoft. Microsoft .net framework developer center: .net compact framework. http: //msdn.microsoft.com/mobility/netcf/, 2007. Natuurlijke Interactie Technieken op Tabletop Interfaces

97 [26] Edward Tse and Saul Greenberg.

Rapidly prototyping single display groupware

through the sdgtoolkit. In AUIC ’04: Proceedings of the fifth conference on Australasian user interface, pages 101–110, Darlinghurst, Australia, Australia, 2004. Australian Computer Society, Inc. [27] S. Greenberg and Tse. E. Sdgtoolkit in action. In Video Proceedings of ACM CSCW’06 Conference on Computer Supported Cooperative Work. ACM Press, November 2006. [28] Chia Shen, Frédéric D. Vernier, Clifton Forlines, and Meredith Ringel. Diamondspin: an extensible toolkit for around-the-table interaction. In CHI ’04: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 167–174, New York, NY, USA, 2004. ACM Press. [29] Stephen R.G. Fraser. Pro Managed C++ and .NET 2.0 Development with Visual Studio .NET 2005: A Problem-Solution Approach. Apress, Berkely, CA, USA, 2005. [30] 3M Touch Systems. vices.

Legacy cleartek capacitive touchware tabletop de-

http://solutions.3m.com/wps/portal/3M/en_US/3MTouchSystems/TS/

TechnicalInformation/TouchDrivers/#LegacyTouch, 2002. [31] Tobias Isenberg, Petra Neumann, Sheelagh Carpendale, Simon Nix, and Saul Greenberg. Interactive annotations on large, high-resolution information displays. http: //pages.cpsc.ucalgary.ca/~isenberg/papers/Isenberg_2006_IAL.pdf, november 2006. [32] Elizabeth D. Mynatt, Takeo Igarashi, W. Keith Edwards, and Anthony LaMarca. Flatland: new dimensions in office whiteboards. In CHI ’99: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 346–353, New York, NY, USA, 1999. ACM Press. [33] Bohyun Cho, Namgyu Kim, and Gerard J. Kim. Interaction for tabletop computing environment: an analysis and implementation. In MUM ’05: Proceedings of the 4th international conference on Mobile and ubiquitous multimedia, pages 11–18, New York, NY, USA, 2005. ACM Press.


98 [34] Thomas F. Stahovich Levent Burak Kara, Leslie Gennari. A sketch-based interface for the design and analysis of simple vibratory mechanical systems. http://www.andrew. cmu.edu/user/lkara/publications/kara_detc2004_57529.pdf, october 2004. [35] Geoffrey G. Towell and Jude W. Shavlik. Knowledge-based artificial neural networks. Artificial Intelligence, 70(1-2):119–165, 1994. [36] Sebastian L¨ uhr, Geoff West, and Svetha Venkatesh. Recognition of emergent human behaviour in a smart home: A data mining approach. Pervasive Mob. Comput., 3(2):95–116, 2007. [37] Francois Guimbretière and Terry Winograd. Flowmenu: combining command, text, and data entry. In UIST ’00: Proceedings of the 13th annual ACM symposium on User interface software and technology, pages 213–216, New York, NY, USA, 2000. ACM Press.


Auteursrechterlijke overeenkomst Opdat de Universiteit Hasselt uw eindverhandeling wereldwijd kan reproduceren, vertalen en distribueren is uw akkoord voor deze overeenkomst noodzakelijk. Gelieve de tijd te nemen om deze overeenkomst door te nemen, de gevraagde informatie in te vullen (en de overeenkomst te ondertekenen en af te geven).

Ik/wij verlenen het wereldwijde auteursrecht voor de ingediende eindverhandeling: NITTIs : Natural Interaction Techniques in Tabletop Interfaces Richting: Master in de informatica Jaar: 2007 in alle mogelijke mediaformaten, - bestaande en in de toekomst te ontwikkelen - , aan de Universiteit Hasselt. Niet tegenstaand deze toekenning van het auteursrecht aan de Universiteit Hasselt behoud ik als auteur het recht om de eindverhandeling, - in zijn geheel of gedeeltelijk -, vrij te reproduceren, (her)publiceren of distribueren zonder de toelating te moeten verkrijgen van de Universiteit Hasselt. Ik bevestig dat de eindverhandeling mijn origineel werk is, en dat ik het recht heb om de rechten te verlenen die in deze overeenkomst worden beschreven. Ik verklaar tevens dat de eindverhandeling, naar mijn weten, het auteursrecht van anderen niet overtreedt. Ik verklaar tevens dat ik voor het materiaal in de eindverhandeling dat beschermd wordt door het auteursrecht, de nodige toelatingen heb verkregen zodat ik deze ook aan de Universiteit Hasselt kan overdragen en dat dit duidelijk in de tekst en inhoud van de eindverhandeling werd genotificeerd. Universiteit Hasselt zal mij als auteur(s) van de eindverhandeling identificeren en zal geen wijzigingen aanbrengen aan de eindverhandeling, uitgezonderd deze toegelaten door deze overeenkomst.

Ik ga akkoord,

Wouter Groeneveld Datum: 22.05.2007

Lsarev_autr

kfqqfë=w=k~íìê~ä=fåíéê~åíáçå=qéåüåáèìéë=áå=q~ääéíçé= fåíéêñ~åéë

Recommend Documents