2009 – Fraunhofer FIT
Top 10 European institute of research. The branch in which I work focuses more on Communication and Cooperation, Artificial Intelligence and Virtual Reality.
Breiny – Master thesis application
1Yesterday I did the last step in my Media Informatics master endeavor: I presented my master thesis. After quite a few months of development on the Microsoft Surface, the application that resulted was a good start for a (possible) commercial product.
We started from the idea that a multitouch table device would offer more space, possibilities and opportunities to improve the collaboration and communication in the brainstorming phase of any project. This evolved very much during the development and conceiving the master thesis. It became a tool which not only supported and enhanced collaboration, but also, to name a few:
- offered clues gathered from Twitter and Flickr images,
- free drawing and sketching,
- text input using the virtual keyboard,
- audio recognition features,
- save / load of session,
- integration with a CRM, serving as repository;
- user-friendly navigation in sessions using also the CRM repository interface.
Master thesis – Conclusions
0This article presents an overview of my Master thesis. It summarizes the work by presenting the contributions to the research field and also the future work based on the already created prototype. The Breiny application is meant to support the Brainstorming process by using computers in a modern way – Natural User Interface. After creating the prototype, a User Evaluation was used to prove or disprove the theoretical hypotheses.
In the Related work is presented the relevant work on which my master thesis relyies on and the systems that are the basis for comparison with the developed prototype. It considers several already available collaboration and brainstorming systems and compares their features with the proposed Framework for analysis. As a conclusion of the chapter, none of the considered systems fulfill all the requirements from the proposed Framework. (more…)
Overloading methods in ASP .Net MVC
0
Today is another ASP .Net MVC day, and as always, I encountered a challenge. Being so used with overloading methods from OOP, I asked myself what if I would do the same with the Controller’s. The sad answer is no, you can’t have two methods with the same name and SAME verb to which they will respond. The rational is simple – routing engine tries to map the request for a controller, and then will try to get the action and the verb. Since there are two methods with the same verb, you run into trouble! Let’s examine a little bit the problem and see several workarounds.
The problem
The compiler will show “Type YourController already defines a member called YourAction with the same parameter types” in the following example:
[HttpPost]
public ActionResult Show()
{
// implementation
}
[HttpPost]
public ActionResult ListOrders( string userName )
{
// implementation
}
Solutions – ASP .Net MVC 3
1. Just change for a method the request verb that will map it to a certain route – be careful to change also the calls to this action!
[HttpGet]
public ActionResult ListOrders()
{
// implementation
}
2. Another alternative would be to keep the name of the method, but decorate it with ActionName. This will map the method (valid both as name and signature for .Net, but invalid for .Net MVC framework) with another name. But be careful at the route, which will not map on the name of method, but rather on the name from the ActionName parameter:
[HttpGet]
public ActionResult ListOrders()
{
//implementation
}
[HttpGet]
[ActionName("ListOrdersForCustomer")]
public ActionResult ListOrders( string userName )
{
// implementation
}
3. Create a single action method which will be responsible with both use cases, switching between them on the incoming Request type:
[HttpGet]
public ActionResult ListOrders( string userName = null)
{
// OPTION 1 - handling by request type
if (Request.HttpMethod.ToUpperInvariant() == "GET") {
// do the get handling
}
else if (Request.HttpMethod.ToUpperInvariant() == "POST") {
// do the post handling
}
// OPTION 2 - handling by optional parameter
if ( !String.IsNullOrEmpty( userName ) ) {
// do the parameter handling
}
else {
// alternate handling
}
}
More about how an method becomes an action you can read in Phil Haack’s blog, one of the main contributors of the ASP .Net MVC frameworks.
Master thesis – User evaluation
1The Users for the first session were 5 males and 1 female, with age ranging from 27 to 49. For the second, there were 4 males with age ranging from 26 to 52, with significant Brainstorming sessions experience, using Mind-mapping software, whiteboard computer based systems. The room setup consisted from a large space around Surface, with chairs surrounding it. All users were in the Contributor role and they had the opportunity to switch to Session Master any time. The application was started, with no Brainstorming Ideas on the tabletop.
The Evaluation session started with the Prototype presentation. This was targeted only on the User Interfaces, explaining how and which actions can be performed with each area of interest (UserControls and Main SurfaceWindow from Implementation Chapter). The users were encouraged to experience the interface and ask questions during the presentation, in order to understand better the interaction with the prototype.
Following the presentation phase was designed as a game, in order to exercise the prototype’s interface and evaluate the system and its features. The game was built around a imaginary, newly created, travel agency. The participants should create the company’s portfolio in a Brainstorming session, composed from the four phases (scenarios) presented in Typical use cases. They were disclosed one by one, in order to not affect the brainstorming process.
(more…)
Master thesis – Theoretical evaluation
0The theoretical evaluation of the thesis work starts with by assessing in which measure the research questions were answered by the proposed concept. Then, the analysis will focus on the comparison of the implemented prototype’s features with the ones presented in Related work, in order to see which ones were implemented and how the prototype’s features map on the array of desired ones. Finally, this chapter will conclude with a matrix in which the implemented functional requirement are marked, giving a final overview on the capabilities of the prototype to fulfill all the requirements stated in Requirement elicitation. (more…)
Master thesis – Implementation of Breiny
4The prototype’s architecture implementation
The architecture was already presented in the Prototype application architecture and now we’ll see the actual implementation. The prototype implementation tries to follow as close as possible the recommended architectural patterns and guidelines. To support the argumentation, a class diagram will be presented to give a visual orientation through the prototype implementation presentation.
The built prototype supporting Brainstorming Sessions on Microsoft Surface, further named Breiny, was developed as part of this thesis and uses all the above framework features. Thus, it is creating the basis for future work by being flexible in development yet fully packed with features.
Breiny’s class diagram
Master thesis – User Interface
0This section will present the Breiny application’s user interface and the available interactions with it, features which will be evaluated both theoretically and by the users. It is composed from a main SurfaceWindow named “Main screen” in figure below, on which all the interaction occurs. Following the requirements for extensibility, modularity and flexibility, the subsequent visible objects were separated into several user controls.
In the following subsections the main screen will be presented first along with its specific interactions, then the discussion will continue with the available item types and their particular available features.
Main screen
The main window acts as an aggregator for all the interactions, providing also support for the other controls and their interactions. It offers access to the main contextual menu, to the tag recognition and visualization, offers the data context through binding against the Session singleton and, because binding is propagated to the children controls, allows subsequent binding context to all of them.
In the figure from the left, the Breiny application was started and a new Brainstorming session is created. In this specific case the Brainstorming Items Repository didn’t already contain Brainstorming Items, thus none of these appeared on the application screen. But the users may have prior access to other devices that can interface with this thesis proposed system (iPhone, iPad or Adobe Air client) as mentioned in Architecture chapter and send they initial suggestions. If so, their Brainstorming items will show on the newly created Brainstorming Session. (more…)
Master thesis – Implementation of Repositories
1My thesis proposes several approaches as result of the research questions. Their validity of each approach should be verified by allowing users to interact with a prototype built to fulfill all the proposed solutions. Hence, the final users will prove the correctness of this thesis approaches. The implemented prototype will be a brainstorming supporting application.
Because my thesis studies brainstorming on a tabletop, I will choose the Microsoft Surface as the underlying hardware because it supports multitouch and multiuser experience. As development environment I will use Visual Studio 2010 and the programming will be done in C# with User Interface (UI) built in Windows Presentation Foundation (WPF) framework.
In this article I will start with a brief introduction in general details of the baseline system and the technologies implied in the creation of the prototype system. I will continue with the presentation of the architecture of the actual implemented system, which tries to follow the proposed one; the differences between the proposed system and the actual implementation will be underlined and the choices motivated. The article will continue with the class diagrams of the prototype and will end with the presentation of the User Interface, allowing a clear view over the features and the way the prototype performs in achieving the goals of the previous concept presentation. (more…)
Master thesis – Architecture
1This article presents the system architecture and the underlying decisions that were taken to achieve the above requirements. The system requires a repository for sessions, a repository for Brainstorming items and a native Windows application for achieving the baseline of desired features. Thus, a distributed client – server architecture is considered, exemplified below.
Session repository architecture

The above schema represents the Session repository architecture. Its main purpose is to offer two main features:
- communication over network
- means for storing, retrieving and sharing the sessions
The server and the native application can be mixed together, but with limited sharing options. Because of this reason, we will use an already created system which not only that offers through its network module of API (Application Programming Interface) both means of storing and retrieving of the session data, but also allows advanced features of sharing the data in an already familiar interface.
Brainstorming items repository architecture
The architecture for the Brainstorming items repository is similar with the one for Session repository, but the most important feature it brings is the possibility to interface with other devices, not only with the tabletop.
Another reason for creating this secondary architecture is the fact that it easily enables an offline scenario, in which the repository server is not available because of the network availability issues. Nevertheless, the mobile devices can connect to this repository through creating a local wireless network without the need to be connected to the internet. Another advantage is that, because it’s small complexity, can (but it is not required to) be installed on the same tabletop. The offline scenario is not covered in this paper, but rather proposed as future work.

Master thesis – Requirements elicitation
1We already covered the proposed general usage scenario and particular use cases of a Brainstorming system. In order to evaluate their implementation, in this section the application requirements will be presented. They are split into functional and non-functional ones. The first refers to all the features needed to be implemented, while the second category refers to performance, extensibility and scalability of the system.
Functional requirements
| Description | |
| FR.1 | The system will allow multiple users to interact with the system simultaneously |
| FR.2 | The system will allow multiple devices to interact with the Microsoft Surface simultaneously |
| FR.3 | The users will be able to send ideas to the tabletop using mobile clients |
| FR.4 | The users will be able to generate and input ideas in the system |
| FR.5 | The Contributors will be able to input Brainstorming items directly on the tabletop |
| FR.6 | The Contributors will be able to Group Brainstorming items |
| FR.7 | The Contributors will be able to Edit Brainstorming items |
| FR.8 | The Contributors will be able to Relate Brainstorming items |
| FR.9 | The Contributors will be able to Print Screen |
| FR.10 | The Contributors will be able to promote Twitter or Flickr items to Brainstorming items |
| FR.11 | The Session Master will be able to login into its BSCW account |
| FR.12 | The Session Master will be able to Save a Brainstorming Session |
| FR.13 | The Session Master will be able to Load a Brainstorming Session |
| FR.14 | The Session Master will be able to set Session Goal |
| FR.15 | The Session Master will be able to start the application using his Tag |
| FR.16 | The Session Master will be able to search on Flickr using a keyword |
| FR.17 | The Session Master will be able to search on Twitter using a keyword |
Non-Functional requirements
| Description | |
| NR.1 | The application will be designed to be extensible and maintainable |
| NR.2 | The application will be highly responsive |
| NR.3 | The application will be reliable |
| NR.4 | The application will use responsibly hardware resources |
Now let’s move to the Architecture of the application!

























