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

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

#281

Post by boomlinde » Sat, Aug 04, 2018, 11:43 AM UTC

kovek wrote: post #105

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…

I remember on Hipchat you could edit your last message by sending a message using this (sed?) syntax: s/flock/duck/ . I remember hearing someone saying that was the worst design they've seen in their life. I almost agree. I do agree that text interfaces are better. I really wish that more products were exposed through a purely textual interface. I think hipchat could have solved the issue with a text interfaces bette…

Correcting yourself using sed syntax is a common IRC idiom. In that sense the design is sensible; you build your interface on what a lot of users already do habitually and let it have the desired effect. For everyone else it's just a very terse and simple syntax that anyway has an obvious mouse based equivalent.

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

#282

Post by dunham » Sat, Aug 04, 2018, 11:45 AM UTC

tomxor wrote: post #273

freefal wrote: post #225

Earlier quoted context omitted.

Just so no one accidentally deletes an email on Gmail, 'e' is archive and '#' is delete.

Also ctrl+enter is send email (immediately) which is very annoying after working in google sheets for a while where ctrl+enter is newline...

The most annoying for me is “j” in outlook. It means “move down” in Gmail and dozens of other apps - in outlook it means “mark as junk”.

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

#283

Post by [deleted] » Sat, Aug 04, 2018, 11:47 AM UTC

fpgaminer wrote: post #87

I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…

[deleted]

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

#284

Post by agumonkey » Sat, Aug 04, 2018, 11:48 AM UTC

One of my favorite application interaction was an old as400 thing from the 80s at the tax office. I was in college and still a bit into async js + css (in theory). That app had usual terminal screens, but the ergonomics were holistic, no brainer keyboard usage, no latency whatsoever, and the software was helpful. It was such a bliss. Software was never in the way, the only time it bugged you was to actually notify you of important issues (absurd data) and to provide either correct automatic fixes or a few clear suggestions. I realized how much context/paradigm is worth. It was obvious the efforts were spent on logic and not tech for the sake of it. Ironically it was the first wave of web2.0 business fad, so we were introduced to the new reincarnation of the tax UI in html/css and it was subpar in speed and ergonomics, and was of no help.

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

#285

Post by swaggyBoatswain » Sat, Aug 04, 2018, 12:33 PM UTC

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…

Thats the same way with architectural CAD design programs like AutoCAD

You can do things with the toolbars but every competent architect relies on CLI tools instead for common things like "move" , "scale", "copy", etc

I've never considered slack as a CLI tool for the masses this is a great analogy. I should do more research on existing slackbots

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

#286

Post by TeMPOraL » Sat, Aug 04, 2018, 12:40 PM UTC

TheOtherHobbes wrote: post #75

There are very few web apps where users need - or want - to do any kind of intelligent, complex text editing. Most web apps are virtual paper forms with pre-filled menu options and - usually - a bread crumb trail so users can change their choices and/or their minds. Animations are largely irrelevant to the user experience. The best way to speed up this kind of web app is to iterate over and over to find the sticking…

I disagree on several aspects.

I do agree that "most web apps are virtual paper forms with pre-filled menu options (...)", but that doesn't mean they don't need productivity improvement. First of all, many people use those "forms" for work, not just casual browsing. It's one thing when you're putting up some old book you found on eBay, it's another when you have to manage hundreds of such auctions each day. Suddenly, the difference between old and new web design trends is measured in 10x increase of time spent on task.

I know because I sometimes help my SO do her work tasks faster, and usually get 10x-100x speedup with clever application of web scraping, regular expressions and batch processing in command line.

Another thing - people don't "fill in forms" in isolation. Each webapp being a productivity-hostile silo causes pain whenever a task involves more than one of them. Often, users do in fact need "composability or grep-like text manipulation options", they just don't get them, so they suffer (or delegate to a friendly programmer, who can force a webpage to have some semblance of interoperability, whether its authors want it or not).

> So no - I do not think there's anything of value in the OP, except perhaps as another example of "Developers want to turn everything into a emacs and a build system, because that makes them happy, even though it's 100% inappropriate for non-developers."

It's not that - though I do believe that Emacs presents a much better UI paradigm than the one accepted in the mainstream (due to flexibility, interoperability and consistency). It's just that present day software - web apps in particular - are ridiculously hostile to productivity. The perfect solution is not doing everything from CLI, but it's also not shiny, animated web UIs exposing as little functionality as possible while still being able to sell the product.

Someone upthread mentioned the concept of threshold and ceiling. Emacs and CLI tools are high-threshold, high-ceiling. Webapps and mobile apps are low-threshold, low-ceiling. Perfection would be low-threshold, high-ceiling - that is, something accessible to beginners, but designed so that they can level up and become power users, if they need/want to.

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

#287

Post by TeMPOraL » Sat, Aug 04, 2018, 12:44 PM UTC

jancsika wrote: post #213

> 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…

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

Personally, I think that operating systems (and browsers) failed in enforcing such a framework, or at least strongly suggesting it.

Compare with Emacs, which is a prime example of how interoperable software could be, if it adhered to a common paradigm more. There's a reason people run tasklists, e-mail, IRC, shell, time tracking, invoicing and others straight from it. It's not because they're crazy. It's because the overarching UX principles enable greater productivity and integration than it's possible elsewhere.

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

#288

Post by TeMPOraL » Sat, Aug 04, 2018, 12:47 PM UTC

blunte wrote: post #197

As with debugging, it's important to choose your battles. How often do you start up slack? Is that 45sec once per day or even per hour, or is it per minute? Obviously it's not a frequent occurrence. So that delay, regardless of your computing power, is not an issue. A case where it does matter is with a good mobile phone camera. It must launch and be able to capture an image within one or two (or at least within 5) s…

> But back to the Electron topic... Would you rather a tool exists and isn't perfect, or it does not exist at all? Ok, or maybe it exists but costs $99 per user?

In a winner-takes-all, marketing>quality market of today's web? I'm inclined towards "not exist until it's at least somewhat good". The problem with Slack is that it sucked out air from everything else, and it became a de-facto standard for intra-company communications. It's hard for a better solution to take off, as it now has to fight uphill against a rich corporation and network effects.

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

#289

Post by ubercow13 » Sat, Aug 04, 2018, 12:53 PM UTC

GordonS wrote: post #247

NegativeLatency wrote: post #189

Earlier quoted context omitted.

But it needs plugins, fish has it builtin. Nothing to configure

Do you mean it just ships with support for a list of preset commands, or can it provide autocomplete for any command? (I have no idea how that could possibly work, mind)

The latter, to an extent; it parses man pages to provide completion/help for commands

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

#290

Post by collinmanderson » Sat, Aug 04, 2018, 1:00 PM UTC

freefal wrote: post #225

sharmi wrote: post #212

Earlier quoted context omitted.

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 differ…

Just so no one accidentally deletes an email on Gmail, 'e' is archive and '#' is delete.

Weird. I’ve always done ‘y’ for archive.