End-User Programming (2019) | Hacker News Reader

End-User Programming (2019)

inkandswitch.com

50 pointskarlicoss8 comments

This is a really interesting space that I'm deeply passionate about. I think the issue exists in general with any abstraction: from highest levels where users have to understand and maintain a text document to deepest level of maintaining and understanding computer code.

Making a text article understandable isn't just about the syntax or the structure or the images; you have to have knowledge in the subject to be able to grasp its contents.

With this in mind you can probably create the most amazing UX for allowing end-users to program a system. Problem is that if the user doesn't have any domain knowledge then there's no amount of syntax-system-trickery one can do to make it easier for them to program it.

The space is also highly subjective: something that might work for me might be completely alien to others.

With that said I think the work by Harel et al on "scenario based programming" is fundamentally something that will impact this space greatly [1]. Their vision calls for not just making it easier for "end-user programming" but to shift the way we think about software as something that is more aligned with how we generally think about systems. I gave a talk about this earlier this year: https://www.youtube.com/watch?v=1oKzTrq0gMM

1. http://www.wisdom.weizmann.ac.il/~harel/papers/Runware.pdf

Got to love a passionate opinionated essay with that kind of depth!

I definitely took away a lot from it, but I do not quite agree with their rather rigid duality of "this has end-user programming" and "this has not". Like they give Hypercard as an example of end-user programming and then imply that there was no end-user programming software in that space afterwards.

If I look at a particular niche, it looks more like a...multidimensional sine wave?

Look at writing code for example:

Text editors add configurability and plugins and customizability until they are indistinguishable from an IDE, and a bloated one at that. Some startup makes the next minimal editor and here we go again. Alternatively, the disgruntled dev goes back to vanilla vim. Cue a long vimrc, cue plugins, cue neovim. And so on.

Notice how all of these merging and splitting branches trade-off toolchains, embodiment, convenience, automation and a hundred other factors defining whether you could call it "end-user programming" all the time.

The same thing can be said about Browsers, E-Readers or Games. I think it is important to be aware of the complexity so you can add sensible improvements to the infinite iterations instead of thinking that we are just one cool invention away from the glorious goal of end-user programming.

Back in the day I used to love Office's extensibility. With it you can add your own button that "does stuff" and it was just some VB code. Keep in mind I am a C++/Java/JS/TS dev but I loved the extensibility of tools that let you extend and customize with code. This was generally before HTML forms had the ability to copy-paste images and just be "uploaded" like you can in, say, confluence today. Before that you kinda had to publish things the hard way, safe the screen shot with a file name, add it carefully to your Post and then just keep messing with the HTML a bit.

So being an instructor of both a C++ and a Java class in the early 2000s I wanted a way to quickly publish course content for the students - complete with screenshots out of the IDE. LOTS of screenshots. So many pictures that it was eating a lot of my time to carefully save each and name the file, etc.. So what I did was build my own micro PHP CMS that supported a small REST API that lets you post the HTML and images together. I added a button to word that takes a Doc file and saves it as HTML, and then for all the related image files, it would go and automatically upload them to my custom CMS. So yeah, took me a good 12 hours during a couple weekends to get that working, but after that I was able to get articles posted up for the students very quickly, with thousands of pictures - because with word I was able to use screen shot tools in the clip board and then just PASTE them into the doc file.

I mean now days many wikis with a WYSIWYG mode now support native paste. But that was just one example of how awesome adding a bit of code to random stuff helped me.

emacs is mentioned twice, and not considered a success story?

I can't think of any other end user application that allows such levels of extensions. Excel does come close

Emacs is fairly impenetrable for the majority of computer users. Excel is far more familiar - it looks like a normal program, has context menus, and has a conceptually simple model of execution: you say what you want a cell to be, and it just automagically becomes that value. No lisp syntax or keyboard shortcuts need to be learned, and nothing new needs to be installed.

I agree that Emacs is more extensible, but it doesn’t make itself as available to regular computer users as something like Excel does.

> ... [Emacs] doesn’t make itself as available to regular computer users as something like Excel does.

The word "regular" is the load-bearing word in your argument. Your examples suggest that you feel end-user programming is not going on unless the user is taking advantage of some visual affordance like context menus to discover and use the program's capabilities. An online help system (as emacs offers) serves a similar purpose (that is, it similarly allows capabilities to be discovered).

But punching in some emacs lisp to change the behavior of the editor does not, in your view, qualify as end-user programming?

Maybe if you said it was not "regular end-user programming", I'd agree. Is the distinction useful? I don't know.

edit: typos

I guess my perspective is that end-user programming has to be easily discoverable and doable by end-users, and provide some method of progression from simple tasks up to more complicated ones (a perspective shared by the article authors). It’s not the visual affordance of the context menu that I think is good, it’s the progressiveness and discoverability. Sticking a manual in someone’s face is very different to them choosing to ask a certain UI element “what else can be done?”

Of course punching in some emacs lisp qualifies as end-user programming, I’m just don’t think it will be a kind of programming accessible or available to the majority of end-users of computers.

Yeah, now that you mention "progressiveness", I see the distinction. You don't have to know how to accomplish the task in its entirety before you attempt it, and the system exposes more relevant affordances as you make progress on your task.

Reply on news.ycombinator.com