Academia.eduAcademia.edu

Figure 13 – uploaded by Victor Callaghan

See full PDFdownloadDownload figure
Figure 10 Two screenshots for two events: driving and having a meeting at the university. The story is created through running various parallel scripts that test for keywords (i.e., context values) and then determine the behaviours of the various sprites selected to make up the story and the selection of the background. The user has a lot of freedom to decide what colours, sprites, and background: 0 choose. For example, in our story the Home location is shown as a background o: iser’s house (Figure 11) and the university location with a picture of the campu: Figure 12). Driving is shown by changing the background (Figure 12) though it car ilso be shown by using a car as a sprite. Current time is shown through various clocks [he meeting is shown through a sprite (Figure 12). The user has the option to select ar wn sprite as her avatar and she can customize its colour to reflect the emotiona ontext: in this case the user decided to choose green for energetic (during driving anc it home) and red for excited (during the PhD board). The appropriate sprite is ther chosen based on the heart rate. Having such freedom to map emotional states to colour emoves the ambiguity issues around personal interpretations of certain colours [57]. The collected information is used to create derived information and create values for the contexts described above. The context values are then written in files that correspond to the list of lists structure described in Figure 11. The daily story we create is a list of events, where each event is defined by the various aspects of context and each context has one or more values. The values given to contexts are used to create the graphical representation of each event by using features offered by the Scratch environment.

Figure 10 Two screenshots for two events: driving and having a meeting at the university. The story is created through running various parallel scripts that test for keywords (i.e., context values) and then determine the behaviours of the various sprites selected to make up the story and the selection of the background. The user has a lot of freedom to decide what colours, sprites, and background: 0 choose. For example, in our story the Home location is shown as a background o: iser’s house (Figure 11) and the university location with a picture of the campu: Figure 12). Driving is shown by changing the background (Figure 12) though it car ilso be shown by using a car as a sprite. Current time is shown through various clocks [he meeting is shown through a sprite (Figure 12). The user has the option to select ar wn sprite as her avatar and she can customize its colour to reflect the emotiona ontext: in this case the user decided to choose green for energetic (during driving anc it home) and red for excited (during the PhD board). The appropriate sprite is ther chosen based on the heart rate. Having such freedom to map emotional states to colour emoves the ambiguity issues around personal interpretations of certain colours [57]. The collected information is used to create derived information and create values for the contexts described above. The context values are then written in files that correspond to the list of lists structure described in Figure 11. The daily story we create is a list of events, where each event is defined by the various aspects of context and each context has one or more values. The values given to contexts are used to create the graphical representation of each event by using features offered by the Scratch environment.

Related Figures (12)

The Data Gathering Agent is responsible for collecting data from various input sources. Such sources can include various devices used by the user during the day (e.g., work machine, home machine, mobile phone, etc.) as well as external content servers providing user-related data, such as emails and calendar events. The data collection can be done both asynchronously and in real time, according to the intended scenario. We have so far mainly focused on the asynchronous mode, as we are more interested in providing support for user reflective behaviors. Throughout this chapter we will consider this type of information gathering. We will further discuss certain aspects of such system along three main information lifecycle: gathering, processing and visualization. Figure 1 presents a multi-agent view of our system along such components.
The Data Gathering Agent is responsible for collecting data from various input sources. Such sources can include various devices used by the user during the day (e.g., work machine, home machine, mobile phone, etc.) as well as external content servers providing user-related data, such as emails and calendar events. The data collection can be done both asynchronously and in real time, according to the intended scenario. We have so far mainly focused on the asynchronous mode, as we are more interested in providing support for user reflective behaviors. Throughout this chapter we will consider this type of information gathering. We will further discuss certain aspects of such system along three main information lifecycle: gathering, processing and visualization. Figure 1 presents a multi-agent view of our system along such components.
Figure 2 Input sources and data collected Figure 2 shows what input sources we have now and what information we are able to collect. The system can collect information from both physical (raw data) and logical sensors (interpreted data). Here are more details about the main sources we are using:
Figure 2 Input sources and data collected Figure 2 shows what input sources we have now and what information we are able to collect. The system can collect information from both physical (raw data) and logical sensors (interpreted data). Here are more details about the main sources we are using:
Figure 3 Data collection platform Figure 3 shows a platform view of the information collection process. The Data Collection Platform component comprises of various modules gathering data from multiple distributed sources, over various technologies (¢.g., Bluetooth-BT, USB, IP) and storing it into distributed data storages.
Figure 3 Data collection platform Figure 3 shows a platform view of the information collection process. The Data Collection Platform component comprises of various modules gathering data from multiple distributed sources, over various technologies (¢.g., Bluetooth-BT, USB, IP) and storing it into distributed data storages.
Figure 4 Main entities in the Information Model The Information Model captures both raw and processed information as well as relationships between them (i.e., how processed information has been obtained). A representation of the main objects included in the model is shown in Figure 4. An important phase in the modeling process is to identify which features should be extracted from the available information. Figure 5 shows what information can be
Figure 4 Main entities in the Information Model The Information Model captures both raw and processed information as well as relationships between them (i.e., how processed information has been obtained). A representation of the main objects included in the model is shown in Figure 4. An important phase in the modeling process is to identify which features should be extracted from the available information. Figure 5 shows what information can be
Figure 5 Information processing derived based on available initial data and how initial and derived information are combined to create the various types of user context [55].
Figure 5 Information processing derived based on available initial data and how initial and derived information are combined to create the various types of user context [55].
In our system, we explore this type of story-based information presentation from simple to more complex structures enabled by a modeling process that takes information from the Information Model and arranges it into a story-based representation, according to the Story Model (see Figure 6).
In our system, we explore this type of story-based information presentation from simple to more complex structures enabled by a modeling process that takes information from the Information Model and arranges it into a story-based representation, according to the Story Model (see Figure 6).
Scratch is a Squeak-based environment (Figure 7) created as a way of making programming fun for kids. It has been developed by the Lifelong Kindergarten group at MIT Media Lab. Figure 7. Scratch environment The reason we have eventually decided to use Scratch is that it provides an easy way to create rich media stories, where images, colours, texts, sounds and animations can easily convey the multidimensional sense of change within a sequence of events.
Scratch is a Squeak-based environment (Figure 7) created as a way of making programming fun for kids. It has been developed by the Lifelong Kindergarten group at MIT Media Lab. Figure 7. Scratch environment The reason we have eventually decided to use Scratch is that it provides an easy way to create rich media stories, where images, colours, texts, sounds and animations can easily convey the multidimensional sense of change within a sequence of events.
Figure 8. Main elements in Scratch Our vision is to create a system that can offer both high-level, summarized view of information as well as allow access to more lower-level recorded data in order to increase user understanding. For this reason we have decided to use both stories and graphs. For creating more detailed visualizations are using Google Visualizations and correlated two or more types of data. The visualizations are embedded into a diary-like interface built within a WordPress environment one of the most commonly used blogging platforms [63]. The next section presents in more detail how collected data is interpreted and visualized as part of a user experiment. Time can also be conveyed in Scratch in various ways, such as using a sequence of clock images (see Figure 8) or by using an animated time line. Each character or object (called sprite) used in creating a Scratch story can be individually customized and controlled through parallel running scripts.
Figure 8. Main elements in Scratch Our vision is to create a system that can offer both high-level, summarized view of information as well as allow access to more lower-level recorded data in order to increase user understanding. For this reason we have decided to use both stories and graphs. For creating more detailed visualizations are using Google Visualizations and correlated two or more types of data. The visualizations are embedded into a diary-like interface built within a WordPress environment one of the most commonly used blogging platforms [63]. The next section presents in more detail how collected data is interpreted and visualized as part of a user experiment. Time can also be conveyed in Scratch in various ways, such as using a sequence of clock images (see Figure 8) or by using an animated time line. Each character or object (called sprite) used in creating a Scratch story can be individually customized and controlled through parallel running scripts.
All the visualizations created based on the collected data are accessible via a Wordpress-based system, in order to create an environment that is familiar, portable and based on available and commonly used technologies. The Wordpress interface integrates with our MySQL user backend database and we have created various PHP and Javascript programs that access, interpret and visualize collected data. A widget PHP script runs to check if new data is available in the database. If data is available for a certain day then the script creates posts that allow the user to access the data by using various visualizations of the data (raw and interpreted), including the story created based on the data.
All the visualizations created based on the collected data are accessible via a Wordpress-based system, in order to create an environment that is familiar, portable and based on available and commonly used technologies. The Wordpress interface integrates with our MySQL user backend database and we have created various PHP and Javascript programs that access, interpret and visualize collected data. A widget PHP script runs to check if new data is available in the database. If data is available for a certain day then the script creates posts that allow the user to access the data by using various visualizations of the data (raw and interpreted), including the story created based on the data.
4.2. Visualizations
4.2. Visualizations
In Figure 10 we have included various visualizations for data such as heart rate, noise levels, number and name of BT devices around, GPS coordinates, even button, keystrokes, application and web activity. In some of the visualizations, we were able to correlate certain data, such as GPS and time, number of BT devices, time and BT names, and heart rate and annotations based on certain conditions by using the AmnotatedTimeLine A PI and the MAP API offered by the Google Visualizations. More detailed information can be obtained by using the table representations (Figure 10.f), where full detail of captured data is available (i.e., time of collection, URL and window caption). Summarized visualizations, focused on giving an overall picture of words, are created by using word cloud API (h and g). Such summarized visualizations give ¢ clear indication of what the user’s focus was during the recording period.
In Figure 10 we have included various visualizations for data such as heart rate, noise levels, number and name of BT devices around, GPS coordinates, even button, keystrokes, application and web activity. In some of the visualizations, we were able to correlate certain data, such as GPS and time, number of BT devices, time and BT names, and heart rate and annotations based on certain conditions by using the AmnotatedTimeLine A PI and the MAP API offered by the Google Visualizations. More detailed information can be obtained by using the table representations (Figure 10.f), where full detail of captured data is available (i.e., time of collection, URL and window caption). Summarized visualizations, focused on giving an overall picture of words, are created by using word cloud API (h and g). Such summarized visualizations give ¢ clear indication of what the user’s focus was during the recording period.
Figure 9Story creation process For creating the story, we have used BYOB (http://byob.berkeley.edu/), whict mplements certain extensions to Scratch while keeping the same main interface anc oncepts. The main reason we use this environment is that it allows lists of lists. List: re collections of elements, much like arrays. Y ou can see in Figure 11 how this feature s used. 4.2.2. Building the story While such visualizations can give a very good picture of various aspects of user’s context at the time of the recording, it is very hard to combine them all into a summarized format based on graphs or maps. That is the main reason why we believe that stories are the appropriate format to create compressed and user-friendly interfaces.
Figure 9Story creation process For creating the story, we have used BYOB (http://byob.berkeley.edu/), whict mplements certain extensions to Scratch while keeping the same main interface anc oncepts. The main reason we use this environment is that it allows lists of lists. List: re collections of elements, much like arrays. Y ou can see in Figure 11 how this feature s used. 4.2.2. Building the story While such visualizations can give a very good picture of various aspects of user’s context at the time of the recording, it is very hard to combine them all into a summarized format based on graphs or maps. That is the main reason why we believe that stories are the appropriate format to create compressed and user-friendly interfaces.
Related topics:
Instrumentation EngineeringPhysiologyHuman Computer InteractionHealth SciencesMedical SciencesWearable ComputingInformation VisualizationAffective ComputingPublic HealthHealth Care Management
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved