Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

151–160 of 379 posts

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

#151
Reading this reminded me of my parents sitting on their patio, complaining about the neighbor's air-conditioning unit. I wouldn't even notice the sound it was making until they said something—but for for them, being so tuned into it and having it already on their mind as 'a problem,' it was a prevalent part of their experience.

There are two regularly occurring situations times where I'm delayed by the slowness of interfaces:

1. At work, waiting for our web app to reload after I've made some changes to the source. This is actually a problem and eats up a significant amount of time and makes me lose focus.

2. I'll occasionally come across a slowly loading webpage. And I stress 'occasional' here—it's maybe once every couple of days when I open an article on HN or something and it's some site with a tons of ads and stuff. It's a non-issue—easily less than 5 minutes per week.

Aside from those delays, I basically never find myself waiting for whatever software interface I'm interacting with, and that's on a 2014 macbook pro.

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

#152
post #44

Earlier quoted context omitted.

IIRC all Commodore machines did this. The C64 did. That's how you edited a program: you LIST'ed it, and then scrolled up and changed the lines on the screen. When you hit ENTER the new line overwrote the original one. The C64 did not have any way to directly show or edit system memory, though. That's cool.

Are you forgetting about POKE and PEEK?

No. But an actual monitor was a much easier way to directly access system memory.

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

#154

Earlier quoted context omitted.

IIRC all Commodore machines did this. The C64 did. That's how you edited a program: you LIST'ed it, and then scrolled up and changed the lines on the screen. When you hit ENTER the new line overwrote the original one. The C64 did not have any way to directly show or edit system memory, though. That's cool.

The C64 was indeed one of the only Commodore machines that did not ship with a Machine Language Monitor. You could however install one: https://www.c64-wiki.com/wiki/Machine_Code_Monitor

Sure. I even wrote my own, as an exercise in learning 6510 assembly.

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

#155

I think this article points out some very valid problems (I relate a lot with Slack's loading, OSX spaces taking too long to switch between, etc), but the conclusions may be a little misguided. To address specific examples first: 1. Slack is slow to start, and, as others have pointed out, uses animations to remind the user that it's working and not just frozen. The fix here is to improve the application's performance…

I think another example of this would be using something like Adobe Photoshop or Illustrator. Switching between tools can be accomplished by clicking an icon, a drop down, or some other GUI element. However, once you get to a certain level of skill, it becomes faster to just use the keyboard shortcuts. For a novice, it's more forgiving. But for the expert, it's possible to be very efficient. It's also possible to go…

I still use cheat sheets, but I design my own into wallpapers that fit my desktop perfectly, than have them rotating randomly every hour. Keeps my refreshed on shortcuts in my popularly used programs, and adding a new one to the rotation is a great way to learn all the shortcuts for a new program.

It's not like I ever leave my desktop visible for a pretty wallpaper to matter. My nice ones are on my lock screen.

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

#156

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…

You may check telegram’s games, services and other bots that allow to manage your entire world via chat (with programmatic buttons and menus to ease /cmds a little). I don’t use it much, but my coworker said that he almost lives there, visiting sites only for long, static content.

From this perspective, “we” don’t “need” as the article says, since it’s already there and writing a simple bot is a no-brainer. (Downsides of proprietary protocol are obvious.)

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

#158

I highly disagree that the animations are superfluous for the vast majority of users. Yes, they can be superfluous, but that's not by their nature of existing. History shows us that consumers value good UX, of which animation is a key component. The iPhone wasn't the first smartphone, but it was the fist one to take UX as seriously as the hardware. As for the examples: - Slack: Yes, it takes forever to load and I hat…

The user could be told what's going on without breaking the entire flow through. That's what status bars did. Even if they're not the answer now, there's endless ways to notify a user of action. The old rotating "e" of Internet Explorer. A progress bar embedded next to the relevant part that's loading. A tick mark that shows up then fades away when an item is done. Etc etc

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

#159
post #5

>>> These powerful devices should be propelling our workflows forward with us gangly humans left barely able to keep up, and yet, almost without exception we wait for our computers instead of the other way around. We’re conditioned ourselves to think that waiting 30+ seconds for an app to load, or interrupting our workflow to watch a half second animations a thousand times a day, are perfectly normal. In addition, th…

This extends to how people think about teaching others about computers. I would get so frustrated with E-mails that consisted of about 9 “steps” to walk through when using a WEB site, instead of posting a direct link to the final target! The progress animations are out of control too. Every time I see one, I imagine the engineering hours it took to animate and wondered if they could have just spent hours optimizing t…

Indeed, I've seen installation instructions that come with hardware accessories or software, where it's page after page with pictures of dialogs with circles and arrows and a paragraph on the back of each one.

And they don't apply to your version of the OS.

The instructions for installing the same thing on Linux is just a series of commands that you copy and paste into your console.

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

#160

One of the failures of modern GUI design is exemplified by the calculator app on the iphone. It looks exactly like the old stand-alone desktop calculators. What could be wrong with that? Have you ever used a calculator, and wondered if you'd punched in the operands correctly? I have. And so I do the calculation again. With a scrolling terminal, you can see (and check) the operands on the previous line(s).

It's for macOS instead of iOS, but numi is a great scratchpad calcualtor. https://numi.io/

Never tried it, but Soulver looks like a good solution for iphone: https://acqualia.com/soulver/

and CalcNote on Android - just installed this and its' just like numi. https://play.google.com/store/apps/details?id=com.burton999....

Post reply on HN