It's not just button syndrome. Lots of companies continuously fail their users in terms of just being to able to perform basic functionality while marketing themselves as world-changing, good-doing champions for people.<p>Being a developer, I'm one of the main points of contact in my family whenever a relative can't figure out how to do something software-related, and boy has it been a sobering look into the future.<p>I recently helped a relative file for unemployment verification through ID.me, which is a popular identity verification platform. My relative, who is not well off financially, had an old phone that didn't play nicely at all with the ID.me verification flow. I spent an hour trying to get my relative signed up and I never could get it to work. The site was barely mobile-friendly, and the photo upload process kept failing, which was a required step for verification.<p>It was so Orwellian to see this kind of UX on a device that wasn't new (and of course, how is someone on unemployment expected to purchase a new phone?) I truly wonder how many people have starved because they didn't have access to devices that allowed them to collect their unemployment through this platform. It really kept me up that night.
I think it's worth talking about a couple downsides of a search-based interface:<p>Speed: Search-based puts a floor on how fast an interaction can be. "Button Syndrome" interfaces are a slow "hunt and peck" for new users, but experienced users can use them extremely fast, building up muscle memory so they don't even need to consciously think about the action they're taking. Imagine piloting an F35 with a search-based interface.<p>Discoverability: Buttons make it explicit what functionality is offered by the product... somewhat. Users may not know exactly what a button does, but they can make an educated guess based on labeling and context, and it gives them a jumping off point to experiment with it or find it in the documentation. With search-base interfaces, there's no natural way for a user to discover functionality they aren't aware of. Worse, a user may remember a function exists but forget the terminology, flailing in the search box guessing different terms.<p>This is not to say search-based interfaces are bad. There are mitigations to the downsides (the article mentions a few, like search suggestions), plenty of upsides to go along with it, and let's not pretend that button-based interfaces are all sunshine and rainbows. I only mean to say that these are things that should be considered.<p>I think the broader takeaway of the article is: Always be thinking holistically. It's important to consider how your users interact with your product as a whole, not just the individual features. Also important to consider how different users of varying experience with the product and the domain will feel with the UI—Often features for "power users" come at the expense of new users or vice versa.
I loathe "smart" interfaces that want to cram everything into a dynamically-adjusting control panel. Because what the programmer <i>thinks</i> I want to do is so frequently not what I <i>actually</i> want to do.<p>Give me panels that I can open, close, and arrange as I see fit. Let me craft the interface of your complex, featureful program into something that matches what <i>I</i> need most often. Pick a simple set to expose to new users that covers the basics, sure, great idea. But let the skilled user tell the program <i>exactly</i> what sets of knobs they want to have handy.
Author uses aircraft cockpits as an example of "improvement".<p>I've been getting back into DCS recently, and one thing that's struck me with the A-10C (II) is just how incredibly resilient the entire design is.<p>Sure there's a lot of work starting the aircraft and setting up systems etc, and there's an immense learning curve, however you have a staggering amount of redundancy in case of failures, in all levels of the aircraft design.<p>As a consequence, pilots have been able to limp home ridiculously damaged planes, surviving to fight another day and go back to their children.<p>Then there's the F-16. I've only just begun to scratch the surface of this one, the simulation is equally as amazing as the A-10C. This aircraft is likewise very manual, but if something goes wrong the pilot has immediate control; in the F-35 (from what I've read) he would be completely reliant on the glass/ computers working as intended / desired, with a level of complexity that makes Tesla's entire FSD program appear as basic calculus.<p>That's perhaps a big tangent to computing, however I strongly feel that simplifying everything might take away more than you add. The best designs would combine quick, express usage functionality with expert panels for advanced, expert users/usage. This should be combined with a transparency of design that allows their users to understand the underpinnings.
The OP doesn't actually describe what he thinks is wrong.<p>> It isn't just us, here's Office 2003.<p>> [image]<p>> Here it is after the rebuild.<p>> [image that is similar, but on a narrower screen]<p>> To understand why - and to find a solution - the history of software is helpful.<p>Step back. To understand why <i>what</i>? To find a solution to <i>what</i>?
<i>If there were a science of user interaction, its second law could be called the Wide Angle Fallacy. When a disgusted user goes back to the designer saying, “Your system doesn’t perform the special function I need,” the designer’s ego is deeply affected. To regain the good graces of his customer—and to re-establish his self-esteem—the designer is likely to answer, “I can fix it in no time. I will just add another command for you.”</i><p><i>Later, the same man will be seen at conventions, meetings and workshops, extolling the virtues of his system, the “power” of which can be measured by the great number of commands it can execute. I believe this is usually a fallacy and users should recognize it as such.</i><p>— Jacques Vallee, <i>The Network Revolution: Confessions of a Computer Scientist</i> (1982) chapter six, <i>Obfuscatology</i> (<a href="https://books.google.com/books?id=6f8VqnZaPQwC" rel="nofollow">https://books.google.com/books?id=6f8VqnZaPQwC</a>)
I am not so sure that replacing physical fixed function buttons with context sensitive buttons in a fighter is really a good idea.<p>If you look at the Navy, there have been several mishaps that have been blamed on poor electronic controls.<p>In addition, and likely more importantly, a fighter pilot trains for hundreds of hours in their cockpit. They develop muscle memory. Having a button at the same place, with the same feel, that does the same thing, is likely vital when you are engaged with an enemy fighter and don't want any extraneous distractions. Instead, it seems you have the cockpit version of Apple's Touch Bar.
I know this isn't the point of the article but the supposed F16 cockpit in this article is an F15 cockpit. The F16 has a sidestick, mfds and the canopy has no support arch.
But I <i>like</i> buttons. The more, the better. Complexity is more a function of depth than breadth.<p>I don't trust your integrated search feature to understand what I want, and in any event, I rarely feel like playing a game of Zork to get my work done.<p>Please use buttons, clearly labeled in English (if not the user's native language.)<p>Looking at your screenshots, you pretty much had it right the first time.
On my iPhone 6 with safari I’m just seeing an error message:<p>> Application error: a client-side exception has occurred.<p>But from the other comments I get the impression that “button syndrome” has something to do with UX/accessibility. Tad ironic.
A lot of times too many buttons/UI is just lack of design. I can't say if that's the case here as well, but I've seen it many times.<p>Usually well intentioned founders who know what they want to achieve, but fail to understand the subtleties of designing UI's and interaction. Or developers who sometimes lack the viewpoint of a "regular" user.<p>In most cases hiring a good (interaction/ux) designer can solve this pretty quickly.<p>Maybe a bit pretentious but it does kind of state it nicely:
"To complicate is simple to simplify is complicated. Everybody is able to complicate. Only a few can simplify." - Bruno Munari
He missed one of Office’s key innovations - commands-on-selection, which is now available on the web app as well.<p>It reinforces the story even better than the given examples and has been there since Office 2007. The web version just added search-for-command in the right-click menu as well, which is similarly powerful.<p>This seems to be called the “mini toolbar”. Very hard to Google, easier to find through use. It is in Outlook for web now, too. The version in word is more powerful, especially when working with tables.
I think I want to agree with this article, but I found it a little confusing.<p>In particular, I think it's strange to compare the F-16 with the F-35 when the former is regarded to be one of the best fighter jets ever made and the F-35 is infamous for being problematic. My understanding is that they are also different kinds of planes for different purposes, but at any rate, I struggle to focus on UX when there's that contextual elephant in the room.
Interesting article. It looks like the solution you came up with works well for your product which is the most important thing.<p>I see a lot of products these days using more of a hybrid approach. Some of the most basic buttons to get new users used to the product and discovering what it can do. Then adding in a CMD/CTRL + K search menu for when users reach a better understanding of the product and just need to get shit done.<p>There is a fine line between too basic and too advanced (depending on the audience for your product) and a challenging thing for most UXers is balancing new user onboarding against the power users of your product.
A friend of mine has been in software development for over 10 years - possibly closer to 20 but I'm not sure on that point. We chat a few times a month about work stuff, and <i>routinely</i> he will express amazement at being disappointed about something not working 'correctly'.<p>"Well, the documentation says this takes key X, but it doesn't work if I send key X, I have to send Y"<p>"This service seems to break when this JSON comes back down a second time".<p>"I press this button and it shows it being clicked, but it just locks up for 5-10 seconds before finishing the click. That's a really bad user experience. I'm surprised companyX doesn't seem to understand that's confusing to people."<p>And on and on. After... years of these observations, I pushed back a bit with "I'm surprised you continue to be surprised by any of this. You've worked in software for years now. You should probably be surprised that anything works and continues to work."<p>A system continuing to work between various client/browser versions and system upgrades over a period of years, serving multitudes of users, with as little downtime and no data corruption is really... surprising in these modern times. It <i>shouldn't</i> be, but there's so many moving parts, so many players, that long functioning services do surprise me.<p>A recent bank merger meant that two regional banks are merging. A recent mortgage refinance meant that this newly merged bank also bought my mortgage, and I'm supposed to make payments to them. Their system for setting up a mortgage payment is broken. Like.... errors in dev tools console, with relatively obvious root cause as in a field like CustomerId is referenced in another part of some code as CustomerID, and when I try to click X to move forward there's breaking JS code.<p>This was a problem for at least 5 weeks that I know of, but from the little I could see via twitter and forums, weeks before that. There is <i>0</i> way of me contacting anyone who could even understand my issue in the first place, and that's a whole other topic. That they likely didn't have monitoring in place (I couldn't see any obvious tools such as sentry installed) is another story, but... I didn't chose this bank. I don't have a choice in using them (same with regional utility companies, etc).