Bob Carpenter’s favorite books on GUI design and programming

Bob writes:

I would highly recommend two books that changed the way I thought about GUI design (though I’ve read a lot of them):

* Jeff Johnson. GUI Bloopers.

I read the first edition in book form and the second in draft form (the editor contacted me based on my enthusiastic Amazon feedback, which was mighty surprising). I also like

* Stephen Krug. Don’t Make Me Think.

I think I read the first edition and it’s now up to the 3rd. And
also this one about general design:

* Robin Williams. Non-Designers’ Design Book. (not web specific, but great advice in general on layout)

It’s also many editions past where I first read it. I’m also a huge
fan of

* Hunt and Thomas. The Pragmatic Programmer.

for general programming and development advice. We’ve implemented most of the recommended practices in Stan’s workflow.

11 thoughts on “Bob Carpenter’s favorite books on GUI design and programming

    • It’s a pity he changed the name. The Psychology of Everyday Things gives us a PET while the Design of etc. gives us DET (which, depending on the pronunciation sounds like my bank manager or an mosquito repellant.

    • I think having both options is useful (command line for flexibility, GUI for simplicity). But if you’re trying to get actual people (ie people from applications) to use your software, then GUIs all the way.

    • I think it really matters who you’re building the software for. One important consideration is that people have different preferences and there’s not a single “right” answer.

      Starting at a lower level than command-lien vs. GUI, we’re building the Stan C++ math library at the API level to be useful for other C++ programmers in their code. And the rest of the Stan C++ library to make it easy to develop interfaces to Stan’s language, fitting, and posterior analysis tools.

      CmdStan is a client of C++ Stan that provides a client interface through the Stan language and command line. It’s very portable and easy to script that way.

      Although not quite what I’d call a GUI, RStan and PyStan are integrated in process through the Stan C++ library. MatlabStan, Stan.jl and now StataStan are all call-a-standalone-procedure interfaces.

      shinyStan is an R-based GUI written in Shiny and available as a web service. But so far, it’s only for posterior analysis.

      Andrew would very much like to have a Stan-on-the-web where we build a GUI (though with the Stan language interface on the back end along with canned models to select or piece together) and people use Stan through the cloud as a web app.

      There’s a pretty big difference between a web-based GUI for clients and a standalone GUI application. Not to mention a mobile application.

      Other than Michael Betancourt, who uses Xcode, I don’t think any of our developers use GUIs to develop Stan. I use emacs and the shell and make.

      And then you can raise the LaTeX (what you script is what you get) vs. Word (what you see is what you get) issue. Again, different people have very strongly entrenched varying opinions on this kind of thing. The Stan team’s pretty old school — all of our docs are LaTeX.

      • I also don’t think it is a great idea to make a GUI out of something as big as STAN. But a GUI that does something specific (like MRP or Age-Period-Cohort models) for a limited set of situations aimed at a particular audience that does the computation and produces paper/report-ready graphics is a good way to get a set of models out into applied circulation.

        The downside, of course, is that you have to make the software sufficiently easy to use, which requires a lot of expert knowledge about how inference schemes work in certain contexts, as well as stability in the underlying computational scheme. It’s a very very hard job!

      • Only anecdotal, but most of the people whose technical skills I admired most were somehow mostly command line guys. Not sure if that is a more general pattern.

        Perhaps experts tend to be power users and power users get along well with the flexibility and power of a command line?

    • This is a no-brainer: command lines. I have never met a serious programmer who thought otherwise. Long ago, Neal Stephenson wrote a super essay called ‘in the beginning was the command line’, which documents some of the arguments in detail, and is a great read – though it misses the most important one as far as I am concerned: the most effective way to design a complex software object is to specify its extensional behaviour – its algebra. Direct access to the algebra is via the command line. And command line scripts can in their turn be algebraically manipulated / transformed.

  1. I didn’t realize Andrew was going to post this on the blog! I haven’t read anything on GUIs in years—there must be many more references out there.

    Anything good aimed at mobile apps, for example? The last GUI I built was a prototype for a spoken-language application on a Compaq iPaq handheld (a proto smartphone; Eric Woudenberg had to pop it open to solder in a microphone jack so we could use close-talking speech).

Leave a Reply to Rahul Cancel reply

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