website statistics A Small Matter of Programming: Perspectives on End User Computing - PDF Books Online
Hot Best Seller

A Small Matter of Programming: Perspectives on End User Computing

Availability: Ready to download

A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power. Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technica A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power. Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technical issues of end user programming. In particular, it examines the importance of task-specific programming languages, visual application frameworks, and collaborative work practices for end user computing, with the goal of helping designers and programmers understand and better satisfy the needs of end users who want the capability to create, customize, and extend their applications software. The ideas in the book are based on the author's research on two successful end user programming systems - spreadsheets and CAD systems - as well as other empirical research. Nardi concentrates on broad issues in end user programming, especially end users' strengths and problems, introducing tools and techniques as they are related to higher-level user issues. Bonnie A. Nardi is a Member of the Technical Staff at Hewlett Packard Laboratories.


Compare

A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power. Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technica A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power. Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technical issues of end user programming. In particular, it examines the importance of task-specific programming languages, visual application frameworks, and collaborative work practices for end user computing, with the goal of helping designers and programmers understand and better satisfy the needs of end users who want the capability to create, customize, and extend their applications software. The ideas in the book are based on the author's research on two successful end user programming systems - spreadsheets and CAD systems - as well as other empirical research. Nardi concentrates on broad issues in end user programming, especially end users' strengths and problems, introducing tools and techniques as they are related to higher-level user issues. Bonnie A. Nardi is a Member of the Technical Staff at Hewlett Packard Laboratories.

30 review for A Small Matter of Programming: Perspectives on End User Computing

  1. 4 out of 5

    Omar

    excellent. the thesis of the book is that end-user programming should be built around an actual task and task-specific operations: if you're a spreadsheet and people want to add stuff, give end users a SUM function, rather than making them declare a loop counter and do a for loop. let them always be working with reference to the task rather than programming details. (motivation being essential to self-directed learning...) a lot of the book is really a _defense_ of formal languages and text-based excellent. the thesis of the book is that end-user programming should be built around an actual task and task-specific operations: if you're a spreadsheet and people want to add stuff, give end users a SUM function, rather than making them declare a loop counter and do a for loop. let them always be working with reference to the task rather than programming details. (motivation being essential to self-directed learning...) a lot of the book is really a _defense_ of formal languages and text-based programming, drawing on fascinating ethnography of spreadsheet and CAD users. spreadsheet users don't mind writing text formulas, so why should we believe non-textual language like Scratch is necessary for end-user programming? I also read it as a defense of the end user as an expert in their domain who is willing and able to learn a powerful tool like Excel or CAD and pick up the formalism, not a 'novice programmer' who needs hand-holding and automation. so a non-obvious conclusion is that 'silver bullet' approaches are wrongheaded for end-user programming. these and others may be useful techniques, but that's all they are: - visual (block-based, flowchart) programming - programming by inference from examples: an especially effective takedown, almost implying that programming by example just requires general AI, since you could be building examples drawing from arbitrary world or mental knowledge - programming by informal natural language specification (?) then a really great description of the social practices around end-user programming. I love the "local developer" / "advocate end user" / "gardener" category: 10-20% of every end-user programming group the author had heard of. these people would get into computing, would use the cool features and make macros and help everyone else. mediating between classic programmers and the rest of the users. collaboration as a key part of how these systems work. and maybe offering a way to move up the learning slope over time? the time evolution of this stuff wasn't clear: are these categories inherent to personality/interests or do people move between them? still trying to grasp the generalization of spreadsheets to visual formalisms, and less impressed with the concrete ACE system shown at the end, although I like the idea of a meta-system. need to reread those last bits.

  2. 5 out of 5

    Michael Dubakov

    В 90х ребята уже делали то, что мы примерно делаем сейчас в Fibery. К сожалению пришествие интернета фактически приостановило все наработки в сфере no-code решений (это такие штуки, где пользователи решают свои проблемы через создание собственных аппов, типа excel, AutoCAD, etc.). В книге почти все главы клевые. В частности можно найти ответы на вопросы: 1. Почему голосовые интерфейсы вряд ли станут массовыми? (потому что для многих задач они медленные) 2. Почему не стоит недооценивать интеллект по В 90х ребята уже делали то, что мы примерно делаем сейчас в Fibery. К сожалению пришествие интернета фактически приостановило все наработки в сфере no-code решений (это такие штуки, где пользователи решают свои проблемы через создание собственных аппов, типа excel, AutoCAD, etc.). В книге почти все главы клевые. В частности можно найти ответы на вопросы: 1. Почему голосовые интерфейсы вряд ли станут массовыми? (потому что для многих задач они медленные) 2. Почему не стоит недооценивать интеллект пользователей? В основном эти люди ориентируются на решение конкретной задачи в своем домене, им программирование до задницы как форма интеллектуальной игры. Но многие делают со своими тулами довольно сложные вещи, например создают невероятные таблички с формулами или пишут макросы. 3. Почему языки общего назначения для пользователей плохи? Потому что порог входа в них большой и для решения их конкретной задачи они слишком удалены от домена. Так что для продвинутых пользователей нужны task-specific languages, фактически DSL. 4. Какие есть способы создания приложений? Визуальное программирование, form-based программирование, программирование на основе изменения примеров, автоматическая генерация приложений) и почему все эти способы не сработают в целом (потому что только здоровый микс разных подходов может дать нужный уровень абстракции для разных задач. 5. Почему не взлетел HyperCard (давно) и Eve (недавно)? Потому что были слишком общими средами для разработки приложений, и это было серьезным барьером для пытливых пользователей. А программистам такие штуки нафиг не нужны, у них есть IDE и Java. Для любого разработчика no-code платформы — весьма любопытная книга с примерами и глубокими мыслями. Мне было очень интересно прочитать, что мы в Fibery во многом дублируем подходы авторов и переизобретаем велосипеды 25-летней давности. Ну что поделать, в вебе нам приходится изобретать эти велосипеды заново...

  3. 5 out of 5

    Dave Paola

    Definitely a bit dry but overall there is some good info locked in this book. Anyone designing software for humans should probably at least read the chapter summaries.

  4. 4 out of 5

    John

  5. 4 out of 5

    Maximilian

  6. 5 out of 5

    Derek M.

  7. 5 out of 5

    Polar Bear

  8. 5 out of 5

    Amy

  9. 4 out of 5

    Adam Wiggins

  10. 5 out of 5

    Sean Rose

  11. 5 out of 5

    Benoît Fleury

  12. 5 out of 5

    Jens Lincke

  13. 5 out of 5

    Jeff Dyer

  14. 4 out of 5

    Jonathan Skjøtt

  15. 5 out of 5

    Max

  16. 5 out of 5

    Mary Rose Cook

  17. 4 out of 5

    Roy

  18. 5 out of 5

    Chris

  19. 5 out of 5

    Chris Rabl

  20. 5 out of 5

    Filip Kis

  21. 4 out of 5

    Gabino

  22. 4 out of 5

    Graham Lee

  23. 5 out of 5

    Julian Dax

  24. 4 out of 5

    Grant

  25. 4 out of 5

    Patrick

  26. 5 out of 5

    Mark McGranaghan

  27. 5 out of 5

    Joshua Loong

  28. 5 out of 5

    Alex Lyashok

  29. 5 out of 5

    Nick Arner

  30. 4 out of 5

    Gien Verschatse

Add a review

Your email address will not be published. Required fields are marked *

Loading...