- 1 Bjoern's Slides
- 2 Extra Materials
- 3 Discussant's Materials
- 4 Reading Responses
- 5 Valkyrie Savage - 10/31/2011 18:04:25
- 6 Steve Rubin - 11/14/2011 22:04:27
- 7 Yun Jin - 11/15/2011 20:51:06
- 8 Cheng Lu - 11/15/2011 20:53:33
- 9 Galen Panger - 11/16/2011 0:58:25
- 10 Ali Sinan Koksal - 11/16/2011 1:23:46
- 11 Derrick Coetzee - 11/16/2011 4:41:30
- 12 Peggy Chi - 11/16/2011 5:32:51
- 13 Suryaveer Singh Lodha - 11/16/2011 7:14:48
- 14 Laura Devendorf - 11/16/2011 7:41:43
- 15 Allie - 11/16/2011 8:35:22
- 16 Donghyuk Jung - 11/16/2011 8:51:35
- 17 Apoorva Sachdev - 11/16/2011 8:52:26
- 18 Rohan Nagesh - 11/16/2011 8:58:37
- 19 Yin-Chia Yeh - 11/16/2011 8:59:13
- 20 Sally Ahn - 11/16/2011 9:00:42
- 21 Manas Mittal - 11/16/2011 9:00:58
- 22 Shiry Ginosar - 11/16/2011 9:06:50
- Stacksplorer: Call Graph Navigation Helps Increasing Code Maintenance Efficiency. Thorsten Karrer, Jan-Peter Krämer, Jonathan Diehl, Björn Hartmann and Jan Borchers. UIST2011. paper
- HyperSource - Bridging the Gap Between Source and Code-Related Web Sites. Björn Hartmann, Mark Dhillon, and Matthew Chan. CHI2011. paper
Valkyrie Savage - 10/31/2011 18:04:25
Programmers need help, too. There are actually a few sets of people to consider, not least of which is the end user who programs things like spreadsheets. A programmer’s cognitive load can be eased with better tools, no matter who she is.
The excessively long paper by Ko et al. seemed like it had good motivation, but dropped the ball. I was interested to hear about other end-user software engineering situations than spreadsheets, but that was the only example given. I’m certain there are other people, too, who perform similar manipulations who are just being ignored as populations... well, I guess it doesn’t matter. The research overview was interesting nevertheless. A lot of the discussions seemed very “duh” as discussions go: for instance the one about how end user software engineers don’t understand how their programs execute and have a hard time figuring out how to fix them.
There were two bits in the paper that I liked: one was about a rewards cycle that encourages good software engineering and use (surprise, explain, reward) and the other was the discussion of what exactly an EUSE is and how that differs from a professional SE. The remarks about how the requirements stage is murkier for EUSEs than professional SEs made me realize that research is that same kind of sliding scale... although the researching SE idea is sort of a different class again from both of these groups: we are end-users of some software, but deep down we’re all kind of professional SEs, since our work will theoretically be made public at some point. Hm.
The idea of CodeBubbles is intriguing. The software engineer in me revels in that idea, but I’m not certain their execution (or testing) was super great. As far as execution goes, the navigation sounded clunky (perhaps it’s just because I read a textual description of a fundamentally visual process), particularly the use of alphanumeric hotkeys for CBs. I mean, there are a lot of things I’d be doing in Eclipse that involve typing alphanumeric characters that don’t have anything to do with CB navigation. As for their study, the previous paper discussed self-efficacy of people and how it tended to correlate differently with task completion for females. The studies here were based solely on task completion, and they included just one female each in the study group...
Steve Rubin - 11/14/2011 22:04:27
The first paper we read for today's class was a survey of the state of end-user software engineering (EUSE) tools. Because the vast majority of people who program are not professional programmers, ongoing research has attempted to improve various aspects of the software engineering for non-software engineers. The second paper discussed a novel IDE called "Code Bubbles," whose primary philosophy is that when we are working with code, we want to view a working set--groups of methods, for examples--instead of viewing one or two files.
The survey on EUSE covered five main activities that significantly differ between professional SE and EUSE: requirements, specifications, reuse, testing/verification, and debugging. A section on each of these topics covered related research. EUSE is, in many cases, intended to create one-off programs. While the paper acknowledged this, they claimed that such single-use (or personal) pieces of code could often get distributed and become much more prevalent than the original author expected. I bring this up because the whole concept of supporting and improving EUSE kind of seems like nailing jello to a wall. First of all, users are unlikely to know exactly what they want to do when they begin work (see: requirements), so why should they spend their time seeking out tools to improve their yet-undetermined engineering process? It seems like most people would only spend time finding these tools if they had very well-defined tasks in hand. The paper admits that persuading people to both use these tools and to use them correctly is challenging, but I'm not sure if it's the right goal. Unlike professional programmers, end-users are (probably) not going to be hyper-aware of state of the art tools, so all of this research may be going unnoticed by those it would benefit most. In general, end-user software engineers do not classify themselves as end-user software engineers, so there is no systematic way to disseminate this research to them.
In "Code Bubbles," the major abstraction is the bubble. Each bubble corresponds to a single method, so files become largely transparent. This paper was interesting in light of the first paper because it focused on a tool designed for professional programmers. While I like the idea of code bubbles, I am skeptical as to whether it could have a major impact on the IDE scene. It would be going up against competitors like Eclipse and Visual Studio that, while bloated, are very powerful and very widely adopted. They follow the same paradigms as emacs and vim--paradigms that most programmers are comfortable with. Code Bubbles does not offer anywhere near the speed that emacs or vim would to an expert user. All of that aside, I hope that Code Bubbles does see success. The file-based metaphor for programming is, as they say, useful for compilers but not incredibly important for developers anymore.
Yun Jin - 11/15/2011 20:51:06
In this article, they focus on software engineering activities. They start by proposing definitions of programming, end-user programming, and end-user software engineering, focusing on differences in intents and priorities between end-user programming and professional software development. And they follow with a lifecycle-oriented treatment of end-user software engineering research, organizing more than a decade of research on incorporating requirements, design, testing, verification, and debugging into end users’ existing work practices. They then discuss a variety of crosscutting issues in end-user software engineering research, including the role of risk, reward, and domain of practice on end users’ decision-making, as well as strategies for persuading users to engage in more rigorous software engineering activities as part of their normal work. They also discuss individual factors, such as self-efficacy and gender, and their influence on how effectively people use EUSE tools. In the second paper, they propose a novel user interface metaphor for code understanding based on collections of lightweight, editable fragments called bubbles, which form concurrently visible working sets. They present the results of a qualitative usability evaluation, and the results of a quantitative study which indicates Code Bubbles significantly improved code understanding time, while reducing navigation interactions over a widely-used IDE, for two controlled tasks. Qualitative studies indicate that a feature complete IDE based on Code Bubbles would be valuable to professional developers. A quantitative experiment showed significantly improved performance on two code understanding tasks compared to Eclipse, and significantly less time spent navigating. Moreover, they discovered the surprising result that the reduction in performance time could not be attributed to navigation alone, meriting further research into potential cognitive benefits of this approach.
Cheng Lu - 11/15/2011 20:53:33
The first paper, “The State of the Art in End-User Software Engineering”, summarizes and classifies related researches, defining the area of End-User Software Engineering (EUSE) and related terminology. Most programs today are written not by professional software developers, but by people with expertise in other domains working towards goals for which they need computational support. Although these end-user programmers may not have the same goals as professional developers, they do face many of the same software engineering challenges, including understanding their requirements, as well as making decisions about design, reuse, integration, testing, and debugging. The article then discusses empirical research about end-user software engineering activities and the technologies designed to support them. The article also addresses several crosscutting issues in the design of EUSE tools, including the roles of risk, reward, and domain complexity, and self-efficacy in the design of EUSE tools and the potential of educating users about software engineering principles
The second paper, “Code Bubbles”, propose a novel user interface metaphor for code understanding based on collections of lightweight, editable fragments called bubbles, which form concurrently visible working sets. Developers spend significant time reading and navigating code fragments spread across multiple locations. The file based nature of contemporary IDEs makes it prohibitively difficult to create and maintain a simultaneous view of such fragments. The paper presents the results of a qualitative usability evaluation, and the results of a quantitative study which indicates Code Bubbles significantly improved code understanding time, while reducing navigation interactions over a widely-used IDE, for two controlled tasks.
Galen Panger - 11/16/2011 0:58:25
I'm really impressed by Code Bubbles, though I'm surprised that they did not align themselves at all with the tradition of Zooming User Interfaces (ZUIs) or concept maps which have long exploited our spatial recall abilities to navigate our workspaces and ideas. The interface envisioned by the late Jef Raskin, inventor of the Macintosh, was that your documents on your workspace would be laid out and grouped, and you'd simply zoom in to work with the specific content (in this world, there are no applications, only functionality).
The benefits for navigation and for side-by-side analysis and comparison are huge. I would love to try Code Bubbles (I may, next time I code in Java!)—the ease of grouping bubbles AND functionality like documentation and debugging to me is revolutionary. It's much, much better to debug with your object parameters in a bubble next to your code than it is to have to navigate through a sidebar to figure out what your parameter values are.
I agree that we spend way too much navigating between code fragments to compare them, copy-and-paste, etc. That's a really big deal. The tradeoff, however, is long-term maintenance of the workspace. Typical file-based workspaces arrange your files alphabetically, etc. There's nothing really to maintain; in contrast, once a workspace grows it can be difficult and costly in time to maintain proper and logical arrangement (just think about how you arrange and organize your house!).
I might also begin to chafe at the small-ish bubble size and opt for a larger/longer default view. Still, for specific programming tasks, Code Bubbles is a big win, and the user testing proves it.
Alternatively, I wonder what would happen if Code Bubbles moved the programmer fully into a bubble world, where there was no visible file system. With an infinite Zooming User Interface, things like API includes/headers could be represented as bubbles that could be consulted or re-arranged. Each function could be a single bubble, and would connect visually to anything it called and anything that called it. Just a thought!
I was not as impressed by the End-User Software Engineering article, though I did appreciate the personal-public use distinction/continuum, and the concerted effort to define what is different about EUSE from professional software engineering.
Ali Sinan Koksal - 11/16/2011 1:23:46
Today's first paper is a thorough survey on end-user software engineering techniques. End-user programming, in contrast with professional programming, consists in users achieving programming tasks for solving their own problem and not offering this software as a service to a large community. Research in end-user software engineering is explored in terms of software engineering themes, such as requirement capture, design, code reuse, testing, verification and debugging.
The theme of "path of least resistance" can be revisited here in the context of design processes. EUSE tools can have great value if they encourage good designs, in other words exploit user laziness to impose good principles. I think that domain-specific languages are a great way to help EUSE. By restricting the language, the users can be guided to write simple, clear programs at a high level, while a compiler / synthesizer underneath can have enough freedom to implement the low-level details in a manner that increases efficiency. Such high-level languages can also ease the task of verifying code, as I witnessed in one of my former projects on a high-level amenable to verification, intended for scientists to explore sparse matrix formats for efficient matrix operations.
The second paper is a work on providing a programming interface for improved code understanding. Code Bubbles offer a simultaneous view of multiple code fragments, with a minimal design that exploits space very well, in a large workspace. The system is evaluated both qualitatively (which, for instance, showed that developers did not seem to disturbed by not being able to see whole source files) and quantitatively, showing that the technique significantly improves code understanding on a bug fixing scenario.
The minimal design, and the automatic layout of code fragments to improve spatial efficiency were interesting aspects of the system for me. I also found the evaluation to be rigorous, which is another strong point of the work that I appreciated.
Derrick Coetzee - 11/16/2011 4:41:30
Today's readings discussed user interfaces for software development.
The first work by Ko et al is a broad survey of end user programming, which is done incidentally to support a domain task and is often performed by non-programming specialists. It discusses software engineering issues like requirements and specification, testing, and code reuse in the context of end user programming and discusses social aspects and persuasive methods that are unique to this area. It omits much discussion of implementation/construction, which has been covered by other surveys.
Of the wide variety of works surveyed, many of which I was already familiar with, I was particularly interested in tools to support finding code for reuse and managing code snippet databases, and in the Surprise-Explain-Reward method of persuading users to use a beneficial feature. I was intrigued by WYSIWYT testing visualization and would like to see this kind of continual test feedback in other development environments.
On the negative side, while at the outset they endeavored to carefully define "end user programming" in terms of intention and separate it from notions of inexperience or domain specificity, in the end they fell victim to conflating these. For example, table 2 characterizes end-user programmers as being overconfident about testing and debug opportunistically, but expert programmers exhibit these problems to a much lesser degree if at all. I was also confused about their discussion of "tailoring," which seems to be merely reframing customizable applications - which include nearly all professional applications - in terms of an asynchronous collaboration between developer and end user.
Additionally, the work is targeted at an advanced HCI audience and this makes it inaccessible to many of the end user programmers under discussion, who might otherwise be able to offer feedback or ideas about how to make progress in this area of research.
The second work by Bragdon et al discussed Code Bubbles, a novel user interface for professional programmers that allow many editable source code fragments from different locations to be on screen at once.
Based on my own experience with commodity IDEs, I found all the features of code bubbles exciting. The ability to not only view all of one's working set at once, but to view files and debug data as they existed in the past, switch between working sets easily, share working sets with others remotely, and preserve working sets indefinitely for revisiting later would all have been invaluable in my day-to-day work. I was also impressed by analysis features like finding paths between functions. I'm trying out the Visual Studio plug-in Debugger Canvas and plan to sign up for the upcoming beta.
The use of functions as the primary "bubble units" may prove problematic in situations where functions are very large - neither vertical elision nor a scrollbar are very elegant solutions. It may also be problematic for functions that don't have enough context by themselves, or simply aren't a natural way to think about the problem. However, this doesn't seem like a fundamental limitation.
With any system that does dynamic reformatting/reflow of code, a danger is that users will unwittingly mess up the underlying "real" formatting when trying to manually change the formatting of code. Most professional projects have strict style guidelines, and reformatting changes can obscure more important changes in version control systems. Dealing effectively with this may require either forcing users to expand the bubble to alter formatting, or abandoning the use of manual formatting altogether.
A YouTube commentor (Dessimat0r) suggested that the system would be more useful if it could incorporate unit testing as well - for example, if you could easily view and run all tests exercising a function, or pop up all tests that are currently failing. In general testing support would be a welcome extension.
Peggy Chi - 11/16/2011 5:32:51
The End-User Software Engineering (EUSE) paper discussed the needs of a better support to end-user computational environments (broader scope), in addition to the programming activity (narrower scope). End-user programming and programming by example have been explored for a long time. Though I'm not too clear how EUSE differs (and wonder why most examples seem outmoded), I expect that the day everyone can easily program comes.
Suryaveer Singh Lodha - 11/16/2011 7:14:48
Code Bubbles: A Working Set-based Interface for Code Understanding and Maintenance
The basic idea of this approach is to show code in fragments. The methods and classes are shown in bubbles, as opposed to the traditional file based views prevalent in current IDEs. It is also easy to link, group, arrange or search in a bubble. This allows the software developer more flexibility when viewing/loking up code. The basic argument is that bubble based views will lead to easy, faster and convinient navigation for software developers. The idea intuitively seems good. Having bubbles allows for the required code only to be viewed. Also as the user can arrange the bubbles per need, it would also help in better utilization of desktop real-estate! I think that utility of this system is based on the size of code base we are dealing with. If we need to deal with a bunch of methods belonging to different classes, then this might be useful!
The State of the Art in End-User Software Engineering:
This chapter describes the current state of the art in end user software engineering (EUSE). This discipline evaluates how users who program for their own uses (scripts, spreadsheets) design, program, and evaluate their programs. Its a really long, but a thorough and good literature review. The authors break down the work in terms of 5 tasks: requirements, design and specifications, reuse, testing and verification, and debugging. I think, requirements and design specifications are mostly still ill documented. While people in industry talk about re-use all the time, on occassions i have seen copy-pasting of code - though I would admit that most of that was legacy code and the person working on it had a very tight deadline to meet. Nevetheless, copy-pasting is still prevalent. I doubt if industry has adopted to high testing and verification methods, or do they still folllow the old test-suites. While debugging, even though we have language debuggers ( ex python debugger), I still find myself using print statements, but may be I need to get a move on and use the debuggers in a more efficient way.
Laura Devendorf - 11/16/2011 7:41:43
The State of the Art in End User Programming discusses a number of terms, definitions and considerations to keep in mind when studying end-user programming languages. Code Bubbles describes a method to reduce the time overhead spent navigating through code files in an IDE.
I found this article very interesting but I struggle a bit with the separation of what makes and end-user programming language as opposed to any other programming language. I understand that it is unrelated to experience but I think that the line between what you do for yourself and what you do for others can be blurry. For instance, many things I've made for myself, I have later shared with others. I liked the discussion on choosing the right abstraction and how specific abstractions can limit flexibility. Many of the themes in the paper also tied back to the paper we read about behavioral change. Particularly, the concepts of goal setting and creating a system where a user has confidence in their ability to achieve a goal.
Code bubbles is an interesting concept as well and I think much of my interest in the paper comes from my own experiences working in IDEs and searching for code fragments. The description of how it is implemented seems fine but I think much more would be gained from playing the system and using it in a real scenario. From reading, I thought the movement of the bubbles would be frustrating or distracting but it seems like the qualitative results prove that this is not the case.
Allie - 11/16/2011 8:35:22
In "State of the Art in End-User Software Engineering", Ko et al introduce a new area of research called End-User Software Engineering (EUSE), in relation to design, reuse, integration, testing and debugging for end-user programmers, as distinct from professional developers. Differing identity and intent differentiate end-user programmers from professionals, with EUSE prioritizing goals over software quality issues. The challenge is to incorporate these activities into the end users' existing workflow, from the angles of 1)requirements 2) design and specifications 3) reuse 4) testing and verification 5) debugging. The paper looks at various applications that simulate the visual flows of programming, taking WYSIYG apporaches ove rmachine language, considered the most mature error-detecting approach for end-user programmers. The paper also introduces the Surprise-Explain-Reward strategy, which consists of 1) surprise the user in order to raise curiosity about a feature 2) provide explanations to satisfy the user's curiosity and encourage trying out the feature 3) give a reward for trying to feature, encouraging future use of the feature.
"Code Bubbles: A Working Set-Based Interface for Code Understanding and Maintenance", focuses on a code bubble user interface to help reduce professional programmers' time spent reading and navigating code. The results are quite successful, with various enhancements such as dimension restriction without text clipping; semi-transparent undo buttons; a heuristic recursive algorithm that attempts to find a global minimum; and grouping by surrounding bubbles with semi-transparent halo. The side-by-side feature of the code bubble with the actual program helps developers offload memory, and offers the opportunity to reference other methods while making edits. Code Bubbles helped users reduce average navigation time by 68.6%, with speculations that the speedup comes from factors rooted in the limited nature of human working memory.
Both papers introduce interesting technologies that are at the heart of HCI. EUSE is more genearl, and evaluates different types of end users by needs specific to their professions. Code Bubbles target professional programmers, who as defined in the EUSE paper are quite different from end users.
Donghyuk Jung - 11/16/2011 8:51:35
The State of the Art in End-User Software Engineering
This paper represented definitions that distinguish end-user programming from professional software development as well as related researches incorporating requirements, design, testing, verification, and debugging concerns into users’ existing work practices. According to this paper, an end user is simply any computer user and they do program to achieve the result of a program primarily for personal, rather public use. It is true that there is a wide variety of people may engage in end-user programming (Table 1, page 7). Additionally, It was good for me to know programming activities along dimensions of experience and intent and qualitative differences between professional and end-user software engineering. Those tables well illustrated what is the differences between professional and end-user software engineer. However, I think that it is hard to admit end-user software engineer as another type of software engineer. The functions for end-user software have been developed from simple tasks (e.g. setup alarm clock or spam filter) to complex tasks (e.g. add some scripts for automation or batch process). Nowadays, every user expect that the software must have those functions with different levels of difficulties and they would consider themselves as just end-users not end-user software engineers.
Code bubbles: a working set-based interface for code understanding and maintenance
In this paper, the authors presented a novel user interface metaphor for code understanding based on collections of lightweight, editable fragments called bubble, which form concurrently visible working sets. They insisted that Code Bubbles significantly improved code understanding time based on the result of evaluation, while reducing navigation interactions over a widely-used IDE. I think their approach was very unique because modern IDEs are file-based as well as creating and maintaining views of multiple simultaneously visible fragments is difficult. I agree that expandable work space with connected bubbles can give us its overall structure but, Code Bubbles look like a good combination of UML designer and IDE. In my opinion, this tool would be good for small-sized collaborative programmings (e.g. final project for a course work) because it will give users great overview with pan and zoom functions. However, I don’t think this tool would be productive in big-sized tasks like enterprise platforms because there will be way too many bubbles and connected line between bubbles, which can distract developer’s focus.
Apoorva Sachdev - 11/16/2011 8:52:26
Today’s readings were ‘ Code Bubbles: A working set-based interface for code understanding and Maintenance’ by Andrew Bragdon et al. and ‘The state of the art in End-User Software Engineering’ by Andrew J.Ko et al.
The first reading about Code Bubbles was interesting and very useful. I have previously faced problems trying to read code spread over a number of files and constantly juggling between files to keep track of various sub-functions spread over other files. I find the “Go to function definition” option on eclipse very useful and Code bubbles implements this in a way which allows one to view the function alongside the current code instead of forcing the user to navigate away. Their quantitative analysis shows that the programmers performed the first task significantly faster using CB in comparison to Eclipse; however the difference was not significant for the longer/difficult task case. This was attributed to lesser time given and it could also be the structure of the question as I feel CB would be very relevant for when you were writing new functions based on other helper functions that existed in other classes and get quick reference rather than searching through code specifics where tools like “show which functions call this” and “show which functions it calls” might be more useful.
The second reading was pretty long but nonetheless informative. The authors made some good points but I feel like it could have been more concise. The main difference they seem to highlight was between end-user programmers and programmers and how their goals are very different but still their approach maybe similar. The paper covered in depth how the end-user programming literature deals with requirements, design specs, reuse of code, testing and verification and debugging and how one can help the end-user programmers improve the quality of the code. Programming by example seems to be a common approach for end-user programmers; however, it is not very extensible/reusable. I think the key takeaway in this article was the realizing how programming fits in the bigger picture of the end-user programmers experience and lives, in contrast programming is central and core of a programmer’s life. Thus, future software designs have to take that into account to make sure it can be made easier for end-user to design applications around their core subject.
Rohan Nagesh - 11/16/2011 8:58:37
The first paper "The State of the Art in End-user Software Engineering" discussed the implications of designing not for professional software developers, but for "end-users"--users whose intents are not for the code to be deployed widely and publicly. The second paper "CodeBubbles" describes a new visualization in IDEs to quickly aggregate information across a variety of code snippets to reduce total task completion time.
I found the first paper's definition of end-users to be quite interesting. Under their definition, even an experienced programmer who is coding for themselves or coding an internal testing procedure falls under the category of an end-user programmer as opposed to a professional programmer. The authors' main points were that there are these end-users who far outnumber professional programmers and for end-user programming, the emphasis on design, reusability, and scalability many not be necessary. My definition of an end-user was anyone who programmed as a side function to their real occupation, which basically boils down to programmers who don't have software engineering expertise and are not professional developers.
The second paper discusses CodeBubbles, a novel UI to allow programmers to not have to constantly switch between files in IDEs to find the code snippets they're interested in for the current task. I do believe in and understand this problem, and what usually happens for me is I'll copy the second or third snippet into Notepad and use Alt+tab to switch between eclipse and Notepad. Now, obviously if you could do all of this within the native IDE environment, that would be a huge timesaver. I thought it was interesting too that not all of the speed-up was attributed to navigation, but some of it was also due to reduced cognitive load.
Yin-Chia Yeh - 11/16/2011 8:59:13
The two papers today are about programming interface. The code space paper introduces touch, device and skeleton tracking based system for reducing code understanding time. The end user software engineering paper surveys the current state of non-professional programming such as email rules and spreadsheet formulas.
I like the research question of code space paper, i.e. to reduce code understanding time. I also like the idea of connecting different devices together to allow more interaction. However, I do have question on whether gesture control is the right interaction technique for this task. After watching the demo video, I have the feeling that most of the interaction techniques in this paper can actually be replaced by a mouse, which should be readily available in programming environment. Touch control can be useful for the presenter to direct manipulate on the large display, but how about those gesture controls? I would like to see can they replace the gesture controls with mouse and compare the difference.
The statistics in end user software engineering paper is very interesting. There are 3 million of professional programmers in U.S., and 55 million of end user programmers! This reminds me that I once heard someone claim that within 20 years programming will be a basic skill for everyone. It seems to be true according to the statistics in this paper. Overall, the point I agree most in the paper is that instead of forcing end user programmers to use end user software engineering tools, what should be done is to train those programmers about software engineering and computer science principles. People cannot use these tools well until they really have an understanding of the concept behind these tools.
Sally Ahn - 11/16/2011 9:00:42
Ko et al focuses on the programming experience of the "end-user" and presents definitions and review of this area of research. In the second article, Bragdon et al presents a system designed to improve reading and navigating code for professional developers.
I found "The State of the Art in End-User Software Engineering" an interesting article because it addresses a niche in interface research I had not really thought about before, and the authors clarify the factors and goals of this area. A key point I took away from this article is that end-user programming should not be confused with experience; it is the goal of the programmer--whether to write code for themselves or others--that distinguishes end-user programming. In my experience, a lot of the programming done for research falls into this category, as rapid prototyping and testing of ideas is a vital first step of any project. The authors make an interesting point that the growing diversity of programmers in this group presents an opportunity to study the generalizability of software engineering tools.
I can definitely relate to the motivation behind the problem Bragdon et al identifies: the time taken to navigate and understand a large code base is often a tedious and frustrating task, especially for new employees in industry. I think the biggest contribution of this paper is the suggestion of changing the interface metaphor itself (i.e. moving from the file-based system to a code fragment based system). Since the task of understanding code often involves referring to synthesizing relevant pieces of code distributed across many files into a coherent system in one's head, this seems like a good approach.
Manas Mittal - 11/16/2011 9:00:58
Distinction between end-user programmers and professional programmers: - Use code, vs Ship Code. - Outside Customers for code, vs using it for internal purposes.
The Ko et al. paper is a overall survey of the state of end-user programming. The authors make an interesting distinction - the people who program for others (i.e., ship code) and those who program for themselves. One interesting thing to note is that almost all of the hobbyist (arduino, processing style) communities are almost all entirely made out of people who program for themselves. Among other things, you see the artifacts of this in the form of tools available and acceptable. For example, the Processing standard UI does not support break-point debugging. No professional programmer would choose to work in such an environment, but its quite the norm in the hobbyist community.
Another thing to think about is how these 2 communities view each other (although, depending on their 'mode', a person might belong to both communities). Who are the people who write tools for the amateur communities? Are they those who belong to both communities.
The gender based distinctions are interesting - especially the notion that male-tinkering is negatively related to success vs female tinkering is positively related to success.
The Code Bubble Paper is interesting and was a point of discussion while I was employed as a professional software engineer at Apple, Inc. One can imagine the idea of making 'transparent APIs' by automatically identifying variables in the code bubble, abstracting it and making it easily tweakable (+ the designer can annotate the variables). In this case, the API is not a opaque box (and so its much easier to design).
Shiry Ginosar - 11/16/2011 9:06:50
The papers today address programming interfaces from two directions, one from the point of view of end user software engineering such as scripting and the use of spreadsheets, and the other from the point of view of programmers using a programming language.
In The State of the Art in End-User Software Engineering, Ko et al discuss the primary challenges in designing end user programming interfaces and review the research that has been done in this domain. The challenges all stem from the fact that programming for the end user is not a goal but a means to an end, and therefore the focus on code quality is lower than in professional environments. It is interesting to think how quality checks can be automated and presented interactively to the user. Graphical query construction tools for RDBMSs come to mind. As for the paper itself, I found it much too long and wordy to be able to read all at once. This is unfortunate as it seems like many of the key points could have been communicated in a more efficient way.
Code Bubbles introduces a novel way to read and interact with code in professional and novice environments. Instead of using the usual file metaphor, bubbles are created one for each method and presented side by side on the screen. Moreover, calling relationships between the methods are drawn as arrows between the bubbles. This metaphor seems to work well based on the user studies performed and as a software engineer, I as well could really use one of those interfaces. From experience I know how irritating it is to size terminal windows to the correct size so that all the code snippets in my working set appear on my screen! I also thought that the evaluation metric they chose to use was interesting and novel - measure the understanding of code based on the ability to fix a bug by reading the code only.