IKANGAI Solutions. e.u.

Mobile Business Solutions

T F G+ E

Posts Tagged ‘Tweetflow’

Tweetflows @ WWW

January 15th, 2011 by Martin No Comments

Unfortunately, our Paper which we submitted to the WWW conference, was rejected:

The selection process was highly competitive; we received 658 submissions out of which 82 were accepted as regular papers and 29 were accepted as posters.

Overall, our idea seemed interesting to the reviewers, but the did not provide enough evidence to convince them:

=== Reviewer 1 ===
OVERALL RATING: -2 (Probable reject, unless someone champions)
REVIEWER’S CONFIDENCE: 3 (high)
What is the rank of this submission in your pile?: 5 (5)
Is the submission worth considering for the Posters track?: 2 (yes)

The paper describes a novel workflow management system for software engineering projects. This system is based on Twitter as a communication backbone. One of the nice features of this system is that it integrates human and machine work, thereby adopting a crowdsourcing paradigm.

I really wanted to like this paper. It is well written (mostly) and it is somewhat cool by leveraging crowdsourcing and twitter to solve technical (software engineering) problems. At the end, however, I just could not convince myself that there was significant technical content here. It just felt like building a big system without much behind it. If people want to use twitter to coordinate their (distributed) software engineering tasks, why don’t they just do it? Why do they need Tweetflow and the whole mechanism that it involves? I just did not understand what the big innovation in this paper is and how it was applied to solve a really interesting problem.

a.) Motivating Scenario: It is a cool project for a class on software engineering. But, do you really need to write about this in a top-tier conference like WWW?

b.) Twitter: Twitter was described like a holy grail that solves all problems. Actually for this particular scenario it adds some problems because twitter data is open on the web. I can imagine that many software projects would require more privacy. So, why don’t you just build your own twitter? That way, a great deal of the limitations of Twitter that you seem to be fighting in the paper go away, too. Building Twitter is not really rocket science. (Maybe, building Twitter at Web-scale is rocket science, but you do not really need that for your purposes.)

c.) Why is Twitter a better tool for service discovery than the Web-based interface of microtask platforms such as Mechanical Turk. I just did not see the magic here.

d.) In 3.2, the paper mentions the difficulty of human/machine communication. There is a whole community that deal with that issue (HCI). The paper does not add much to that topic. In particular, the language proposed did not add much to that – might be okay for people who are used to tweak messages into Twitter, but not for everybody.

e.) It would have been interesting to read about some of the experiences made with the technology at work. Architecture etc. are pretty straightforward. The game-changer of crowdsourcing is to make it really happen.

=== Reviewer 2 ===

OVERALL RATING: -2 (Probable reject, unless someone champions)
REVIEWER’S CONFIDENCE: 3 (high)
What is the rank of this submission in your pile?: 2 (2)
Is the submission worth considering for the Posters track?: 2 (yes)

This paper presents a framework for offering and consuming services, mainly human offered services, on Twitter. In a way it provides an implementation of MechanicalTurk over tweets for finding relevant service providers. The paper is timely, and on an interesting topic. The paper is not very well written, but still readable. It requires some efforts to understand the paper.

However, the paper does not offer what it claims (in the title and abstract), and still the approach is in an early development stage. In particular, how workflows are formed, supported and monitored, and how Web services are found, consumed and monitored are never explained in a clear manner in the paper. I would rather be happier if the paper claims to provide a framework for offering and consuming services (mainly human provided) over Twitter. However, still in this sense it is not clear from the paper, how automated services would be able to accept and process tweets (as they are mainly text, unless the services that are designed to so so and receive a strictly formatted text as input).

The cryptic language that is presented for Twitter is still complex for human users to parse and comprehend. This is particularly challenging due to the limit on the number of tweet characters.

Although, there is a discussion on the architecture of the solution, its implementation and whether a prototype has been built and evaluated is not discussed in the paper. Nevertheless, experience on using the current Twitter site for some initial experiments on using this approach is reported among a group of students and researcher.

Given the approach presented in this paper is interesting, and as an application is novel, but in its very early stages of development, I suggest it to be referred to poster track for consideration.

minor comments:

- page 3, right column, paragraph before section 3.2, “can be discovery” => “can be discovered”

- page 3, right column, paragraph before section 3.2, “to discovery” => “to discover”

- the first sentence in section 3.2, please revise, not complete sentence (in terms of meaning)

- section 3.2, lines -3 and -3 in page 3, please revise “we strive … which are descriptions…” meaning not clear

- page 4, the few sentences before 3.3., “After … workflow” is long and not clear, what do you mean? consider breaking into smaller sentences

=== Reviewer 3 ===

OVERALL RATING: -2 (Probable reject, unless someone champions)
REVIEWER’S CONFIDENCE: 4 (expert)
What is the rank of this submission in your pile?: 2 (2)
Is the submission worth considering for the Posters track?: 2 (yes)

Authors propose use of Twitter as a orchestration platform between human and software services in the context of
workflows. The overarching concept is integration of human driven services in a service-oriented manner, following SOA principles. Authors propose dynamic embodiments of services at any point in time of workflow execution. By monitoring traces of social interactions authors propose to monitor tasks progress thereby making it transparent. The idea is interesting, however there is no substantial background about the implementation details, and the value of this technical approach. It is neat – by why is it significant? Furthermore, the paper could be significantly improved by including more evaluation of the Tweetflows.. e.g. scalability, etc.

This comments help us to improve our work and we thank the reviewers for their work. We already started to use Tweetflows with student projects and hope to gain interesting insights from this experiment.

your ikangai science team

Code Snippet of the Week: Writing a simple Twitter iPhone Client

December 28th, 2010 by Martin 5 Comments

How difficult can it be to write a Twitter iPhone Client? Not very difficult, if you have help from various sources. All you need is to add some source files into your XCode Twitter Client project and that’s it. Well, actually, it’s not THAT easy. You need some additional steps to do. An excellent tutorial that guides you through this can be found here. We followed the steps of the tutorial and created a really simple Twitter iPhone Client that lists recent Tweets of your followers and lets you post Tweets. You can download the XCode Project from here. In order to makes things work, you have to change thew OAuth settings in the code of the TweetflowViewController:

- (void)loadView {
...
// Create a TwitterEngine and login to your account
NSString *username = @"yourUserName";
NSString *consumerKey = @"yourKey";
NSString *consumerSecret = @"yourSecret";
twitterEngine = [[MGTwitterEngine alloc] initWithDelegate:self];
[twitterEngine setUsesSecureConnection:NO];
[twitterEngine setConsumerKey:consumerKey secret:consumerSecret];
[twitterEngine setUsername:username];
OAToken *token = [[OAToken alloc] initWithKey:@"yourToken"
secret:@"youtTokenSecret"];
[twitterEngine setAccessToken:token];
[twitterEngine getHomeTimelineSinceID:0 startingAtPage:0 count:20];
[token release];
...
}

And that’s it. Now, you should be able to run your own Twitter Client.

Our next step is to integrate additional features for the support of Tweetflows, which are part of the research by Martin Treiber in the context of Web based crowdsourcing.

your coding and collaborating ikangai team

Crowdlearning with Students

December 21st, 2010 by Martin No Comments

Inspired by an article that investigated crowdsourcing in the context of proofreading and shortening of (scientific) texts, I have been thinking on how to integrate the idea of crowdsourcing into the teaching of my group. We have already implemented an agile method: regular SCORE project meetings, in which students give a short summary of their project-related activities. During the meetings, students start to discuss with each and get interested in the work of other students. At the same time, students write about their progress and post these reports on the dsg blog. However, there are sometimes ambiguous descriptions in the blog posts as well as grammar mistakes. These are typically corrected by the supervisor. In order to strengthen the work among students and help them to learn from each other, we propose the application of crowdsourcing principles to help students correct each other’s blog entries. In order to support the communication, we intend to use Twitter as a communication medium between students.

The proofreading process works as follows: upon completing a blog entry, the author (student1) tweets it and asks the followers (the other students) to proofread the blog entry and post corrections:

[sourcecode autolinks="false" light="true"]SR #document.proofread <url> [3..5] [/sourcecode]

The url points to the document that requires proofreading. The expression in the square brackets denotes that a minimum of three independent proofreading services are required. If a student decides to make corrections, s/he announces it thus:

[sourcecode autolinks="false" light="true"]SC @student1 #document.proofread <url> [/sourcecode]

If this response (made by student 2) is accepted by the originator of the request, then an acknowledge tweet is posted:

[sourcecode autolinks="false" light="true"]AC @student2 #document.proofread <url>[/sourcecode]

When the corrections are completed, the corrected document is created as a text resource and the link to the corrected text is tweeted:

[sourcecode autolinks="false" light="true"]SF @student1 #document.proofread <url>[/sourcecode]

The correction itself can have many different formats, we suggest to use simple text-based format as shown below:

Pinciples of Oriented Architecture are well adopt for realizing complex distributed Service-based applications (SBA). In this paper, study the applicability of SOA principles for mobile domain with respect to existing infrastructures like App and Apps on mobile devices.
We present both an approach and a middleware platform for the discovery and the invocation of mobile services and show how social aspects of the user can be utilized in such a set- ting.

==correction==
Principles of Service Oriented Architectures are well adopted for realizing complex distributed Service-based applications (SBA). In this paper, we study the applicability of SOA principles for the mobile domain with respect to existing infrastructures like App Stores and
Apps on mobile devices. We present both, an approach and a middleware platform for the discovery and the invocation of mobile services and show how social aspects of the user can be utilized in such a setting.
==correction==

If parts of the text are unclear, an explanation can be requested. If the text is longer than a tweet, an external document can be created, containing the part of the text that needs clarifications or additional explanations:

[sourcecode autolinks="false" light="true"]SR @student1 #document.explain.SBA? <url>[/sourcecode]

The explanation is tweeted as follows (again, it the explanation is longer than a tweet, an external document is created) :

[sourcecode autolinks="false" light="true"]SF @student2 #document.SBA.explained <url>[/sourcecode]

If no further clarification is required and the explanation is accepted, then the following tweet is posted:

[sourcecode autolinks="false" light="true"]AC @student1 #document.SBA.explained <url>[/sourcecode]

The same principles can be applied for all other text-related modifications. For example, if links are missing in parts of the text, this is posted like this:

[sourcecode autolinks="false" light="true"]SR @student1 #document.add.Link? <url>[/sourcecode]

If a link is added, this is tweeted as follows:

[sourcecode autolinks="false" light="true"]SF @student2 #document.Link.Added <url>[/sourcecode]

If the request is accepted, but no link is added (but on a later time), this is posted like this:

[sourcecode autolinks="false" light="true"]AC @student2 #document.Link.Added <url>[/sourcecode]

The basic interaction scheme follows a simply request/reply pattern: [sourcecode autolinks="false" light="true"]SR <servicename>"."<verb in present tense>"."<object>"?"[/sourcecode] is used for requests – the corresponding response is AC/SF [sourcecode autolinks="false" light="true"]<servicename>"."<object>"."<verb in past tense>[/sourcecode]. This interaction scheme matches the command message pattern and is a well adopted enterprise integration pattern.

Your ikangai science team

Presenting Tweetflows

November 19th, 2010 by Martin No Comments

your ikangai science team

Twitter Communication Primitives

November 17th, 2010 by Martin No Comments

As discussed in previous posts, Twitter turns out to be a quite useful supplement to traditional conversation means for projects. The Project Tokyo team, for example, uses it for coordinating their work and people can track their activities by looking at project-related tweets. However, we’ve realized that some the existing Twitter communication primitives need further refinement. Thus, we began to refine some of our Twitter-related communication primitives and patterns. Our existing pattern models sequential activities (actions) that are represented by tweets. We encapsulate the description of these sequential activities (actions) in what we call Tweetflows. A Tweetflow consists of one or more Tweets with a special header – TF – which marks Tweetflow Tweets. This is very similar to existing Twitter primitives, like Retweet (RT). To give you an impression of how Tweetflows work, we give you a simple example. The Tweetflow below calls a translation service that translates the last Twitter Blog entry into German and then calls a transformation service that transforms the text into a Latex file.

TF @ikangai #translation.translate[en, de] http://bit.ly/9tN3kz | @martintreiber #transform.textLatex

There are more details to this example which need to be discussed, like using “@” for addressing a service – a service provider respectively – or storing the result of the service execution. We will address these issues in a future post when we discuss our software prototype that is able to handle Tweetflows.

your tweeting ikangai science team