LondonTube: Overcoming Hidden Dependencies in Cloud-Mobile-Web Programming Christopher Scaffidi 1, Andrew Dove 2, Tahmid Nabi 1 1 Oregon State University 2 National Instruments

2 Health scientists have often requested help with creating cloud-mobile-web apps How to make creation of simple cloud-mobile-web apps so easy that non-CS researchers could do it?

3 Status quo: Creating cloud-mobile-web apps by writing programs that exchange data App code Server code Browser code

4 A major problem: Hidden dependencies Component-to-component App-to-server Server-to-browser Within-component Functions that asynchronously call functions that asynchronously call functions

5 Cognitive Dimensions A useful tool for discussing design tradeoffs A key issue in that code example… Hidden dependencies : Important relationships not made obvious by the language and/or tools Most general available solution? Secondary notation : Embed comments explaining what the language and tools fail to make obvious

6 Object-oriented, Java-like A language idea inspired by home health-monitoring proposal

7 Object-oriented, Java-like A language idea inspired by home health-monitoring proposal Potential benefits -Role expressiveness (An API or language element for each purpose) Potential liabilities -Hidden dependencies -High abstraction gradient (Need to learn many concepts, e.g., OO classes)

8 Event-oriented, English-like A language idea inspired by asthma-monitoring project

9 Event-oriented, English-like A language idea inspired by asthma-monitoring project Potential benefits -Lower abstraction gradient than Java-like Potential liabilities -Dependencies are still fairly hidden

10 Visual dataflow, LabVIEW-like A language idea inspired by proposal to study impacts of vitamin C

11 Visual dataflow, LabVIEW-like A language idea inspired by proposal to study impacts of vitamin C Potential benefits -No more hidden dependencies -Potentially low abstraction gradient Potential liabilities -Diffuseness, verbosity (May need many symbols and space to display code)

12 LondonTube example program

13 Structured Dataflow Nodes represent pieces of executable code Wires represent passing data from one node to the next A node executes when all of its inputs are ready and when it is finished produces it outputs Structured data flow adds flow control elements on top of that For loop executes its contents n times o Shift registers pass data from one iteration of the loop to the next Case structures represent branching Inherently parallel because any node can run as soon as its inputs are ready

14 LondonTube Hybrid paradigm Structured dataflow with actors Distinctive language elements Device structures Event structures Sensor nodes Database nodes UI Diagram structures

15 Server (cloud, intranet, etc) After a scientist draws LondonTube code and hits "Run" on the code editor menu… Editor Compiler Deployment subsystem Browser- based runtime Browser- based runtime In-memory runtime App-based runtime Java-based execution stack: Tomcat (J2EE) JRE MySQL backend Desktop browsers Embedded browser Player BP and FP files (JSON) Generated JavaScript Data exchange facility Serialized messages (JSON) Mini-Player

16 Empirical evaluation 6 participants, 2 in each of 3 conditions Session #1: CS students using traditional tools Session #2: CS students using LondonTube Session #3: Non-CS students using LondonTube Each condition: 1 undergraduate, 1 graduate student All CS students had completed a 1-term course on mobile+cloud development and/or mentorship All conditions started with a 3-hour tutorial o Reviewing material from the cloud+mobile course (Session #1) o OR training in comparable LondonTube concepts (Sessions #2, #3)

17 Programming task Specification Read accelerometer’s magnitude every few minutes Send to cloud for storage in database Display all values in chart on browser Session #1 participants could use any tools they liked Undergraduate chose o Google App Engine in Java o iOS Simulator (w/ via 3 rd party accel. library) in Swift Master’s student chose o Google App Engine in Java o Android device in Java

18 Time taken on the task (minutes) Traditional tools LondonTube CS undergraduate 240 * 9 CS graduate 240 * 8 Non-CS under-graduate N/A ** 8 Non-CS graduate N/A ** 8 * = didn't finish** = didn't attempt

19 Examples of time-consuming difficulties encountered by students with traditional tools Accelerometry-read not occurring Incorrectly registered asynchronous callback Data not flowing through to server Sending data to incorrect URL parameter Compare to LondonTube Blue wires: automatically handle asynchronous callback between functions on the mobile device Green wires: automatically match up the client to the server endpoint

20 Proportions of questions asked by participants during tutorial or task Networking, 29%

21 Survey (5-point agree/disagree Likert items) How well the notation made hidden dependencies visible “It is easy to see how pieces of code interact with one another” “It is easy to understand a system by looking at its code” “Pieces of code sometimes can affect one another in surprising ways.” Notational consistency among cloud/mobile/browser code “Pieces of code have a similar overall structure to one another” “Pieces of code have a similar visual appearance to one another” “Pieces of code use similar functions (or APIs) to carry out their purpose” Error-proneness of the notation and supporting tools “It is easy to create this code without making errors” “It is easy to tell when this code is correct” “These tools involved making many errors along the way” Learnability of the notation, tools and related concepts “Learning these tools required learning many new concepts” “Learning these tools required learning many new functions (or APIs)” “Learning these tools required thinking in new ways” Usability of the tools Speed of using the tools “Rate the overall usability of these tools” “Rate the overall speed with which these tools can be used”

22 Survey results

23 Related Work Other work with features similar to LondonTube Annotations in text-based environments Visual languages for cloud & web applications "One step" operations in languages for mobile apps Other work suggesting ideas to improve LondonTube Data manipulation Sketching user interfaces Triggering code Reading sensors

24 Future directions Enhanced discoverability of language elements By tools that guide scientists as they create code Easy replication of studies Through whitebox reuse of LondonTube code New forms of debugging support Indicators of where code isn't running well

25 Takeaways Potential to ease creation of cloud-mobile-web apps through integration of dataflow + visual elements Need for apps that monitor sensors, store on cloud, display on browser Students who took a course encountered time-consuming problems when creating a simple app Students using LondonTube were faster, more satisfied, and also less puzzled by dependencies

26 Thank you… To Kyle Sweeney and Laxmi Ganesan, who tested an early version. To USDA (AFRI ) and NIH (R21-ES024718), which funded the creation of components reused as part of LondonTube