Comment by sbuttgereit | Hacker News Reader

Comment by sbuttgereit | Hacker News Reader

Parent Full thread

A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discoverability you mention found in the GUI based system. It was just easier to use. This didn't come for free however. At a different client making the same transition from TUI based system to GUI based system (same target software), we measured the productivity of well trained staff and the TUI was well ahead in daily productivity. Now the different companies had different employment profiles; they were both retail businesses, but the first one that measured training was more decentralized and saw higher staff turnover rates and so cared more about training efficiency; the other had more centralized operations and so had fewer, more senior staff members with longer tenures where daily performance was a more important metric for efficiency.

Now a TUI isn't the same as command line and most GUIs allow for substantial keyboard functionality, but I think developing for a TUI tends to get you thinking about a person working a keyboard whereas developing a GUI you're thinking more about the person with a mouse/trackball/trackpad/touchscreen.

Personally, I do a lot of database work; mostly PostgreSQL. I decided some years ago to bite the bullet and get rid of the GUI and just use straight psql. I largely haven't looked back, though if I'm doing heavy development work I just started using DataGrip since it helps avoid stupid errors that a simpler text editor doesn't find.

What about a system that shows actions in a GUI as a list of equivalent plain text commands. New users would have the discoverability of a GUI while being able to see what goes on command-wise. With time they would be able to convert to plain-text commands and scripting for increased efficency.

AutoCAD sort of does that - actions can be launched both via the GUI and the command line, and all actions launched via the GUI also appear in the command line history, so you can pick up the names of the commands over time as you're using them (alternatively, they're also mentioned in the mouseover tooltip in the GUI).

More applications should do this.

I've actually contemplated this very idea and think it has merit. What I've found in many applications is that there is a stark distinction between GUI and TUI/CLI that isn't completely necessary... I speculate that there's more room for grey between the two. To be clear many GUIs can be used via keyboard alone, but often times that ability feels bolted on in that you only get things like shortcuts for a button presses whereas many text oriented interfaces offer more actions which are composites or which might not make sense in a visual presentation of the functionality.

Having said that, I think that the inertia of "good enough" is a real danger to the concept. The new user that uses the less efficient GUI aspects of the interface to learn quickly may not have much incentive to go the next step and work the keyboard oriented workflow into their muscle memory. Also, if you realize that issue, there's also the problem that if the keyboard interface were less used, there would be less incentive to fix issues or add features to it as the application changed. Rightfully, it could become less useful because of less attention. I can tell you that in practice I find it fairly uncommon to see staff using the keyboard capabilities insofar as it's already supported by their GUI applications.

An interesting UI paradigm I've run across [0] is using a keyboard-accessible hierarchical menu for all actions. It's similar to how AutoCAD works, but the "commands" you type are actually just sequences of menu hints. Most desktop apps support these hints with Alt, so the capability is there, but there is something about using the hint sequences as primary keyboard shortcuts that appeals to me.

The nice thing is that by using the keyboard to navigate menus, you develop muscle memory for "shortcuts" without really trying. And if you ever get "stuck", not knowing how to complete the sequence, you only have to look at the currently open menu.

Formica doesn't do this, but this could be extended into rudimentary scripting.

This kind of paradigm won't fit all software, for example I don't think it's a good fit for software where typing mildly structured text is the main mode of interaction. It might be mainly useful for shortcut-heavy software.

[0]: The software in question: https://www.formica.cz/

FoxPro worked like that. The language itself had commands for various IDE actions, like editing a source file (MODIFY PROGRAM ...) - these worked everywhere, but were really meant to be used in the Command window, basically a REPL. And then if you use the GUI to do the same thing - e.g. File -> Open - it would simply execute the corresponding command in the Command window.

This worked surprisingly well. New users mostly stuck to the menus to discover things, but then gradually switched over to commands for common actions, because they were faster. It also helped that the Command window had context-sensitive help, so once your menu action generated the corresponding command, you could easily open the manual page for it to read up on the details.

I think CLIs should be able to provide a very generic UI from their command definitions like this:

https://github.com/hediet/ts-cli/blob/master/cli/README.md

Relevant: the Commando application from A/UX: http://toastytech.com/guis/aux3.html

Maybe one day everyone will adopt PowerShell as the CLI standard.

PS scripts (and even functions) declare command line arguments up front, and depending on how much time and thought you put into it, you can constrain the arguments quite well. See [0] for overview of the available functionality. A quick TL;DR:

- You can make parameters typed, and PS will handle relevant conversion if the user just types strings in. E.g. you can mark a parameter as [DateTime], and if the user types e.g. "2021-04-01", the script will receive an object that represents the midnight on that day. If the user types in "foobar" instead, they'll get an immediate error[1] telling them the parameter cannot be read as a date.

- Add [] to parameter type (e.g. [DateTime[]] instead of [DateTime]), and now the parameter can accept multiple values (arrays), - but behaves smartly if only one is given.

- You can mark parameters as mandatory. You can mark parameters as positional (i.e. provided without specifying parameter name on invocation). You can mark a parameter as designated "catch-all". You can define aliases for parameters, to allow user to write e.g. -Runs, -Run or -R, and have all three refer to the same parameter.

- You can mark parameters as "accepting values from pipeline" (and define how exactly). Since PS pipes transport typed objects, not raw bytes, this is how you can both set expectations, and write scripts that can flexibly mix pipes with commandline arguments.

- You can define validation for every parameter individually.

- You can group parameters into sets, based on what other parameters are provided, or some custom logic. So e.g. if arguments -A and -B only make sense together, and then -C doesn't do anything, you can encode this cleanly.

- Autocomplete in PowerShell is aware of all these things! It'll hint you appropriately. And you can provide your own autocomplete hints too.

How is all that relevant to this thread? The last point is a spoiler: all these declarations can be extracted from the script, and they provide enough information to build a high quality GUI for the script automatically. PowerShell ISE, that comes with Windows, exploits this to a limited degree - it contains a GUI for running PS cmdlets that lists parameters and their types, makes use of optional/mandatory status, and groups them by parameter sets. There's nothing stopping one from building an equivalent UI generator that would also provide custom widgets based on argument types (e.g. file pickers for paths, calendars for DateTimes, etc.).

--

[0] - https://docs.microsoft.com/en-us/powershell/module/microsoft...

[1] - Errors in PowerShell are a bit user-unfriendly. Niceties like invocation with underlined mistake are surrounded by long error text and small stack trace. I wish they improved on that; even for script developers, most of the error message is quite useless.

They have worked on improving error messages between Windows PowerShell and PowerShell, e.g.

    PS C:\> 1/0
    Attempted to divide by zero.
    At line:1 char:1
    + 1/0
    + ~~~
        + CategoryInfo          : NotSpecified: (:) [], RuntimeException
        + FullyQualifiedErrorId : RuntimeException

is now:

    PS C:\> 1/0
    RuntimeException: Attempted to divide by zero.

And everywhere else they've tried to make a shorter, clearer default error.

Good to know, thanks! I've been mostly developing on the Windows PowerShell, but I'm about to move to PowerShell/.NET Core, so I'm happy to know error messaging improves there.

Powershell Core is so much better. It’s updated much more frequently, and they address bugs so fast.

I would like to see a PowerShell equivalent to the autocompile feature in Visual Basic.Net where error checking is done after each character pressed.

I like powershell, but I find its Syntax very hard to learn for casual usage. -eq is just cruel if you are used to proper programming languages. I'd love to see a sane script language ala typescript established as general purpose shell/shell scripting language!

TypeScript is not yet expressive enough for direct shell usage, but not much is missing imo (most importantantly a pipe operator).

Agreed. Having recently written a bunch of PowerShell scripts that were too big for their own good[0], I'm pretty much in love with it, but the language itself does bug me constantly. Operators are one of the big annoyances. -eq, -gt, -icontains, -match...

But I get it. It's the consequence of trying to use the same language for code and command line input. > and < are already used in pretty much every single shell to indicate IO redirection; particularly with >, it would be really dangerous for it to have context-dependent meanings. And then foo -match bar is more CLI-input-friendly than foo.match(bar) or match(foo, bar). You can get a similar experience if you try to use (or design) a Lisp shell. S-expressions are awesome, but having to move the caret back and forth to add/modify structure in your command is too annoying for a shell language. For shells, you essentially want as much appending and as little editing as possible.

And as much as I don't like JavaScript ecosystem, I would like something like TypeScript in the shell. Personally, my main requirements are 1) optionally typed, and 2) piping structured data instead of unstructured text/byte streams.

(And then I'd like a terminal emulator that makes full use of type system in pipes and command arguments.)

--

[0] - They started simple, then they grew, and before I noticed, they've crossed the threshold where, if I were to write them again, I'd use a regular programming language. I think the point in which I started including bits of C# code in the scripts should've been a wakeup call... but on the other hand, isn't it just cool you can drop down to C# in the middle of a script and have it Just Work?

Have you looked into pgcli, psql is great but pgcli is a little nicer.

https://www.pgcli.com/

I have, but it's been awhile since I looked. My recollection was that it felt sluggish, but that might be a false memory. I think what it brings to the table is helpful, but not enough for me to warrant it's use. When I'm writing simpler queries at the command line, I'm usually well within my knowledge of the databases I'm writing for or would have to appeal to something like the table definition anyway... which as I recall I couldn't really do in pgcli (start writing, flip to the table definition, pick up where I left off).

When the sorts of things that pgcli does becomes most helpful is when I'm writing functions and procedures, but then the command line isn't well suited for that. That's where I'm finding something like DataGrip helpful: a database tool focused on development rather than administration. DataGrip has a lot of faults, but for the past couple of weeks I've been using it, it's been on balance a win.

All GUI apps should be controllable entirely through the keyboard.

This is generally true of built in Windows applications (even if the transition to ribbon interfaces complicated flows). It is spotty for third party applications.

Unfortunately on Linux, at least on KDE (I don't like Gnome since v3), keyboard navigation is broken even on default applications like Dolphin or Discover.

Mac OS, I remember (Tiger -Lion) being pretty good.

Not gonna happen. Startup-driven agile web development practices and accessibility don't go hand in hand.

Out of curiosity, what's the practical difference between TUI and GUI when it comes to discoverability? The kinds of TUI I'm familiar with - mostly from DOS, so stuff like e.g. Borland IDEs (and various third party apps written using Turbo Vision), FoxPro, and VB for DOS - are essentially the same as GUI in that regard; you get a drop-down menu on top, windows with various widgets, often a help bar at the bottom and/or context-sensitive help with F1 etc.

what is your setup to save queries in file and run them, does psql support this model

i use ssms for mssql, and i have a large solution with multiple projects

i know datagrip can be used in the same way as ssms, but can you this be done using psql

You can use the .psqlrc for this purpose, though I suppose you could also real that in via a file on demand, too. You make entries something like:

  \set show_slow_queries
  'SELECT 
    (total_time / 1000 / 60) as total_minutes, 
    (total_time/calls) as average_time, query 
  FROM pg_stat_statements 
  ORDER BY 1 DESC 
  LIMIT 100;'

(got from https://www.craigkerstiens.com/2013/02/21/more-out-of-psql/)

and then later at the command prompt you access it as; ":show_slow_queries".

I have a few system queries like this in my .psqlrc file, but I don't do much which this feature often truth be told. I have a pretty strong knowledge of the database schema I work with, I do a lot of work on systems I don't regularly control so its not dependably available, and readline history suffices for more immediate needs.

Reply on news.ycombinator.com