Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

Post reply on HN
Print view View original

181–190 of 379 posts

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

#181

Post by [deleted] »

cortesoft wrote: post #118
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…

In a lot of ways, chatops is even better than a CLI. It basically can turn a channel into a shared terminal, with history, search, and the ability to comment

[deleted]

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

#182

Post by 0x445442 »

cortesoft wrote: post #118
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…

In a lot of ways, chatops is even better than a CLI. It basically can turn a channel into a shared terminal, with history, search, and the ability to comment

And display hypermedia.

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

#183

Post by 0x445442 »

swerveonem wrote: post #133
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…

It's the rediscovery of mIRC like interaction workflows.

Got most of my music through mIRC :p

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

#184

Post by daleco »

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…

The process to get there takes time. A clever simple solution always look easy to come up with.

Creating Intuitive interfaces has been solved, you need a design centered culture, a good design system, and implementing user centered methodologies (look into human factors, cognitive engineering...)

It takes more investment upfront, but it’s worth it in the long run.

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

#185

Post by eikenberry »

sorahn wrote: post #166
westoncb wrote: post #142

Earlier quoted context omitted.

I've been wondering this for years. It seems like the most obvious way to greatly improve CLIs, yet no one seems to talk about it...

Check out Fish Shell.

Zsh can also do this.

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

#186

Post by 0x445442 »

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…

I've mentioned his name elsewhere in this thread but Aza Raskin had some very interesting thoughts on this subject.

One of his main assertions was a big problem is the whole app paradigm. The whole notion of silod apps bound to native widget tool kits is very limiting and that the host platform should really just provide a facility for running commands.

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

#187

Post by 0x445442 »

sleepyams wrote: post #175
mikeryan wrote: post #164

Earlier quoted context omitted.

There’s an inherent dichotomy in UI in that the most “efficient” interfaces generally have the steepest learning curve. You can be really efficient in a terminal or VIM. But figuring those out take a lot of work. When we design interfaces we try to make them have a short learning curve but expose greater ability as you use them but it’s still hard.

That makes sense, for example Reddit has a very simple concept with the upvote/downvote, but also more advanced features if you need them. But I would also argue that UIs also implicitly convey a preference for how data on the web should be organized, and that affects usage. For example the feed, besides being a UI pattern, also claims that content on the web is for consumption and not exploration, and so we remain s…

Duckduckgo David Galernter and Lifestreams. He predicted the feed over 20 years ago but his vision accounted for the exploration aspect as well.

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

#188

Post by arg84 »

juancampa wrote: post #103
arg84 wrote: post #74

Earlier quoted context omitted.

Following that logic would mean that the more time we spend interacting with the medium the less important aesthetics/gestalt is, and that the medium should instead be focused solely on function. I think one thing the low level tech focused individual can sometimes overlook is that it is humans interacting with these interfaces, and humans are varied, and as such interfaces need to incorporate many different methods…

Aesthetics are always welcome as long as they don't compromise usability. What I've noticed is that the more you look at something, the more normal it tends to look, regardless of whether initially you thought it was beautiful or ugly. Not sure why it happens but aesthetics stop being as important as time passes.

I agree. I just think we shouldn't be too quick to write off things that seem frivolous or maybe slow down the power user. For example a fade animation may seem like it's wasting time, but used properly it creates a visually pleasing transition, while at the same time possibly allowing for work to be done in the background while the UI would be otherwise unresponsive. However, I have also seen this abused as well. I think it's best that we continue to call it into question like this article does, but also try and stay balanced and not ignore some of the other considerations.

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

#190

Post by teej »

the8472 wrote: post #180
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…

JIRA pages are "animated" by new widgets popping in, then showing loading icons and then finally displaying their final content. You cannot target any single element on the page while it does that because everything moves around every 500 milliseconds or something like that. You just have to sit there and wait until all done. And then it only loaded X of Y items and you have to click to get the rest which again leads…

Poorly executed X does not make X bad.
Post reply on HN