End-User programming in mobile devices through reusable visual components composition
Tiago Almeida · 2012
An era where smartphones surpassed the s sales has begun [stPSi]. In this era, the end-users (the ones that ultimately use the smartphone) are demanding quantity and complexity from their applications and devices. is demandmakes it impractical for a soware developer to “foresee” every possible combination and explore every valid alternative. A possible solution to make customizable applications is to empower end-users with enduser programming () tools. is “the practice by which end users write computer programs to satisfy a speci c need, but programming is not their primary job function” [LSBM]. at tool could be a collaborative framework, where novices and experts can co-exist and share their implementations, while end-users explore their requirements. With such scenario, expert programmers can create components that end-users can connect using a visual programming language (). Such tool could not only reduce the number of “small”, similar, speci c-tailored applications, but also foster discovery and experimentation by end-users. To construct this tool we start with an analysis into the problems we have to solve. Studies in the gave us a start with six recurring problems end-users have [KMA]. Next, we went further and explored another area: End-User Soware Engineering (). tries to embed soware engineering concepts into solutions [KAB]. Additionally we analyzed s since they can be a good solution for [WNF]. is analysis was followed by a summary of the s properties, and some examples of s usage. With the gathered knowledge, we created a prototype for Android to study how end-users percept and accept a in a smartphone. In this prototype end-users can connect blocks and create tasks. ose tasks can be shared and reused, and they depended on events generated by the smartphone. With this prototype we tried to provide answers to questions such as: Can we implement a in a small screen? What is the necessary level of abstraction so we don’t confuse end-users and we don’t limit expert programmers? How can we integrate task reusing with block reusing without confusing end-users? We made several changes in our prototype because of end-users’ feedback. However, when some of the improvements weren’t done because we felt limited by Java’s language. To surpass this limitation we conducted some experiments where we tried to combine Java with Prolog, and Java with Scala. ose experiments allowed us to create a rewrite rule system to automatically group blocks according to a set of rules de ned by expert programmers.