Hacker News Reader

>> fuzzy matching, and it can learn what you usually do so it can prioritise the things you use often.

>Every time that I saw something like this in any application/OS (Android is a prime example), it was such an epic fail that it is almost beyond words.

A counterexample: the fuzzy matching in the address bar for firefox and chrome is awesome. Typing "Hacker" brings up "news.ycombinator.com -- Hacker News".

It would be awesome if the HUD could operate like this, * especially* as an alternative (not replacement) for menus (which are probably more efficient for common commands).

that's true, but sometimes it's a bit too smart for my taste... There is an internal company website that I often visit, say test.company.com. Chrome always autocompletes this with test.company.com/admin, even though I quite often also visit other parts of the domain, say /backend, /statistics, and so on... Now, the action is self-reinforcing, as I would type "t", press -> to autocomplete it, delete until there was just "test.company.com/", then select one of the options that only now show in the dropdown menu.

Actually, for me this is a perfect example--since I hate the combined search/URL bar in chrome. I'm conditioned to type urls in the URL bar, not search queries, and the only matching I want done is against the urls in my history. So instead of typing "hacker" I type "news." and usually, hacker news is way down on the list until I type "news.y", and even then on some browsers, it doesn't appear at the top (even though it is the only thing in my history with a URL that has that pattern in it.) This Ubuntu HUD would worry me heavy GUI apps like GIMP that have organically developed relatively complex menus. It seems to be a good thing to be able to search for the menu item, but having to remember all the different menu names could be problematic, not to mention the dependence on the keyboard on a app that is primarily mouse driven. I'm assuming context/right click menus won't be impacted by this?

> I usually learn faster than a computer, so the way I see it is not computer "learning", but computer arbitrarily "changing" its behaviour. So, instead of memorizing "to call Jack, I have to press J and Down and Down", I have to always pay attention when the interface changes...

Thanks for putting this in words. This is an example of an innovation that reduces the learning curve to a device, but almost certainly makes it slower for the experienced user. One of the reasons that I use GNU/Linux on my personal computers is precisely because FOSS interfaces tend to not make this trade-off (as evidenced by Emacs, Vim, Blender, Inkscape, and many more). So, I am a bit luke warm towards this new HUD interface (then again, I haven't forced myself to swallow the Unity pill yet, either).

My keyboard doesn't randomly swap around the keys on my keyboard, and I appreciate that because I spent the time learning to touch type. Arguably, adaptively moving keys could be faster for 'hunt and peck' typists, but not for people who have spent some time learning how to type.

Sure, but the holy grail is a system which guides the users towards becoming trained. It's not necessarily a dichotomy between easy-to-learn-but-not-efficient-in-the-long-run and emacs.

> Obviously, HUD and menus have different functions, and different use.

A hybrid wouldn't be impossible. In the example screenshot, the menu breadcrumb trail is shown. One possible solution would be to show the top level menu items in the HUD when it's first pulled up and allow the user to navigate it via mouse.