The%20Past,%20Present%20and%20Future%20of%20Programming%20in%20HCI - PowerPoint PPT Presentation

About This Presentation
Title:

The%20Past,%20Present%20and%20Future%20of%20Programming%20in%20HCI

Description:

The Past, Present and Future of Programming in HCI Brad Myers and Andy Ko CMU UW – PowerPoint PPT presentation

Number of Views:112
Avg rating:3.0/5.0
Slides: 63
Provided by: BradM156
Learn more at: http://www.cs.cmu.edu
Category:

less

Transcript and Presenter's Notes

Title: The%20Past,%20Present%20and%20Future%20of%20Programming%20in%20HCI


1
The Past, Present and Future of Programming in
HCI
Brad Myers and Andy Ko CMU UW
2
why talk about programming?
  • programming languages are human-computer
    interfaces
  • The Psychology of Programming 1973
  • Software Psychology Ben Shneidermans
    book1980
  • Empirical Studies of Programming (ESP) 1986
    through 1999
  • Psychology of Programming Interest Group (PPIG)
  • since 1987

3
why talk about programming?
  • programming languages and tools affect
    human-computer interfaces
  • HCI researchers have contributed to the way most
    software is created today
  • ubiquitous use of toolkits and IBs
  • general computer use increasingly involves
    programming-like activity
  • scripting, customization, mail rules, Web 2.0,
    etc.

4
talk outline
  • computing becomes a field 70s, 80s
  • everyone computes 80s, 90s
  • everyone is connected 90s, 2000s
  • everyone is programming the future

5
talk outline
  • computing becomes a field 70s, 80s
  • everyone computes 80s, 90s
  • everyone is connected 90s, 2000s
  • everyone is programming the future

6
drivers
  • the software industry was new
  • CS departments were new
  • but learning syntax was difficult and typing code
    was cumbersome
  • studies of novice programming errors
  • new interaction techniques (visual programming,
    programming by example, syntax-directed editors)
  • algorithm animation, code visualization

7
trying to make programming easier
  • simpler languages
  • visual programming
  • visualization
  • programming by example
  • toolkits and interface builders
  • syntax-directed editors
  • interactive development environments

8
simpler languages
  • maybe we can make programming accessible by
    making the language simpler, and including
    graphics?
  • Basic (1963)
  • Logo (1966)
  • Pascal (1970)
  • Hypertalk (1987)

Nope
9
why not?
  • didnt understand what was fundamentally hard
    about programming
  • inherent difficulties of computational thinking
    Lewis Olsons cognitive barriers, 1987
  • we identified 5 classes of barriersKo Myers
    2004
  • (have been hundreds of studies about why
    programming hard)
  • people confused when syntax is flexible
  • learning programming didnt transfer to better
    learning in math science

10
visual programming
  • maybe we can make programming easier by using
    graphics instead of text?
  • PICT
  • Glinert 1984
  • Flowchart
  • Only 4 variables
  • Animate execution

11
visual programming
  • maybe we can make programming easier by using
    graphics instead of text?
  • Agentsheets
  • Repenning 91
  • Agentsheets.com
  • Before and afterpictures as rules

12
visual programming
  • maybe we can make programming easier by using
    graphics instead of text?
  • try using ideas from spreadsheets
  • NoPumpGNicholas Wilde, Clayton Lewis. CHI90
  • C32Myers 91

Nope
13
why not?
  • visual programming doesnt scale to useful-size
    programs
  • visual programs have higher viscosity
  • Cognitive Dimensions analysis by T.R.G. Green
  • spreadsheet ideas havent generalized
  • didnt transfer to helping large numbers of
    people to be able to program

14
visualization
  • maybe it will help to show pictures of the code
    and data
  • Algorithm animation
  • Code data visualization

Nope
15
why not?
  • not a big part of the understanding problem
  • some people dont understand the pictures either
  • Stasko showed that constructing viz might help
    learning, but viewing, not so much CHI93

16
programming by example
  • maybe it would work to let people provide
    concrete examples of what they want the computer
    to do?
  • Pygmalion
  • Smith 77
  • Show the computerthe desired steps

17
programming by example
  • maybe it would work to let people provide
    concrete examples of what they want the computer
    to do?
  • Peridot
  • Myers 86
  • Show behavior ofcontrols (widgets)by example

18
programming by example
  • maybe it would work to let people provide
    concrete examples of what they want the computer
    to do?
  • Gamut
  • McDaniel 96
  • Tries to infer morecomplex behaviors
  • Do Somethingand Stop That

Nope
19
why not?
  • people are actually not very good at coming up
    with concrete examples
  • examples tend to show the system the same thing
    over and over
  • people cant think of the edge cases and negative
    examples
  • people need to be able to edit the code, so need
    a representation they can understand

20
interface builders and toolkits
  • can people draw their user interfaces?can
    providing libraries help developers?
  • Menulay
  • Buxton 83
  • Draw graphical parts of UI

21
interface builders and toolkits
  • can people draw their user interfaces?can
    providing libraries help developers?
  • Andrew Toolkit
  • CMU 82
  • first component architecture
  • Macintosh toolkit
  • Apple 84
  • provide a library of widgets
  • object-oriented frameworks
  • MacApp - 1986

YES!
22
why?
  • (See HCIC99 talk)
  • Address the useful important aspects of UIs
  • Threshold / Ceiling
  • Right balance
  • Path of Least Resistance
  • Helps create good UIs
  • Predictability
  • Programmers can tell what will happen

23
syntax-directed editors
  • maybe we can solve the problems with syntax by
    letting the editor help with it?
  • Cornell Program Synthesizer, 1981
  • MacGnome, 1988

Maybe?
24
why not?
  • quickly gets tedious for any reasonable size
    program
  • syntax stops being the big issue fairly quickly
  • viscosity is a problem
  • hard to edit programs

BUT.
25
Alice
  • Alice Pausch (1995 - today)
  • drag-and-drop program parts
  • pop-up menus for parameters
  • dramatic impact onlearning andattitudes
  • wide uptake for firstfew weeks ofintro to CS

26
interactive development environments
  • maybe tools can help with the programming tasks?
  • creating, maintaining, debugging code
  • somewhat independent of the particular language
  • code completion, syntax coloring, indenting,
    integrated with debugger
  • early examples Smalltalk (1972), Interlisp
    (1979), Mesa (1980)

YES!
27
why?
  • tools from the early 80s had most of what is
    found in modern tools like Visual Studio and
    Eclipse
  • appropriate level of support for professional
    programmers
  • code completion is the most common means of
    exploring
  • obviates need for short names and helps with slow
    typing

28
but why did it take so long?
  • resistance from real programmers to using IDEs
  • against adopting new tools
  • universities were biased towards Unix and away
    from MacPC, and no decent IDEs for Unix, so IDEs
    were not taught
  • bias against teaching with tools
  • IDEs wouldnt scale to real applications
  • Visual Studio not widely used internally at
    Microsoft
  • not until universities switched to Java that had
    good IDEs for students to use
  • now, programmers are used to using IDEs
  • Eclipse also re-invigorated IDE research
  • plug-in architecture

29
summary of becomes a field
  • learning to program is still hard
  • building small things is easier
  • tools and toolkits and IDEs have a big impact on
    all all levels

30
talk outline
  • computing becomes a field 70s, 80s
  • everyone computes 80s, 90s
  • everyone is connected 90s, 2000s
  • everyone is programming the future

31
drivers
  • computers went from niche to ubiquitous
  • what people wanted software to do became
    incredibly complex
  • software gets more complex
  • more features because companies used
    feature-creep to sell new versions
  • globalization created demand for
    internationalization
  • viruses, spam, hackers ? code must be more secure
  • long-lived software ? the people who understood
    it are gone
  • too big risky to rewrite, so need support for
    learning old software
  • need to use multiple languages and paradigms
  • database, web, spreadsheets, regular languages
    together

32
increased requirements
  • commercial software had to get more complex to
    meet these requirements
  • 1960s  1980s, what we built was limited in
    scope
  • we built large systems, but of relatively
    simplicity
  • DOS 1.0 4,000 lines of 8086 assembly
  • Linux Kernel 2.6 6 million of C
  • Vista 50 million

33
Increased requirements
  • even for research systems
  • used to be possible in research to make small
    things
  • Garnet and Amulet were popular with less than 10
    widgets
  • now, any toolkit needs complex capabilities, like
    standards-compliant HTML rendering
  • similarly, for IDEs tool expectations about
    what is needed

34
APIs manage complexity
  • old
  • write programs from scratch, or
  • use Unix command lines, so used only use standard
    unix libraries
  • new with Windows and Java, massive APIs
  • Java very much designed without I/O built-in
  • shift from writing from scratch to heavy reliance
    on APIs
  • needing lots of documentation examples

35
standards
  • software became more integrated and more
    standards based
  • more different standards
  • more complex standards
  • plain text (Unix) -gt html -gt XML
  • plain ASCII -gt many different flavors of Unicode
  • standard protocols for IDEs
  • expectations that IDE support CVS version control
    system
  • standard for how to compile things

36
summary of everyone computes
  • how cope with increased complexity?
  • APIs to the rescue!
  • but during this period, little research work on
    new languages or tools for helping with software

37
talk outline
  • computing becomes a field 70s, 80s
  • everyone computes 80s, 90s
  • everyone is connected 90s, 2000s
  • everyone is programming the future

38
drivers
  • the Internet arrives, leading to
  • open source software
  • globalization and outsourcing
  • streamlined information seeking
  • team-oriented tools
  • studies of software teams

38
38
39
open source software
  • now possible to collaborate remotely on large
    software projects
  • version control systems
  • bug reporting systems
  • blogs, IRC, mailing lists, Twitter, Google Docs,
    IM

39
39
40
globalization outsourcing
  • teams no longer fit into a room
  • separated by time zones
  • distance increased collaboration requirements
  • increased need for specifications, design
    rationale

40
40
41
intercontinental design rationale
Amazon hires firefighters to carry design
rationale across the Pacific Ocean in their heads
41
42
streamlined information seeking
  • previously had to find expert (in person or on
    usenet) or a book
  • millions of examples on the web, blogs, usenet,
    discussion boards, etc.
  • search simplified finding
  • example code
  • troubleshooting information
  • documentation

42
42
43
team-oriented tools
  • Eclipse framework enabled a generation of
    integrated, collaborative tools
  • Jazz and Mylyn, two successful research projects
    in broad use

43
43
44
new software development methods
Agile/eXtreme Programming ideas small
groups collocation rapid iteration constant team
awareness software industry realizing that
collaboration is a crucial part of software
quality and productivity
44
44
45
studies of software teams
resurgence of studies of cooperative and human
aspects of software development coordination,
awareness, expertise, ownership, decision-making,
information seeking, trust, training, API
usability
45
45
46
software industry, research is paying attention
  • Microsoft has growing group of HCI experts in
    Visual Studio division
  • Microsoft Research recently formed Human
    Interactions in Programming
  • software engineering research has increasing use
    HCI methods to understand problems, evaluate tools

46
46
47
summary of everyones connected
the Internet changed programming enabling new
kinds of software teams renewing interest in
programmer productivity blurring line between
software engineering, CSCW, HCI
47
47
48
talk outline
  • computing becomes a field 70s, 80s
  • everyone computes 80s, 90s
  • everyone is connected 90s, 2000s
  • everyone is programming the future

49
end-user programming
  • more people are programming computers to support
    their work and hobbies
  • used to just be spreadsheets and HTML
  • but now much more

49
49
50
long tail of applications
of needy
millions of apps 100s of users
e.g. Twittering a random synonym of the music
genre playing on my iPod
100s of apps millions of users
e.g. word processing online banking photo
management
need
50
51
programming customization
mail rules to filter, file, and flag
email CoScripter/Chickenfoot/d.mix scripts to
automate web tasks CSS/JavaScript/AJAX to
customize World of Warcraft clan site
51
52
last months NY Times
250,000 financial analysts, biologists,
statisticians, teachers, engineers, clinical
medicine using R no training in CS, all kinds of
bugs, but good enough most science today is
fueled by custom software, often written by
scientists
52
53
gt 50 million end-user programmers
  • most people who write programs at work are not
    professional programmers(based on data from US
    Bureau of Labor Statistics)

53
53
54
end-user programming is enabling wonderful things
but it has its problems
54
54
55
opportunism vs. discipline
  • opportunism is sufficient if
  • code isnt reused
  • requirements dont drift
  • and precision/accuracy of output isnt critical
  • otherwise
  • in 2003, TransAlta bought 24 mil in worthless
    hedging contracts because of a cut and paste error

55
55
56
programming is an educational barrier
programming is now so pervasive, its becoming
part of engineering, science, art, design
training people are abandoning these disciplines
because they involve programming
56
57
a study of 60 computing biographies
Ko 2009 (?) almost all (non-CS) students
learned to code with TI graphing calculators,
BASIC, or view source command positive, social
experiences pre-college negative, isolating in
college
57
58
languages and tools are terrible
  • need to design languages and IDEs that are
    expressive enough for unique domain requirements
  • how do we choose the right primitives
  • can we attain the benefits of software
    engineering practices without having to teach
    them?

58
58
59
summary of everyone is programming
everything that mattered in the 70s, 80s, 90s
and 2000s to computer science and
engineering is soon going to matter to everyone
59
60
whats the role of HCI in this future?
61
open HCI issues
  • simplify creation of multi-language,
    multi-paradigm mashed up software
  • understand, predict API usability
  • understand software design as CSCW
  • create new languages/tools to support specific
    domains of work and hobbies

61
61
62
13 papers at CHI 2009
Team Analytics Understanding Teams in the Global
Workplace ESPranto SDK an Adaptive Programming
Environment for Tangible Applications Support for
Context-Aware Intelligibility and
Control Comparing the Use of Tangible and
Graphical Programming Languages for Informal
Science Education Designers Wanted Participation
and the User Experience in Open Source Software
Development Understanding How and Why Open Source
Contributors Use Diagrams in the Development of
Ubuntu Development of Decision Rationale in
Complex Group Decision Making Finding Causes of
Program Output with the Java Whyline Fisheyes in
the Field Using Method Triangulation to Study
the Adoption and Use of a Source Code
Visualization Two Studies of Opportunistic
Programming Interleaving Web Foraging, Learning,
and Writing Code Amplifying Community Content
Creation with Mixed Initiative Information
Extraction Attaching UI Enhancements to Websites
with End Users User-created Forms as an Effective
Method of Human-agent Communication
62
Write a Comment
User Comments (0)
About PowerShow.com