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

251–260 of 379 posts

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

#251

Post by TeMPOraL »

laumars wrote: post #123
kovek wrote: post #105

Earlier quoted context omitted.

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…

Skype supports the regex s/search/replace/ notation as well. Which threw me off guard one evening.

Does it? I know it did 7 years ago on Linux clients, but AFAIR it doesn't now. It's definitely the feature I missed the most on Windows client.

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

#252

Post by akx »

ssorallen wrote: post #228
0x445442 wrote: post #179

Earlier quoted context omitted.

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.

I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over. Is there a terminal with similar ability?

Fish's abbr feature does this. They're aliases that expand in place. For example I have gph abbr'd to "git push origin HEAD", and I can continue editing the command after expansion.

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

#253

Post by theelous3 »

erikbye wrote: post #230
chocolatebunny wrote: post #126

Earlier quoted context omitted.

Reminds me of a former coworker's Emacs workflow. He organized his work in orgmode. He used emacs for email, jabber, and irc. He would copy paste new tasks between email and orgmode, and he could copy paste the code snippets he was working on to irc if he needed help.

He'd get a lot of flack unless he gisted his snippet first. But, of course, we have gist.el.

Shout out to termbin for being a useable and simple cli option here.

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

#254

Post by kenneth »

eridius wrote: post #31
jwr wrote: 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!

It would not surprise me in the least if the 1Password unlock animation is a deliberate attempt to hide the time it takes 1Password to decrypt your password list.

It's not the decryption process that is slow (computers can do AES really really fast these days), it's the deliberate slowness introduced by PBKDF2, which attempts to thwart brute force attacks.

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

#255

Post by theelous3 »

j88439h84 wrote: post #234
ericpsimon wrote: post #194

Earlier quoted context omitted.

Has Slack innovated in the last 5 years?

I dunno. Do you think that's important? Why?

Buggy mobile client (andriod) and dumpster tier performance are two areas they have been dropping the ball on since release, and requires innovation in some sense of the word.

Those are both very important. Innovation is generally important and I'm half curious as to why you ask.

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

#256

Post by arendtio »

JoshMnem wrote: post #241

Animation is unnecessary in most cases. Minimal animation can be added where the UI would otherwise be unclear, but other than that it's visual spam. Animation should be like a very thin layer of icing on a cake, but we're getting fed cakes with 4 inches of icing on the top. There is often little aesthetic restraint. Designers should be asking, "how can I remove as much animation as possible?" It spammy and also an a…

I wouldn't say animations are unneecessary. There are cases where they do add something positive. For example I see this open/close animation of yakuake [1] up to a hundred times per day since years and I still like it.

I think the key to good animations is that they use the right timing. They are best when you barely even see them. They should transport a notion, but as soon as you see it clearly, you have to wait for your computer to finish rendering and that sucks.

[1]: Terminal emulator which comes down from the top of the screen https://www.kde.org/applications/system/yakuake/

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

#257

Post by JoshMnem »

pavlov wrote: post #244
JoshMnem wrote: post #241

Animation is unnecessary in most cases. Minimal animation can be added where the UI would otherwise be unclear, but other than that it's visual spam. Animation should be like a very thin layer of icing on a cake, but we're getting fed cakes with 4 inches of icing on the top. There is often little aesthetic restraint. Designers should be asking, "how can I remove as much animation as possible?" It spammy and also an a…

Animation in UIs is like corridors in architecture. If the user can’t get directly from A to B, you need to have something in between to carry them through the transition. An architect would never dream of adding extra corridors just because they’d be a nice place to display some framed art. Neither should a UI designer add animation for its own sake. I used to work on a UI modeling tool, and users were constantly di…

I'd argue that UIs usually don't need something to carry through the transition, and that those kinds of animations can be dropped in most cases. I can see the use of animation in games, but for content-based sites/applications, there should be little to no animation. Users already know how to get around and what the various buttons do.

Between the time I started using computers (early 80s) until a few years ago, there wasn't much animation and it wasn't missed. There were some complaints about back then too -- flying butterflies[1], powerpoint transitions, blink/marquee tags, etc.

[1] http://www.dynamicdrive.com/dynamicindex3/leaves.htm

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

#258

Post by TeMPOraL »

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…

One more thing RE car analogy. People are spending 30+ hours learning how to operate a car before being allowed to do it on their own on public roads. Software vendors no longer expect users to spend even 5 minutes learning. This is a cultural problem.

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

#260

Post by TeMPOraL »

teej wrote: post #190
the8472 wrote: post #180

Earlier quoted context omitted.

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.

Then again, we're not talking about perfect true X, but the typical execution of X. Typical execution of animations is terrible, so it's a problem.
Post reply on HN