Research Directions in HCI I

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Readings

For this lecture, please watch Prof. Brad Myer's talk on "End-User Design and Development" from the IBM NPUC 2009 Conference (his talk starts at 13:30 and ends at 66:30)

http://vimeo.com/5640073

The slides to follow along are posted here:

http://www.almaden.ibm.com/cs/user/npuc2009/slides/EUP-Myers-NPUC-overview.pdf

Questions: Where are the biggest opportunities for Human-Computer Interaction to positively impact how end-users write and debug programs? What approaches were thought to be promising in the past but have not been successful so far? Why?

readings

Brian Chin - 4/19/2010 16:20:26

I thought this reading brought up many interesting issues concerned with the design of social media platforms that exist today. Perhaps one of the most important points that the reading brought up was the fact that it was difficult to figure out what users want in a social networking and collaborative environment. Looking at the sites that have been successful, it is difficult to draw any connections between them. Some, such as facebook, are feature rich, and have a variety of ways that users can interact with one another. Others though, such as twitter, are simple, heavily text based, and have only one main way of interaction. The article also brings up interesting points about the difficulties in testing social media on users. Whereas with standalone interfaces, one can just run a user study, a person's interaction with social media depends greatly on what other users do. This makes it very difficult to run a usability study as there are too many variables to control for and would require a very large number of users to generate sufficient content.


Mikhail Shashkov - 4/19/2010 17:16:04

The tone of this article is celebratory and descriptive; it doesn't particularly dare to say which of the various collaboration types is a good idea or not. In particular, (especially after your criticism of virtual reality in lecture), I am wondering when it is possible to make the distinction between an idea being implemented poorly with a bad UI or design, and an idea being bad in general (having no good UI). At least in the concrete example of virtual reality...


Jason Wu - 4/20/2010 15:52:59

In my opinion, the two biggest opportunities for HCI to positively impact how end-users write and debug code are to improve Visual Programming systems and create Better Environments. Visual Programming systems such as National Instruments Labview, which I have used in EE20N, are quite powerful since end-users no longer have to spend a great deal of time learning syntax, and they also can apply their natural visual cognition skills to solve problems rather than mentally step through the program while staring at a wall of text. I agree with Myers that Visual Programming is not a panacea, and indeed some graphical programs are just as hard to understand as text programs, especially those involving recursion or several nested loops. However, I feel that in the near future, HCI designers may be able improve the ease of editing visual programs as well as eliminate the problem of space. Rather than design for small monitors, I think HCI designers should focus on creating Visual Programming systems for large interactive displays such as the Microsoft Surface or the very impressive interactive whiteboard shown in the previous lecture. With so much more space, graphical programmers can actually see the entire program at once rather than scrolling the screen to view various components. Furthermore, since such displays allow direct manipulation, the functions/tools palette should appear wherever the user touches to facilitate editing; this would be far superior to the current Labview model of having to search in the top menu bar or a palette docked to one side of the screen.

I also strongly believe that Better Environments will greatly assist end-users with programming by decreasing the amount of time and mental strain necessary to write code. Interface builders are extremely helpful, and I am not surprised at all my Myer's assertion that drawing can be up to 125 times faster than coding. From personal experience, XCode's interface builder has been a godsend, and I can't imagine how much longer the programming assignments would have taken if I had to create all views programmatically rather than just drag and drop buttons in the nib file. With ubiquitous computing quickly becoming a reality, HCI designers should create more powerful interface builders (with more widgets, more customization options, etc.) to facilitate building mobile applications. Furthermore, I have never before seen WhyLine, but it looks like an amazing and innovative way to debug code, and I really like how it visually alerts the user to lines of code that may have caused the problem. However, such tools can certainly be improved, and HCI designers should focus on minimizing the gulf of execution. For example, a user should be able to ask a "Why?" or "Why didn't?" question without having to choose them from a hierarchical menu (as in WhyLine) since this is not an intuitive way of asking questions.


Kathryn Skorpil - 4/20/2010 16:14:42

I have many times encountered a situation where trying to explain why computer science is so difficult. Many people not in the field have a hard time understanding what exactly it is we do and how we do it. I definitely agree that it is because the bridge between natural languages and computer science is very wide. Some languages like python have very little syntax and thus are simpler to use, but it is somewhat slow because of not having to manage memory. I am nto sure if we will ever find that perfect middle, but I believe that we are working well with what is given to us.


Yu Li - 4/20/2010 18:04:47

End-User development includes activities from customization to component configuration and programming. It is a research topic that focuses on the activities or techniques that allow end users who are not professional developers to create and/or modify software. Some examples of this are: accounting/spreadsheets, Matlab, creating a web page with an interactive tool, creating email filters, and kids authoring simulators and interactive worlds just to name a few. Many of these tasks are programmed in C++, JAVA, and scripting languages. Although many end users may say they are programming, less then 3% of them are professional programmers.


Annette Trujillo - 4/20/2010 20:53:48

One example given in the lecture about approaches that were thought to be promising was visual programming. It was thought to be successful because people see pictures all the time so it should be a lot easier, can take advantage of peoples 2D and 3D knowledge, avoid syntax, let people enter flowcharts and data flow directly, and overall seemed like an easier to use system. It did not succeed because it does not scale (can't do large programs), it isn't easier to read visual program from textual program, and hard to edit (high viscosity), and it takes more space. I think today visual programming would not be such a hit because people are not used to it, and it may be complicated to learn, depending how the system was created.


Wei Wu - 4/20/2010 21:23:53

Some approaches to end-user programming that have been unsuccessful are programming by example and visual programming. That the former has not caught on is not surprising to me, since programming is very much a thing that has to be learned by doing on your own. Reading examples may carry someone through specific tasks but in order to achieve bigger-picture operations, they need analytical skills and a conceptual understanding of situations and problems that cannot be covered by books. Similarly, visual programming has only been successful at helping kids develop programs because the scope of tasks that can be achieved purely through visual elements is limited and elementary in nature. As soon as interactions in a program becomes complex, its visual presentation could very well be more confusing than a textual representation.

The two biggest opportunities in HCI to impact how users program is through the development of simpler textual languages and better tools for debugging. Making programming languages more readable and intuitive eliminates the frustration that comes with learning a whole new set of syntax for each language. It also makes the language more understandable and appealing to a wider range of people like those who do not program as a hobby but do so as a necessity for their jobs. As addressed in the video, debugging is still an area that has been relatively stagnant for decades, and has much room for improvement, since it is the area of programming that people spend the most time on. I feel that debugging is a task that requires a lot of prior experience and learning to accomplish successfully, and thus, HCI could perhaps alleviate the steep learning curve that comes with it somehow.


Daniel Ritchie - 4/20/2010 23:14:39

I don't think that any one of the approaches to EUP that Myers presented is "the right one." They each have their own benefits, though, and I think these could be amplified if used in conjunction.

I'll apply this idea to one of my early EUP experiences: Marc Overmars' "Game Maker" system. I used this tool to create simple games long before I had any aspiration to formally study Computer Science. Game Maker allows users to quickly create games via a drag-and-drop interface. Users manage assets like "Objects," "Rooms," and "Sprites" with a GUI that allows interactive placement and editing.

However, a user can only go so far with this system. To truly unleash the tool's power, users need to dive into its scripting language--something that I tried to do on several occasions, with no success. The scripting language seemed so daunting and so divorced from my experience thus far with the drag and drop interface. Game Maker appeared to me to be two different interfaces: A Visual Programming tool (the drag-and-drop portion) and a Simple Textual Language.

I think this interface could be much improved by intertwining these two aspects. For instance, if a user puts a new sprite into his game via the GUI, he should have the option of viewing the code that would do the same thing. Much like Visual Studio or the "view source" option in Firefox, this feature allows for end users to build up a formiddable knowledge via "example-centric programming": as they see more and more fully formed examples that fit a general pattern, they're increasingly able to recognize this pattern and modify it to fit their needs.

There are obviously technical hurdles to overcome in implementing such an interface ("if the user modifies the code generated by a drag-and-drop element, can we parse that code and change the drag-and-drop element accordingly?"), but they're not insurmountable. From what I've seen, the Alice programming environment permits interactions along these lines: a GUI that can be gradually stripped away to reveal a Java-like language running under the hood. Alice was designed with programming learners in mind, but I believe this same principle can be succesfully applied for the benefit of end-users, too.


Bryan Trinh - 4/20/2010 23:27:25

As a student with very minimal exposure to programming I have spent just as much of my time this semester learning how to navigate the IDE and debug effectively as I have learning the coding structure. If the world really wants to unleash more programmers into developement, spending time on developement tools could bring about exponential change in productivity.

One of the biggest issues for me is learning how the code should look and be called. If there was a barebones example for every object reference in the the documentation, it would drastically speed up coding time for me. I wouldn't have to search different online resources for tutorials.

I have used several visual programming tools and they are no where near as easy to use as a simple program like Matlab. The cost of dragging graphics around is just too high to do things quickly and efficiently.


Alexander Sydell - 4/20/2010 23:33:59

The biggest opportunity for HCI to positively impact how end-users write and debug programs is to make those tasks easier for them by creating a lower barrier to entry and lowering the ceiling on difficulty of use. As Myers demonstrates, current languages and technologies become very hard to use very quickly, which is something that end-users can't cope with, and some languages are quite difficult even for the most basic things (as shown by his Java hello world example). Approaches that have been tried include visual programming, which took up too much space and was difficult to edit, programming by example, which did not always work because people were bad at providing examples and sometimes the examples were hard to understand, simpler textual languages, which still appear to be too difficult for end-users, and better programming environments, which tend to be limited to certain parts of programming.


Jessica Cen - 4/20/2010 23:44:50

The biggest opportunities for HCI to positively impact how end-users write and debug programs are if they build better environments with interactive tools. I believe some end-users are not good programmers because they might not believe that a line of code makes some kind of effect. An interface builder, however, might let them better visualize what the code is expected to do. In addition, interface builders avoid writing a lot of code for the user interface. Even Myers stated that “drawing is up to 125 times faster than coding.” However, interactive tools such as Visual Basic are still not as popular as Java because they are limited and more coding is needed to do more things.


Richard Mar - 4/20/2010 23:50:25

I think the biggest opportunity by far for impacting the writing and debugging process for end-users lies in the tools that they use. One of the most powerful properties a tool can have is high-speed feedback of what a user has written. It's the fastest way to learn what a given object does, as well as test the behavior of the user's creation.

Intuition based on teaching, such as using a set of rules to create a program, did not translate well from theory to reality. Humans are bad at catching corner cases, and the rules they end up creating are often too inflexible. A rule system is still mired in the quicksand of syntax, and describing complex cases would quickly become unmanageable for users.


Boaz Avital - 4/21/2010 0:39:59

I can't find anything about it online but I know the .NET team at Microsoft is working on visual programming, kind of like creating an activity diagram where you specify what each node does or what decision it makes and it compiles like a real program.

To be honest, I don't understand what the goal is here. What's wrong with needing to learn to be a programmer in order to be a programmer? You need to learn to be a carpenter in order to be a carpenter. I think it's an interesting characteristic of programmers themselves that we are always trying to make things simpler.


Calvin Lin - 4/21/2010 2:38:03

On a conceptual level, I think what makes programming seem like an alien language to many of my friends and just average people in general, is that programming requires you to shift your mind from your normal way of thinking and interacting with the world to the world of the programming language(s) you’re using. There is a huge gap between popular languages such as Java and a person’s natural way of describing what they want to happen, and thus it takes students like me several years to become a strong programmer.

I think the biggest opportunity for HCI to impact end-user programming is for language designers to bridge the gap between the way a programming language is expressed and the way an average user thinks, speaks, and interacts with real-world objects. Prof. Myer gave several examples of languages that have attempted this, but none have been successful because they each had major limitations and most don’t scale. In the lecture he gave a simple example with the survey on describing Pacman’s movement. That kind of expression (“Pacman stops when he runs into a wall”) should be the goal. Perhaps we can still ask programmers to overcome a substantial learning curve, but I think natural language input would make programming extremely accessible for the general public.


Aneesh Goel - 4/21/2010 3:08:39

Visual programming is both oversold by its proponents and underrated by most "serious programmers"; it's a powerful tool with two valuable benefits to EUD that many programmers ignore, but outside those domains it falls short, something that proponents of systems like LabVIEW try to handwave away, leading to frustration for new programmers and derision from those with experience.

Visual programming's two strengths lie in emulating and controlling hardware and physical processes and in providing an easy to understand interface for simple programs. Working with Lego Mindstorms demonstrates both principles; children in the 4th grade can quickly master controlling the various motors on their robots, build programs, and even add clever rules for sensor interrupts; FIRST Lego League students at that age design fully autonomous robots for completing simple tasks using those sensors and motors.

Even in complex tasks, visual programming can shine, so long as it is used to enforce proper lessons about writing code; with good documentation and modularity in both, graphical representations of code can be close to as readable as text-based code, though as Professor Myer's talk mentioned it is certainly not *more readable*. However, for tasks outside its effective domain, building blocks in graphical programming languages can become a painful exercise; this is where enthusiasts lose sight of the problems and the effectiveness of using graphical programming as a learning technique falls apart. UC Berkeley's EE20 course is an example of this; while some of the coursework is perfectly suited to using LabVIEW, other parts are awkward and are best done by inserting a text-coding block into the flow that both disrupts the programming and requires learning a whole new idiom; the code ends up being less readily understandable than either format would have been alone, and harder to write.


Owen Lin - 4/21/2010 3:49:10

The statistic that drawing UI is 125 times faster than programmatically coding UI is very shocking. I feel that using Apple/Xcode's Interface Builder is very intuitive for the most part, and can't imagine coding buttons and placing them programmatically when it's so easy to snap the buttons in the right place using WYSIWYG. I feel that if the Interface Builder can be expanded to have more functionality, it may cut down coding time even more. For example, right now users have to manually push/pop views through the navigation controller programmatically, when it could just as easily be done through Interface Builder. However, much programming (such as algorithms or data structures) is done more efficiently in code, and I think that there's not much room for improvement there. Algorithms are just inherently difficult to grasp.


Hugh Oh - 4/21/2010 5:18:19

The biggest opportunities for Human-Computer Interaction to positively impact how end-users write and debug programs is increasing the ease of use. This is important in two ways. First, to increase the number of end-users which will allow more people to understand and break down code. Second, stripping down the unnecessary syntax can really clear most bugs since a lot of bug have to do with the actual language itself other than higher level concepts.


Vidya Ramesh - 4/21/2010 8:57:29

Brad Myer discusses "End-User Design and Development" in his lecture. He starts off with a bunch of definitions including the definition of development and end-user development. The latter he defines as the end user doing any design, programming, testing, documentation, management, or any other development related activities. He mentions that even something as simple as creating email filters can be considered as end-user development. He also emphasizes the importance of end-user development as well as the consequences that arise from poorly done development. A way of preventing such consequences is through GUIs and interactive tools for end-user designers. Myers comes up with this approach he calls "Natural Programming" where the tool is designed to support the way people think about a task rather than the way needed to execute the task.


Andrey Lukatsky - 4/21/2010 11:26:10

I really think Visual Programming is the best way to get young people interested in the field of Computer Science. I think the CS department at Berkeley would receive more students if instead of learning Scheme, we build with Lego Mindstorms. I think this would definitely ignite more initial interest.


Dan Lynch - 4/21/2010 11:54:13

Brad Myers first talks about definitions of programming. He then stratifies the different programmers. This is interesting. Some people may be programming that are not actually programmers! This category is End-User programmer.

Why is it that Development does not include using the program? Using it should always be the development due to iterative design, but I'm guessing he is just defining this in a rigorous way.

First off, I think this is the wave of the future. That is because you aren't really designing for the dumb user anymore, but someone that you expect some small degree of intelligence. Even some form of graphical programming requires that they know some organizational structure and math. In addition, a more intelligible user base allows us to give them more powerful tools. I myself have participated in this movement, by creating a scripting language for building 3D scenes. I truly believe in developing for the psuedo-programmer. I have explicity limited my users base to people who will create a 3D scene via a text file and some graphical interactions. By utilizing this model, my framework is much more fluid, and has allowed many macros and scripts to be developed fairly quickly, and helped me to come up with ideas as I use the software throughout its development.

With 12 million programmers, we have a lot of room to develop. With graphical programing and interactive web pages, we can easily create software that allows end-user programmers to program more effectively. I have also created user interfaces that generate html and xml. This was probably my first proof of being able to develop for the non-developer. My brother for example, is a film maker and wanted to make a website. He was able to create an entire web page with 10+ video galleries, numerous photo galleries, biographies of people working on his movie, etc., with no experience in html or web design. I came up with this idea in parallel with many others out there in the web. These types of interfaces are in their infantcy. We will see *much* more.


David Zeng - 4/21/2010 11:57:29

I recently read an article about the recent advent of programmers and the seemingly reduced abilities of said programmers. While it may be important for users to have a good UI, it seems that any decent programmer will be able to work with a non-disastrous UI. In fact, many of the best programmers I know work with vi, which doesn't even seem to have any apparent interface, only keyboard shortcuts. I'm not saying that we shouldn't care about the interface for programmers, just that, we should keep in mind that making everything easier for programmers also makes it so that they don't have to train their minds as much. Consequently, it leads to a reduction in ability, which is not the overall purpose.


Darren Kwong - 4/21/2010 12:32:24

I think there is a balance between functionality and usability. A complex syntax might be tedious for novices, but it tends to offer a high ceiling for experienced programmers for a particular language. HCI can improve programming by making things more efficient in terms of auto-completion and real-time debugging features, such as in Eclipse. The goal seems to be to make things easy while offering high functionality and options, which tends to involve a complex language and a good programming/development environment. The learning curve seems to be a big issue, and good programming environments can help bridge that gap.


Jeffrey Bair - 4/21/2010 12:50:37

Some of the biggest places where HCI can impact how end-users program include creating better APIs and documentation for functions that people create. With a good API people can have a higher level of understanding, and be able to program without trying to write basic methods that should already be in the API which can speed up the process by at least 2x. Making better graphical user interfaces for programming is something that many have already tried but it can still be improved as there are still a lot of issues users have with it. Oftentimes what we interpret with graphics may not be what another person interprets and having just text cuts the errors down by a lot. An approach that was thought to be promising in the pass include use of Visual Basic. Though the language may seem to have a small learning curve, some things including design, selection, use, coordinating, and understanding caused users to hit barriers that they couldn’t overcome. The use of new graphical user interfaces such as the iphones interface builder can cut coding time by a lot but also introduces new problems such as the linking of pictures to code which people may not really understand.


Michael Cao - 4/21/2010 12:50:49

One approach to end-user development that was thought to have been successful and promising in the past but has not been successful so far is visual programming. The draw was that visual programming would be more natural to the typical user and that people were already using graphical notations. However, studies later have shown that visual programming is no better for understanding than just normal text based programming. This is because visual programs are usually very difficult to edit, and they take much more space than text. It may be that sometime in the future, someone will invent a way to use visual programming well. But until then, looks like text based programming will remain as the standard.


Long Do - 4/21/2010 13:07:04

I am a big fan of end-user programming since many times the user will often use the system differently than how the developers intended. If the users are able to be given a template system and be able to customize it to the way they want it, this would be great. The only problem is that the programming is still a mystery to users and the gulf of execution is often vast, with users not knowing the syntax of the language or some other reason. Interface builders, like the one used by xCode, is very helpful for novice users to plan out how their app will look like but it is still very complicated in the steps of connecting the UI elements to the code. The IB is also limited in how accurately it shows the elements, such as UI Tables not showing an accurate representation of the cells. To help end-user programming, we should help bring code-writing to a interface-building system.


Nathaniel Baldwin - 4/21/2010 13:32:14

This was a neat video - an interesting overview and history of the challenges people face in doing "programming" of any kind, and some of the attempts to reduce them. I found it really heartening that people are doing work in this area, because I've long thought along similar lines to the 1985 quote he presented - not enough time was being spent on improving the ease of use of programming, instead being devoted to more technical details. I guess that's why I'm a CogSci student interested in CS, and not the other way around. I've really enjoyed using Interface Builder for this class, so I'm glad he touched on that as one of the ways to improve the programming experience, and hope that continues to be extended in a user-focused way. I thought it was interesting that many of the attempts at making programming "more friendly" were aimed at kids. I think that's a good idea, and hints at something that he didn't touch on, but is probably also important going forward; as more and more things that were previously done by humans instead are done by computers - that is, as the job world evolves - the education and training that we give young people in preparation for that job world is going to need to evolve as well. That may be a whole 'nother can of worms, though...


Matt Vaznaian - 4/21/2010 13:38:42

The biggest opportunity for HCI to positively impact how end-users write and debug code is through a concept called Visual Programming... essentially allowing the programmer to get his/her thoughts out without having to understand the syntax and complexities of a programming language. An example approach would be Programming by Example. This is where the user gives an example or two about the design they are trying to create and the computer figures out how to generalize it. This was no as successful because end-users are not that good at giving examples. When asked to show multiple examples they get stuck, so the system never learns. Also a lot of concepts are really hard to give examples of, like sorting. Another approach is simpler textual languages. However, some of the text was ambiguous, which confused users. Drag and Drop editors like Alice have proved to be successful, however editing code is pretty difficult to do.


Divya Banesh - 4/21/2010 14:14:47

One of the biggest opportunities for Human-Computer Interaction to positively impact end-users is to provide better software tools for writing and debugging programs. As Professor Myer says in his talk, end-user programmers come from a variety of backgrounds and experience working with programming. They may be writing code a lot or just some of the time. Nevertheless, giving them a easy user interface to work with, that explains how to program for non-programmers is essential. Giving a more graphically based ui might help them with syntax or make less mistakes, allowing them to spend more time on their subject and less time coding.


Weizhi Li - 4/21/2010 14:50:34

This presentation gives us an overview of the current issues involving Human-Computer Interaction for end-user programming. The industry are working on improve End-User Development experience for many years but have not been successful so far. The programming development for end-user is still unfriendly. Many commercial attempts have moved away from addressing end users and programming is still too hard for most people. The main problem is we are facing trade-off between usability and functionality, which makes End User Programming is still research goal.


Bobbylee - 4/21/2010 14:58:55

Better environment is probably the thing that can impact positively how end-users write and debug programs as it helps writing, maintaining and debugging the code. Visual Programming was thought to be something that should work. The reason for failure is probably because it is still too difficult for end-users to learn about the syntax. I learnt VB when I was in middle school. I found that it is even harder to learn than c.


Brandon Liu - 4/21/2010 15:03:25

The biggest opportunities for HCI to positively impact how end-users write and debug programs are by lowering the abstraction barrier to programming.

Certain approaches similar to the ones described in the talk have failed. For example, the Japanese government's initiative for "Fifth Generation Computer systems" in the 1980s was led by the belief that declarative logic programming languages (Prolog, for example) would lower the barrier to entry for end-users and give them access to the compute power of huge parallel machines and databases. The inference made was that procedural programming (thinking like a machine) is the hardest part for end-users. The project as a whole failed due to the introduction of the GUI and personal computer as more agile alternatives.

Languages that attempt to solve some of the issues in the talk, such as COBOL, have succeeded in the sense that moving away from machine language to natural language has helped people pick up programming faster. This is also reflected in today's high-level scripting languages.

The ultimate benefit of these systems will be to increase the number of capable programmers, but I don't think they will help to reduce the number of errors. For example, there are few solutions to lessen errors on formula-driven spreadsheets: one such example is in Apple Numbers where highlighting a cell will also highlight the cell it references. However there's no way for software to detect an errors in this case unless they can predict what types of references are common or uncommon, and point out uncommon use cases.


Jonathan Hirschberg - 4/21/2010 15:09:33

Myers describes several aspects of the process of implementing the ideas a programmer into an application on the computer. He talked about the improvements made to the different steps of the process. For visualization, there are visual programming languages like Labview. To simplify learning languages, there's Logo. There are IDEs like Eclipse to improve the programming environment. One aspect of the process not addressed is the design process. Programmers may have ideas about what they want and may be able to express them, but there needs to be a program that facilitates project management. There are repositories and UML to diagram how things work, but we're on our own in terms of planning out iterations and ensuring that features are completed. Unfortunately, I don't know how such an application could be structured. A potential design would have to be researched with a usability study, just like the studies that Myers described. Those studies exposed the limitations of these improvements to the programming process, and it is important to find out the limitations of this new application so they can be improved upon in the future. For example, graphical programming like Labview was thought to be promising because humans think visually. However, it wasn't that successful because cluttering the screen with graphical elements is still just as hard to read as text. Also, it is hard to build large programs using these graphical elements. They take up the screen and need to be placed and connected properly.


Sally Ahn - 4/21/2010 15:33:11

Myer's discussion on visual programming reminded me of the Logisim program we used in CS 61C to design a cpu. I think this is an example of a successful graphical interface because it made it very easy to see the logic implemented by each circuit component. This is probably because the limitations of visual programming that Myers mention compare the benefits of graphics versus text, and circuit design doesn't require text while programming does. I agree that "Graphical programs are no better for understanding than text" for understanding programming. In high school, we used BlueJ to learn Java. Although graphical representations for classes were easy to manipulate, they could not communicate the concept of what a class was in OOP.


Wilson Chau - 4/21/2010 15:45:50

Questions: Where are the biggest opportunities for Human-Computer Interaction to positively impact how end-users write and debug programs? What approaches were thought to be promising in the past but have not been successful so far? Why?

The biggest opportunity for HCI to positively impact how end-users write and debug programs is to start taking into account usability in the design of languages. Some things in programming are just part of programming, but usability is something that cant be greatly improved making it easier for users to do what they actually want.

An approach tried unsuccessfully in the past is a shift to visual programming. The attempt at visual programming was successful in some ways but its shortcomings like difficulty in editing and that it ultimately didn't help users understand their programs better didn't allow it to become a highly copied style.


Charlie Hsu - 4/21/2010 15:59:32

I found the problems with programming by example very relevant to programming languages as user interfaces in my personal experience! Searching for code documentation or code tutorials online can be helpful, but many of the problems Myers brought up are very true: lots of Objective-C examples I've read did not operate in the same environment I did (different case), and were either too specific or too general. There were simply too many "different cases" to create examples for all of them.

I felt Myers was right to address IDEs and interface builder applications; certainly, a well crafted IDE aids the programming process and can be an important user interface where design makes a big difference in productivity. However, I felt Myers left out some characteristics of good IDEs that I feel have made programming much easier (at least for relatively skilled programmers), such as colored text, autocomplete, keyboard shortcuts for common code navigation, etc.


Richard Lan - 4/21/2010 17:42:45

Programming can be viewed as a human-centered activity, because it involves the conscious transfer of logical ideas from the mind into a . End user programmers are typically people who need to program, but only do it to accomplish something else. Therefore, they are not professional programmers and don't know that much about programming. The development of good programming interfaces should then focus on how to make the process of designing a program easier for novice programmers. Originally, computers were designed solely for programming, so anyone who used a computer was a programmer. Some aspects of programming, such as abstraction and recursion are inherently difficult, but other problems are usability or systems problems. In these problem areas, interfaces between the human and the computer have room to improve. One way to alleviate this problem is to reduce complexity in our programming languages and to reduce the learning curve associated with these languages. Good programing languages are natural and mimic how people actually think about the programming problem. Programming is the expression of logical ideas, in essence, and oftentimes the ideas are easier to express graphically. Therefore, another approach is to use visual programming languages, such as scratch, which remove the need to learn language syntax.


Jungmin Yun - 4/21/2010 17:43:08

End-User Programmers are people who write programs, but not as their primary job function. They write programs in support of achieving their main goal. End-User Design is about deciding things about the program, what to program, how the program will work, and user interface from the program. End-user development is about all the activities invalid in software, and it requires analysis, testing, documentation, management, etc. Visual programming, programming by example, simpler textual languages, and better development environment are approaches for EUD. Recently, we focus on reliability.


Daniel Nguyen - 4/21/2010 17:46:24

I think that the best way for HCI to positively impact end-users is through mixing graphical and traditional programming environments, such as the XCode system that is used in class. Using this in combination with a new, intuitive yet deep language would probably be the most successful tool in allowing the end-user, wherever they may be on the spectrum of skill, to accomplish their goals. However, this is a very idealized notion that could never be perfectly implemented due to users' constantly changing expectations and needs. But given the examples of end-users from the presentation, it seems like the real challenge is providing an way for the end-user to learn what the need to know for their specific applications. Personally, I believe that the best, and sometimes only, way to do this is by learning the basics of programming just as any other person would. This way, their skills are more universal and transferrable, as opposed to very selective and unique.


Geoffrey Wing - 4/21/2010 17:46:28

I enjoyed the video, rather than the reading this week. Brad Myers talked about a lot of things that I have touched upon in the classes I have taken in the past. In API usability studies, the slides say that "Documentation can overcome some of these problems." I agree with this statement, and I personally like to make sure I create good documentation when possible. Documentation is also a heuristic we learned of earlier in this course. In addition, the same slide states "indirect creation of objects has penalty of taking 2.1 to 5.3 times longer," which reinforces the notion of direct manipulation in UI design.

In his discussions on visual programming, he uses LabView as an example. In EE20, we had to use LabView during labs, and though in theory, I feel like visual programming would be easy to do, it was rather cumbersome with LabView in practice. In my experience, his drawbacks of visual programming (difficult to edit, not any better to understand that text) are true. In high school, when I took AP Computer Science, we used an IDE (BlueJ) that had a small visual programming interface. We could create classes in a project graphically, but we actually had to write physical code. When we implemented or inherited from another class, the interface showed some sort of an arrow to show the connection between each class. When we manually coded a relationship, some sort of an arrow would appear between classes. As a young programmer, I found that pretty helpful.

In his section about "Better Environments," he talks about interactive tools like "interface builders." Interestingly enough, we have an interface builder in XCode. I can appreciate the visualization of connections, but often, I still get confused on what to actually connect. Sometimes you need to write some code, before you can make connections.


Andrew Finch - 4/21/2010 17:47:04

I found the most interesting part of Brad Myers' lecture to be the piece on visual programming. I used to wonder why visual programming methods hadn't completely taken over traditional text-based approaches, but now I can see that it isn't really that much better--editing is slow, it's not easier to read, it takes up a lot of space, etc. However, I believe that there is a place for graphical representations in programming, and that is in program execution and debugging. One of the biggest problems with current IDE's is that they do a lousy job of giving the user a good idea of what's going on while the program is running. It would be nice to see this process animated. Animated visuals such as arrays being traversed, instances being created, and memory being allocated would vastly improve the debugging process.


Long Chen - 4/21/2010 17:48:36

A past approach that has not been significantly effective is visual programming. Although they are helpful in representing physical objects or teaching young programmers, there are some limitations being solely dependent on graphics. The user's range of freedom or precision is only as good as what the tools can offer. There is also an extra layer of HCI on top of the actual code and thus the speed and efficiency may be decreased. As mentioned in the video, visual programming is definitely a great introduction for beginners, but are not optimal for any in depth projects. I believe Hardware is actually more of the key driver of upcoming HCI products. Although the Software is still important in dictating the interaction experience, new hardware introductions will actually allow experiences that were not possible before. Things such as the HP Slate and Microsoft Surface are potential game changers with Human-Computer Interaction. Also, the development of almost ubiquitous internet connections will make HCI more a collaborative and group experience. The visual programming discussed above would be done in a completely new and collaborative environment, and the corroboratory aspect will make programming and debugging a more streamlined process.


Jordan Klink - 4/21/2010 17:49:09

The biggest opportunity for HCI to positively impact how end-users write and debug programs would be to develop an interface for a user that would completely abstract away all elements of programming to the point where the user didn't even know he/she was actually programming. Whether or not this is realistic remains to be seen, of course, but this is potentially the greatest goal HCI could achieve for end-users. The previous approaches have all failed because they either did not abstract away enough programming detail, or the interfaces themselves added so much overhead that it was just as difficult to use the interface as it was to just program regularly.


Mohsen Rezaei - 4/21/2010 17:50:23

User-end programming have had its ups and downs in terms of writing code, debugging, and motivation. Programming languages have different popularity and some have even been turned down for not being efficient and effective. Languages like HyperTalk been turned down since the syntax is not programmer friendly since its too long and hard to remember. The syntax was invented this way because it was meant to be like English language. AppleScript is an extended/newer version of HyperTalk which is still not as popular as other scripting languages. Changing text-based programming languages IDEs to more of a interactive programming languages IDEs programmers are more efficient and effective. As mentioned, for example when designing UIs the programmer would be able to drag-and-drop in the IDE which is faster and more familiar to any programmer. WhyLine is the other IDE that focused on debugging a program that somebody has written. This helps people write their programs even faster. All these come together to decrease and minimize the frustration and time, and maximize output and quality.


Victoria Chiu - 4/21/2010 17:53:05

Instead of using keywords, using graphical notations has been used to make programming easier. However, graphical notations are not necessary to be easier to understand than actual keywords. Visual programmings are also hard to edit and take more space than text.


Linsey Hansen - 4/21/2010 17:53:25

For starters, I thought this was neat because I never though of "End-Users" as being their own group of people (I kind of just thought of everyone as programmers, where some had more experience than others). But yeah, I personally thought visual programming like "Lego Mindstorm" was totally awesome when I was younger, even though I didn't know how it worked, but up until now, I always thought of that as being one of the easier ways for someone who wasn't a "programmer" to program, but after watching/reading through this, I now realize that is probably one of the worse (unless you are a little kid). Other programming methods are definitely a lot more efficient and probably less confusing in the long run... As for "better environments" I am actually kind of a fan of those, since as with the iPhone interface builder, I was totally able to use that even though I had no idea what I was doing... Although now I guess it is kind of bad for learning because of that, and it can definitely hinder the user's understanding of a program.


Conor McLaughlin - 4/21/2010 17:53:44

The divide between effort oriented towards interpreting programming between the syntax and the computer versus programmer and the syntax highlights why Computer Science is considered such an incredibly difficult major that only a certain type of masochistic personality is willing to indulge themselves in. The success of interface builders (125 times faster, whoooaa) shows there is a definite unexplored field that could revolutionize the time it currently takes to implement a vision of a project. Debugging, one of the most tedious and obnoxious of tasks associated with programming would be vastly improved if I could get my hands on the Why Line and speed up debugging by three to eight times. The truth is Computer Scientists enjoy how opaque their field is, but as designers we design products and programs to make the lives of others easier and thus allow them to do their job better and push it to further and further bounds. If we take the same approach to our own interaction with our chosen profession, we can hopefully produce similar results and push the field of Computer Science to limits no one would think possible in the time given.


Wei Yeh - 4/21/2010 17:54:22

I disagree with the whole idea of end-user programming, at least in the sense that it should not be thought of as traditional programming. Just as not everyone who drives a car should be able to fix their car like a car mechanic, not everyone who uses something powered by a computer should be a programmer. Programming should be left to programmers. The user interfaces provided to end-users should not at all resemble what a programmer would have to communicate to a computer. Basically, my opinion is that if an end-user has to "program", then you're doing it wrong.


Wei Yeh - 4/21/2010 17:56:01

I disagree with the whole idea of end-user programming, at least in the sense that it should not be thought of as traditional programming. Just as not everyone who drives a car should be able to fix their car like a car mechanic, not everyone who uses something powered by a computer should be a programmer. Programming should be left to programmers. The user interfaces provided to end-users should not at all resemble what a programmer would have to communicate to a computer. Basically, my opinion is that if an end-user has to "program", then you're doing it wrong.


Brian Chin - 4/21/2010 17:58:28

I felt the video was an interesting introduction to end use design and development. I think that end user programming is growing rapidly in the US and is become vastly more important than in the past. I agree with the author when he talks about how end user programming is still difficult to do. I have seen various applications that have been made to help end use programming and feel that there are great drawbacks to each. One of the ones mentioned in the slides was flash. Flash is an easy way to create graphics or movies, but the interface can become cluttered and difficult to use. Also, many of the more advanced features are difficult or impossible for new users to use. Another example that I think of is scratch. Scratch helps amateurs program by using blocks that can only be attached together if they would not cause an error. But I feel that this may just cause users to concentrate on conecting blocks instead of programming to solve a problem. Much more research needs to be done in this area.


Arpad Kovacs - 4/21/2010 17:59:18

The fundamental problem discussed by the video is that programming is still very hard for the general public, therefore our goal is to design gentle slope systems that start from a low threshold to avoid barriers to start programming.

Several different approaches were used to help programming for EUDs.

1. Studies:

Identified problems with learning different languages

Natural programming approach - see how people think about a task and design tools to support their thinking

Barriers for users to learn a language - how it is used, how to design the algoritm, etc.

Behavior studies - prototyping complex behaior is harder than the appearance, sketches and storyboards may not be adequate


2. Visual programming

Building on graphical tools, such as flowcharts and state transition diagrams, use graphical representation to avoid syntax and harness the human visual system

A well known example is National Instrument's LabView program. The early, schematic-like version with its engineering notations was replaced with a much more readable and easier to understand tool.

Lego Mindstorm - PC brick building architecture, easy to use

Scratch - new language for kids, jigsaw pieces fit together

Problems: There are some benefits for novices, but every notation has advantages and disadvantages, graphical programs are no better for understanding than text and visual programs are usually very difficult to edit while taking up more space than text.


3. Programming by Example

Create a program by performing the steps by example. It helps avoid the problem of abstraction, but it assumes the user knows how to solve the problem and the user knows how to do the problem concretely. Other problems are that the systems often need examples of different cases and people are not good at giving good examples. Sometimes by example is harder than expressing desired result. Most coding is reduced to editing the code, but if someone can write the code, why not write it directly.


4. Simpler Textual Languages

Many languages were designed to allow easy programming starting from the Basic language. Some of them designed to be similar to English, but results are inconclusive whether that helped.


5. Better environments

Integrated development environment (IDE) helped with creating, maintaining, and debugging the code. While structured editing can help the construction of correct programs, acquiring language syntax is a barrier to novices, especially for children. Reorganizing and editing the code later is also very difficult.


General problem: Not much support for EUDs and especially for debugging; Some Promising approaches:


1. WhyLine debugging tool - support for debugging. Debugging problems are addressed by "Why" questions, "why did" and "Why didn't", and the UI allow directly asking these questions. Answers use visualization and highlighting of code. This technique makes debugging 3 to 8 times faster.


2. Interface Builders

Allow graphical parts of interface to be created with an interactive tool. Drawing is up to 125 times faster than coding, limited to only parts of the development.


3. Recent End-User Software Engineering

Initiative to make software created by end users more reliable and correct, bring "Software Engineering" principles to end users who will not follow strict processes. An example is WYSIWYT (What You See Is What You Test), where users can enter assertions and the system can figure out more assertions to pin-point errors and problems.


Mikhail Shashkov - 4/21/2010 18:24:50

This is "late" because the spreadsheets.google server was down and giving me a 505 error about 1.5 hrs before now.

I wanted to comment that all of these "more visual" programming languages seem like good ideas, but will never be successful for programs requiring low-level manipulation, it is simply too complicated to represent visually.

Also, I wanted to say that there was surprisingly little mention (1 slide) about debugging. To me, if you could keep everything the same but find a way to provide meaningful error messages that really tell you what is wrong and perhaps how to fix it, programming would be a million times better for everyone. I'd like to know more about current pursuits at achieving this.


Raymond Lee - 4/21/2010 19:09:05

I think that many of the approaches discussed have been successful in their niche markets. For example, the lego mindstorm visual programming language is robust enough such that there are still many novice programmers building lego robots today. As for interface builders, the large volume of iPhone applications by amateurs and professionals should speak for the success of the "better environments" approach to improving end user programming. What I don't see working out that well is the "simpler languages" approach. Many of the languages discussed in this section don't seem to be used often, I think it is because they fall into a crevice where they are not easy enough for novices to learn and not powerful enough for professionals.


Tomomasa Terazaki - 4/21/2010 21:52:14

Looking at the video, it seems as if there is a bright future waiting for us in the sense of Human-Computer Interaction. I did not know that 12 million people do some type of coding before the video. I thought it was much less than that since every time I say I am a computer science major to other people, they do not really know what computer science is how to code. It will be interesting to see if end-user programming becomes popular because in that way, everyone will basically have his/her own HCI and that way it will make the convenience of using the computer much easier. Also, the End-User Software Engineering opened my eyes because it was such a new idea for me. Soon all the computers will be personalized for each person’s use. However, this is not good all the time since that way other people cannot use other computers or laptops. Right now the computers are made so it satisfies 95% of the people as we learned earlier this semester but I think that is good enough. Even though End-User Programming would make mine easier but I will not be able to understand others, so I like this idea of having standardized computer we have today.


Saba Khalilnaji - 4/21/2010 22:45:17

End User's far outnumber professional programmers because clicking and typing hello world is vastly easier than creating a program to do the same thing. Furthermore there is a level of complexity confusion with programming languages where in the example given for a java hello world, the programmer needed to know 9 specials words and use 3 different parenthetical symbols to complete the task. I think the idea of natural programming sounds very reasonable in a sense that I wonder why there are no amazing simple languages that are just logical in a sense of its syntax and meaning. But languages need some sort of complexity with them for some programs need are large array of features that are only appeased by complexity. Although there are definitely some amazingly simple languages, like scheme, that are versatile enough to create amazingly complex programs.


Arpad Kovacs - 4/21/2010 22:53:51

Google forms was not working this afternoon for me, so I am resubmitting my response.

The fundamental problem faced by End User Development (EUD) is that programming is very hard for the general public. Although programming tools have evolved over time, very little attention has been devoted to making debugging easier.

One approach is visual programming, which uses graphical representations such as flowcharts and state transition diagrams to avoid the syntactical pitfalls of textual coding. National Instrument's LabView for engineers and Scratch, a language for kids consisting of jigsaw-like pieces that fit together, are successful examples of this paradigm. However visual programs have some limitations: they are often quite difficult to edit and take up more space than text; in addition, visual programs do not scale well, therefore it is very difficult to make large complex programs with them. Another approach was the use of simple textual languages. Some of these like Basic and Pascal were intended for teaching programming with their English-like syntax, but results about their success are inconclusive. Programming by example seemed to solve all these problems by creating programs from a user-defined archetype. While this approach helped to avoid the problem of abstarction, it assumed that the user knows how to solve the problem. Additionally, people are often not good at giving good examples, or sometimes it is hard to provide a good example.

Promising developments are better environments (IDEs) that can help programmers create, maintain, and debug their code. Interface builders can help avoid tedious coding, increase efficiency, and reduce error rates substantially by placing buttons and other graphical elements on the screen interactively with a well-designed toolkit. The WhyLine debugging tool can speed up debugging by visualizing how certain values were derived. Another example of a debugging tool is WYSIWYT (What You See Is What You Test), where users can enter assertions and the system can infer more assertions to help identify errors and problems. Finally, End-User Software Engineering can educate EUDs to create more reliable and correct code by bringing relaxed Software Engineering principles to end users who are not expected to follow strict processes.



[add comment]
Personal tools