Learning from Terminals to Design the Future of User Interfaces • Hacker News Board

Re: Learning from Terminals to Design the Future of User Interfaces

#211

Post by apatters » Sat, Aug 04, 2018, 4:06 AM UTC

madeofpalk wrote: post #90

tonysdg wrote: post #66

Earlier quoted context omitted.

This goes to the article's point about caching; a chat app -- of all programs -- should cache conversations for a fast boot up. Sure, _updating_ the conversations -- the "cloning" stage -- may take some time, but why should you have to wait for the network requests to complete before seeing your past conversations? The git equivalent would be if you had to wait for git to do a fetch/pull every time you ran "ls" on a…

It's obvious from the outside, isn't it. Hindsight is everything. But the reality is is that Slack is an application made by a real company by real people/developers who all faced real constraints. Go build Slack for yourself, through the same history they have, and lets see what we come out with.

I hope someone takes your advice so that we can dump the slow bloated resource hog that is Slack :)

Re: Learning from Terminals to Design the Future of User Interfaces

#212

Post by sharmi » Sat, Aug 04, 2018, 4:16 AM UTC

ssivark wrote: post #119

aphextron wrote: post #68

I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I…

Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes. The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communica…

Maybe because, the cli mode means, you need to remember the commands?

In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring.

Whereas under console mode, there is no unifying paradigm. So each tool has a different way of doing the same thing. There is a lot of inertia at the start. Like what command is it for help 'h' or 'h?' or 'help' or 'H' ? What command is it for quit 'q' or 'quit' or 'ctrl+d' or 'ctrl+c' or 'bye' ?

For example, in gmail, I expected archive to be 'a' and delete to be 'd' or atleast "DEL". Very basic operations and basic expectations. Turns out, archive is '#' and delete is some char I can't remember now (I think '{' and '}' to indicate whether to go to the previous mail or the next mail. A 'd' to go to next mail and a 'D' to go to previous email would have been a lot more intuitive). Of course, you can customize the key bindings, but then you got to go do it across all your accounts.

While people may be quite happy to be able to wield so much power within the slack environment, they are very quickly going to lose their enthusiasm with the introduction of each new console tool, unless what they have learned in the slack environment translates into easier learning curve in the next console env.

Basically for users to be able to adopt the console mode, there is should be some sort of standardization.

Re: Learning from Terminals to Design the Future of User Interfaces

#213

Post by jancsika » Sat, Aug 04, 2018, 4:27 AM UTC

> Composability: I’m far from a zealot singing the praises of the Unix philosophy, but most terminal apps produce output that I can process in some way to get into another program.

Composability within the conceptual framework of the terminal itself (e.g., using a pipe).

But suppose I want to shuttle text back and forth across the terminal/GUI domain.

Do I even have a reliable way to select and copy text that extends past the viewport of a terminal? Even the method of copying a selection isn't cross-platform in terminals (e.g., among terminals running in Linux/OSX/Windows).

Compare that to the holy trinity of , and in any viewport of any web browser.

Plus, you can't even depend on a particular feature being available to a terminal of a single platform. Take the example of middle-click selection pasting from the terminal. Can I depend on distros to never bother me by removing that feature? If so, what is the standard that governs the requirement for this feature?

Re: Learning from Terminals to Design the Future of User Interfaces

#214

Post by unit_circle » Sat, Aug 04, 2018, 5:07 AM UTC

srazzaque wrote: post #192

It's interesting to me that nobody has yet mentioned the Bloomberg terminal, which is basically what the author is describing. It seems Bloomberg "got this" a while back, and dug their heels on for their keyboard-driven terminal-like UI whilst all other shops were going w32, Excel plugins, Web, etc. It's not sexy by any means, looks like it's from the 80s in a mainframe, but it works well for a lot of people. Images,…

This is super cool! Are there any OSS like Bloomberg Terminal?

Re: Learning from Terminals to Design the Future of User Interfaces

#215

Post by gmueckl » Sat, Aug 04, 2018, 5:13 AM UTC

sxates wrote: post #114

Asooka wrote: post #96

Earlier quoted context omitted.

I think a simple data-display UI shouldn't be that hard to code. Every program you run has access to a terminal, which it can use to display and read text. It shouldn't be hard to extend that to displaying and reading structured data. One dream I have is to have a Desktop where each program can send an ioctl to stdout that turns it into a stripped-down browser, so it can then just dump XHTML data and have it be visua…

The difficulty is not just in coding the UI, but crafting one that's easily and intuitively understood by users. We haven't yet established a universal design pattern for GUI's yet, to the parents point, just a bunch of conventions that are often tossed in favor of something new. A 'solved' UI example would be of a car (not the radio, but the operation of the vehicle). Learn to drive one car, and you can pretty much…

If you know how to drive cars, you will still not be able to drive trucks, motorcycles or tractors. Software in general us more diverse than the types of vehicles that are in existence.

If you want to make a car analogy, then you should compare cars to browsers. And these have very similar UIs, the underlying stupefying complexity nonwithstanding. So we seem to create standardized interfaces for certain common classes of user interfaces over time.

I think that people tend to think in terms of discrete and dedicated appliances because this is how the real world is structured. Being faced with a small box with the overbearing set of capabilities of a swiss army jackhammer (atomic bombs included) ends with confusion unless lot of time is devoted to trying to discover and learn all the magic spells to which that infernally picky and annoying thing will respond meaningfully.

Re: Learning from Terminals to Design the Future of User Interfaces

#216

Post by jamesrcole » Sat, Aug 04, 2018, 5:21 AM UTC

ken wrote: post #28

The animations serve a valuable purpose, though, especially for new users. They show what's happening. Lots of old UIs (like those running in VT100 emulators) had instant wipes from one view to another, but made it impossible to tell what had happened, or why. Even when I wish animation was faster (like with Spaces, sometimes), I rarely wish it didn't exist at all. I often have people watching me, and with animations…

I agree. I've long thought that animation could potentially make it much clearer what's going on in Vim.

Like if the user types 'das' to delete the current sentence, and it quickly highlights the text to be deleted, and then shows it shrinking away, as the text that was following it moves in to take its place. (Obviously, you'd want the animation to happen pretty quickly).

Such animation could make it clearer what the command is doing, and this could also make it easier to tell if you'd accidentally typed a command that didn't do quite what you wanted.

Re: Learning from Terminals to Design the Future of User Interfaces

#217

Post by seanmcdirmid » Sat, Aug 04, 2018, 5:31 AM UTC

chris_mc wrote: post #117

sxates wrote: post #113

Earlier quoted context omitted.

Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if every app had dozens of commands you had to learn and memorize. Sure you could do it and be blazing fast, but that's a really steep learning curve a lot of users wouldn't adopt.

Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote `, a listing sh…

Isn’t that just apropos?

Re: Learning from Terminals to Design the Future of User Interfaces

#218

Post by omaranto » Sat, Aug 04, 2018, 5:39 AM UTC

GlenTheMachine wrote: post #162

astrobe_ wrote: post #104

Earlier quoted context omitted.

I suggest Chrome or Firefox. I find the conclusion of the article totally off the mark. The author seems to not understand that problems begins with multimedia support and other "gimmicky" stuff (as he puts it). You want video? Then use your terminal to launch a video player. A tiling manager is precisely perfect for this (I wonder why you switched to i3 if you don't know that, btw).

Oh, I know that. But what I'd really like is something akin to Jupyter, only for the shell. I think I'd like that, anyway. For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command di…

How about instead of something merely like Jupyter you just use precisely Jupyter? I'm sure someone wrote a shell kernel, and if not, use ipython's shell magic.

Re: Learning from Terminals to Design the Future of User Interfaces

#219

Post by skewart » Sat, Aug 04, 2018, 5:42 AM UTC

wruza wrote: post #156

aphextron wrote: post #68

I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I…

You may check telegram’s games, services and other bots that allow to manage your entire world via chat (with programmatic buttons and menus to ease /cmds a little). I don’t use it much, but my coworker said that he almost lives there, visiting sites only for long, static content. From this perspective, “we” don’t “need” as the article says, since it’s already there and writing a simple bot is a no-brainer. (Downside…

Genuinely curious, why don't you use it much?

Re: Learning from Terminals to Design the Future of User Interfaces

#220

Post by skykooler » Sat, Aug 04, 2018, 5:46 AM UTC

ssivark wrote: post #119

aphextron wrote: post #68

I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I…

Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes. The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communica…

It would be interesting to make an Alexa-style device, which instead of natural language used a set of composable voice commands, like Bash and the unix utilities but pronouncable.