DOC PREVIEW
More Natural End User Software Engineering

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1. INTRODUCTIONNEW WORK2.1 Studying Designers2.2 Whyline for Java2.3 API Usability2.4 Understanding Code3. RELATED WORK4. CONCLUSIONSACKNOWLEDGMENTSREFERENCESMore Natural End-User Software Engineering Brad A. Myers, Andrew Ko, Sun Young Park, Jeffrey Stylos, Thomas D. LaToza, Jack Beaton Human Computer Interaction Institute Carnegie Mellon University Pittsburgh, PA 15213 412-268-5150 [email protected] http://www.cs.cmu.edu/~NatProg ABSTRACT The “Natural Programming” project at Carnegie Mellon University has been working for more than 10 years to make programming more “natural”, or closer to the way people think. We have addressed the needs of all kinds of programmers: novices, professionals and end-user pro-grammers. Many studies were performed which provided new insights and led to new models of programmers. From these insights and models, we created new programming languages and environments. Evaluations of the resulting systems have shown that they are effective and successful. This paper provides an overview of the entire 10-year Natural Programming project, but focuses on our new re-sults since WEUSE-III in Dagstuhl. Categories and Subject Descriptors H5.2. Information Interfaces and Presentation – User Interfaces; D.2.6. Programming Environments. D.2.5 [Testing and Debug-ging]: Debugging aids, tracing. D.2.6 [Programming Environ-ments]: Integrated environments. General Terms Design, Human Factors, Languages. Keywords Designer, Interactive Behaviors, Survey, Authoring, End-User Software Engineering, Natural Programming, Programming by Demonstration. 1. INTRODUCTION The Natural Programming Project [33] has been applying human-computer interaction (HCI) techniques to develop and evaluate models and tools to help novice, professional, and “end-user” [32] programmers. We started by studying how people think about programming concepts and algorithms [36, 38]. Participants in these studies did not know how to program, but they were familiar with a variety of computer applications. The goal was for the language to work in the way that people who do not have programming experience (novice programmers) expected. We then used these results to design a new programming language and environment [35, 37]. A summative study showed that it did help novice programmers create programs more easily [37]. Figure 1: The original Whyline for Alice. The “Why” menu is at the top, and the time-line visualization of the answer is at the bot-tom. [19] Next, we performed several studies of programming environment use. One study focused on novice programmers learning to use Visual Basic.NET [21]. Another looked at the influence of the programming environment on the types of errors that users of Alice [39] inserted into their code [18]. In another study, we in-vestigated experienced programmers using Eclipse on several software maintenance tasks [22]. Our observations from these studies led to a number of design ideas for more helpful tools. For example, we designed the Whyline, which allows programmers to ask “Why” and “Why not” questions about their program’s be-havior, in order to help them better understand the causes behind their program’s execution (see Figure 1) [19]. This led to the de-sign of a similar tool, Crystal, which helped end users ask why questions about the behaviors of word processors, including the application’s more complicated features, such as the “styles” mechanism and auto-correction [31]. We also created Mica, which helps programmers solve the vocabulary problem [13] by using Google to find example code and documentation from the words that the programmer can think of [44]. Our Jasper tool [9] allows programmers to select fragments of relevant code, and also Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, re-quires prior specific permission and/or a fee. WEUSE IV’08, May 12, 2008, Leipzig, Germany. Copyright 2008 ACM 978-1-60558-034-0/08/05...$5.00. 30choose other types of data from web pages and write notes about a task. All of this information is collected and presented in a sin-gle place, and saved in a single document, so that it can be re-turned to later and shared with coworkers who might also work on the task. 2. NEW WORK In this workshop position paper, we focus on our new work, even though some of it is more related to professional programmers than EUP. Our earlier EUP systems are well-documented in other papers; those who are interested can see the citations above or our WEUSE-II overview [30]. The four topics on which we are cur-rently working are how designers think about authoring behav-iors, transitioning the Whyline to work for Java, studying how to make APIs more usable, and improving how people understand existing code. 2.1 Studying Designers Designers are skilled at sketching and prototyping the look of interfaces, but to explore various behaviors (what the interface does) typically requires writing scripting code using Javascript, Flash or other programming tools. There have been many previ-ous studies of the processes, techniques and tools that are used by designers, but none has focused on how the interactive behavior of the interface is created and communicated. We conducted field studies of 13 designers, and a web-based survey, which received 231 responses, to investigate the particular issues for the design of interactive behaviors. We particularly focused on people who are not programmers, but rather who are trained and work on Interac-tion Design, Graphics Design, Information Architecture, Experi-ence Design, Visual Design, User Interface Design, or equivalent. Many of our findings confirmed what others have reported in previous surveys, for example that designers prefer to start by sketching (about 97% in our survey), and most designers (88% in our survey) also use storyboards. However, we did find some interesting new results that have not been previously reported: • By a large margin, the participants in our survey agreed that prototyping the behaviors was more difficult than the design of the appearance (86% said prototyping the behaviors was more difficult). • Sketches and storyboards


More Natural End User Software Engineering

Download More Natural End User Software Engineering
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view More Natural End User Software Engineering and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view More Natural End User Software Engineering 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?