“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.”—Fred Brooks
The role of the UX designer is, in many respects, to mediate between users’ needs and software engineers—to translate user requirements into well?defined interactions that software engineers can implement. But End User Programming (EUP) bypasses this relationship completely. Instead, EUP users become developers themselves, taking complete control of the software development process. This could be the most effective approach. After all, users fully understand their problem domains and needs, so given the right tools, they should be able to create an optimal solution. However, few approaches to EUP have seen wide adoption by users.
An effective approach to EUP must support users in producing working code—users who have little or no formal training in programming. This is a difficult challenge. This column looks at some approaches to EUP and examines their strengths and weaknesses from a UX perspective.
Champion Advertisement
Continue Reading…
EUP for the Masses: The Spreadsheet
The most ubiquitous EUP tool is the spreadsheet. Many users feel comfortable using a spreadsheet to enter their data, manipulate it—using the available functionality—and display the output. Although there are serious deficiencies in the quality of the output of many spreadsheet applications, their popularity remains undiminished. (One study found that 95% of financial models are based on spreadsheets.) So why has the spreadsheet been so successful as a tool for users who want to engage in programming tasks?
Spreadsheets are readily available. They’re part of the suite of applications on most computers.
Spreadsheets provide immediate feedback. Users can make a change in one place and immediately see the results—bypassing the code/compile/test cycle that conventional, compiled programming languages require.
Users can transfer the skills they learn on one spreadsheet application to another.
Most importantly, users can stay focused on solving their problems, using tools that were designed around their needs.
While the spreadsheet has been the most successful programming tool for users, it is still far from commonplace to find users developing particularly complex programs—perhaps for the following reasons:
The application domain is very restricted. Users perceive spreadsheets as tools for processing numeric information, and the majority of their available functionality is built around this assumption.
Users interact with a spreadsheet via a text?based user interface, with little or no support for other modes such as color.
While the code is available at the point of need—that is, in the specific cells to which it applies—it is hard for users to see the overall structure of the program.
Programming By Example
Programming By Example (PBE) systems are both related to and available for spreadsheet applications. Commonly taking the form of macro recorders, PBE systems capture the actions a user takes and enables their repetition on different data sets. Users can either choose to edit the code the system generates to adapt it to another use or use it in its native form. The main advantage of this approach is PBE systems’ ability to show users the code that implements a given set of transformations. Additionally, users can edit the code or expand upon it—gradually introducing users to the macro language and enabling them to learn how to perform more complex tasks. Like the spreadsheet, however, the PBE approach is typically restricted to a single textual mode, albeit with color-coded and structured text.
Visual Programming
UX practitioners understand that how a system represents a concept is fundamental to users’ ability to understand it. The creators of visual programming systems claim that they represent concepts in a way that is closer to users’ own internal representations. Interestingly, proponents of object-oriented programming such as Grady Booch have made similar claims. These systems are notable for their broad use by a huge range of users, across vastly different age groups. Examples range from National Instruments’ LabVIEW—a tool engineers and scientists can use to develop measurement, test, and control systems, shown in Figure 1—to the LEGO Mindstorms system, which children—and many adults—use for constructive play.
Figure 1—LabVIEW
Both LabVIEW and Mindstorms employ the VPL concept of virtually wiring together visual representations of system elements on the screen. Analogous to an object in a more conventional programming language, an element has both functionality and data—some of which users can edit. Of the two systems, LabVIEW is the more specialized. In addition to its visual programming features, it also provides more conventional programming concepts such as hierarchies, arrays, and strings. Users assemble programs by wiring up their various elements, using an approach that is very similar to creating an electrical circuit. Although some may regard this as a way of combining the benefits of both a VPL and a conventional programming language, it also means effective use of the system depends upon knowledge of both circuit notation and programming concepts.
LabVIEW is perhaps the most striking example of how a system whose creators have designed it around an understanding of users can deliver major productivity gains. Research comparing two teams performing the same task, using LabVIEW or the programming language C, confirmed the effectiveness of LabVIEW. In three months, the LabVIEW team went beyond the original requirements in their completed product, while the C team had not yet finished addressing all of the requirements. The fact that LabVIEW facilitated communications between the developers and their customers may have been a major factor in this, because the greater understanding of the system under development by the customers—who were also engineers who understood the LabVIEW syntax—let them contribute more effectively.
Mindstorms is, in some ways, even more remarkable than LabVIEW. Figure 2 shows the LEGO Mindstorms NXT software, which is powered by LabVIEW. Made for children, Mindstorms lets them program hardware components, using a closely integrated hardware and software package. The actual construction of code is similar to that in LabVIEW—that is, users create a flowchart of the components, which they can modify in small ways. Mindstorms lets users see the results of their code immediately—not only on a computer screen, but through the physical artifacts into which their code breathes life.
Figure 2—Mindstorms NXT software
So, does this mean that visual programming languages are the ultimate approach to EUP systems? Both of the VPL systems I’ve described are relatively specialized applications. Their implementations tie them closely to either specific hardware or a specific user skill set. VPLs tend to be limited to concepts we can represent effectively through a visual medium. While logographic language systems such as Chinese can represent a wide range of concepts visually, it is probable that Western language speakers might find it difficult to understand such a wide range of concepts when they are presented visually. For certain programming concepts such as data structures, no appropriate visual representation may exist.
As with any metaphor, the effectiveness of a visual programming environment depends upon users’ familiarity with the source knowledge domain. Therefore, some important questions arise: Is there is an unavoidable power/accessibility trade off? Are metaphors that are capable of powerful visual manipulations necessarily accessible to only small user populations?
In Summary
Back in the early days of personal computing—1981, in fact—some developers created a programming language they claimed would be the last programming language anyone would ever need. So strong was its designers’ belief in this, they called it The Last One. This language essentially took a wizard?based approach to program generation, with users entering broad design details and the program taking care of the rest. However, many years later, software development remains a complex, specialists’ task. Far from that programming language having been The Last One, there are now an estimated 4,000 programming languages available.
Are EUP systems destined to remain niche products? Far from it. Looking at available EUP systems, we can draw a number of design principles for a successful approach to creating others like them:
Build on existing skills and knowledge. Help users by understanding and building on their existing knowledge base.
Provide immediate feedback. Let users experiment and see what works and what doesn’t.
Let users change the level of abstraction. Users need to see the high-level structure of what they are creating, as well as have control over the low?level details.
Make it clear how the details relate to the big picture. Show users how the different elements—both high level and low level—relate.
Users who are programmers are strongly motivated to solve the real?world problems they’re experiencing. Like software engineers, they learn about the parameters of a problem in the process of solving it. The days of users’ creating their own software are still some way off, but for the moment, UX designers, users, and software engineers should continue working closely together and share their understanding, so they can bridge the divide between problem and solution.
Thank you for an excellent article. The article has drawn useful design principles out of some well-illustrated examples. In particular, it had not occurred to me that spreadsheets are a form of EUP. I am investigating the relationship between EUP and web or RESTful APIs. Do you have any thoughts about where web APIs belong in the bigger picture of EUP?
Peter has been actively involved in Web design and development since 1993, working in the defense and telecommunications industries; designing a number of interactive, Web-based systems; and advising on usability. He has also worked in education, in both industry and academia, designing and delivering both classroom-based and online training. Peter is a Director at Edgerton Riley, which provides UX consultancy and research to technology firms. Peter has a PhD in software component reuse and a Bachelors degree in human factors, both from Loughborough University, in Leicestershire, UK. He has presented at international conferences and written about reuse, eLearning, and organizational design. Read More
