Permalink
Browse files

Henriks proof reading and fixes

  • Loading branch information...
1 parent df1d8f5 commit e9b381cda43a78c06ee61a2e8a640555d4649a25 @Zefz Zefz committed May 23, 2012
@@ -7,8 +7,8 @@ \section{System overview}
The system consists of:
\begin{description}
\item[Libraries:] Social library, Communication library
- \item[Applications:] T-shirt application, other applications
- \item[(U.I.) Prototypes:] T-shirt prototype, other prototypes
+ \item[Applications:] Jacket application, other applications
+ \item[(U.I.) Prototypes:] Jacket prototype, other prototypes
\end{description}
The figure \ref{fig:design-toplevel} illustrates the overall system architecture.
@@ -24,15 +24,15 @@ \section{System design}
\label{sec:system-design}
As the requirements for the product were not set early on by the customer, a lot of effort
was put into producing working prototypes to show during the meetings in order to receive
-as much feedback as possible and identify the ideas the customer had in mind; these would provide
+as much feedback as possible and identify the ideas the customer had in mind. This would provide information on
what was needed to proceed with system design. At some point, after roughly one month,
we understood that we were going in the wrong direction, and that our design wouldn't satisfy
the requirements the customer had mentioned. The design of some parts of the system had to be revised.
\subsection{First design}
-Our first system design was based on the scenario where the user would download the T-shirt
+Our first system design was based on the scenario where the user would download the Jacket
and the social applications, browse for some content from within the social application
-and actively send it to the tangible user interface (the T-shirt) by pressing a 'share' button.
+and actively send it to the tangible user interface (the jacket) by pressing a 'share' button.
This scenario is illustrated in figure \ref{fig:design-usecase1}.
\begin{figure}[h!]
@@ -42,7 +42,7 @@ \subsection{First design}
\end{figure}
Please note that in this scenario the user is required to actively send data from
-the social application (which acts as a Facebook client) to the T-shirt application,
+the social application (which acts as a Facebook client) to the jacket application,
which is merely capable of receiving. Also, both are implemented as Android applications.
The figure \ref{fig:design-resp} illustrates the communication between the applications.
@@ -56,21 +56,21 @@ \subsection{First design}
\subsection{Second design}
It turned out that the user was not supposed to browse for social content and actively send it
-to the T-shirt application. Instead, after downloading the software, he would just setup a set of rules
-specifying the behavior of the T-shirt. This scenario is illustrated in figure \ref{fig:design-usecase2}
+to the jacket application. Instead, after downloading the software, he would just setup a set of rules
+specifying the behavior of the Jacket. This scenario is illustrated in figure \ref{fig:design-usecase2}
\begin{figure}[h!]
\centering \includegraphics[scale=0.35]{img/design-usecase2}
\caption{Use case for the product (second design)}
\label{fig:design-usecase2}
\end{figure}
-This new scenario made clear that the T-shirt and social applications had to be re-designed so:
+This new scenario made clear that the jacket and social applications had to be re-designed to support new requirements.
\begin{description}
- \item [T-shirt application:] A user interface, implemented as an Android application,
- that the user would to setup the rules for the T-shirt. The application needed also a
+ \item [Jacket application:] A user interface, implemented as an Android application,
+ that the user would configure to setup the rules for the jacket. The application also needed a
background component (such as an Android service or Thread) that would 'ask' the required information
to the social service.
@@ -91,12 +91,12 @@ \subsection{Second design}
\label{fig:design-reqresp}
\end{figure}
-The T-shirt service is now 'asking' the social service for a specific content.
+The Jakcet service is now 'asking' the social application for a specific content.
This happens in the background, without user interaction.
\subsubsection{Sequence diagram}
-This sequence diagram shown in figure \ref{fig:design-sequence} shows a sample communication between the social and T-shirt applications.
-The T-shirt application requests the list of friends from Facebook whose age is the same as 'Anna'.
+This sequence diagram shown in figure \ref{fig:design-sequence} shows a sample communication between a social app and the jacket application.
+The jacket application requests the list of friends from Facebook whose age is the same as 'Anna'.
\begin{figure}[h!]
\centering \includegraphics[width=1.0\textwidth]{img/design-sequence.png}
@@ -111,7 +111,7 @@ \subsection{The Social library}
The Social library is the link between the Android applications that control the
behavior of TUI prototypes and social networks. It provides abstractions for
many common concepts found in different social networks like Facebook, Twitter
-and OpenSocial allowing third-party developers to use these concepts seamlessly
+and OpenSocial. This allows third-party developers to use these models seamlessly
between different social networks and extend them to possibly support others.
It also defines and implements a set of classes to allow Android applications
and services to exchange such data models. This mechanism is based on Android's
@@ -136,10 +136,10 @@ \subsection{The Communication library}
This library consists of a Java library (implemented on Android) and an Arduino firmware (figure \ref{fig:comlib-diagram}),
both implementing the ComLib protocol. The Java library provides a set of classes that simplify the connection to Arduino
devices that run the Communication library Arduino firmware. The library also implements a mechanism to request a list of
-services the remote device supports and any software download links associated with the remote device. A service might
-be a sensor, a lamp, display screen while download links are represented as an URL link. All this meta information is stored
-on in the firmware on the remote device as raw text using the JSON format. This meta-data can also be stored an retrieved
-in a QR code or anything else that can store plain text.
+services (components) the remote device supports and any software download links associated with the remote device. A service might
+be a sensor, a lamp, display screen, etc, while download links are represented as an URL link. All this meta information is stored
+on in the firmware on the remote device as raw text using the JSON format. This meta-data can also be stored and retrieved
+in a QR code or other plain text formats.
\begin{figure}[h!]
\centering \includegraphics[scale=0.4]{img/comlib-diagram.png}
@@ -187,7 +187,7 @@ \subsubsection{Arduino firmware implementation}
The user of this library can register local methods to be called with RPC when the corresponding instruction is called.
The instructions follow strict rules on how they are constructed (see Table~\ref{tbl:instr_struct} for sizes of the different parts).
Each instruction has to start with a "start-byte" which is always 0xFF (255 decimal). The next part is the size, which tells the number of bytes to come for this instruction (including the size byte itself). The rest is defined from which instruction is sent, but it is important to
-remember that the content cannot be empty, and has to at least contain 1 byte. This byte however, is not necessarily read or used.
+remember that the content cannot be empty, and has to at least contain one byte. This byte however, is not necessarily read or used.
The following figure \ref{fig:arduino_states} illustrates the Arduino state machine:
@@ -240,9 +240,8 @@ \subsection{oSNAP Jacket Application} \label{section:app-jacket}
\end{wrapfigure}
This application was developed to use and test the full functionality of both the ComLib and Social library in combination with the
Jacket Prototype (shown in figure \ref{fig:jacketapp-overview}). It connects to the Jacket via Bluetooth and uses any Social network services installed and running on the
-Android system. It will retrieve any status updates from these services and can via rules set up by the user output something
-on the Jacket. One example could be a rule to play a sound effect through the Jacket speaker whenever something happens
-on a twitter feed.
+Android system. It will retrieve any status updates from these services and can via rules relay the user output to the Jacket.
+One example could be a rule to play a sound effect through the Jacket speaker whenever something happens on a twitter feed.
\begin{figure}[H]
\centering \includegraphics[scale=0.35]{img/jacketapp-overview}
@@ -300,7 +299,7 @@ \subsection{oSNAP Temperature Application}
upload temperature updates to Facebook through the ComLib. This application is a proof-of-concept that the libraries work independently
and are not hard-coded for one application. It also shows that the ComLib supports two-way communication.
In the planning stage of this prototype, a paper prototype (see figure~\ref{fig:prototype2-paper}) was showed to the
-customer. Due to some problems with getting the initial design to work properly, the GUI was revised (see
+customer. Due to some problems to get the initial design to work properly, the GUI was revised (see
figure~\ref{fig:prototype2-gui}) to make it more user friendly and visually appealing.
\begin{figure}[H]
@@ -321,7 +320,7 @@ \subsection{oSNAP BlingLED Application}
\begin{wrapfigure}{l}{20mm}
\centering \includegraphics[scale=1]{img/app-led}
\end{wrapfigure}
-This application uses ComLib to connect ot the third prototype, the LED Matrix (see section \ref{section:prototype-led}). It allows the user to control the color of each LED in the matrix wirelessly through Bluetooth. This is yet another showcase for how the ComLib can be integrated into any application. Figure \ref{fig:design-ledmatrix} shows the Android application used to control the prototype.
+This application uses ComLib to connect to the third prototype, the LED Matrix (see section \ref{section:prototype-led}). It allows the user to control the color of each LED in the matrix wirelessly through Bluetooth. This is yet another showcase for how the ComLib can be integrated into any application. Figure \ref{fig:design-ledmatrix} shows the Android application used to control the prototype.
\begin{figure}[h!]
\begin{center}
@@ -340,8 +339,7 @@ \subsection{oSNAP Twitter application}
\section{Prototypes}
\label{sec:prototypes}
-Three different prototypes will be produced for the project. Their purpose is to serve as proof of concept and
-to show that the libraries and can effectively simplify the prototyping of Arduino-based TUI
+Three different prototypes will be produced for the project. Their purpose is to show that the libraries can effectively simplify the prototyping of Arduino-based TUI.
One of the prototypes, the oSNAP Jacket (formerly the T-Shirt), is significantly bigger and more complex than the other two.
The oSNAP Jacket is the main prototype of the project; the purpose of the other two
is just to show that the libraries can be use for other applications and in different contexts - to showcase the generic nature of our libraries.
@@ -372,7 +370,7 @@ \subsection{Prototype 1: The oSNAP Jacket}
\end{figure}
The application of this prototype will feature several displays and indicators which will receive social data through an Android phone.
-The shirt features different tangible interfaces (see figure \ref{fig:design-TShirt}):
+The jacket features different tangible interfaces (see figure \ref{fig:design-TShirt}):
\begin{itemize}
\item LEDs
@@ -6,14 +6,14 @@
\section{Existing solutions}
We did some research on the Internet about similar and related products. It is important to underline that our task was
-not just to create another prototype, but instead a set of libraries that would ease future development of new protoypes
+not just to create another prototype, but a set of libraries that would ease future development of new protoypes
connecting Arduino to social networks. These existing products were relevant in order to confirm that tangible user interfaces
for social networks using Arduino were a reality. They also provided some ideas to take into consideration.
\newpage
\subsection{LikeLight}
-This product found on the internet (\ref{link:likelight}) is a Facebook like indicator that glows when some content the
+This product introduced by the customer (\ref{link:likelight}) is a Facebook like indicator that glows when some content the
user posted on Facebook is liked by someone. It was realized with an Arduino board inside a giant Lego hand.
(Figure \ref{fig:prestudies-likehand})
@@ -28,9 +28,8 @@ \subsection{LikeLight}
\section{Our own ideas}
\subsection{YepMailbox}
-The YepMailbox (Figure \ref{fig:prestudies-YepMailbox}) was another concept that we thought of, of a tangible Arduino-powered prototype
-that would interact with the user Facebook wall. The mail flag would rise powered by a small servo motor and a printer
-would print out the new message.
+The YepMailbox (Figure \ref{fig:prestudies-YepMailbox}) was another concept that we thought of. A tangible Arduino-powered prototype
+that would interact with the user Facebook wall. When a new message arrives, a flag powered by a small servo would rise, and the message print out.
\begin{figure}[h!]
\centering \includegraphics[scale=0.4]{img/prestudies-YepMailbox}
@@ -42,8 +41,8 @@ \subsection{YepMailbox}
\subsection{Facebook Wall}
The "Facebook Wall" (Figure \ref{fig:prestudies-facebookwall}) is another concept we came up with. It is a wall with two holes in it for people to put their faces in.
-The prototype would then make a picture and replace the wall with some image and add bodies to the two faces. The image
-would then be automatically uploaded and posted on Facebook.
+The prototype would then take a picture and replace the wall with some a image and add bodies and background scene to the two faces. After user confirmation, the image
+would then be uploaded and posted on their Facebook.
\begin{figure}[h!]
\centering \includegraphics[scale=0.22]{img/prestudies-facebookwall}
@@ -55,7 +54,7 @@ \subsection{Facebook Wall}
\subsection{T-Shirt}
The T-Shirt (Figure \ref{fig:prestudies-tshirt}) features electronic circuits powered by an Arduino Lilypad board.
-The Lilypad is an Arduino board designed specifically to be worn. It is connected wirelessly to the Internet through
+The Lilypad is an micro chip designed specifically to be worn. It is connected wirelessly to the Internet through
an Android phone, and downloads status updates from a social network such as Facebook.
The content fetched is then displayed through one of the electronic devices: LEDs, LCD screen,
sound module or a vibration module.
@@ -58,7 +58,7 @@ \subsection{F4: oSNAP Jacket Application}
\begin{description}
\item[On and Off:] The user shall be able to turn the application On
and Off. When the application is not running, no social data will be
- forwarded to the Jacket prototype.
+ forwarded to the Jacket prototype F7.
\item[Libraries:] The application shall use the Communication library to
communicate with the Jacket prototype and the Social library to
receive and send data from/to social services.
@@ -90,11 +90,11 @@ \subsection{F6: oSNAP Twitter Application}
\subsection{F7: Jacket prototype}
\begin{description}
- \item[Features:] The prototype shall map some social content to various
+ \item[Features:] The prototype shall map data from jacket app F4 to various
embedded electronic devices.
\item[Libraries:] The prototype shall use both the Social and Communication
libraries.
- \item[User input:] Once the rules for the Jacket are set, no further user
+ \item[User input:] Once the data for the Jacket are set, no further user
input shall be required.
\end{description}
@@ -118,15 +118,14 @@ \subsection{F10: oSNAP Temperature Application}
\begin{description}
\item[Mac address:] The user should be able to scan the mac address from a QR code, and/or enter it manually.
\item[Share temperature:] The user should have full control over when and to which social media the temperature data is shared.
- \item[Time interval:] The user should be able to set automated updating of the temperature.
- \item[Dependecies:] Facebook service application.
+ \item[Time interval:] The user should be able to set automated updating of the temperature from prototype F8.
\item[Libraries:] The application shall use the Social and Communication libraries.
\end{description}
\subsection{F11: oSNAP BlingLED Application}
\begin{description}
- \item[Connection:] You must be able to establish a wireless connection from the Android to the prototype (F9) through Bluetooth.
- \item[Lights:] When the appropriate light levels are adjusted on the Android, the prototype (F9) should adjust the LED matrix accordingly.
+ \item[Connection:] You must be able to establish a wireless connection from the Android to the prototype F9 through Bluetooth.
+ \item[Lights:] When the appropriate light levels are adjusted on the Android, the prototype should adjust the LED matrix accordingly.
\item[Libraries:] The application shall use the Communication library.
\end{description}
@@ -148,7 +147,7 @@ \subsection{Libraries}
shall be developed in independent, thus reusable modules so that adding new
functionality will be fairly easy for new developers.
\item[Target platform:] The library shall be compatible with the Android
- system starting from version 2.2. This will place restrictions on the
+ system starting from version 2.2 in order to support more cell phones. This will place restrictions on the
existing software and on the programming languages that will be adopted.
\item[Documentation:] The library shall be documented using Javadoc.
Since the product is going to be further developed by other people and is

0 comments on commit e9b381c

Please sign in to comment.