I get what you're saying, and you certainly have a valid point about flashy GUIs not necessarily being effective GUIs.

However, speaking as someone who does a lot of UI work, there is also the other side of the coin, which is that CLIs and plain text log files are often neither the most efficient nor the most accurate way to configure or discover the things you care about.

In their favour, plain text formats are amenable to scripting and analysis using general text manipulation tools, and of course they have longevity. But they are also unstructured, they offer little interactive, real-time support, and ultimately they are limited to what you can express in sequences of characters (which is just about anything, but only if you're willing to write enough).

Even in highly technical environments, a good visualisation can present information in a form that is prioritised and draws attention to the most important features or anomalous results, or that gives a realistic overview of the current situation far quicker than scanning text output would. If you start to make those visual representations interactive, you can potentially also make complicated configuration work or progressive explorations of the data quicker and less error-prone.

Seconded!

I once saw a Java class with pages of complex multi-threaded code to update the horizontal offset of the ticker in a GUI. Not counting the usual minimum content of a class file, I replaced it with a single line along the lines of "return velocity * getCurrentTime();". So satisfying! 8)

This.

It's surprising how little feedback there is in the real world.

One of the best experiences of my career (when I had a developer hat on), was sitting in the room where Level 1 and 2 support staff were on the phone, supporting a system that I had built and was doing Level 3 support on. Until then, it would not have occurred to me that a good 20% of their time was wasted on looking up contact details. No problem, I integrated a one-click contact-lookup function into the dashboard system. They loved it. I never would have thought that "fast search" (think milliseconds) was a "feature" until I saw how important it was for a helpdesk person to not have to wait for anything while talking to someone interactively.

Things of that nature resulted in a UI that -- while a bit quirky from a developer's perspective -- allowed them to get their jobs done efficiently! It was all really simple stuff to implement, but I wouldn't have ever gone down that path if I didn't have that direct feedback and on-site observation of user behavior.

Yes they can, but not for free.

This sort of idea makes us geeks feel warm and fuzzy inside, but the reality is that you're talking about implementing two completely different versions of that UI feature. Doing so takes time and money, and you’d be spending that time and money purely to support a use case that probably represents a negligible number of users (people who want to run these UIs but have JS disabled).

Of course portability and compatibility are important for user interfaces, but this is a cost/benefit question. There is a line beyond which the results do not justify the effort, and any resources you’re spending past that line aren’t being spent on implementing other features or improving the usability elsewhere in your UI.

That’s not entirely fair. As a guy making UIs, I love hearing from the front-line what the users actually want, what they like and what they would like to see improved.

However, most development roles aren’t naturally customer-facing, and the focus for most people between the customers and the developers is usually on features (and commercial matters like pricing, of course), so this is the information that will naturally flow through an organisation and drive development.

Likewise, from the user’s side, often the people who are in contact with suppliers and making buying decisions aren’t the people who are personally going to get that 4am wake-up call to actually use these products. If there are things that matter and they aren’t obvious in the way that a tick in a feature column or a discount on a price are obvious, someone has to tell the guys doing the buying/negotiations so they can pass it on.

Basically, picking up more general usability issues like the ones bertok mentioned above either takes an exceptionally enlightened and well-structured organisation where this kind of information routinely gets passed on as well, or it takes guys at both ends of the chain who form side channels to get the little details through, and this goes on both the supplier and the customer side.

Thank you for the insightful post. I create user interfaces professionally, I share many of your frustrations with the generally poor standards in the industry, and I find it reassuring that at least some people who use the kind of tools I build do actually value good usability!

The one big thing I would add to your points is that whatever kind of user interface you’re building — CLI, GUI, API, whatever — it’s always going to be limited by how well thought-out the underlying configuration model is. If you have a system that requires 745 interacting settings to be correct before it works, and the guy who changes those settings is doing it at 4am after his pager woke him up, you’re unlikely to see a happy ending no matter how polished the presentation of those 745 settings might be in any UI. It never ceases to amaze me how many UIs don’t get their fundamentals down first, and just think it’ll be OK as long as the UI is pretty, compatible with Brand X, compatible with Scripting Tool Y, compatible with Management Protocol Z, or some other useful but second-tier benefit.

Please do share any other rants, general frustrations, examples of things that were really useful, or other similar comments you have. These kinds of threads are gold for those of us who work in the industry.

Specific examples are hard to come by, but I've noticed the general trend that differentiates the "good" from the "barely usable"..

* Scalability. For example, a good interface will pop up a "search" box for finding a security group in Active Directory. A bad one will let me chose security groups from a list or a drop-down. Both look equally good when the developer is working in a test environment. The latter will crash when used in a million-object directory. Similarly, check out the DNS management dialog box in Windows, or some Oracle tools. Both will show you "all" objects up to some limit (e.g.: 5000), but then provide a filter option to allow you to narrow down the "search" to prevent the GUI from melting if you look at a database with 500K tables. Yes. It happens. A lot. More than you think. Really.
* Annotations. It's 2014 for Christ's sake! There is absolutely no reason not to include a general "note" or at least a "description" field with every. Single. Thing. Seriously. All of them. I'm not kidding. Look at VMware's vSphere interface as an example of this done reasonably well but not perfectly. They at least allow custom columns so you can tag things systematically. Better yet, newer versions of Microsoft's Group Policy allow annotations on every single setting.
* Versioning. For example, Citrix NetScaler keeps the last 'n' versions of its configuration automatically (5 by default I think). Why the fuck Cisco can't do the same with their 1KB but omfg-they're-ultra-critical-to-the-whole-goddamned-enterprise config files I just don't understand. Maybe they're trying to save precious bytes...
* Policy. Good examples are Cisco UCS Blades and, of course, Active Directory Group Policy. Settings should trickle down through hierarchies. I should never have to set the exact same setting five hundred times. Settings should set-and-unset themselves automatically based on the scenario, e.g.: replacing a blade should not involve having to reconfigure its BIOS settings by hand. A typical bad example is 99% of Linux, where every setting has to be either manually set or set via a script. A script is still manual, just faster. No! Smack yourself in the face! A script is NOT a replacement for a policy engine. Don't breathe in, ready to go on a rant about how great Linux is, and how easy it is to manage, because it's really not. Scripts are a "write only" management tool that result in impossible-to-reverse-engineer solutions that can only be replaced wholesale years down the track.
* Help. I'm not really a storage engineer, I just... dabble. However, I've set up labs with IBM and EMC kit, no problem. The one time I got asked to create a simple logical volume on a Hitachi array, I walked away backwards and refused to touch the stupid thing. It seriously had 10 pages of settings along the lines of "L3 Mode: 5/7?" I mean... wat? So sure, I press F1 for help like a naive fool. It helpfully informed me that the setting configures L3 Mode to either mode 5 or mode 7. I can press "OK" to accept the mode setting, or "Cancel" otherwise. I was enlightened. Meanwhile, the same dialog box on the EMC array basically asks for where, what size, and what RAID level.
* Behind the Scenes. Some GUIs have 1:1 mappings with some sort of underlying command-line or protocol. Consoles based on PowerShell such as most Microsoft and Citrix products come to mind, most Linux/Unix GUIs, and Database admin tools. The better ones will have a "tab" or a pop-up somewhere which shows the "script equivalent" of whatever you're doing in the GUI. This is very useful, particularly for beginners, and we're all beginners with every product at least once.

Really, GUI design is -- or should be -- a science, and not a trivial one! It integrates serious engineering constraints, business restrictions, project management priorities along with the fuzzy complexities of both individual psychology and the complex dynamics of interacting groups of people. It's done woefully wrong even by the largest corporations. In practice, it boils down to the developers not having administrator experience, or a realistic test environment. The best GUIs I've seen were usually those were the developers were working against production systems at scale. That's both rare, and by no means a guarantee...

This utter garbage makes it to the Slashdot front page while just below it is this headline: The Rise of Hoax News.

The Sony Bravia 4K TVs have HDMI 2.0 ports, and can display this video.

The hiccup is that as far as I know, there are no PC video cards with HDMI 2.0 outputs!

D'oh!

It is very much backed by the real world: Debt Deflation

Waving your hand and saying that it's "not a problem" when it obviously is, doesn't make it magically go away. Keep in mind that the deflationary spiral talked about by most economists is for deflation on the order of a few percent per year. The deflation of Bitcoins is an order of magnitude greater than that!

The inventor of Bitcoin is a criminal genius, and should be jailed for inventing the biggest Ponzi scheme ever.

This assumption by the OP:

... is entirely wrong. One of the defining features of Mathematica is symbolic expression rewriting and arbitrary-precision computation to avoid all of those specific issues. For example, the expression:

N[Sin[1], 50]

Will always evaluate to exactly:

0.84147098480789650665250232163029899962256306079837

And, as expected, evaluating to 51 digits yields:

0.841470984807896506652502321630298999622563060798371

Notice how the last digit in the first case remains unchanged, as expected.

This is explained at length in the documentation, and also in numerous Wolfram blog articles that go on about the details of the algorithms used to achieve this on a range of processors and operating systems. The (rare) exceptions are marked as such in the help and usually have (slower) arbitrary-precision or symbolic variants. For research purposes, Mathematica comes with an entire bag of tools that can be used to implement numerical algorithms to any precision reliably.

Conclusion: The author of the post didn't even bother to flip through the manual, despite having strict requirements spanning decades. He does however have the spare time to post on Slashdot and waste everybody else's time.

Interestingly, you claim your choice of programming language suits your requirements, but then you state a bunch of issues endemic to it, but mitigated or absent in other languages.

For example, the need to sometimes, but not always, initialize objects, libraries, or whatever is typical of C/C++ code, but rare in Java or C#, where constructors or factory methods usually do that automatically for you on demand. The worst I've seen is some Microsoft C++ code where every object had both a C++ constructor and an init function, which wasn't consistently named and would lead to annoying run-time crashes if missed.

Similarly, the need to chase related code between two unrelated files is decidedly a C/C++ centric problem. A typical Java or C# class file is complete and self-contained, except for some special circumstances such as generated "partial" files used in C# or whatnot. Code discoverability is many-fold improved in Java and C# because of intelligent refactoring IDEs that can accurately chase references across millions of lines of code. That's just not possible with C/C++ where the same header code can be interpreted differently depending on the context in which it is included! Macros in general, particularly when combined with opaque 'void*' pointers, severely limit IDE capabilities.

I feel your pain. I've tried to hook in C libraries such for basic tasks such as ZIP compression or PNG decode in the past, only to discover that each and every one of them reinterprets what "int" means, how to "malloc", "free", read a stream, and return messages or error codes. Meanwhile, this just never happens in Java or C#. The size of integers is fixed and typedef is flat out missing, memory is garbage collected and released automatically, both languages have a built-in System.IO.Stream, and both have exceptions for safe and consistent error handling.

Sure, I'll believe you can remember to call "free", but which one of the dozens in the libraries you're using? Are they all thread-safe? Are you sure? Are your co-workers? All of them?

I'll even believe that you "need" C++ performance, except that in my experience I can spend 1/5th of the time developing the logic a C++ programmer, which then leaves me 4/5ths of the time for optimisation, usually by making the code highly multi-threaded or whatever. Given the same "budget" I can usually produce faster, better code, with less pain.

That was all actually slightly off-topic relative to your original gripe regarding insufficient documentation, which is also largely "solved" (as much as it can be, anyway) in Java/C# land: not only do you get vastly better tab-complete, but both systems have standardized embedded doc-comment standards that are indexed for searching in IDEs!

That's great, but my 4K TV only has HDMI inputs, just like every other new TV out there.

Has anyone else noticed that despite the endless 4K resolution marketing being put out there by AMD, there is not a peep on the specific type of HDMI port the card has?

There is a HUGE difference between HDMI 2.0 and 1.4, but it's always specified as just "HDMI" with no version number. No review mentions the HDMI version, even though one would think that a real journalist would put in some effort to research this and find out.

I suppose it's easier to run the card through a bunch of automated benchmarks, cut & paste 15 pages of results to maximise ad impressions, and call it a "review".

The weak point is not with the mathematics. It's like claiming nobody can break into your house because you have a solid steel door, but at the same time you have glass windows.

The weakness in SSL is the trust you have to place in the CA infrastructure, none of which is really that secure. Your browser will trust any valid certificate rooted in a trusted CA. There's no need to crack the keys of the certificates issued by Google. Keys have leaked, CAs have been hacked, intermediate authority certificates are often very weak (512bits), and the NSA could simply issue an order to a US corporation under national security to provide them with whatever key material they desire. The Stuxnet worm is a great real-world example of this happening: its creators used private keys stolen by intelligence agencies to create fake device driver code signing certificates.

Not to mention that it wouldn't be a difficult for an agency with the resources of the NSA or the CIA to simply infiltrate larger IT organisations such as Google and make copies of their private keys. That way they could man-in-the-middle without having to change the certificate fingerprint.

That's all academic anyway, the rumours are that the NSA doesn't have to bother decrypting anything because they have moles inside all large organisations that provide them with the plain text content directly whenever they want. This wouldn't even require that many people. Just by having someone in the top-5 ISPs, Apple, Google, Microsoft, IBM, Oracle, and Amazon you'd basically ensure coverage of the core "cloud" services that most computers connect to on a daily basis.