Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

171–180 of 379 posts

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

#171
post #8

I absolutely agree that aesthetics shouldn't come at the expense of efficiency, but I don't think it's practical to expect every user to be a power user. There are some products and programs, like the Adobe Suite and a bunch of terminal programs, that are marketed for and should be designed with power users in mind. But I'd say the majority of programs we use every day aren't designed with professionals in mind - the…

Yes, I agree here and you would not be losing much with the added effort. power users are already more likely to dig into most software/s and tweak settings so it is a win-win

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

#172
post #95

These rants always seem to miss something important. Not everyone thinks like you (seasoned terminal users) do. There are different kinds of intelligence. The only way to get good with a terminal is to RTFM and _play_ with it, until you're used to it and have constructed a mental model of its internal "types", their logic and composability. Software developers are as a group highly predispositioned to construct menta…

> Not everyone thinks like you (seasoned terminal users) do. There are different kinds of intelligence. The only way to get good with a terminal is to RTFM and _play_ with it, until you're used to it and have constructed a mental model of its internal "types", their logic and composability.

Yes, and here's the point I would like to stress that is completely lacking to make the idea of user friendly terminals work:

GUI:s are more user friendly than Terminals because of discoverability and limiting affordances.

User friendly Terminals might just be possible if you allow users to explore what is possible with clever search and query completion. It should be able to recognize what entities you are likely typing about and suggest commands that use them. Let's call it "Semantic terminal"?

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

#173

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 think that's absolutely fair. The pace at which the industry is starting to solve really big, hairy problems in standard ways is ever accelerating; the devops space right now is undergoing massive solidification under the Cloud and Kubernetes. UI is one of those problems I hope we're humble enough to admit that we got horribly wrong with HTML/CSS, and maybe we need to go back to square one.

But at the same time, lets pick on Slack. There's no good reason that it needs to take more than 5 seconds per team to load. Maybe its Electron, HTML, and CSS. Maybe they're loading too much data at the start. Maybe their Ruby servers are a little slow.

All of that could be true, but one thing is definitely true: There's a Product Manager or an Engineering Lead somewhere in San Francisco who looked at what their engineers had built and said "Yup, this lives up to the quality our users expect, ship it."

Jira is the same way. Its dog slow. Its full of UI bugs and inconsistencies. But people still buy it, and someone at Atlassian has to have said "we'll worry about this UI bug later, we have more reports for middle management we want to add to the product."

Our best minds will solve the tremendously difficult UI problem one day. But today, the best thing most of us can focus on is the People problem. Expect and Pay for better. Reach out to leaders at these companies on Twitter. A core problem in the software purchasing process is that, often, the people who buy the software aren't the people who have to use it day-in day-out, and often there's obvious lost productivity between the feature bullets on the marketing page and an engineer on an old PC her company won't upgrade for another year.

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

#174
post #6

Yes! I am so glad somebody called out the UI animations! The one in 1Password bugs me every time, I don't use Spaces because it takes too long for the animations to play out. There are more examples. Every time a programmer adds an animation, a settings option should also be added to "disable animations". Advanced users will love you for it!

I'm confused. By Spaces animation, are we talking about the horizontal sliding transition? On my machine (High Sierra) the transition time between Spaces is dependent on the finger gesture swipe velocity. I'm not really sure I would even call this an animation- the Spaces x-offset is being adjusted as I move my fingers along the track pad in the same way as scrolling up/down in a browser behaves. There's literally no…

They are keyboard-based ways to switch spaces too.

I do find that if you use the keyboard to switch spaces quickly, the animations become faster too. Unfortunately the app in the other space do not get new keyboard input during the animation.

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

#175

Earlier quoted context omitted.

Will we ever solve UI? UI is the meeting place of tech and user, and in a sense it is THE problem for humanity right now. UI informs how we tend to use the internet, and for example we are currently involved with UIs that tend towards consumption (e.g. discovery mechanisms, feeds, etc). To solve UI would imply a certain optimal way to live our lives, if that exists. I agree with you that UI is unsolved and extremely…

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 stationary on these aggregation platforms instead of 'browsing' the web as we used to. This is efficient but politically bad for society, and we would need to introspect on how we use the internet in tandem with the development of new tech like decentralized platforms.

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

#176
I think animations that you don't notice as animations are the most useful. Take scrolling and scroll locking an element to fixed when a threshhold is reached. A slide down of a section opening, a zooming of an image, a swipe left... these are useful gestures that are not noticed but rather feel as though they should be part of the experience naturally. Focus on useful animations that add to the experience but we are not going to the stark days of command lines ever again although as a programmer I love them and can't stand probing for settings deep in UIs or navigating nested trees via clicking. We are not normal though.

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

#177
post #105

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…

I don't think the sed syntax was implemented in an effort to make a good interface; rather, they simply implemented what many (albeit technical) users have been writing for years. I've been using sed-like notation to chat with colleagues for years. HipChat just chose to do something about it.

I believe you could also edit your last message with the mouse, or by pressing "up" (but I don't remember if that was opt-in).

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

#178

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 millions of people use WeChat for a large percentage of their needs.

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

#179
post #113

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…

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.

Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area.

The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.

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

#180
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 to more layout changes. It's as I am watching the same rube goldberg machine over and over again.

Ok, I can see that something is happening. But that renders the whole UI unusable while it does. And it gets tiresome after the first time.

Post reply on HN