Hacker News Reader

Comment by justsomeguy123 | Hacker News Reader

Gnome people basically looked as how Apple managed to be firm about design and though they can be even tougher since they do it for free.

Such reasonable / obvious requests linger for decades and after a while the system has been rewritten and bugs are auto-closed.

I no longer report any bugs nor care.

View on HN

I loathe all auto-closing so much, it's such a cheap way out of issue triage. The ostrich method of project management. It's a good red flag though, I know not to waste my time on the project. Who knows what major issues have been auto-ignored.

It can be especially inane if the issues are also locked automatically, you're already ignoring the issue why the f can't you let people discuss workarounds or request reopen.

Firefox Android did that and I stopped contributing. It's not even that I hold a grudge, but the ostrich method is extremely frustrating to the reporters

I keep hoping someone will be gutsy enough to build and deploy a bumpbot (or bots!) to combat stalebot.

I keep hoping it will simply gain a way to say 'I still care, this is still an issue, there's no new information to add, (nor asked for!) it's just not being prioritised so please leave it open'. Or infer that after a couple of stale removals.

Sure they close a lot of junk from drive-by question askers which helps maintainers, but they piss off a lot of good citizens providing information on actual bugs/feature requests that are just waiting for attention too.

Combine that with the CLA plague and you have a recipe for nothing but corporate-backed open source contributions. Individuals need not apply.

An undead open-source project.

Not a bad idea. Should make it so it runs under user tokens so people can run it under their own accounts with their own message template.

This is the thing - if you're going to be like Apple and dictate design, you have to get it right. macOS and Apple hardware is not to everyone's taste, and they make mistakes, but they prototype and dogfood and iterate like crazy and they have thumbnails in the damn file picker.

When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.

> When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.

Wait, what? That would have been super useful, but how was I supposed to find out?

This works in every Finder window; if there's a window with files you can use Quick Look. I'm not sure if it's documented anywhere anymore, but it's been around 15 years.

It's not indicated anywhere visually. I don't even remember how I found out about it.

This is a downside of macOS and iOS design - lot of hidden gestures. For example, you can right-click the text title of a Finder window to open a quick navigation to all the parent folders of the current directory.

Wait, what? I knew about the spacebar thing but this one is new to me.

https://support.apple.com/en-us/HT201236 or https://support.apple.com/guide/mac-help/view-and-edit-files... I guess?

First one also mentions the ⌘-click on a window's title

One thing I'll give Apple credit for is in the early days of OS X, they had (and perhaps still have, if it's the same thing) a document called Human Interface Guidelines. They actually did real experiments with real people and came up with a set of UI patterns that were proven by science to make software features and UI discoverable, usable, and clear, with the least amount of cognitive load.

Things like, the buttons on a dialog should should be a verb indicating the _action_ the user wants to take. Like "Run This" and "Go Back" instead of "Yes" and "No". (Or worse, the old Windows "OK" and "Cancel", which is rife with ambiguity in so many cases.)

And the tone of the document was that it was intended to be useful to _all_ user interface designers of all software and on all platforms, not just OS X. I just skimmed over the current edition and as far as I can tell, these days it's basically just about how to stay "on brand" with the Apple experience when writing your own UI.

Windows also had a similar document. E.g. here's one for Win7:

https://docs.microsoft.com/en-us/windows/win32/uxguide/guide...

The problem is getting the app developers to actually follow them.

Here's my favorite Human Interface Guidelines version (2009-08-20): https://web.archive.org/web/20101113134550/http://developer....

For what it's worth Gnome also has an HIG: https://developer.gnome.org/hig/

And they have claimed in the past to have done UX testing with actual users.

> And they have claimed in the past to have done UX testing with actual users.

How many testers were there and how were they selected? Are they representative of gnome's current and future user bases?

I think I read once that their test group was basically the developers and their mediate friends. If so, then this is not how you do UX testing.

> I no longer report any bugs nor care.

Past that point years back, kept going.

I just don't use anything Gnome related, if I can help it. I have found some things that unfortunately use the toolkit and somehow manage to not be intentionally irritating, but I assume that's an oversight to be corrected once I'm dependent on it.

Like is too short to use irritating software.

This 1000x. Apparently it's called being "opinionated" nowadays.

Reply on news.ycombinator.com