Started off as a great article. Turned into an endless rant that's entirely ignorant to the idea that maybe what works for you doesn't work for me. My eyes eventually got fatigued from the constant rolling, and I stopped reading at some point.<p>The whole rant ends up boiling down to putting form over function, which I think is backwards relative to good UX. The form should absolutely be dictated by the function.<p>Now, there are a couple points of (what I read from) that rant with which I do agree:<p>1) The insistence upon shoving everything into a hamburger menu is asinine.<p>2) The insistence upon shoving a mobile-first UI paradigm down desktop users' throats in general (an example of which being the previous point) is asinine.<p>2) It makes sense to have a visual distinction between application-level and window-level operations, and to have those operations segregated into their own respective application-level and window-level (e.g. task-level or document-level) menus.<p>Where I <i>strongly</i> disagree is when there's this strange assertion that there should only be one application menu displayed at any given time. That falls flat for several reasons:<p>1) A monitor may have multiple applications visible<p>2) A set of monitors may have multiple applications visible even when each monitor is dedicated to a single application<p>The solution - in my mind, at least - would be to make sure that if an application's windows are visible on a monitor, then the application's menu is visible on the monitor <i>somewhere</i> (and if the application has no visible windows, then feel free to hide the application's menu somewhere out of the way. Whether that menu is attached to each window or to the monitor itself can (and should) be up to the user's preference (I have no objective opinion on a default setting for this, though personally I'd probably prefer these application menus to be in the status bar for the same reasons as the author articulates). Hell, if the user wants to pull a NeXTSTEP and not attach the application menu to <i>anything</i>, then go for it (I probably would <i>not</i> want this as a default, but hey, if you're going for a classic NeXT aesthetic, then you do you). User wants all of the above? Maybe a bit redundant, but if that makes it easier for the user, then why not?<p>This works great no matter the form factor. Larger screens would be more likely to have multiple applications on display at once, and thus would show multiple application menus. Smaller screens would be more likely to have one (or at most two) applications on display at once, and thus would only need to show one or two application menus.<p>In the case of a monitor-level menu, the function here may or may not overlap with a dock or some equivalent interface element. I'd probably combine the two in that case. App launching can be done through a single Activities/Launcher button (with "pinned" and/or running-but-not-currently-visible apps being front and center). Managing running apps can be done through the app's menu, whether the app's visible (and thus would have a visible menu on the monitor's bar) or not (and thus would have a menu hidden somewhere but still readily available, e.g. in a context menu - or hell, an actually-visible menu - on the app's launcher icon).<p>In the case of an application-level menu on each window, I'm envisioning something like the menu Firefox (IIRC) used to have at one point: a button by the window controls (or maybe at the other end) with the application name and/or icon as the label (plus a window-specific title for the window itself). A hamburger menu icon might also make sense here to signify that this is in fact a menu, but that should be in <i>addition</i> to the application title/icon, not as a substitute.<p>In any case, if a window is visible, its application is visible. The user can quickly find the application menu and perform application-level tasks (like opening a new window) without necessarily needing to perform a separate action of switching focus to one of that application's windows (this is a reason why I agree with the author about detaching the app-level menu from the window: much easier/faster to find when it's in a consistent spot).<p>In summary: a hard-to-use interface is poor UX by definition, regardless of how "pretty" or "elegant" or "minimal" it may be. Good interface design means making common things easy while keeping uncommon things at least possible. If the interface is a little cluttered as a result, then so be it.