^I finished the book a while back and just got around to jotting down some wandering notes. Would anyone be interested in doing a zoom book club discussion? Slack threads per chapter are nice for participation across time zones, but I prefer the format of reading then chatting about the whole book in one sitting

I’m sorry I fell off track, I’d love to finish it though and join this. Are there any chapters in particular that you think are a must read or could be skipped?

I am out of town without my marked up book, so I'll get back to you on this^ @Jacob Zimmerman!

Sounds good!

My biased answer to your question re must-read/skip (tldr - I enjoyed the first half more than the second half): Chapter 1 👍 • Must-read because it sets the stage for the whole book Chapter 2 👍 🤔 • Interesting chapter — reads very current (LLMs) Chapter 3 👍 🙂 • I thought the beginning of chapter 3 was fascinating as a casual baseball fan • I also appreciated the spreadsheet analysis as someone who used to spend most of my workday in Excel Chapter 4 👍 • Feels a bit outdated, but I liked thinking about modern examples of the different end-user programming approaches as I read it Chapter 5 🤷‍♂️ • I'm not super into visual programming (scared to admit that here lol), but worth reading if you are Chapter 6 🤷‍♂️ • Similar take as chapter 5. If you're particularly interested in collaborative multi-player software it'd be more worthwhile Chapter 7 🤷‍♂️ • Examples felt outdated, but it's short and wraps up the book All that said, the book isn't long, so you could just skim through the parts that don't grab you. Sorry for taking so long to respond here!

I just finished ch4 but meanwhile wanted to bring up a conundrum from ch3. > It seems that the only way to know how specific a set of program constructs should be is to study the domain very carefully to ascertain how tasks are broken down and performed. A guiding principle is that users will want to be able to create their applications with only a few basic operations, as the experience of UNIX users (Greenberg and Witten, 1988), spreadsheet users (Nardi and Miller, 1990) and CAD users (Tee, 1992) shows. 1. You have to provide primitives that are high-level enough to correspond to concepts & tasks users have. 2. Users want to learn & use few primitives. Sometimes they are happier with lower level yet more composable primitives. 3. Striking a good balance requires interviewing users a lot - which requires not just programmer skills but sociology skills (how to interview, "activity theory", etc.) 😟 • The book hopes for advances on the last point (3). So, has there been? Are there simple & proven interview techniques? "ask these questions and you'll design a good EUP system" ☑️ ? • Frame challenge: are there ways for users themselves to design for their domain 🤔? • Challenge on few requirement (2): were there advances on giving users both composite & lower-level primitives so they can inspect the relation ("A flange, for example, can be created out of a cut and a protrusion") and pick for themselves - something users do anyway - without overwhelming them 🤕 ?