Skip to content

Commit

Permalink
Incorporate first tips from Frank and add more verbose description of…
Browse files Browse the repository at this point in the history 
… the different chapters
  • Loading branch information
@ArloL
ArloL committed May 15, 2012
1 parent 7e2ef98 commit 686617f
Showing 1 changed file with 146 additions and 86 deletions.
232 changes: 146 additions & 86 deletions _includes/Thesis.md
View file
Expand Up @@ -14,7 +14,7 @@ Thanks to Chris Burns for reviewing my code and giving me feedback.

Thanks to Paul Hegarty and [Leland Stanford Junior University](http://www.stanford.edu) for the course [CS193P "iPad and iPhone Application Development"](http://www.stanford.edu/class/cs193p) that is available for free via [iTunes U](http://itunes.stanford.edu/).

Thanks to Prof. Dr. Manfred Meyer and [Dr. Frank Maurer](http://ase.cpsc.ucalgary.ca/) for giving me the possibility to write my thesis in the beautiful town of Calgary, Alberta, Canada.
Thanks to Prof. Dr. Manfred Meyer and [Dr. Frank Maurer](http://ase.cpsc.ucalgary.ca/ase/Frank.Maurer.php) for giving me the possibility to write my thesis in the beautiful town of Calgary, Alberta, Canada.

# Zusammenfassung

Expand All @@ -23,14 +23,31 @@ Thanks to Prof. Dr. Manfred Meyer and [Dr. Frank Maurer](http://ase.cpsc.ucalgar
# Content

1. Introduction
1. Motivation
2. Research Goals
2. Related Work
3. Definitions
4. Application domains
5. Mission statement
3. REST
4. Range of Applications
6. Requirements
1. Devices
2. Operating Systems
3. Programming Languages
4. Application Requirements
5. API requirements
7. Design
1. Restrictions
2. Design Decisions
3. Technology Evaluation
8. Implementation
1. Architecture
2. Application Stack
9. Evaluation
1. Performance
2. API Usability
3. Device Interaction
4. User Experience
10. Conclusions
1. Future Work

# List of Figures

Expand All @@ -48,43 +65,52 @@ The number of devices used in everyday and professional life is increasing daily

In this thesis I will present a framework that enables these interactions.

# Related Work
## Research goals

An overview of research in the field of device interaction.
The basis of these research goals comes from the [Google Web Toolkit](https://developers.google.com/web-toolkit/) and many parts are copied or adapted from it's [mission statement](https://developers.google.com/web-toolkit/makinggwtbetter#introduction).

* Ubiquitious Computing
* Multi-surface
* Device interaction
* Multiple devices
IntAirAct's goal is to radically improve the user experience by enabling developers to use web technologies to build interacting applications for any modern operating system.

# Definitions
**to radically improve**

## Framework
The unconventional premise of IntAirAct (i.e. use REST, JSON and HTTP in a local network, having HTTP servers on mobile devices) sets the tone for how we are to be open-minded about approaches that make a big impact. We are willing to invest extra consideration and work to find solutions of the "order-of-magnitude" rather than the "good enough" variety.

> What is a Framework to me?
**user experience**

## Device Interaction
The experience we want to optimize is the end user's experience. We strongly prioritize features that can make the biggest difference to end users. Obviously, we want to make developers' lives easier, too, but never at the expense of the user experience.

> What is Device Interaction to me?
**by enabling developers**

There are obviously two parts here: Device and Interaction.
IntAirAct is about enabling developers to do great things, not necessarily spoon-feeding them or putting them in a straightjacket. IntAirAct strives to be easy to use without sacrificing efficiency. We generally prioritize ensuring that the basics of IntAirAct work very well rather than adding dozens of features. It's much better to provide a solid platform so that other great libraries can be built on top of IntAirAct rather than trying to be all things to all people out of the box.

### Devices
**web technologies**

Basically just a list of all the possible devices:
The web is everywhere. A lot of developers start by learning web oriented languages such as HTML, CSS and PHP. We want to utilize this existing knowledge and move it into the local domain. This makes the learning curve very steep - as in you learn a lot very quickly.

* Mobile devices
* Tablets
* iPad
* Android
* Phones
* iPhone
* Android
* Windows Phone
* Blackberry
* Touch Tables
* TV
* Sound station
**interacting applications**

We strongly believe that device interaction will play a big role in future application development and therefore we should start creating the basic frameworks for developers to use.

**any modern operating system**

IntAirAct should be as portable as it can be so long as it doesn't involve sacrificing user experience in any significant way.

# Related Work

> An overview of the field of communication: MOM, protocols, TCP/IP, HTTP, GameKit
# REST

> What is REST for me?
I understand it rather as the REST API than the architecture style described by Fielding [quote dissertation].

# Range of applications

* Multi-Surface Environments
* Ubiquitious Computing
* Device interaction
* Multiple devices

### Interaction

Expand All @@ -97,17 +123,15 @@ A conversation or exchange between people.
* Videos
* General Messages

### What is Device Interaction

Device Interaction is an exchange between devices.

## REST
## Device Interaction

> What is REST for me?
> What is Device Interaction to me?
I understand it rather as the REST API than the architecture style described by Fielding [quote dissertation].
There are obviously two parts here: Device and Interaction.

### What is Device Interaction

# Application domains
Device Interaction is an exchange between devices.

## Existing examples for Device Interaction

Expand All @@ -122,40 +146,36 @@ I understand it rather as the REST API than the architecture style described by
## Usage scenarios

Example applications of device interaction.

# Mission statement

The idea of a mission statement comes from the [Google Web Toolkit](https://developers.google.com/web-toolkit/) project and many parts are copied or adapted from it's [mission statement](https://developers.google.com/web-toolkit/makinggwtbetter#introduction).

IntAirAct's mission is to radically improve the user experience by enabling developers to use web technologies to build interacting applications for any modern operating system.

**to radically improve**

The unconventional premise of IntAirAct (i.e. use REST, JSON and HTTP in a local network, having HTTP servers on mobile devices) sets the tone for how we are to be open-minded about approaches that make a big impact. We are willing to invest extra consideration and work to find solutions of the "order-of-magnitude" rather than the "good enough" variety.

**user experience**

The experience we want to optimize is the end user's experience. We strongly prioritize features that can make the biggest difference to end users. Obviously, we want to make developers' lives easier, too, but never at the expense of the user experience.

**by enabling developers**

IntAirAct is about enabling developers to do great things, not necessarily spoon-feeding them or putting them in a straightjacket. IntAirAct strives to be easy to use without sacrificing efficiency. We generally prioritize ensuring that the basics of IntAirAct work very well rather than adding dozens of features. It's much better to provide a solid platform so that other great libraries can be built on top of IntAirAct rather than trying to be all things to all people out of the box.

**web technologies**

The web is everywhere. A lot of developers start by learning web oriented languages such as HTML, CSS and PHP. We want to utilize this existing knowledge and move it into the local domain. This makes the learning curve very steep - as in you learn a lot very quickly.

**interacting applications**
# Requirements

We strongly believe that device interaction will play a big role in future application development and therefore we should start creating the basic frameworks for developers to use.
> Take the range of applications and build up a list of requirements.
**any modern operating system**
### Devices

IntAirAct should be as portable as it can be so long as it doesn't involve sacrificing user experience in any significant way.
Basically just a list of all the possible devices:

# Requirements
* Mobile devices
* Tablets
* iPad
* Android Tablets
* Phones
* iPhone
* Android Phones
* Windows Phone 7
* Blackberry
* Touch Tables
* Microsoft Surface
* TV
* Restriction: with a computer/media center connected
* Apple TV
* Boxee
* XBMC
* Windows Media Center
* Sound station
* Restriction: with a computer/media center connected

## Application Domain Requirements
## Application Requirements

* No central server
* Ad-Hoc-Situations
Expand All @@ -165,9 +185,9 @@ IntAirAct should be as portable as it can be so long as it doesn't involve sacri
* Location
It should enable the tracking of location

## API requirements
## API Requirements

Look at the messaging system parameter from EAI and include it here.
Look at the messaging system parameters from EAI and include it here.

* State-of-the-art programming models
* iOS specific
Expand All @@ -191,21 +211,22 @@ Look at the messaging system parameter from EAI and include it here.
* Objective C
* Java
* C#

> Summarize what combinations of platforms and languages we're going to have.
# Design

## Restrictions
## Architecture

* Same (W-)LAN
* Bluetooth sucks
* Focus on iOS
* because it is mainly used inside lab
* Proof of concept for other OSs
* Security is not a real issue
But it should be able to be added later
* Not solving the problem of automated stuff. I consume services that I know (!) about.
> Describe the basic architecture of the system. This has to be device, operating system and programming language independent.
## Design decisions
## Application stack

> Build a layered description of the framework and describe the tasks provided by each layer. This has to be device, operating system and programming language independent.
## Design Decisions

> Take each layer of the application stack and describe the possible technologies and then describe the decision made in favor of one.
* ZeroConf
* Enables device discovery
Expand All @@ -229,24 +250,63 @@ Look at the messaging system parameter from EAI and include it here.
* Authentication -> Service
* Rights/Users/etc. -> Service

## Technology evaluation
# Implementation

## Restrictions

* CocoaHTTPServer + RoutingHTTPServer
* RestKit vs. Resty
* RestKit
* Resty
> If there are restrictions introduced by the design decisions summarize them here.
* Same (W-)LAN
* introduced by ZeroConf
* Bluetooth sucks
* Focus on iOS
* because it is mainly used inside lab, has highest markt percentage, etc.
* Proof of concept for other OSs
* Security is not a real issue
But it should be able to be added later
* Not solving the problem of automated stuff. I consume services that I know (!) about.

> The automated stuff has to be a design decision as well.
## Technology Evaluation

> For each task introduced by the layers of the application stack and the design decisions describe possible technologies for the different environments.
* iOS
* CocoaHTTPServer + RoutingHTTPServer
* RestKit vs. Resty
* RestKit
* Resty
* Java
* jmDNS
* Android
* jmDNS
* C#
* Apple Bonjour SDK

# Evaluation

## Performance

Test this by playing ping pong.
> Write up a test scenario, implement it and run it. A simple example would be to just return fixed values. This should include one device only tests, two-device and three-device tests. Also cross-platform tests to show that it works cross-platform.
## API Usage Experience Results
## API Usability

Finish the API and then have people use it.
Prepare an interview with them and analyse the results.

Donate to Robby Hanson and ask for a code review.
> Donate to Robby Hanson and ask him to use the system. How about Taras Kalapun? Or other guys that do awesome stuff!?
Evaluate the usage in the Multi-Surface Environment and Facet projects.

## User experience

> If we have a focus group in the Facet project perhaps I can use them to do a user experience study. Or perhaps Chris and Teddy will do sth. similar for their thesis.
# Conclusion

> Look at the Research goals and compare them with the evaluation.
## Future work

> What is going to happen with this in the future?

0 comments on commit 686617f

Please sign in to comment.