Mobia Modeler: Easing the Creation Process of MobileApplications for Non-Technical Users

FlorenceBalagtas-Fernandez

Media Informatics GroupUniversity of Munich

florence.balagtas@ifi.lmu.de

Max TafelmayerMedia Informatics Group

University of Munichmax@tafelmayer.de

Heinrich HussmannMedia Informatics Group

University of Munichheinrich.hussmann@ifi.lmu.de

ABSTRACTThe development of mobile applications has now extendedfrom mobile network providers into the hands of ordinarypeople as organizations and companies encourage people tocome up with their own software masterpieces by openingup APIs and tools. However, as of the moment, these APIsand tools are only usable by people with programming skills.There is a scarcity of tools that enable users without pro-gramming experience to easily build customized mobile ap-plications. We present in this paper a tool and frameworkthat would enable non-technical people to create their owndomain-specific mobile applications. The tool features asimple user-interface that features configurable componentsto easily create mobile applications. As a proof of concept,we focus on the creation of applications in the domain ofmobile health monitoring. In the future, we would like toextend our work to cover other domains as well.

Author Keywordsmobile application, modeling tools, domain-specific model-ing, user-centered design

ACM Classification KeywordsH.5.2 Information interfaces and presentation: User Inter-faces—Graphical User Interfaces; D.2.2 Software Engineer-ing: Design Tools and Techniques—User Interfaces, Evolu-tionary prototyping; D.2.6 Programming Environments: Graph-ical Environments

General TermsDesign, Experimentation, Human Factors

INTRODUCTIONWith the mobile phone gaining ground in being the most ac-cessible computing device [5], applications for such devicesare no longer limited to be created by mobile phone com-panies alone, but are now extended to anyone with the right

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.IUI’10, February 7–10, 2010, Hong Kong, China.Copyright 2010 ACM 978-1-60558-515-4/10/02...$10.00.

skills and motivation (e.g. Android platform, iPhone plat-form). However, like any other programming task, devel-opment for mobile devices is a complicated job. Therefore,we proposed [1] to apply the model-driven development ap-proach in creating such applications. In this approach, anapplication is generated by first creating a model of the ap-plication and later on transforming the model to platform-specific code through transformation tools. The main focusof this paper is to discuss the Mobia Modeler which is a toolthat enables users without programming experience to eas-ily build mobile applications through modeling. The MobiaModeler serves as the front end of the Mobia Frameworkwhose two major components are the modeler mentioned,and the Mobia Processor which is responsible for transform-ing the models into platform specific code. We followed auser-centered iterative design approach in the developmentof the modeler’s user interface. There have been variousdesigns in the past as mentioned in our previous paper [2],which were tested and lead to improvements that were fi-nally applied to the current design. The design of the MobiaProcessor and the process that the model goes through in or-der to generate the final code will also be presented.

RELATED WORKVarious systems allow people with no technical expertise todevelop applications. Examples are, ESPranto SDK fromVan Herk et al. [10], Vegemite from Lin et al. [7], UI Finfrom Puerta et al. [9], and MAKEIT from Holleis et al. [5].Our work is similar to the researches mentioned in a waythat we want to create an environment that would help userswith limited technical knowledge, create useful domain spe-cific applications. However, the difference between the Mo-bia Framework from the mentioned related work is that, thefocus is not only on the usability of the modeler for non-programmers, but in the design of the underlying frameworkas well such that it can be easily extended to support othertypes of applications for such mobile environments in thefuture.

MOBIA FRAMEWORK USE-CASE SCENARIOIn order to fully understand how non-technical users canbenefit from using a tool like the Mobia Modeler, we presentin this section an example scenario in the area of mobilehealth monitoring.

Increasing Quality of Life with Mobile Health MonitoringThere has been an increased awareness of people with re-gards to their health. Many technological devices are be-ing created in order to aid people in their goals for betterhealth. Some tools [3] aim to aid people in keeping trackof their physical activities and at the same time motivatingthem through visual and/or audio feedbacks. Others tools[8] help people with existing health problems by monitoringand analyzing physiological signals. However, the problemwith these existing applications and tools is that they alreadycontain predefined displays and functionalities. It would bea big help if there was a way to customize these types of ap-plications depending on the type of health related issues thatare to be addressed by such applications without the need todo low-level programming. A tool like the Mobia Modelerwould be useful in order to achieve this.

Giving the Power to Create: The Target Users

Figure 1. The Mobia Framework and its use cases

As we have mentioned in our conceptual paper [1] about ap-plying domain specific modeling for mobile health monitor-ing, different types of people can benefit from a tool like theMobia Modeler. Domain experts in the field of healthcaresuch as doctors, nurses and clinical technicians can createcustomizable applications for their patients. Other domainexperts such as people in the field of medical research canalso make use of the tool for their own purposes. Other typesof users for the Mobia Modeler are ordinary people who arejust concerned about their own well-being and would liketo create their own applications for monitoring their health.For clarification purposes, we want to emphasize that theusers we mentioned here are the people who create the ap-plication using the Mobia Modeler. They may be the user ofthe final application (e.g. ordinary people creating applica-tions for themselves), or they may create the application forother users (e.g. healthcare experts creating the applicationfor their patients). Figure 1 shows an overview of the wholeMobia Framework and its use cases.

Health Monitor: A Sample ApplicationThe scenario discussed is adapted from Leijdekkers et al. [6].A doctor monitors his clinically obese patient by keepingtrack of his nutrition, physical activities and heart rate. Hewants to ensure that his patient is eating the right foods anddoing the assigned exercises by getting a daily update onthe patient’s food intake and physical activities. Since thepatient just recently had a heart attack, the doctor wants toensure that the heart rate does not go over 120 bpm for thenext 30 days. In case this happens, the doctor would like tobe notified via his pager. He also configures the application

to call an emergency number when the patient’s heart rategoes up beyond 150 bpm [6].

THE MOBIA MODELERThe main design idea for the Mobia Modeler is configura-tion over combination. This means that instead of buildingmobile applications by assembling individual user interfaceelements on the screen, users can just add components tothe model and configure these artifacts based on the applica-tion requirements. We call these components ConfigurableComponents. The formal definition of configurable compo-nents in the context of Mobia is: it is a logical container formultiple user interface elements that has a clearly definedmeaning and acts as a whole, and which functionalities canbe modified through simple configuration. The approach ofconfigurable component-based design has been applied tomany areas in software and embedded systems. However,according to Fernando et al. [4], there are still issues thatneed to be addressed in the design of such systems. Thekey issues emphasized pertain to the attribute-dependent cat-egorization of components, the development and storage ofcomponent configurations, and how to provide guidance tothe developer/user to choose the right components [4]. Weaddress the issue of categorization mentioned by Fernandoet al. [4] by grouping configurable components in the Mo-bia Modeler into: Basic, Structure, Sensor and Special (seetable in figure 2). The issues of development, storage anddeveloper guidance will be addressed in the next sections.

A Step-by-Step Guide into the Mobia ModelerThe modeler starts with a wizard which helps the user con-figure the modeler’s general user interface and supportedfunctionalities. This is the time where the tool collects do-main specific properties (e.g. domain, users) and adapts thetool base on the supplied information. The modeler’s inter-face (figure 3) is composed of three main parts: the MainArea, the Menu Bar and the Side Bar. The Main Area isthe only view used by the Mobia Modeler for modeling mo-bile applications. Previous studies [11][2] conducted sup-ports this single view design since it increases the learnabil-ity of an application. The Side Bar contains elements thatrepresent the different configurable components which aregrouped according to the four types mentioned in the pre-vious section, and can be added to the screens in the MainArea. To guide users, not all configurable components areavailable at a given time. Some are disabled depending onthe current state of the model. The sidebar can be adaptedindirectly through settings made in the configuration wizardduring the creation of a new application. The Menu Bar islocated at the top of the Mobia Modeler’s user interface andcontains additional functions. All the menu items shownin figure 3 are already supported in the current version ofthe Mobia Modeler except for the Simulation function. Thecreated model can be saved and loaded either through theserver or as a local copy. Components can then be added tothe main area depending on the application the user wantsto create. Each component can be configured by clickingon the pen symbol (see figure 3) on top of each component.Aside from tool tips, the Mobia Modeler also offers visualhints to the user such as the change in color of a config-

Figure 2. Examples of Component types

Figure 3. (left) The Mobia Modeler with the Health Monitor sample application model and its (middle) serialized form. (right) The design of theMobia Processor and the whole code generation process.

urable component if the default values have been changed,or by disabling components in the Side Bar to prevent usersfrom doing invalid moves. Finally, the graphical model canthen be serialized into some XML format (see figure 3) thatis an important data used for processing the model into codewhich is the topic of the next section.

From Model to Code: A Look into the Mobia ProcessorIn our previous paper [1], we have discussed an overviewof the initial design of the Mobia Framework including itscomponents. In this section, we will elaborately discuss theMobia Processor component of the framework and the stepsneeded to achieve code generation (figure 3).

The process starts when the application model (Mobia PIM(Platform Independent Model)) is exported from the MobiaModeler. The Mobia Manager then loads the informationfrom the Mobia PIM into the runtime system of the proces-sor. It then calls the Configuration Loader which loads plat-form specific information (e.g. target platform, code genera-tion templates, Mobia metamodel) based on the informationspecified in the Mobia PIM. The Mobia metamodel whichis in the form of an XSD file, contains a general descriptionof a model in the Mobia Framework. The Mobia Processorrelies on the Mobia metamodel to process the PIM file. Forfuture work, we want to use the Mobia metamodel to eas-ily extend the Mobia Modeler in order to support other do-mains, or add/modify currently existing components in themodeler’s interface. The Model Mutator then processes theMobia PIM and transforms them into Mobia PSM (PlatformSpecific Model). The difference between Mobia PIM andMobia PSM is that the Mobia PSM contains additional infor-mation that is targeted towards a specific platform. The ter-minologies PIM and PSM are borrowed from Model-DrivenArchitecture (http://www.omg.org/mda). The Model Muta-

tor then passes the PSM object to the Apache Velocity En-gine (http://velocity.apache.org/) which merges the informa-tion from the PSM and the code templates to generate thefinal source code. The Mobia Manager then calls the MobiaArbiter which is responsible compiling and deploying thefinal application.

EVALUATION THROUGH QUALITATIVE USER STUDYA qualitative user study was conducted in order to identifyissues that arise from the current design of the Mobia Mod-eler and find ways to improve it. There were 16 partici-pants in the user study (7 males, 9 females) with the aver-age age of 30. All of the participants have experience incomputer usage. 10 of them have no experience in program-ming, while the other 6 use programming in their respectiveprofessions. Although none of the participants have expe-rience in using mobile health monitoring applications, theyclaim that they understood the concept. In order to evalu-ate the different features of the Mobia Modeler, we observedhow the participants interacted with the modeler during theexploration phase and combined it with the participants’ an-swers during the interview (see figure 4). Comparing theviews from the two types of participants (programmers andnon-programmers or the non-technical people), in terms ofunderstanding the general concepts, usability and design ap-proach of Mobia, it scored higher in the programmers’ groupas compared to the non-programmers. The variance betweenthe answers of the people in the non-programmers group isalso higher which correlates to the different experiences thatthe participants in this group have.

SUMMARY AND FUTURE WORKWe have presented in this paper the Mobia Modeler whichaims to allow non-technical users to create domain-specificmobile applications through modeling methods. We also

Figure 4. Comparing feedback from non-programmers (non-technicalpeople) and programmers with regards to the Mobia Modeler and itsconcepts

briefly described the design of the Mobia Processor whichworks together with the Mobia Modeler in order to gener-ate platform specific code. We combined the use of modelsand configurable component-based design is our approach.However, our work still has issues which need to be resolved.

• Provide Richer User Experience and Help. Users ingeneral are more encouraged to work on a certain task ifthey see immediate feedback. One thing that is currentlymissing in the modeler is the simulator that shows the ba-sic functionality of the application being modeled. An-other thing that can be added is to provide templates orpre-made models that the user can explore in order to seethe capabilities that can be done with the tool. Support forPlug-and-Adapt which automatically adapts the interfacebased on detected hardware components (similar to [10])would also ease the initial configuration process.

• Support for Other Domains and Components. The un-derlying Mobia metamodel which is in the form of anXSD file, influences how the Mobia Processor deals withthe generated model for code generation. The next planis to automatically generate and adapt the modeler’s inter-face based on the changes to the metamodel. To furthersimplify the task, a separate tool may be created such thatnew domains and its constructs can be added to the mod-eler without having to manually edit the XSD file.

• Support for Multiple User Types. The current targetusers of the front end (modeler) of the Mobia Frameworkare novice users. However, as they mature and becomesemi-skilled users, there should be a way to address theirgrowing needs. More research has to be done in terms ofadapting the tool to accommodate this change in expertise.

• Experience Report. Getting feedback from the targetusers/domain experts with regards to the practicality ofusing the tool for their respective fields is another impor-tant thing that needs to be done in the future.

• Verification and Validation of Generated Artifacts. Test-ing and verification of the models generated by the MobiaModeler and the code generated by the Mobia Processorstill needs to be done.

REFERENCES1. F. Balagtas-Fernandez and H. Hussmann. Applying

domain-specific modeling to mobile health monitoringapplications. Information Technology: NewGenerations, Third International Conference on, pages1682–1683, 2009.

2. F. Balagtas-Fernandez and H. Hussmann. Evaluation ofuser-interfaces for mobile application developmentenvironments. In Human-Computer Interaction. NewTrends, volume 5610/2009, pages 204–213. SpringerBerlin/Heidelberg, 2009.

3. F. Buttussi and L. Chittaro. Mopet: A context-awareand user-adaptive wearable system for fitness training.Artif. Intell. Med., 42(2):153–163, 2008.

4. L. F. Friedrich, J. Stankovic, M. Humphrey, M. Marley,and J. Haskins. A survey of configurable,component-based operating systems for embeddedapplications. IEEE Micro, 21(3):54–68, 2001.

5. P. Holleis and A. Schmidt. Makeit: Integrate userinteraction times in the design process of mobileapplications. In Pervasive ’08: Proceedings of the 6thInternational Conference on Pervasive Computing,pages 56–74, Berlin, Heidelberg, 2008.Springer-Verlag.

6. P. Leijdekkers and V. Gay. Personal heart monitoringand rehabilitation system using smart phones. In ICMB’06: Proceedings of the International Conference onMobile Business, page 29, Washington, DC, USA,2006. IEEE Computer Society.

7. J. Lin, J. Wong, J. Nichols, A. Cypher, and T. A. Lau.End-user programming of mashups with vegemite. InIUI ’09: Proceedings of the 13th internationalconference on Intelligent user interfaces, pages97–106, New York, NY, USA, 2009. ACM.

8. N. Oliver and F. Flores-Mangas. Healthgear: Areal-time wearable system for monitoring andanalyzing physiological signals. In BSN ’06:Proceedings of the International Workshop onWearable and Implantable Body Sensor Networks,pages 61–64, Washington, DC, USA, 2006. IEEEComputer Society.

9. A. Puerta and M. Hu. Ui fin: a process-orientedinterface design tool. In IUI ’09: Proceedings of the13th international conference on Intelligent userinterfaces, pages 345–354, New York, NY, USA, 2009.ACM.

10. R. van Herk, J. Verhaegh, and W. F. Fontijn. Esprantosdk: an adaptive programming environment fortangible applications. In CHI ’09: Proceedings of the27th international conference on Human factors incomputing systems, pages 849–858, New York, NY,USA, 2009. ACM.

11. M. Q. Wang Baldonado, A. Woodruff, andA. Kuchinsky. Guidelines for using multiple views ininformation visualization. In AVI ’00: Proceedings ofthe working conference on Advanced visual interfaces,pages 110–119, New York, NY, USA, 2000. ACM.