Programming I

From CS260Wiki
Jump to: navigation, search

Lecture Slides

File:Cs260-slides-21-programming1.pdf

Extra Materials

Discussant's Slides and Materials

Kinect Brainstorm

Group Brandon Charlie Linsey Matthew

  • Blindfolded tag game with depth camera feedback
  • Enhanced Google Street View with depth info
  • Night vision
  • Crowd movement / traffic analysis
  • Hand/body movement/gestures as control for presentations
  • Virtual clay modeling
  • Direct manipulation in CAD applications


Group Four -Kinetic prototyping and design tools

-Analysis for sports medicine

-automatic avatar reconstruction

-3d surface reconstruction for interior mapping

-3d surface reconstruction for face reconstruction / biometric authentication

-gait analysis for authentication

-cheap LIDAR alternative for collision detection for outdoor robots

-augmented reality first-person shooter

-crowd pong / crowd surfing games


Group just another group

  • Augment google street view w/ user contributed RGBD from buildings
  • Architecture/real-estate visualization apps
  • Ikea++
  • Blind person assistance (face recognition)
  • Space remembers
  • 3d instructions

Reading Responses

Luke Segars - 11/13/2010 23:33:00

Code Bubbles

This paper describes a UI enhancement for programmers that presents code fragments on-screen in small, easily parsed "bubbles." The authors argue that presenting this information to users in small, simple cells could improve a developer's speed and precision with common programming tasks. These cells were also enhanced to provide grouping and an auto-spacing algorithm that could reposition bubbles dynamically as new ones were added.

Overall, this idea seems pretty practical and sounds like something I would potentially use when programming. I have certainly experienced the frequent flips from one file to another to compare code and will be the first to admit that it's non-ideal. Code Blocks seems to provide a workable solution to this problem, assuming of course that the user has enough screen real estate to turn over to the bubble layout (e.g. two monitors). The virtual 2D workspace and ability to group bubbles both sound like simple and effective features that I would use and benefit from. The results of the user study presented in the paper seem to suggest that the majority of other developers feel the same way.

The paper itself left a few holes in my understanding of the system itself. The authors (frivolously, in my opinion) spent a significant amount of time on the description of the automatic spacer algorithm. Although this was a nice feature, I left the paper itself with an unclear sense of how some very fundamental components of the system worked: how did users create new bubbles? How could they be removed? What happens if you update a bubble / source file? Given that the ideal case of a live demo could not be presented in a paper, it would have been very beneficial to have a clearer understanding of the basic interactions that a user has with the bubbles and system overall.

If I were conducting the evaluation, I would have looked at some additional factors in addition to the ones they presented. The paper was surprisingly barren when it came to discussing the sorts of interactions that the users had with the bubbles themselves. Where they moving them around a lot and regrouping them, or simply using them as static Post-it notes that they could view and then remove? Did they use them for anything other than code blocks, like mental notes? Was that even possible with the provided system? The (probably diverse) variety of use cases could have been examined more closely to understand whether Code Bubbles could be slightly expanded in order to solve a larger subset of the cognitive memory management process that programmers often face.

Ultimately, I'd be excited to hear that this tool were to be available to the public. I think that it's a practical application that has the potential to reduce the painfulness of a number of mundane tasks in programming. The paper states that the majority of developers in the user study were interested in using this tool in their work, but I hope that future work investigates whether the authors' purpose of the bubbles matches the use cases of the individuals who use it.


Krishna - 11/14/2010 10:03:23

End User Programming

This paper is about end user programming - defined by the authors as the practice of programming by users for their own personal use. A classic example they provide is programming the VCR to record a show at some pre-determined time. The authors describe, in detail, how this practice is different from the traditional professional programming practices, they provide an in-depth overview of how the various stages of the software engineering process compare between these two practices. The focus of the paper, however, is to discuss potential user interface solutions to some of the problems inherent in end user software engineering.

Given the well known stages in software engineering : requirements gathering, design specification, re-use, testing and debugging, the authors discuss in detail the issues in each of these stages from an end user programming perspective. For example, requirements and design constantly evolve and change. The whole notion of requirements is only hazy and implicit - contrary to the strict, meticulous requirements gathering done in professional programming practices. Testing is often never done thanks to overconfidence and re-use mostly happens accidentally and through ad-hoc sharing. Debugging is even more an issue as most users do not know how their systems work. Given these issues, the authors discuss many interesting solutions - the highlight is that most of them are at the user interface level.

My favorite solutions among the ones discussed were using programming by example to help end user programmers in their design and implementation stage, using natural language descriptions and then translating them into code, allowing provisionality - allowing users to provide imprecise implementations to many parts of their system and then allowing them to come back and complete them at a later stage, allowing users to customize their own abstractions towards facilitating re-use as in the case of the Topes system, incorporating "why" buttons in systems that explain "how" something happened thus helping users to more effectively debug system and the GoalDebug system that suggests changes to spreadsheets formular based on a desired value. It has to be noted however that, as in most UI solutions, it is not clear how each of these ideas generalize and scale across users, domains and practices.

My key take away from the discussions is that most software engineering issues do not have to do with the design of a programming language or framework and importantly, solutions for the issues can be deliberated and arrived upon from an user interface perspective. My only complaint about the paper is its length.

Code Bubbles

The authors describe an idea that shows code fragments - methods and classes as bubbles, contrary to the file based views in current IDEs. The bubbles can be grouped, searched, and linked - based on calling patterns. The argument is that the code fragment based view would reduce navigation time for developers. They also found that concurrent views and ability to spatially arrange the code fragments helped users to offload their working memory.

An interesting idea, I am not sure how much lack of the 'global/overall' context information provided by a file based view would affect developers. For example, I am very particular about how I arrange, organize my methods within classes - although this has nothing to do with the semantics of my program, it does help me organize my thoughts and code within the perspective of the class - may be I'm just a statistical outlier.


Shaon Barman - 11/14/2010 13:33:15

The State of the Art in End-User Software Engineering

The authors of this paper give a comprehensive survey of the field of end user software engineering.

End-user programmers differ from professional programmers because of their motivations. While professional programmers create software that is meant to be used by a large number of people, end-user programmers make programs for themselves or for a few colleagues. End user programs also face a unique set of problems. Because the code is meant only for a few people, robustness and extensibility are not priorities. The programmer's main concern is to create something which seems to work, and to find quick work-arounds.

One thought I had was the importance of creating good "paths of least resistance." If an end-users goal is to create something quickly in order to save work, they will most likely choose the easy path. Most of the tools described allow an end-user program to use good coding practices by reducing the burden associated with them. Also, it seems like the majority of tools are tailored to a specific domain and are to generalize. This strategy makes sense because of the tools were general, then they would be incorporated into normal software engineering practices. The authors break down the work in terms of 5 tasks: requirements, design and specifications, reuse, testing and verification, and debugging. One note is that these aspects are still quite primitive in industry. Requirements / design and specification are still conveyed in non-precise text documents. While reuse is advocated, there is a still much copy and pasting code which leads the propagation of bugs. The state of the art in testing and verification is rarely used in industry, and instead a suite of incomplete test-cases is considered adequate. And when debugging programs, I have noticed that inserting print statements is still the most useful tool a programmer has.

Overall, the paper does a good job on giving a summary of the issues and results of end-user programming. On a side note, its interesting to see that the most developed domain is formulas in excel spreadsheets. This might be because the domain is mathematical, and therefore easily understood or because the prevalence of spreadsheet programs. Spreadsheet programs are also widely used by non-technical people.

Code bubbles

They develop a new user interface for code, which displays a method as the base unit (instead of a file). The method bubbles can be grouped and arranged which allows the programmer more flexibility when viewing and looking up code.

The bubble idea seems to be very practical. There have been many times when I get confused because of too many tabs in an eclipse window. Even tiling the windows does not fix this, since after 2 window tiles, each screen becomes to small. The bubble allows for the code that is needed to viewed, without displaying excess or unwanted information. Restructuring the bubbles into logical groups allows easy location of a method and the ability to construct views. It seems the increase in productivity would correlate with the working code size of the task. A task which requires multiple methods across different files would benefit from such a UI. I would be interesting if this methodology could be incorporated into the window system, so that programmers could save a bubble when needed but continue to work on the source code as normal.

Overall, this method seems useful but I have doubts about how this would scale when developing a large code base. One thing nice about the current Eclipse GUI is that the complexity is limited. One cannot create arbitrary layouts in the system. With the bubble UI and the extended desktop, I can see situations where the interface becomes too large for a user to navigate successfully.


Kurtis Heimerl - 11/14/2010 14:25:22

The State of the Art in End-User Software Engineering. This book 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.

This was really long, 60-odd pages, and very thorough. There's nothing to argue with, it's a lit review, but a good one. I wasn't aware of how deep this field was, dealing with everything from the technological issues to social issues. Some of the solutions seem quite general; struggling with Qt4 designer this weekend I tried to change button sizes and had no idea why it failed. A system that allowed me to query why my actions were not doing anything would be great. There seems like a lot of value here.

I'm personally interested in the topic, I've always felt as though EUSE would be a great value in the developing world. Computers seem underutilized, and data quality is very low. Basic excel programming would do wonders, but it's never used. It's very likely that it's just my CS bias showing, seeing programing solutions all over the place; hammers, nails, all that jazz.

I'll probably eventually follow some of these references down, particularly programming for teachers. I'd like them to be able to create educational games/tests that are optimized for their particular lesson plans.

Code bubbles: a working set-based interface for code understanding and maintenance. This paper describes code-bubbles, a system for displaying a working set of functions concurrently on a screen in eclipse.

Honestly, I don't get this work. I understand eclipse is bad at this, visual studio is as well. Emacs is great at it; you can have multiple files open and shown on the same screen at the same time. It doesn't chunk by function, and it doesn't do a lot of things eclipse does. However, it provides much of the functionality discussed; each emacs instance is a working set of file I'm modifying and files I'm using while making edits. I have 2-3 emacs instances each with 4-5 open subwindows.

So there were some fancy algorithms for displaying more bubbles at a time which could be handy. There's niceness in determining where a function starts and ends, and what to display. At the end of the day, the core idea is presented as new, and it is not. It's ancient, and I don't think there's any fundamental element of modern IDEs that makes this interesting.

Ok, I just thought of something better. They should have a linux-like multiple desktop scheme to allow me to get rid of all the junk in a modern IDE. I might actually use eclipse if my screen space wasn't so aggressively wasted.


Matthew CHan - 11/14/2010 14:57:40

Code Bubble

Code Bubbles is a unique paper that addresses an common problem for developers and coders: tracing code in several files to understand what's happening. The existing norm is to have several tabs or files open, resizing them to view the necessary method, compare it with another piece of code, etc. Code Bubble aims to simplify that by using the bubble metaphor. The authors use this method to simplify viewing and navigation of code in several files. A unique design that stands out is that no bubble overlaps each other like the existing window paradigm. To address the issue of having too many bubbles, the authors made a design choice by having virtual deskspace which scrolls from left to right. The UI for Code Bubbles looks a little similar to meebo.com where users can control all the chat boxes, have the menu bar at the left. One of the greatest simplification in Code Bubbles is reducing the windows-- unlike the normal window with the "X" and the title bar, the authors removed it entirely and resorted to other interactions to close or move them.

The results were staggering, such that users had a reduction in time in navigating code. THe authors did a usability test by having their participants debug pieces of code. and also had professionals in the area use the software. Qualitative results consisted of particpants asking when Code Bubble would be available and were lauded greatly.

This paper relates to today's technologies in many ways since programs and software consist of multiple files, and developers who go back to them must navigate through everything to debug, expand, or modify code. Code Bubbles could greatly simplify this task and improve productivity. In fact, Code Bubble might even make computer science more user friendly for novice users entering the field. This doesn't relate to my work, but it could have helped me alot in my projects or tasks. I also feel that the authors did a good job addressing many blind spots and having a proposed solution (ie. too many bubbles. Hence, more virtual space).


Linsey Hansen - 11/14/2010 16:12:03

====State of the Art End User Software Engineering====

In the first article, the authors discuss how a majority of people who “program” are not actually professional programmers, but end user programmers who create programs for personal use. The authors then go on to talk about the differences and similarities between end user and professional programmers as well as what sort of research is being done to improve end user programming.


One thing I found interesting is how system administrators were classified as end user programmers as opposed to professional programmers. At first I thought that this seemed kind of wrong since I think of all the sys admin people I know to be “professional programmers”, but as the authors went on to explain that “end user” didn’t mean unprofessional, it just meant that the person coded programs to be used by themselves as opposed to others, it made more sense. However, I would argue that some system administrators do create code that is used by other system administrators or other people using their network. Anyways, thinking of sys admins more as end users does make sense, because they are definitely people who might be able to be more effective with better programming tools, even though a majority of them are hardcore command line and vi users. This mostly just reminded me of psDoom, though I suppose that that mostly aims for making the job more interesting as opposed to more efficient (though it sort of did provide an easier way to perform some tasks without needed to know how to code).

One other interesting thing was the overconfidence in end user programmers. Not to offend CS majors, but most of them are definitely overconfident in most areas. However, similar to what the article said, I feel like this decreases as people progress in school and their careers (well for most people it works like this). This probably just has to do with some “computer god” thing people go through whenever they first learn how to program, since it is pretty cool, but as people learn more they slowly begin to realize that they do not know everything and they do make mistakes. Perhaps the problem with end users is that since they are not coding all of the time, and they are mostly coding for themselves, thus they avoid most outside criticism, they never have much of a chance to get over their godlike self-image, and thus they continue to feel overconfident.


Code Bubbles

In the Code Bubbles article, the authors describe a new technique for allowing programmers to view code—as opposed to forcing programmers to view code by files, which requires a lot of scrolling and window management, the authors made it possible to view code by method.

I am going to start off by saying that the actual concept is quite awesome. I for one can spend way too much time trying to keep track of several contributing methods or classes while programming, and when I am working with abstract classes and such, I find it really annoying when I am trying to compare the same method for two different subclasses. It is definitely a lot easier for me to do in Xcode as opposed to Eclipse, but both can still be quite cumbersome. Honestly, I generally do program by “method” in most cases as opposed to by “class” or “file.” Because I generally like to check that certain parts of various classes and files work together before moving onto other parts of anything, so being able to easily view functions based on whether they are above or bellow the one I am working on in one file makes little sense if the function is mainly going to be used by some other class. For this reason, the concept of having groups is also great because it would allow users to be able to place either similar functions or functions that call each other into the same group.

The only time I see this being a problem is when a programmer has a really long function they wish to look at (which I guess some might call bad coding practice). I didn’t see anything in the article mention how this might be supported, like if it would get two bubbles or if the user would just need to scroll. I suppose that this is not really a large problem, since the whole purpose of the paper is to introduce a more efficient method than editing code based on file, but if I were to use code bubbles, regardless of how spoiled I would feel, I would still be slightly irritated by this sort of thing.


Brandon Liu - 11/14/2010 17:05:07

"Code Bubbles"

This paper was great since it justified the feature in terms of mental models of programmers. While the models of files are hard-coded into a project, the set of code a programmer works with exists only in his head. This project attempts to extract that model and make it directly manipulable. There was, however, too much detail related to the graphics implementation.

The discussion of spatial cognition and working memory was good. It invites a lot of future research directions to see how spatial layouts can affect the efficiency of code understanding, and could apply even outside of computer programs (for example, court documents) 

One discussion I would have liked to see more of is the background on the students who participated. The paper described how variability in the practices of professional programmers was too high, so they chose students. But even among my classmates, we have vastly different habits in code exploration. Some of us use CTAGs or features like TextMate's Fuzzy Finder which help enormously in code navigation and can help us build a strong model of what parts are interacting. 

Another topic that can be explored is why so many professional programmers prefer an editor like Emacs or Vi over an IDE. My hypothesis is that it gives them a more 'concrete' understanding of the code at any time, which has short term costs in navigation or editing time but long term gains in total understanding. 

----- 

"The State of the Art in End User Software Engineering"

This paper distinguishes end user programmers from professional programmers by their intention: a professional programmer at work may be an end user programmer at home, if his intention is to create something for his own use and not by others. I thought this was a good characterization of the target group, although it is very broad in terms of programming experience. 

The approach I'm most interested in is that of code reuse, where end users can create programs tailored for their own use through example modification. The paper described approaches where 'templates' could be given to end users to fit a general need. It seems that even in this case, though, professional programmers would have to provide any such templates. 

The most provocative part of the paper was discussion of cultural issues around end-user programming, especially that of self-efficacy. In my opinion, lack of self-efficacy is the single biggest barrier to letting more non-professionals harness computer technology. One research direction that this paper could lead is how to either increase self-efficacy or somehow 'trick' the user into perceiving a task is easy. The paper mentions how domain familiarity affects perceived risk and reward - Another possibility is that domain familiarity can increase self-efficacy, since the end user feels that they have a complete grasp of what they need to accomplish. 

The discussion of formality vs accessability in end user programming environments was valuable. It may be more enlightening to think about end user programming as a spectrum from the most formal and disciplined environments to the most accessible but least flexible environments.


Airi Lampinen - 11/14/2010 17:32:32

Ko et al. outline in their article an overview of the field of end-user software engineering, considering both definitions, current issues and prior research in the field. They start with the notion that most programs these days are written by people whose expertise comes from other domains and who are working towards goals for which they need computational support, instead of by professional software developers. While the goals of these different groups may be very different, many challenges are shared. The authors go on to discuss a number of issues, including understanding requirements, making decisions about design, reuse, integration, testing, and debugging.

The authors state that taken the differences between expert software engineering and end-user software engineering, the challenge of related research is to find ways to incorporate software engineering activities into users’ existing workflow while avoiding requiring people to change the nature of their activities and priorities. The text is a broad and interesting overview of the domain. I found especially interesting the notion of needing to find ways to support emergent design activities, as end-user programmers' activities tend to mix design and programming - I believe this is often the case in "professional" software engineering, too, even if in a milder form.

Bragdon et al.'s "Code bubbles" presents a "working set-based interface for code understanding and maintenance", as well as both quantitative and qualitative evaluations of the proposed interface. The authors found partial evidence for their hypotheses that Code Bubbles users will be able to understand the code more quickly, take advantage of multiple simultaneous bubbles, and should use significantly fewer navigations/minute on average, and fewer repeated navigations/minute on average. As an unexpected result, they found out that reduction in navigation time only accounts for 33.9% of the performance improvements seen in Code Bubbles.

In essence, the authors state that developers used Code Bubbles not just to avoid navigation but also to offload their working memory onto concurrent views and spatial arrangements. Hence, it seems that the reduction in performance time cannot be attributed to navigation alone. This is taken to point out the need for further research into potential cognitive benefits of the presented approach.


Luke Segars - 11/14/2010 17:39:17

The State of the Art in End-User Software Engineering

This paper provides a survey of the current best practices in EUSE as well as potential directions for future improvement. The paper refers to "end users" as people (possibly professional programmers) who write programs that are not intended to be shared or used in a variety of contexts. The authors focus primarily on the software engineering concerns that are typically brushed under the carpet by the end users because they predict that software engineering practices will become more and more relevant for end users as the complexity of their programs increases with competance. Despite, and perhaps due to, its large scope, I don't feel that I learned a whole lot from reading this paper aside from an understanding of many of the shortcomings that still need to be addressed.

There are two ideas that were summarized in the paper that seem revolutionary. The first of them was the idea of providing program visualizations in order to improve a user's ability to verify and test the accuracy of their program. I think that this is something that both amateurs and professionals would find very useful. The paper discusses applications to both spreadsheets and interest in machine learning algorithms, although I think that general programming languages and environments could benefit greatly from this approach as well. The second great idea was the Whyline project for the Alice programming language. This project generates questions that a user might have about the behavior of their programs during execution. Allowing users and, in particular, learners (aren't we all?) to ask relevant "why?" questions is not only useful for short-term debugging but fundamentally changes the way that novices could learn program. I don't know much about the Whyline project, but it is clear that being able to generate a small set of the right questions would be critical to improving the user experience. If the authors of Whyline haven't investigated the idea of machine learning, there is a huge potential for using it to promote their approach, and to push the entire field of EUSE along with it. This sort of tool could also be used for the actual program construction (not just debugging) by allowing users to try different solutions and get immediate feedback on why their program is executing the way it is. If this could be combined with the functionality of something like HelpMeOut, it would create a powerful platform for social programming that could significantly improve the task of writing end-use or professional applications.

I got the weakest feel for progress in the section that the authors emphasized end-user difficulty in: transforming natural language requirements into system specifications. A number of the tools that were presented still seemed too "techy," like they were targeted at professional developers instead of end users. This is certainly a hard problem, but I suspect that it may also be the biggest barrier to entry for those who are afraid to use programming to solve their real-world problems.


Dan Lynch - 11/14/2010 18:17:54

The State of the Art in End-User Software Engineering

This article gives a very detailed characterization of the end-user programming and software engineering space. The beginning of the article gives some definitions and makes the distinctions between professional and end-user software engineering and programming. In the end, its the goal and intent that distinguishes the two. That is, the end user has a goal that he/she is attempting to complete while the progressional program focuses on maintainability, re-use, and other software engineering ideas.

The paper in my opinion also defined the scope too broadly for what end-user programming is. Is working on an excel spreadsheet really programming? Editing excel is like editing word, but with math. There is no logic, no conditional structure, and it can all be simply copied, pasted, or deleted. If excel is a end-user programming program, then what is a calculator app? I think we lose the meaning of the program here.

I felt that the paper made a lot of general assumptions that were not validated. For example, that computer science students are not experienced programmers. This may be mostly true, but I have met many transfers who worked in the industry before going to school. The author also wants the reader not to "conflate", or combine, the ideas of end-user programmers and inexperience, yet completely gives these prescriptions throughout the paper (end of first paragraph on page 11). The point of this paragraph being that some of these assumptions I felt were not founded and also misused.

Code Bubbles

This paper introduced a new metaphor used for coding: code bubbles. These take code fragments and display them on the screen in a way that allows faster navigation, reading, and editing.

Something in this paper struck me as very important. Not only did they noticed speed-ups in performance, but only 35% of that was due to the navigation utility of code bubbles. The authors hypothesize that this has something to do with human working memory and cognitive abilities.

This is an extremely important topic because it helps coders be more efficient! Why is this not implemented in all code frameworks today?


Anand Kulkarni - 11/14/2010 18:19:28

The State of the Art in End-User Software Engineering

The authors survey end-user software engineering, which is the incorporation of quality, design, and process issues from standard software engineering into the process of creating "end-user programming" software -- software that lets non-programmer users carry out structured activities supported by software en route to achieving their goals.

This work's primary contributions seem to be definition of the concept of end-user software engineering, and extensively surveying several aspects of this idea. I like the notion of end-user programming. I also like the survey of debugging techniques for end users since this is a feature set not often considered by developers. I also like the general problem space, since many activities carried out with software are end user programming even when not described as such.

The validation for the arguments is extensive, coming primarily from several papers. I like the extensive support given by citing published work and find this to be a convincing form of validation. It would have been nice to see some extensive case studies or running examples.


Code Bubbles

The authors present a novel IDE modification dividing code into fragments called bubbles and show that this offers a qualitatively (and to some extent, quantitatively) better interface.


Code bubbles are the primary contribution and offer a new mechanism for understanding code segments and relationships in an IDE. I like that the authors paid attention to efficient use of space and automatically resizing ("reflowing") content and bubbles to maintain readability and reduce cognitive clutter. I like the recursive structure of bubbles because this aids code understanding as compared to the more common linear representations of code offered. I also like the ability to easily zoom and switch between bubbles, since I suspect a substantial amount of coding time is spent searching through code blocks to understand relationships. I wish the authors had taken this one step further and offered a mechanism to "connect" groups of code blocks externally to rewrite and reuse code sections

I like the result that the improvement was not simply because navigation was faster, and the possible cognitive benefit. The authors used a 20-person quantitative study and a 14-person qualitative study to carry out their research, which is great; I particularly like that they took care to make sure all users were fluent in the same coding environment (to some extent). I wish they hadn't used Eclipse as a baseline, because honestly, it's not hard to outperform Eclipse.


Drew Fisher - 11/14/2010 18:33:49

Code Bubbles: A Working Set-based Interface for Code Understanding and Maintenance

Problem: MDI applications (particularly IDEs) require too much manual rearrangement of windows. We can improve this situation by making the IDE:

  1. aware of the context of the code that's being edited, and
  2. handle working with code in a more fluid manner than traditional document editing.

I'm not sure Code Bubbles has a single /novel/ contribution. It's a (rather) nice piece of engineering that combines a ton of previous work in layout management (tiling window managers have existed for a long time), canvas and group-based workspaces (window grouping has been around for years), and associative navigation. Zoom out to see the working set? Apple's Exposé shipped in 2003. Search for a working set among these windows? KDE 4.0, January 2008. Accessibility by making elements map to a single key with dynamic labels? Code Bubbles is probably a more polished and unified tool targeted at software development than the other examples that implement these ideas, but I can't see it as breaking new ground.

I'm not sure how effective this tool would be at handling larger code snippets, or large working sets. I wouldn't be surprised if after a period of use (particularly across multiple sessions) the workspace turns into a mess where the user can't remember where anything is. While it's a wonderful thing to show off a bunch of examples of four-line functions, not everything is that simple to navigate.

I found the video to be quite misleading - Code Bubbles uses a smaller typeface, which means that it has a greater effective work area for a given resolution. I won't disagree that it's probably a better tool than straight Eclipse at matching font sizes, but when you're going to make a comparison video, it's poor form to do so unfairly. On that topic, I wonder how test groups would function working with these IDEs at different font sizes, and where the "sweet spot" lies for different people. It'd be neat to see if it correlates with age or with vision problems in any way.


The State of the Art in End-User Software Engineering

End-user software engineering differs greatly from professional software engineering as a result of different attitudes on requirements, design, reuse, testing, and debugging. Problems encountered include the fact that end users don't know what references to use to obtain more information, limited skill in synthesizing concrete designs from interface ideas, overconfidence in their code's quality, and an attitude that can be described as quick and dirty, with no thought for consequence.

I'm not sure that this problematic attitude can be overcome strictly through interfaces and design tools. While lowering the barrier-to-entry on testing, creating clean and reusable code, and the like are all noble goals, they are not the goal of the end-user at the time said user is writing the code. As a result, to the user, testing and validation seems to get in the way of the user completing her goal - an outcome that is worsened by the end user's notable overconfidence.

Surprise-Explain-Reward runs a risk by surprising the user, a technique which differs at its core from the Rule of Least Surprise in UI design. This makes me wonder if other teaching or interface techniques would also benefit from breaking UI design rules in specific contexts.


Aaron Hong - 11/14/2010 18:44:15

In "Code Bubbles: A Working Set-based Interface for Code Understanding and Maintenance" by Bragdon et al. talks about a novel user interface for seeing and interacting with concurrently visible working sets of code fragments. Instead of the traditional interface for viewing, which is file-based, Code Bubbles creates these minimalistic, non-occluding windows based on code methods.

There are many interesting ideas in this paper. One idea is the Bubble groups, a way to replace file-based views that provide a convenient but rigid way for programer to group methods. The only thing is I wondered if they provided a file-based (or some other higher level structure) bubble group as an initial group? The closest thing they talk about is a "class bubble." However, I don't think they provide anything like that. Another interesting result is that "reduction in navigation time only accounts for 33.9% of the performance improvements seen in Code Bubbles." It's interesting how this spatial interface (which explicitly chose not to use overlap) can help offload working memory onto concurrent views and spatial arrangements. Find that to be useful and true, and not utilized enough in other interfaces.

In "The State of the Art of End-User Software Engineering" Ko et al. talk about the advent of many non-professional programmers, which can have a big impact on the rest of the world. The approach in which these end-user (aka programming not for public use) programmers use is called "end-user software engineering" (EUSE). This differs along the lines of Requirement, Specifications, Reuse, Testing and Verification, and Debugging from professional software engineering. It is a survey of EUSE and talks about some of the implications of it, including motivation to program at all. The article has interested ideas and definitely talks about an area that will have a lot of impact, since there is a little bit of a programmer inside all of us.


Thejo Kote - 11/14/2010 18:44:29

The state of the art in end user software engineering:

This paper is a survey of the research of software engineering activities of end user programmers. The authors define end user programmers as those whose intent is to create and solve problems for themselves. The authors argue that end user software engineering is an important domain to research given the large number of people who are not trained software engineers, but need to program to meet their every day goals.

A major part of the paper is an introduction of prior research in the major areas of software engineering, namely, requirements gathering, design, testing, verification and debugging, as applied to end user programming. The authors discuss the role of the perception of risk and reward and the domain of application to the decision making progress when end users program. They also mention that while much of the research till recently has focused on the major areas of software engineering without considering the impact that specific domains have, it is now changing with researchers studying end user software engineering in the context of its occurrence. They note that this could really broaden our understanding of whether traditional software engineering practices apply to distinct domains of end user programming, or whether we need new processes.

Code Bubbles:

In this paper, Bragdon and co-authors present Code Bubbles, a new take on programming IDEs. In contrast to the file based views that are the norm in existing IDEs, Code Bubbles is based on the metaphor of bubbles of methods which can be grouped together in a working set. The authors describe the system and the results of a qualitative and quantitative study of their hypothesis that Code Bubbles can reduce the time taken to understand code.

The main design goal behind the UI proposed by Code Bubbles is to maximize the utilization of the limited working memory of the human brain. In traditional IDEs, the file metaphor and moving back and forth between them is sub-optimal in terms of efficiently using working memory. Code Bubbles allows a programmer to only focus on specific portions of a code base to better mimic how programmers work. Other features like the extendable virtual 2D workspace and automatic resizing of bubbles and elision of code help in keeping the current context in working memory.

I really liked Code Bubbles. I remember wanting to try out the system when I came across a video demonstration last year. Of course, in its current form, the system does not address issues like the need to scan classes and customizing the spatial layout of code at the file level, which is quite important when writing maintainable code. But, it's a fundamental redesign of major parts of the programming experience and it's something I'd love to experiment with.


Thomas Schluchter - 11/14/2010 18:47:11

===State of the Art in End-User Programming Research===

The paper summarizes decades of research on programming practices of non-professional programmers. It concerns itself with the requirements, design, testing, verification, and debugging concerns that this significant portion of the code-producing population has, and investigates the effectiveness of various approaches to support end-user programming.

As computing has become increasingly pervasive and 'personal', so has the practice of programming. From this perspective, research into this practice is highly relevant. End-user programming transforms the user from a consumer of technology into a (to varying degrees) empowered utilizer. It also is a natural effect of economies of scale: since mass-market software can only satisfy the most widespread needs, more specialized needs are best addressed by end-users.

The most interesting point that the paper raises in my opinion is the difference between professional and amateur programmers in approaching their problems. End-users are less used to abstracting their problems to the degree than professional programmers are. The fascinating thing is that some modern professional programming practices, while maintaining their edge in terms of formal qualification, have embraced the working style that results from the amateur's mindset of starting from the concrete rather than from the abstract. The prototype-first approach is an important exploration technique that recognizes that the complexity of a problem is difficult to gauge in abstraction. In a way, the end-user programmer has an advantage over the professional precisely because she is her own user. The feedback cycles in this development model are rapid and always produce valid results.

Code Bubbles

The paper describes the implementation and evaluation of a novel UI for viewing interdependent parts of a computer program at the function level. The UI organizes code fragments spatially to reflect the references they make to each other, thus aiding exploration of the flow between units of a software program.

The paper raises an interesting point: The fact that code is organized in files is due to the way it is interpreted rather than to the way developers think about it. By breaking up the code to the granularity where developers manage the bulk of logical relationships, CodeBubbles manages to reduce the time spent orienting oneself in code.

The idea of creating a workspace that stretches beyond the boundaries of the screen should be further explored. From reading the paper, I found it difficult to imagine how one would not get lost if the effective workspace could be 20 times the width of the current display. It seems that the researchers made great efforts to minimize the space used by application chrome which, in this context, seems absolutely essential. Introducing non-standard mouse interactions is a little disruptive at first but might not affect the usability of the system in the long term.

I would love to use this as I often struggle to understand even how my own code hangs together after a while. As much as we all would like to be extremely diligent about simplicity and good (emerging) architecture, this aspect of programming often takes a backseat, which greatly complicates understanding of old code.


Siamak Faridani - 11/14/2010 18:53:20

The State of the Art in End-User Software Engineering Authors start with mentioning that the number of people who do programming for their own domain is much more than professional programmers. They call this group of people end-user programmers. Professional programmers have set up methodologies for designing, testing, and debugging their codes. This article is a survey of counterparts in the end-user domain. End-user programming is defined and popularized by Bonnie Nardi as programming for personal use rather than the public use. Professional programmers on the other hand produce codes for public use to make money, have fun or as a community service. Table 2 highlights the key differences of the two paradigms. For example reuse is not planned in the end-user SE but is considered in Professional SE. From this point on in the paper, the paper becomes a survey of current methodologies used in End-user SE. Authors consider different methods used in End-user SE. For example programming by examples and trough templates is practiced in programming in processing. Yahoo pipes also allows users to change pre-made templates and make their own pipes. WYSIWYG is another example that can help users debug and test faster. Table 3 contains examples of different EUSE environments. While I enjoyed reading this paper I am not sure if we can categorize all non-professional programmers as one end-user programmers. One example would be scientific Matlab programmers. Matlab is sometimes directly deployed on embedded computing platforms or on medical devices as a result the SE process is as rigorous as professional SE. Even if we lump all these different people together I am not sure that SE tools that is used in one group can be extended to another group and it seems to me that all of the tools that can be used in EUSE can be also used in professional SE. The second article, Code Bubbles: A working Set-Based Interface for Code Understanding and Maintenance, is an example of a programming tool for both professionals and end-user programmers. If this paper was written a couple of years earlier it would have been part of the first paper. I consider this paper as the SE counterpart of input techniques. They design their presentation method (code bubbles) and later show that the integration of this technique with Eclipse provides efficiency. They run two separate user studies one with students and an earlier one with professional programmers and show that the differences are statistically significant. The demo video was very interesting and helped to convey the idea clearly. Specifically I like the idea of flagging code groups. I am also wondering if they have released their plug-in for Eclipse. Although I am not sure how well this can be used on functional languages like python.


Matthew Can - 11/14/2010 18:57:20

The State of the Art in End-User Software Engineering

This article provides a survey of research in end-user software engineering (EUSE). The authors present a set of well defined terms in this EUSE to clarify their discussion and for the benefit of future researchers. The article discusses the empirical results of EUSE research, comparing and contrasting EUSE to professional software engineering. More importantly, it discusses issues that are important to the design of effective EUSE tools.

As the authors note, one of the big challenges end-users face is how to translate their requirements into the design specifications that describe the working program. One of the approaches described in the article, which I find fascinating, is to eliminate the design process altogether, instead inferring the specifications. For example, in programming by example the user provides many examples of the program’s desired behavior and the system generalizes from the examples. This is a powerful way for end-users to program without learning a specification language. However, as the authors note, the specifications learned by the system typically cannot be reused in future programs the way code can be reused. On top of that, if the inferred specification is slightly incorrect, the user cannot easily modify it but must instead supply a new set of examples.

The article discusses the issue of persuading people to use EUSE tools. One approach is to train users in software engineering principles. However, I think this clearly defeats the purpose of EUSE tools. As the authors indicate throughout the article, the goal of EUSE (and the big challenge) is to integrate software engineering practices into end-users’ existing workflows. The point is that users should not have to change the way they do work; the elements of software engineering should be transparent.


Code Bubbles

This paper presents a novel interface for reading and editing code, Code Bubbles. The results of the qualitative and quantitative studies show that Code Bubbles would be valuable to professional programmers. In particular, it reduces the amount of time spent navigating code and helps programmers understand code faster.

The Code Bubbles interface is based on the metaphor of the bubble; code fragments like functions are contained in a minimalist view called a bubble. The code inside bubbles can be edited. Unlike windows, bubbles are placed in a non-overlapping fashion on a large virtual space. The motivation for this is that the collection of bubbles forms a working set, reducing the amount of navigation on the part of the programmer. Interestingly, the programmer can also offload his working memory onto the space by opening bubbles and spatially arranging them.

I thought the combination of qualitative and quantitative studies made the validation strong in this paper. For example, in the qualitative evaluation, the participants identified a number of ways that concurrent code views are beneficial beyond just reducing navigation. Furthermore, the participants provided suggestions for improving the interface, such as an undo feature for bubble manipulations and a minimum width for bubbles. While the quantitative study lacked this kind of rich feedback, it provides more rigorous evidence that Code Bubbles helps improve a programmer’s code understanding. Compared to Eclipse, Code Bubbles reduced the amount of time taken to complete the study’s tasks by 33.2% and reduced the amount of time spent navigating by 68.6%. The authors do note, however, that their studies do not have strong ecological validity.

I am convinced that Code Bubbles improves code understanding, but I am not convinced that it should replace the Eclipse-style IDE. More specifically, this paper did not sufficiently address how well Code Bubbles performs for tasks of writing and editing code. Additional studies are necessary to verify that it is at least as good as Eclipse in this regard. On another note, it is interesting to think about how Code Bubbles can facilitate collaboration on software development. It seems like a great way to keep the working sets of multiple collaborators in sync, keeping them on the same page.


Aditi Muralidharan - 11/14/2010 19:00:18

"The State of the Art in End user Sofwtware Engineering", by Ko et. al. is a literature review article that explores how end user software engineering research has helped end users tackle the software engineering problems of requirements, design, reuse, testing, and debugging. They find that testing and debugging have recieved the most attention, but that end-user scripting on the web and mobile (and other platforms) is beginning to receive attention. They stress that the end-user programming process is different from professional programming because its ends are personal - code is produced to serve some personal goal, not to be used by others. Because of this, there are other issues that come into the discussion of tools to support end-user software engineering. Users must be made to see value in using the tools, and be able to use them well despite their different goals and prior experiences.

Other than being a comprehensive reveiw of end-user software engineering research, the article does not put forward any opinions or test any hypotheses.

In "Code Bubbles", Bragdon et. al. present a novel solution to a problem that plagues software engineers using today's IDE's : having to keep track of a thread of execution that is spread out over many different files of code all at once, while trying to understand what it does, build it, or debug it. Their solution is based to have a working set of code snippets, that manifest as lightweight, editable bubbles, that the programmer can have open all at once - making for easy navigation and visual comparison among lots of different pieces. Their goal is to remove the two-files-at-a-time the resolution and size of our screens place upon us, thereby reducing the amount of time we spend navigating, scrolling, and resizing.

This paper focuses on an aspect of programming that the first paper did not discuss: software understanding and maintenance, or the large number of files that must often be nagivated in a software project. This is probably because end users rarely have that much code, and don't need to go back and refer to it in the future. Software engineers, however, are encouraged to keep their code modular, but this results in lots of different files, with different functionality neatly parceled away into each.

Fitting methods into bubbles so that many of them can be viewed side by side comes with challenges. The first is fitting the characters into the bubble - the authors explain a text re-wrapping algorithm that snaps to parentheses and function words. Next is the challenge of bubble layout: adding and removing bubbles while maintaining spatial arrangement (so as not to remove spatial memory cues), and the last is maximizing the available screen space (when lots of bubbles are being used) by organizing bubbles into differently-colored groups, and by placing them within a workspace that is actually much larger than the screen's view, and can be navigated by panning.

In their qualitative evaluation, the interface was very sucessful, and surprisingly, no developer expressed the need for viewing files. When quantitatively tested against Eclipse (on a reading and navigating task intended to simulate code understanding), participants were able to successfully complete the tasks more often and faster with the code bubbles interface. The results also indicated that code bubbles help offset the coders' limited-working-memory constraint by giving them some place to offload threads of thought temporarily, making them faster and more effective at the tasks.

The interface seemed like an excellent idea for me, and not just for code understanding. It would be useful in my research because i design interfaces to help scholars understand patterns of language use in text, and the limited-number-of-views constraints is probably an important limiting factor in their performance.



David Wong - 11/14/2010 19:04:32

1) The "Code Bubbles" paper describes a new system for programming that lays out the code in "bubbles" that contains methods in the program. The system allows a user to extend their working memory and significantly decreases the time needed to navigate the code. The paper describes the system, a qualitative and quantitative study, and the results of their study. The "End User" paper discussed the differences between end-user programming and professional software engineering. The paper went into the history of research for end-user programming and how the field of research is shifting focus to several new directions.

2) The "Code Bubbles" paper offers an interesting system that I think can definitely help in programming. As most navigation in code is used to look over sections of code that relate to each other, it is a very natural design to group related functions spatially. As current text editors employ a merely a linear structure, more time is needed to navigate and understand the code. I think that this approach is novel and can definitely inspire a new series of IDE products to help programmers better code. An improved developing environment may also encourage better programming practices, such as writing modular code and using abstraction.

The "End User" paper offers an interesting overview of the research done in end-user programming systems. I think that this research is important because computers are becoming more prevalent in our daily lives, which implies that it will be very helpful to create good programming environments for those who aren't professional developers. Also, improved end-user programming tools will help result in a higher-quality end product. The paper was quite long and was broad in scope, but I think it effectively conveys its message.

3) The "Code Bubbles" paper offers a convincing argument supporting their system. Their qualitative and quantitative experiments show a proof of concept in their system. However, more tests will be needed to see if their system can easily be extended to become an IDE. Their experiments may have been biased by the type of code written for the bug correction. A field study or longitudinal study of their system with developers would be effective in proving whether the system can be used as an IDE and to what extend does it have true added value.

The "End User" paper discusses a lot of previous research and illustrates how research in end-user programming has shifted from a debugging based approach to several new directions. The discussion is long-winded, but it gives the reader an in-depth understanding of this field of research. Altogether, I think the paper is very thorough.


Arpad Kovacs - 11/14/2010 19:06:37

The idea behind code bubbles is that creating concurrent views of code fragments will facilitate navigation and reading of code, compared to the tab-based approach that is used in today's IDEs. The main insight of the paper is that programmers primarily want to view and modify specific functions rather than entire files, and thus code bubbles should save a lot of navigation time involving scrolling to the right location and switching between files. The design of the CodeBubbles interface emphasizes minimal border decoration, free-form layouts, and bubbles that push each other out of the way rather than overlapping. Thus, CodeBubbles allows the user to enjoy the benefits of side-by-side views and quick access to specific methods, without the painful and tedious setup steps that this would take in a traditional IDE interface.

I really like the minimal interface, as well as the automatic text-wrapping to minimize the bounding-box size. However, I think that the authors are trying to solve the problem of showing multiple-views simultaneously and allowing fast access to methods, which already has slightly less convenient solutions (multiple side-by-side buffers in emacs or any diff program, and ctrl+click to jump to any method or object declaration in eclipse respectively). In contrast, the main problem I face while coding is that I tend to open several dozen tabs in order to find the specific method to modify, and it is hard to keep track of how each of the parts integrate into the whole. Code Bubbles will not completely solve this problem, since it will just replace a sequence of tabs with a chain of bubbles (which by the way move around dynamically, making them hard to find later). The rectilinear bubble connections and search system help in this regard, however it seems that the ultimate solution to this problem is increasing the amount of screen real-estate, combined with user-defined color-coding and/or bookmarking schemes. Another useful addition for object-oriented programming languages would be nested bubbles. This would allow the user to instantly view methods from the superclass that a subclass may inherit, while at the same time visually depicting the inheritance. Nevertheless, I would be interested in trying out this new style of IDE, since during the course of its user studies the Code Bubbles IDE offered clear advantages in navigation time for the easier task tested.

=

The End User Software Engineering paper is concerned with supporting the activities of non-professional programmers, who may need to plan or write a program for personal, rather than public use. The main contribution of the paper is setting out formal definitions of this problem space, as well as surveying the previous work and studies performed in this sphere. The paper approaches the traditional software engineering methodology of Requirements, Design & Specification, Reuse, Testing & Verification, and Debugging from an end-user perspective, and shows where the traditional techniques fail for end-users.

It seems that the traditional software engineering methodology is too complex for end users to follow. For example, I would expect few users of Microsoft Excel macros to write a formal specification describing how their spreadsheet should look/behave for every contingency and error condition. Rather, it seems that direct manipulation techniques leveraging WYSIWYG and limited programming-by-example or user-specified assertions seem to be a better solution.

If we look at the most popular end-user programming languages (BASIC, Actionscript/Javascript, and maybe Python in the future), then what we see is that they are all interpreted and action-oriented, and offer quick results with little setup. There is little concern concerning code reuse, since ideally the program should be relatively quick and easy to write. The main contributions of this paper that I see are the focus on verification and testing, as well as debugging, which are severely lacking in the current end-user-programming environments available today. It seems that good visualizations of what the program is doing, as well as automated testing such as consistency checking and WYSIWYT would be most effective in these areas. Finally, I find that the most valuable resource in end user programming is not even mentioned in the paper: the community of fellow end-user programmers who can assist in forums, and provide tips-and-tricks fore more efficiently accomplishing goals. I think that a discussion of how to integrate the community of end-users into EUSE tools would be a significant addition to the paper, and make it more relevant in today's increasingly online, social world.


Bryan Trinh - 11/14/2010 19:12:36

Code Bubbles: A Working Set-based Interface for Code Understanding and Maintenance.

In this paper, a new user interface for understanding source code is provided and evaluated. By controlling the way that windows appear, the user requires less interactions to make use of all the available data. Code Bubbles is an attempt at creating a system that actively displays code windows side by side, without introducing any negative side effects.

It was always apparent to me that reading and navigating source code written by others took up a significant amount of the total time used up for creating new code, but having never attempted to attach a number to this, I was shocked to learn it could be as high as 90%. After reading this, it was easy to see the benefits of displaying all the code at once at a level that is within the cognitive scope of the programmer--methods. After this, the reflow and vertical elision were obvious necessary steps in ensuring that the windows wouldn't take up too much screen space.

One design decision that I would reconsider was the use of rectilinear bubble connections. The intersecting lines can make the associations hard to trace. An alternative solution would be to create a system that generates more organic lines to connect the two bubbles.

What was particularly interesting was that they found that increased performance could not be attributed to navigation gains alone--perhaps indicating a bonus cognitive benefit. My hypothesis would be that the simple design and reduced cognitive load for navigation allows the programmer to focus on the code rather than navigation. The navigation gracefully moves into the background allowing for better flow of the coding task.


Pablo Paredes - 11/14/2010 19:46:52

PART 1:

Summary for Bragdon, A., Zeleznik, R., Reiss, S., Karumuri, S., Cheung, W., Kaplan, J., Coleman, C., Adeputra, F., LaViola Jr. J. - Code Bubbles: A Working Set-based Interface for Code Understanding and Maintenance

This paper presents a novel approach to code maintenance. The system is a simple way to present related code based on methods rather than files. It involves a very simple UI design with the notion of bubbles, which is an instance that does not allow juxtaposition, i.e. requires that each bubble is locates side-by-side with the others. Additionally, bubbles are very basic visual units with no framework or independent navigation or tagging systems, beyond a slider menu and lines that connect bubble with its calls.

I find this approach to code management useful and focused on the right metaphor, as it indeed facilitates code management by linking units of content that make up a higher level understanding unit. Complimentary to the bubble morphological visualization efficiency, the added value of grouping and the extended navigation pane on the top of the screen, which enables a quick visual aid to remember shapes of bubble groups, rather than filenames/methods shows the added value of using human spatial intelligence to offload for traditional memorization.

I believe the system, does not only show great potential for becoming a well-spread tool to be used by programmers, but also it can become a tool that supports other creative processes such as writing, prototyping, product development or others, which rely on different connections between content elements. Although cognitive elements such as memorization and other elements could be further researched, together with ecological performance tests of code bubbles as a complete IDE, I would like to see also an analysis of the level of stress and or anxiety generated by this system as compared with traditional IDEs. I hypothesize that the time it takes to navigate and find a solution working under time pressure (which is usually the case for many programmers) is due not only to the cognitive complexity of the tasks, but also due to the emotional state and sense of progress that is being made. Stress and anxiety can in many cases reduce cognitive and memory tasks due to its overloading nature, which reduces concentration and physical and psychological performance. It would be interesting to do some coupled research on stress levels in these programming tasks using the Stress Management tools being developed at UC Berkeley BiD Lab.


Kenzan boo - 11/14/2010 20:39:46

Code bubbles: a working set-based interface for code understanding and maintenance.

The article describes a new IDE focused arounds modules and individual functions rather than the file. They use bubbles with logically linking arrows that connect the different locations in files. There is also a left right pannable surface that contains the span of all the bubbles. The study determined that it not only decreased the search time to navigate to logical areas, it also seemed to help reduce cognitive load and memory requirement for the users.

When is this available?!? Mapping by fuctions and logical bubbles is a great idea. In my experience coding, something like this would be an amazing help. This system would greatly relieve the memory requirements for me to keep where the next logical steps are. I often have to depend on extra sheets of paper or another text editor to keep the code that i have a logical need for separately. this makes them hard to navigate to and the clone would not be able to directly change. Using a bubble interface logically much better than the current options of using tabs or file management. They should integrate this into an already powerful development platform like eclipse.


The State of the Art in End-User Software Engineering.


This article is about end user programming and how to better support it. Some examples of everyday end user programming is using excel or matlab to help users get their job done better. What makes end user programming different is that these professionals do not do it as their job to ship good code, they simply need to program to help make whatever it is they are trying to do easier.

This is a very important area as more and more professions these days are becoming digital. Everything from accounting to art has become digital with a need for some amount of end user programming to make those jobs easier. This is very different from other programming software that has been made for programmers. These users usually do not have the education in programming to understand extensive programming metaphors, which make writing software for end user programming challenging.