IKANGAI Solutions. e.u.

Mobile Business Solutions

Posts Tagged ‘Tweetflows’

Testing a Mobile Process Syntax

May 17th, 2013 by Martin No Comments

In our last post, we introduced an alternative syntax for describing mobile processes. Now, we are facing the challenge of getting feedback from users. We are contemplating two directions. The first one is to create a Amazon Mechanical Turk Task and ask Turkers what they think about the syntax. We have done this in the past with the basic Tweetflow syntax and we got results really quick. The second one is to built an actual editor and include it in our app qlauncher. The second alternative is to implement an editor (which is a lot of work) and to test it directly in the app. This approach has the main challenge how to include test cases and how to motivate people to use the syntax. We are looking into games where users can “play” with the syntax. This needs obviously a game to play with and we haven’t found the right game to play . Maybe, people could CREATE a simple game with this syntax.

We have tinkered with the syntax and modified it a bit to distinguish context from the rest:

|A|—■———————|
|B|———■—————|
|C|—————■———|
|<—{geo=vienna}—>|

This gives us the possibility to attach different context for different parts of the process and to modify each process according the context:

|A|—■———————|—■———————|
|B|———■—————|———■—————|
|C|—————■———|—————————|
|<—{geo=vienna}—>|<—{geo=rome}—>

Our idea is based on previous work where we introduced the concept of context channels. We plan to extend this work towards social tuple spaces that work well with Tweetflows and hopefully will us help to come up with the final design for the mobile process language description.

your ikangai science team

RFC: Mobile Process Syntax with ASCII Art and Sheet Music

May 15th, 2013 by Martin No Comments

Designing a lightweight syntax for mobile processes/workflows is an interesting challenge. In particular, if you want to design the process ON the mobile device, especially on a smartphone.
There are several constraints that need to be taken into account, but the most important one is certainly the limited screen size of smartphones. We have experimented with a free form editor prototype for Tweetflows in the past and presented our work at SAC 2012:

A graphical notation with circles representing activities and arrows connecting to connect them is certainly very attractive for users, but requires a considerable amount of meta data for the graphical representation and obviously editors that are able to handle the meta data. This transforms directly into the requirement of distributing the editor to a large number of mobile users. This is of course possible and we are already having a (test-)user base of more than 40.000 users for Tweetflows with our app q·.:Launcher. This app includes a basic parser for Tweetflows, but doesn’t include an editor.

For the editor, we were looking into an alternative direction, that is inspired by ASCII art sheet music and Gantt Charts. The idea is to treat a software composition just like a piece of music and describe it in a similar manner. Notes represent activities and their relative position to each other. The example below shows a sequence activities A, B and C.

|A|—■—————||
|B|———■———||
|C|—————■—||

Splits and joins can be described in a very concise manner. In the example, A is followed by B and C in parallel and then D is executed:

|A|—■—————|
|B|———■———|
|C|———■———|
|D|—————■—|

The challenge are if then else constructs and loops. Both require conditions that need to be evaluated and described in the composition. Music sheets are not designed to represent conditional expressions, so we need to add additional meta information as well. We are not yet sure how to solve this challenge in an satisfying manner. One approach is to include this as extra lines on the bottom of the description as shown below which describes the a loop containing the activities A, B and C that is executed while the condition geo=vienna evaluates to true:

|A|—■—————|
|B|———■———|
|C|—————■—|
|L{geo=vienna}—|

One potential direction is to look into mechanisms like loop unrolling. We are not sure which direction to look and comments are more than welcome!

your ikangai science team

Mobile Business Processes

April 2nd, 2013 by Martin No Comments

Everybody goes mobile. According to reports from various sources like this one, we will witness mobile Internet use surpassing Desktop Internet use in 2015.
This development has tremendous impact for businesses. When people use the mobile Internet, they will expect the same on their workplace. Why? Imagine entering a workplace like the one shown below:

It is certainly charming to go back in history when going to work. But who wants to work like we did in the past with old technology, when having access to modern (mobile) technology?
As a consequence, companies will have to change their software infrastructure to satisfy the requirements of the mobile Internet. First and foremost, business processes must be adapted to support mobile devices. That is, the software that drives business processes must be able to communicate with mobile devices. Since mobile devices are not online all the time, business process communication needs to be decoupled in space and time. Secondly, the process communication language needs to be lightweight and both, human- and machine-readable. This means, that the effort for parsing incoming requests from the business process must be minimal and close to natural language. One reason is that requests must be sent over different communication channels like short messaging or push notifications which are both read by persons.
The third reason is that the effort to integrate software services with persons must be minimal: it is certainly not desirable to have a person translating a business process request manually into a (XML) representation and to invoke a software service.
Finally, business organizations will undergo structural changes and it is very likely that businesses will become organized more like social networks with hub and spokes rather than hierarchies with the CEO being the sole authority.
We are currently developing the software infrastructure and the communication language that satisfies this kind of requirements. The language is already in use in one of our mobile Apps and is called Tweetflows. It is a lightweight coordination language that is both, machine- and human readable. We use a social network infrastructure (Twitter) to decouple the process communication in space and time and simultaneously embed the business process in a social network.
However, based on that what we saw in Austrian companies, the support for mobile business processes is not very advanced: there are some companies that use apps for their salespeople, but these apps are limited in terms of mobile business process support. For example, there is no hook for social network integration and the communication mechanism is typically based on eMail.
We believe that there is going to be a lot of work in the future and we will certainly see interesting developments in this area.

your ikangai science team

Input and Output

March 25th, 2013 by Martin No Comments

We continued to work on Tweetflows. Besides the support for more meaningful commands as we discussed in a previous blog entry, we were thinking of a very basic feature, i.e., of how to actually to implement the output functionality of services that are triggered by Tweetflows. So far, we focused on how to invoke services that are more or less one way interactions like open a web page (SR open.webpage URL), download an app (SR download.moodi URL) or follow a Twitter user (SR follow.ikangai URL).
To give you an example for an request/reply interaction: suppose your receive a Tweetflow command that asks you to decode a QR barcode in a picture and to return the result to the requester. Currently, this is a bit of a hassle: you need to copy the picture into your picture library (or event to print it) and then to scan it. Afterwards, you need to copy the scan result (typically a string) into the clipboard and finally post a Tweet with the result. This certainly works, but is not comfortable at all.
To address this challenge, worked on a layered software architecture that encompasses what we call a social layer. This layer is situated above the business logic layer (i.e., the functions that are available in the app – like decoding barcodes) and below the existing graphical user interface of the app. The social layer is responsible of reading, parsing and writing Tweetflow commands into the timeline of the user. Since Tweetflows require some kind of user interaction (users are always in control and decide which command to execute an which not), the social layer triggers GUI interactions. In the case of q·.:Launcher, if the command SR decode.barcode URL is parsed and the user accepts it, the picture from the URL is downloaded and the scanner engine is asked to decode the picture. If the picture contains a barcode, then the result is presented to the user. The user can now decide if she wants to tweet the result with a Tweetflow command (SF didDecode.barcode URL) or to ignore the result.
It is worth noticing that these kind of control activities might not be necessary in cases like this. Therefore, we could add additional settings that automatically execute Tweetflow commands without aksing the user. We are aware that this is a very delicate thing to do: after all, your app could be executing service requests that you do not approve. So, for the time being, we will continue asking the user directly to execute a Tweetflow command.

your ikangai science team

Tweetflow Commands

March 17th, 2013 by Martin No Comments

We have thought for a long time about Tweetflow commands that should be supported in out prototype app q·.:Launcher. Our idea is to take the capabilities of the device, the social network of the device’s owner and the functions of the app into consideration. Or, put differently: to consider available context information when executing Tweetflow commands. Consequently, Tweetflow commands will be used in three different contexts:

to trigger activities that are built-in device features, like watching a video, downloading a picture or printing a text.
to trigger activities in the social network of the user, like tweeting or posting on facebook
to trigger activities that are built in features of q·.:Launcher like scanning

Here’s a list of commands that we will include in one of the next versions of our Tweetflow prototype in q.:Launcher:

watch.Video
add.Event
add.Contact
write.SMS
write.eMail
print.Picture
print.Text
tweet.Text
tweet.Link
tweet.Picture
post.Picture
post.Link
post.Text
download.Picture
scan.Picture

your ikangai science team

Tweetflows are alive and kicking

March 1st, 2013 by Martin No Comments

Our app q·.:Launcher was approved yesterday and now Tweetflows are available for a broader public beta testphase. We are really curios how many will actually take a look a Tweetflows and if there will be feedback from the users. In the first iteration, Tweetflow commands can be read from the timeline of the Twitter user @ikangai.
There is also a limit concerning the type of Tweetflow commands that are supported by q·.:Launcher: Tweetflows ask user to download Apps, to open web pages or to follow Twitter users. We will work on this and add support for additional Tweetflow commands like asking users to take pictures or to open Google maps with a given location.
If you haven’t already downloaded q·.:Launcher and uses Tweetflows, here is how Tweetflows look like in q·.:Launcher:

your ikangai science team