Hacker Newsnew | past | comments | ask | show | jobs | submit | mbishop's commentslogin

Gotta take issue with the characterization of “bolted on”. That’s a design feature and it’s huge. It made interoperability trivial. You can write C, C++, and Objective-C within the same source file.


Bolted on wasn't a value judgement, it was literally bolted on top, it is a strict superset (unlike C++, which is also bolted on, but poorly, since it partially breaks compatibility).

The syntax growing over time is a real issue though. Every time I have to write __bridge_retain I get hives.


Including the CVEs from C style coding, a desgin feature it shares with C++.


> The same is true in a physical card wallet.

But I can write on my cards with a pen to visually make them unique.


I was with you until the last sentence. Removing borders makes it harder. Not being able to see the actual area of a clickable target makes it harder. I never had trouble knowing what to click in the early 2000’s, when UI was ostensibly more dense.


They are indeed awesome and I made one with a simple box fan. It works great but it’s really loud. We can’t really have it on when company comes over.

We got one of these instead and have been really happy with it. Pros: super-quiet low-energy computer fans. Uses standard air filters you can buy at Lowe’s. Cons more than a box fan.

https://www.cleanairkits.com/products/brisk-box




Attention all designers: That skeuomorphic, non-flat design that you might think is unstylish but in reality is so very usable… this book explains why.

In the UI of the 2000’s, the UI is visible, the chrome is visible and it has meaning and utility. Buttons are easily found and pushed because they visibly look like they are extending from the display. That’s an affordance. The window corner used to have a “rough” texture just like exterior stairs have texture strips to keep your feet from slipping. They indicated that the friction from your mouse-pointer on the screen will move the window corner.

These designs allowed user decisions about UI function to exist in the subconscious where they weren’t a distraction from the actual problem at hand.

The bar these days seems to be “is it possible for the user to eventually accomplish their task?) as opposed to “how can we demand even less of the users’ brain for the task to be accomplished?”

I am anticipating this will not be a popular response, but I can’t help but think wrt/ UI design, we’ve collectively thrown out the baby with the bath water for vanity and it’s going to take some criticism to get it back.

Reading this book and studying the UI designs it inspired (ex: early to late 2000’s Mac UI) is IMO the best education a young UI-designer can get.

Edit: I don’t want to lay too much at the feet of designers because it’s probably Product Managers that also need to read this book and care about it.


Can someone please make this, but for creating an orchestral arrangement from a piano theme (maybe with some hints?)


I think the lesson is to not think first about your data and how to put it on a screen.

Start with the user and then figure out how to utilize your data to support your UI.

Dumping database records to a list view on the screen, no matter how pretty you make each entry, is rarely useful.


With that in mind, it might be more effective to write a BASIC REPL in Javascript (I’m sure one already exists) and then run the original programs.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: