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

201–210 of 379 posts

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

#201

Post by 013a »

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…

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

I understand this argument for niche tools. I'm eternally grateful for things like Insomnia (a GraphQL client), NoSQLBooster (MongoDB GUI), etc, all written in Electron. I understand that asking for things like that in native is a recipe for them to not happen, or for them to be Mac-only, or for them to cost $100/year.

Slack is not in this category. It is produced by a corporation valued at three billion dollars. It is a product that is completely, totally, and wholly solved. They produce very little that is novel. I expect that experience to be all twenty shades of pixel perfect, because they have no excuses.

Let's look at Telegram. Great app. But they wondered if there were ways it could be improved, so they released, simultaneously, Telegram X on the app store [1]. A rewrite, using the same backend and APIs. It's even better. With Slack's resources, they could have done this twenty times over.

[1] https://telegram.org/blog/telegram-x

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

#202

Post by binomialxenon »

t1amat wrote: post #38
GlenTheMachine wrote: post #10

I'm switching away from macOS to Linux with the i3 window manager for precisely this reason. But all of his criticisms of terminals are spot on: no multimedia, no support for anything other than monospaced fonts, etc. Lord, somebody give me a terminal program that produces laid-out text and can show inline video.

You can get all of that with Electron-based terminals. Perhaps take a look at Hyper.

Ugh, I can't see any advantage that would justify my terminal emulator running on Electron.

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

#203

Post by KirinDave »

Karrot_Kream wrote: post #149
KirinDave wrote: post #76

Earlier quoted context omitted.

[1]: Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem. [2]: > As Nielsen is focused on web apps and applications, this advice is less applicable to UI…

> The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do. A bunch of people (including Kay and Victor) have talked about this, but accessibility is only one part of the interface. Pieces of software that are productivity related should be easy to get started with and be accessible, but also allow you to b…

And in the spirit of fairness and inclusivity to the console, Lotus 123!

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

#204

Post by devxpy »

> compose able by default

You're looking for click

http://click.pocoo.org/5/

It's the best framework across any programming language that I have found for building command line user interfaces.

I instantly know how to use an application made using click because it prevents you from making non-obvious GMO interfaces.

Even as a developer, I love using it. I often create CLIs for common chores in my projects using click. The applications always come out perfect, with little to no effort.

I wish there was something like this for GUI.

This makes me want to make a GUI framework like click, where you don't deal with the bare components, but "compose" your UI by just providing data

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

#205

Post by jstarfish »

0x445442 wrote: post #178
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…

Ding, ding, ding!!! I've been beating this drum for a few years now. The interesting thing about chat bots is the UI not natural language processing. I think people are completely overwhelmed by the massive lack of consistent UI the Web has brought us. I also think the more "apps" that could be brought into platforms like Telegram, the happier users would be. There's also evidence of this in China where 100's of mill…

Really? It seems that with the advent of Bootstrap and responsive design, website UIs are more consistent and generic than ever before.

Every corporate landing page is a jumbotron/full-width image, followed by three columns of bullshit, followed by a few rows of random glyphicons and more vague nonsense to cross the minimum text SEO threshold, and a footer.

The early internet was a much wilder place. Frames or no frames? Tables for layout or not? Dare we use an imagemap? Fuck it, let's do the whole thing in Flash. It was chaos.

Now, one thing that has also come to pass is websites with straight up cryptic UIs. Buttons no longer have labels. We have hamburgers and hieroglyphs. I think that might be more of a driving frustration.

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

#206

Post by Tagbert »

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…

CLIs work well when the universe of commands is small or the user is very familiar with the application. Discoverability suffers, even with man pages. Where a GUI helps is for the casual user who needs help understanding the options. An interface that can allow both styles of interaction has the flexibility to give both kinds of users what they need.

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

#207

Post by sogen »

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…

https://addons.mozilla.org/en-US/firefox/addon/no-transition...

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

#208

Post by meowface »

sorahn wrote: post #193
NegativeLatency wrote: post #189

Earlier quoted context omitted.

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

Yup this. If I wanted to carry around a bag of plugins all day, I'd just use bash.

On the plus side, by picking and choosing what you want, you can get the precise performance and usability ratio that fits you best. Fish is a great shell but nothing beats the zsh plugin ecosystem.

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

#210

Post by apatters »

digi_owl wrote: post #141
sxates wrote: post #114

Earlier quoted context omitted.

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…

IMO, intuitiveness is overrated. As one snarky joke goes: only the nipple is intuitive, everything else is learned.

That's a hilarious joke, made me LOL. If you want your product to be used though you have to think about what users already know how to do and try to build off of that. This is why baby bottles and skeumorphic design are popular and effective.
Post reply on HN