Hacker News Reader

Chess:

  *  The interface is typically NOT optimized for keyboard.

Typing E4D5 is not optimized. You need to look at a square in the middle, then look which row it is, and which column it is. I've implemented a better one for a similar game (Jungle). You press a character key to highlight one of your pieces, and the game essentially highlights legal moves by displaying alphanumeric chars on tiles. Instead of 4 keypresses, you have 2. In Chess it could be like this: 1-8 selects a pawn, b/B one of bishops, r/R - rooks, k/K - knights, q - queen, i - king. Then another character depending on what shows up where you want to move.

  *  People who play realtime chess (one example is Kung Fu Chess)do use keyboard

certainly those playing in tournaments.

E4-D5 notation is optimized for recording games, not for playing.

"E4-D5 notation is optimized for recording games, not for playing"

depends on the type of player. Every serious hobby player can do it that way. They learned it.

But for casual players it is not the way to go, I agree.

Paint.net is another example of an application that reifies its actions with a nice 'history' window that shows the semantic actions that the user has performed and allows you to jump back to earlier points in your history of editing the file. GIMP does something similar, it seems particularly common in image editing programs.

one day people will have DAG based programs where history has even less importance

I'm curios what you mean by this. I've been working on some software called textgraph [1] (not yet ready for use, and now internally renamed gradesta ) for a couple of years now, so anything with "graph" in it makes my ears perk up.

[1] http://timothy.hobbs.cz/tg/tg.html

the paint.net stacked history is similar to what was used in 3D studio max in the 90s. It was "cool" but too linear (it's a stack after all).

Other software like Houdini or Maya (or NR Shake) used DAG (acyclic graph) of operations to create an output scene/image. There the history isnt linear it's a bit of a multiverse, you can disconnect part of the graph, try new things, reconnect. Everything is there.

Like a modern version control system?

It's the same underlying structure, replace commit by different kinds of operations.

Ditto for AutoCAD -- I loved seeing how the equivalent CLI command appeared in the log as I was using the GUI to draw.

I was thinking about this just a few days ago. This seems like a much better way of teaching people shortcuts than a 20-page cheat-sheet or even "hints" in various menus. No UI clutter, no effort. The program just tells you how to do the same thing in another way. The more you do the "thing", the more likely you are to notice those tips and try out the shortcuts.

I don't think Paint.NET or GIMP do quite what you've described though. They show a history of action, but they don't show commands.

Now I don't have lots of experience with Blender, but I do remember that Blender when hovering a button shows the Title of the interaction, but also a description, shortcut AND the equivalent python code you can run in the terminal to achieve that action. That's pretty awesome.

Here is a example: https://i.imgur.com/NNFruMx.jpg

Related: Emacs does that too. If you invoke a command through M-x that has a keyboard binding available, it will tell you about it in the minibuffer.

You also see this in chip design EDA tools, at least the good ones. Not only will they record the equivalent CLI command that affects the "data", but some will also record the commands that solely affect the GUI! (e.g. resize window)

It's a common technique for document-centric editors in general, because it's usually also the best way to implement multi-step undo. Once you have the steps recorded anyway for that purpose, surfacing them in UI is straightforward.

That reminds me of more extreme work like Bret Victor’s drawing dynamic visualization demo, where drawing commands are reified and can be manipulated/abstracted in place. I saw Dan Ingals do this with some of his work, but can’t find a link ATM.

https://vimeo.com/66085662

The browser?

Though as you mention, many developers nowadays don't see the need for history, and so are putting application/webpage state somewhere other than the router. This IMO is short-sighted, as it undermines the transparency of a user's actions on the web. And plays into the walled-garden effect many of these same developers will lament in the loss of the "open web".

I don't agree that we've lost this ability by moving state to the client or JS (since it seems you're really bitching about single page JS apps).

There are several ways to capture that state, and the nice thing is that the browser allows sites to either opt in or out depending on their requirements.

See: Insights, FullStory, or any other event hooking library.

We can also play back those actions using the very nice WebDriver apis available in modern browsers.

There is zero reason to assume that we've lost reification simply because we've moved away from an approach that requires at least one RTT in latency before updating what the user sees.

Unless you sync app state with the router, then you cannot "Enter a command / url" => "Output a state / action".

I'm sorry, but that's incorrect.

It's not something most users do, so if your argument is "Reification is not on by default for all users" then sure.

But that's a meaningless statement. Most users don't want that ability, or aren't willing to spend the 10 minutes it takes to configure.

Otherwise, you absolutely can enter commands and output state: https://sites.google.com/a/chromium.org/chromedriver/downloa...

Further, there are a HOST of tools that make this process very easy, complete with replay solutions, detailed logging, real time monitoring and all sorts of other fantastic, modern tools.

Just because you choose not to use them doesn't mean they don't exist. Sorry your understanding of web dev is out of date...

Users don't enter urls into browsers?

I think if you use JS your website has broken history by default and you need to go an extra mile (or use a nice framework) to remedy this. And there are things like infinite scrolling pages. And then you find yourself arguing with the developer why it should be fixed ("Yeah ? But nobody uses history anyway.")

If you use C your program has broken history by default and you need to go an extra mile (or use a nice framework) to remedy this. I guess the difference is that in C world, we've more or less standardised on a few nice frameworks (Qt, GTK, etc).

> most GUI toolkits like C# Winforms, C++ Qt, HTML buttons, etc do not include a macro recorder in the default event loop. Therefore, to "reify" the GUI in the same fashion as chess programs or the audio software requires grafting data structures and programming extra code to "record" the button presses into a timeline. Programmers won't do this unless there's a customer need for it. (E.g. Photoshop lets you reify the GUI as "actions" for later playback")

In the MacOS System 7 days when Apple was still pushing AppleEvents/AppleScript heavily, a good portion of Mac software would let you record your actions in them through the AppleScript Script Editor (they would emit the AppleEvent equivalents of your GUI actions), generating an AppleScript which you could then edit. It was a fantastic system. It's still there in macOS X, but it's rarely supported/used now.

Well, with this narrow definition of reification, you could say that any UNDO mechanism basically implements it.

Both of the GUI toolkits I've worked with (GTK and Qt) have a concept of "Actions" which can be (and frequently are) mapped to a menu item and a keyboard shortcut and sometimes a CLI flag; isn't this an example of reification, or am I misunderstanding the concept?

I don't know about GTK but in Qt, those are not recorded into a "timeline".

Sure, but is that implied by "reify"? My understanding is that they are reified and thus it is possible to make a timeline from them. CLI commands are only recorded into a timeline because of shell history, after all--if you call a CLI from a different mechanism, does it become not-reified?

The underlying commands can still be logged.

Hell, often it is useful to launch a X11 program via a terminal as they will dump useful messages that way.

And said output can also be captured in logs elsewhere.

One example of such would be SMPlayer. This is a Qt based media player that wrap MPlayer (and more recently the MPlayer fork MPV). But you can still access the MPlayer CLI output by either launching SMPlayer from a terminal, or going opening the log window from one of its menus.

To be clear, this was my point--because of the "action" mechanism, it's trivial to make a timeline.

The undo stack of any document oriented application is that timeline? Typically if you hover the undo button it says "Undo add frob" and if you undo that, you can see the next item. It's also common to be able to drop it down and see the whole undo stack and undo to an arbitrary point in it.

Since this has been par for the course for for as long as I remember, I take it that's not what's discussed here...

Many apps (or app windows) have actions, but not undo stacks. Undo stacks are typically only used in app windows that display a document of some sort, and then the stack is limited to actions on the document. Have fun trying to revert the last 10 app configuration changes.

Right - the undo stack is always for a "document" of some kind, and more importantly a single user view of a document. Multiple documents can be used (with a single or separate undo stacks) and a settings object can in theory also be viewed as a document although this is rarely the case.

A manager once asked for full undo in a GUI for a shared db. That's not possible...

My point was that if actions are dependent and undoable then they form a stack. If everything can be undone then all that you are affecting (including view state, config, ...) has simply become part of the document.

In the app I'm developing I'm distinguishing "actions" as being what a shortcut/button/menu item represents and "commands" as being document modifications.

Actions aren't necessarily undoable ("quit" is an example) but most actions end up as being commands, and those commands form the undo stack. Actions handle availability (enable/disable) etc. I think this is a fairly standard pattern for document based applications.

Your examples are good, but most users don't _need_ reification for CLI tools either. But at least it's an option when they do.

Reification is always there for the (rare?) cases you need it. With GUI, there's no such option, and it's hard to notice something that has always been missing.