[HN Gopher] The end of the nice GTK button
___________________________________________________________________
The end of the nice GTK button
Author : MartijnBraam
Score : 831 points
Date : 2022-03-24 21:58 UTC (1 days ago)
(HTM) web link (blog.brixit.nl)
(TXT) w3m dump (blog.brixit.nl)
| imglorp wrote:
| I may be alone here, but maybe there are mountains of
| functionality never tackled in Gnome. Basic things like trackpad
| gestures are just now arriving for example.
|
| Meanwhile, the visual design has been hashed over and over: I've
| lost count. Why is L&F consistently prioritized over basic
| capabilities?
| spiffytech wrote:
| A lot of work in OSS desktop environments is driven by someone
| having a personal interest in building a feature.
|
| I wonder if that plays into in (in addition to the effort
| hurdle mentioned by audidude). I turn off trackpad gestures
| every time I get a new machine - I just don't get any use out
| of them. I can't be the only one. And since Gnome lagged behind
| on gestures, we could presume many Gnome developers either have
| perfectly good gestureless workflows already, or haven't even
| had the opportunity to see what gestures can do.
| cwillu wrote:
| The cascade of attention deficit teenagers is a jwz classic,
| which I won't link directly because... jwz.
| smoldesu wrote:
| > Why is L&F consistently prioritized over basic capabilities?
|
| My lips curl ever so slightly apart, my tongue perched between
| both rows of my teeth. A faint whistling sound escapes between
| my two incisors and tongue, reminiscent of the "th" consonants
| that one might expect to hear in the word "thumbnails". Before
| I'm even capable of getting to the word "filepicker", hundreds
| of people are stepping on one another to come tell me what I
| already know. A wave of developers have risen from their
| standing desks, eager to beat me down for such a blatant
| disrespect of their favorite desktop. Fourty-some people have
| convened to demonstrate how I can click and drag icons from
| Nemo onto a file selection dialog as a replacement. Others yet
| are deriding me for not implementing it myself, and lacking
| respect for the developers. Some people have taken to
| referencing their code of conduct, while more are furiously
| typing on Twitter, desperate to label me a troll and move on
| with their life.
|
| They all filter off after around 25 minutes. None of them used
| that time to put thumbnails in the file picker, thou... oh my
| god, they're coming back again...
| audidude wrote:
| > Basic things like trackpad gestures are just now arriving for
| example.
|
| All they had to do was go fix the input drivers, the user-space
| library to communicate them, the compositors to be able to
| mediate gestures, the toolkits to process them, the X11 server
| extensions, wayland protocols, etc...
|
| One of the biggest problems in this is that you can't just fix
| one input driver. You have to go fix them all so that the
| experience is consistent across as much as hardware as
| possible.
| imglorp wrote:
| Oh yeah, I get it, there's a ton of work there. And I am
| grateful to everyone touching Gnome over the last 2 decades.
| I have even supported the trackpad fellow. I'm just asking
| where the developer attention cycles are being spent.
| zwaps wrote:
| The problem is that UI has reached its pinnacle with Win2k/xp
| classic. So if you are a designer, you still have to do your job,
| you gotta design something. But it is never going to be on that
| level, in efficiency, looks or usability. It's such a nihilistic
| proposition, I can hardly be mad at designers of today. Go ahead,
| make that button flat and call it clever. Why not
| zamalek wrote:
| > Microsoft was stupid for doing it. I think Apple is stupid for
| doing it
|
| Microsoft isn't actually responsible for this nonsense. Metro did
| get rid of bevels, but it didn't get rid of obvious buttons: they
| simply turned into trivial colored rectangles.
|
| I'm not entirely sure who "refined" it, but Microsoft did
| eventually end up copying a bad iteration of their own good idea.
| jms55 wrote:
| A lot of comments in this thread are negative. As a developer
| using GTK4 and libadwaita, and as a user that uses gnome, I
| really like the changes. GTK4 brings some much needed changes,
| and the major bugs like listview scrolling being broken or bad
| text rendering on non-hidpi displays suck, but both have people
| working on fixing them. Libadwaita is a huge improvement, and
| makes it way easier to build good apps.
|
| As for themes, I quite like the new libadwaita theme, and prefer
| it to the default GTK theme. You're free to disagree, but you
| can't say your opinion is correct, nor can I.
|
| Keep in mind that libadwaita is an optional library _specifically
| for gnome apps_. If you don't like gnome, don't use libadwaita.
| If you want the widgets from libadwaita, but don't like the
| styling, then either copy the code (it's open source, fork it!),
| or use libadwaita and disable the libadwaita stylesheet (and add
| styling for the widgets that aren't part of GTK).
| lelanthran wrote:
| > As for themes, I quite like the new libadwaita theme, and
| prefer it to the default GTK theme. You're free to disagree,
| but you can't say your opinion is correct, nor can I.
|
| That's the thing - you _can_ say a particular design decision
| is incorrect. There 's objective metrics around good user
| design.
|
| Taking the position that all design is subjective, and
| therefore "just an opinion" is why the gnome team are widely
| derided.
|
| It's not just an opinion - there's measurements you can make
| and metrics you can collect that serve as evidence for or
| against a particular design.
| ayushnix wrote:
| > or bad text rendering on non-hidpi displays suck, but both
| have people working on fixing them.
|
| It wasn't even acknowledged as a bug in the beginning, even
| after screenshots with clear signs of regression were posted.
| Matthias Clasen closed the bug report saying it wasn't a bug
| but an intended feature. There's really no appropriate words to
| describe such behaviour, which is fairly common on the GNOME
| issue tracker, besides calling it "wilfully dense" or
| "trollish".
|
| > As for themes, I quite like the new libadwaita theme, and
| prefer it to the default GTK theme. You're free to disagree,
| but you can't say your opinion is correct, nor can I.
|
| Sure, but in that case, an officially supported method to
| change the theme should be provided in case I don't agree with
| your choice. Apparently, GNOME tweak tool was never supported,
| is not supported, and will never be supported. For now,
| GTK_THEME is being presented as an alternative but do you
| expect me to close all of my programs and relogin to my session
| to change my theme? Should I create wrapper shell scripts for
| all of my GTK apps?
|
| > Keep in mind that libadwaita is an optional library
| _specifically for gnome apps_. If you don't like gnome, don't
| use libadwaita.
|
| The fact that there are no non-trivial GTK4 apps out there that
| don't use libadwaita or libgranite tells me what I need to
| know. Even LibreOffice uses libadwaita now. Is LibreOffice a
| GNOME app?
| akdor1154 wrote:
| > As for themes, I quite like the new libadwaita theme, and
| prefer it to the default GTK theme. You're free to disagree,
| but you can't say your opinion is correct, nor can I.
|
| I agree... but the gnome devs are directly telling me my
| opinion is incorrect, by removing the ability for me to change
| my apps i use to a theme I like.
|
| Oh wait sorry, i guess i should have said gnome's apps.
| stjohnswarts wrote:
| You have to admit that is more work though, and devs on a
| limited size team like the gnome developers have to draw the
| line at some point.
| [deleted]
| kirbyfan64sos wrote:
| This is an unfortunately very common misconception: you can
| still set GTK_THEME on libadwaita apps, it's only the
| gsettings configuration that doesn't work (due to
| implementation constraints, unfortunately).
| smoldesu wrote:
| I've tried that, and besides it being a highly inconvenient
| workaround, it doesn't work on any of my machines.
| kirbyfan64sos wrote:
| That's...strange, I just had it successfully tested
| yesterday. Are you actually testing with a
| GTK4-compatible theme?
| [deleted]
| SkeuomorphicBee wrote:
| I agree 100% with the author, the old GTK button was gorgeous, it
| will be missed.
|
| > I have had to explain to people tons of times that the random
| word in the UI somewhere in an application is actually a button
| they can press to invoke an action.
|
| This is one of my biggest complaints with the super flat modern
| designs. Many widgets lost their skeuomorphic depth, which
| encoded a lot if visual information (the clickability, the
| current status), but in many cases nothing was added to supplant
| the loss of those visual cues, so now it is just a label (or a
| label in a white or grey box) and there is no way of knowing if
| it is clickable or its current status.
| grishka wrote:
| Borderless buttons to have the right to exist, but you should
| be very careful with their use. For example, take this UI I
| made recently:
| https://mastodon.social/@grishka/107998100334356147, 2nd
| screenshot. The button to decline invitation looks like a link
| (same color) and it's next to a real button. No one would ever
| get confused by this, it's pretty clear it's clickable.
|
| But a black word in a larger font among black text would
| definitely NOT be recognized as a button by most people.
| Context matters a lot.
| amatecha wrote:
| It's not very clear to me it's clickable.. Is it an action,
| or a link to a different page/view? If it's an action
| (accept/decline invite), make it a button. If it's
| navigation, make it a text link. You are giving totally
| disparate cues to the user when the actions taken upon
| clicking are of the exact same type.
|
| My initial reaction to a piece of text directly next to a
| button is "why is there random unrelated text there?" and
| then the sensation of anger as I come to the realization
| someone consciously decided to make me think about the UI
| more than I needed to. It's purely a distraction.
|
| Just make it look like a button. There is literally zero
| reason not to, and you can eliminate the chance of confusion.
| Why increase the possibility of uncertainty at all? What
| value does that provide to anyone?
|
| Every UI or design element that causes me to think about it
| wastes precious moments I could have been thinking about
| something I actually cared about, for example the actual task
| I was in the middle of. On top of that, when you use
| unconventional design, even after someone learns the
| seemingly-arbitrary, specific quirks of the design you've
| used, you will cause them to think about it all again later
| when you redesign the application.
| gsinclair wrote:
| Literally zero reason not to? I think it's emphasising the
| "default" action quite nicely, and de-emphasising the other
| action quite appropriately.
|
| "Decline invitation" needs to be something you can do, of
| course, but it will be used < 1% of the time, I imagine.
|
| I find that having buttons side by side forces me to think
| in a mildly unpleasant way, like I have to read two thinks
| more carefully because there is more onus on me to decide
| which is the typical action.
| michaelmrose wrote:
| The button to decline doesn't add an entity. There are
| already two options to consider whether to accept or
| decline. Making the external state and internal state
| match avoids confusion.
| pessimizer wrote:
| > I think it's emphasising the "default" action quite
| nicely, and de-emphasising the other action quite
| appropriately.
|
| What's the reason that the designer wants to nudge me to
| accept invitations again? I missed it.
|
| Also, what's the difference between that and a dark
| pattern?
| amatecha wrote:
| No, that's still not a reason to conceal the
| behaviour/purpose of the UI element.
|
| If you want to emphasize/de-emphasize a UI element, you
| can do something like was established on most GUIs 30+
| years ago: make the default/safest option have a thicker
| border, and the secondary/de-emphasized option have a
| thin border. Early examples (1985 and 1991 respectively):
|
| https://guidebookgallery.org/pics/gui/settings/appearance
| /wi...
|
| https://guidebookgallery.org/pics/gui/system/features/sea
| rch...
|
| Note how immediately-obvious it is which action is the
| "typical". You don't even have to read the text, you
| could even squint your eyes or glance from a great
| distance and still understand which button is the one you
| probably want.
|
| UI design involves trust, especially for software where
| people are trying to actually get something done. Making
| unconventional designs erodes your users' trust. Have
| respect for them and what you can reasonably expect them
| to "know" arriving at your software, and they will have
| an easier time and love you for it. As we can see, these
| conventions have existed for decades, and deviating from
| them warrants a very compelling reason, not just "cuz it
| looks neat".
| totalkrill wrote:
| Like so many other pointed out, this is wrong, I got
| confused, it looks like a link, would that get me to some
| kind of unsubscribe page? is it phising?
|
| buttons should be actions, links should be directions,
|
| directions would take me somewhere, actions would has an
| effect and consequence. That you think this is okay, and
| assume no-one would ever be confused by this. Is clearly an
| issue in the industry at large
| zozbot234 wrote:
| Perhaps online, but links in a GUI dialog box are often
| actions too.
| AlanYx wrote:
| >No one would ever get confused by this, it's pretty clear
| it's clickable.
|
| It's pretty clear that it's clickable, but I definitely
| wouldn't think it's a button. My best guess would be that
| it's a navigation element, and that clicking on it brings you
| to some other page where a decline invitation button might be
| found, or where you have to fill out some form to explain why
| you're declining.
|
| Part of it is because it looks exactly the same as "Test
| User", and presumably that isn't a button... I imagine that
| _is_ a navigation element. But part of it is also because
| quite a few recent Microsoft corporate products (Sharepoint,
| Dynamics, etc.) seem to use the idiom you 're trying to use
| for signaling that something _isn 't_ a button.
| spoils19 wrote:
| I disagree. I had to sit and think for a few minutes as it
| was extremely unintuitive - my first impressions were that I
| couldn't decline the invitation at all, and the button was
| disabled or missing for some reason (I've seen some bad CSS
| in my career so it no longer surprises me when it goes
| missing).
| sph wrote:
| The button and link next to each other is a common pattern
| that has been used for decades at this point. It's core to
| Google's material design.
|
| I agree that it might not be ideal, but when it is used
| literally everywhere I do not believe it's that hard to
| read.
| amatecha wrote:
| Decades? Any examples of this? Material Design has only
| been around since 2014, so that's not really a good
| example to cite.
| zozbot234 wrote:
| That's an action link, not a button. In a UI context it would
| be rendered in a different color and underlined, to highlight
| it being an active element rather than a simple label.
| swiftcoder wrote:
| > No one would ever get confused by this, it's pretty clear
| it's clickable.
|
| I don't know how you can reach that conclusion, because we
| only recognise it because of how many times we've been fed
| this exact pattern over and over again in flat UIs (and
| failed to realise it was clickable the first N times)
| zestyping wrote:
| It does not look like a button. It's just a label floating
| around.
|
| When designing user interfaces, use the mantra: "Don't make
| me think!" Don't make the user think about whether something
| is a button or not. Don't make them have to infer that the
| label is in fact a button due to context.
|
| Just make it look like a button!
| silon42 wrote:
| Yeah... personally I detest anything flat or rounded...
| give me square pixel sharp corners any-day... and not just
| for buttons.
| ShroudedNight wrote:
| I am but an ignorant user, but making you think to do
| complete one action but not another seems to be a
| significant part of the point. I find it deeply coercive,
| and hope to see the other side of this trend sooner rather
| than later.
| happymellon wrote:
| It's bold, so that helps. I assume you are able to click the
| group name and test user since they are also bold?
|
| I would still prefer a border around the button as I'm not
| sure what you gain by removing it, but at least you provide
| hints.
| ShroudedNight wrote:
| Moving the goalposts, but the decline button in your example
| looks significantly harder to engage than the join button,
| and engaging with it would cause at least a twinge of anxiety
| in anticipation of having to essentially coerce the interface
| to accept that I do not wish to travel the gilded path.
|
| It frustrates me that this sort of design has become not just
| acceptable but celebrated as 'correct', and I long for the
| days when interfaces did their best to seek my enthusiastic
| consent to my chosen course of action.
| ghosty141 wrote:
| I too hate the material design kind of flatness. For me, only
| apple somehow gets UI right (at least for me) and it feels very
| intuitive for me while also looking very good.
|
| The new "flat" design that pops up everywhere sometimes just
| feels like a lazy version of UI design, where you basically
| don't need proper styles anymore and just make everything b/w
| with maybe a border here and there.
| lelanthran wrote:
| > I too hate the material design kind of flatness. For me,
| only apple somehow gets UI right (at least for me) and it
| feels very intuitive for me while also looking very good.
|
| I dunno about that (both Apple using flat, and the "gets it
| right" part).
|
| I'm looking at activity monitor now, under memory pressure,
| and the table of memory types has "Memory used" row expanded,
| and yet none of the rows are actually clickable. I spent a
| few seconds yesterday trying to click the other rows.
|
| Then I looked at system preferences, and it's not actually
| flat widgets - they have relief for those things that can be
| interacted with. Things that are clickable are visually
| marked as such.
| tonyedgecombe wrote:
| >I'm looking at activity monitor now, under memory
| pressure, and the table of memory types has "Memory used"
| row expanded, and yet none of the rows are actually
| clickable. I spent a few seconds yesterday trying to click
| the other rows.
|
| I can see why you might get confused there but it feels
| like nitpicking. I never expected to click on any of those
| elements because they don't look like a traditional table
| or outline view.
| kjeetgill wrote:
| My understanding of material design is that it tries not to
| be _too_ flat. Material design reduces the 3d roundedness and
| gradients of many elements but still relies heavily on drop
| shadows to indicate hierarchy and overlapping.
| nanochad wrote:
| dheera wrote:
| UIs go through 3D and 2D in phases.
|
| Windows 2.0 - 3.1: 2D
|
| Windows 95 - 7: 3D
|
| Windows 8 - 10: 2D
|
| MacOS 6 - 7: 2D
|
| MacOS 8 - 10: 3D
|
| MacOS 11: 2D
|
| As a side point, I predict Sheriff and Sans-Sheriff fonts to
| also go into similar phases too though over a longer time
| scale. We're in a very long Sans-Sheriff phase now but I think
| Sheriff will be "in" in 20 years.
| chrismorgan wrote:
| Recently I've been enjoying serif fonts in more places than I
| used to, because I instructed Firefox not to allow sites to
| override my font choices (so I get _exclusively_ Equity for
| serif, Concourse for sans-serif and Triplicate for
| monospace), which is quite pleasant and relaxing in general
| (Google's foolish /poorly-implemented ligature-based icon
| font technique is the _only_ notable breakage /uglification
| I've found in the couple of weeks I've been doing this), but
| apparently it's more common than I realised for people to
| omit the fallback "sans-serif" or "serif" or "monospace" that
| they should always have on their font-family stacks, and my
| fallback default is serif. (e.g. I'm just now looking at a
| `font-family: 'Lato','Helvetica','Arial';`, and yesterday
| examined a `font-family: some-web-font, Open Sans;`.)
| chipotle_coyote wrote:
| > Equity for serif, Concourse for sans-serif and Triplicate
| for monospace
|
| Are you a lawyer? (There is an in-joke here, I swear)
| chrismorgan wrote:
| No, but Matthew Butterick, who made them, is:
| https://mbtype.com/, https://mbtype.com/bio.html.
| chipotle_coyote wrote:
| Yes, that was the in-joke. :) They're among my favorite
| typefaces (as is his newer Century Supra).
| eternityforest wrote:
| The Serif Sheriff wants you in jail if you use Serif these
| days
| mananaysiempre wrote:
| Raymond Chen commented on the fashion cycle back when Office
| XP started drifting in the flat direction[1].
|
| [1] http://bytepointer.com/resources/old_new_thing/20040728_2
| 91_...
| mceachen wrote:
| FWIW, Macintosh System 6 was just black and white (and only
| 640x480px), so 3D wasn't really tenable.
|
| System 7 and 8 had support for color, and was as 3D as it
| could muster, like highlight and shadow treatment on buttons
| and other widgets, and embossed, draggable thumbs.
|
| https://en.wikipedia.org/wiki/System_7#/media/File:Mac_OS_7..
| ..
|
| Mac OS X brought Aqua, which was a pinnacle of 3D and
| skeuomorphic design. You know you're going hard for 3D when
| you add a drop shadow on all the text in your menubar:
|
| https://en.wikipedia.org/wiki/Mac_OS_X_10.0#/media/File:MacO.
| ..
|
| (and that IE logo in the dock wasn't there as a joke: it
| really was the best browser for OS X until Safari was a
| thing, years later)
| rayiner wrote:
| Those pinstripes.
| RuggedPineapple wrote:
| 512x342 actually, at least for the compact macs with the
| built in screen.
| ejolto wrote:
| Sheriff? I think you mean serif, partner.
| [deleted]
| kQq9oHeAz6wLLS wrote:
| I'm assuming they are a victim of autocorrect, pilgrim.
| nathell wrote:
| In some languages (e.g., Polish), the word for "serif" is
| the same as the one for "sheriff".
| bdefore wrote:
| Deputy. Perfect name for a new Sans-Sheriff typeface.
| cwillu wrote:
| ...there's a new serif in town.
| Stratoscope wrote:
| I think Ken Shirriff would have something to say about
| this.
|
| http://www.righto.com/
| fsiefken wrote:
| Windows 3.0/3.1 buttons are quite 3D, perhaps you meant the
| flat Windows 2.0 buttons?
| http://toastytech.com/guis/win31.html
| https://www.howtogeek.com/674574/windows-3.0-is-30-years-
| old...
| tzot wrote:
| You sansed the serif? What about the DPI-t?
| lwkl wrote:
| Is macOS 11 a lot different than macOS 12?
|
| I'm using macOS 12 right now and there are a lot of 3D
| elements especially if you compare it to Windows 10 or Gnome
| in the screenshots of this post. It seems to be a mix of both
| approaches (similar to GTK 3).
| chipotle_coyote wrote:
| It's not very different. I don't know if "flat" was ever
| the right word to describe the look it started moving
| toward post-Aqua; I think I'd be more inclined to call it
| "minimal", occasionally to a fault. With a few exceptions
| (most notably the bonkers choice to make all keyboard
| shortcuts gray in menus so at first glance they all look
| disabled), though, I mostly like the look that Big Sur's
| ushered in.
| gjvc wrote:
| Mac OS X has been in a Sans-Sheriff phase since Steve Jobs
| died
| capdeck wrote:
| A couple of times i found myself clicking on various text
| labels just to see if it is a title or a button. All these flat
| minimalist designs are a step in a horribly wrong direction.
| hulitu wrote:
| And sometimes a text label hides a menu.
|
| The best i've seen was a web page with a hamburger menu which
| had no action.
| userbinator wrote:
| I've seen all 4 combinations of "looks like" vs "is actually"
| {button,static text} on a web app I was once forced to use.
| Some of the plain text was actually a clickable button (with
| NO hover effect), and some of the "buttons" (or more
| precisely, short actionable text with a rectangle around it)
| were actually just labels. Imagine the word "Order" presented
| in both styles, and my astonishment when I figured out which
| one I actually had to click.
| Schroedingersat wrote:
| But at least they spread out all the unnecessary fluff elements
| and then made the clickable portions tiny and close together
| Pxtl wrote:
| This. The author dumps on ms for going flat, but MS did it with
| rock solid consistency.
|
| I had a win phone 7 device. It was the pinnacle of consistent
| Gui.
|
| Is it colored? Then it's a button. Is it white? It's a Text
| box. Is it a giant title? It's tabbed horizontal scroll.
|
| Are you a "designer" who wants to color something non-
| clickable? Piss off, you don't get to do that.
| Sunspark wrote:
| The flatness of some UIs along with the removal of some visual
| cues has happened that I have tapped on things that aren't
| actually a button thinking that they might be one.
|
| When I make my own apps one day, I am going to ignore design
| fads and only make intuitive interfaces.
| BolexNOLA wrote:
| Just go full-audacity and drown people in drop down menus lol
| at least I know what to click!
| WesolyKubeczek wrote:
| Audacity is a piece that made me learn its hotkeys. Once
| you do that, it's pretty nice actually.
| znowcone wrote:
| It works, I guess. But after I've worked with a proper
| DAW (Reaper in my case), Audacity felt like a toy
| BolexNOLA wrote:
| A toy with the best noise cancellation tool of any audio
| program out there though.
| calvinmorrison wrote:
| we started using Full Story at work. It tracks clicks on non
| clickable items. It is staggering that this is even a
| problem. Having to explain to people that links and buttons
| and radio boxes and checkboxes should look uniform has gone
| the way of the dodo and now we must instead have people
| clicking random items to hope something happens.
| totalkrill wrote:
| > It tracks clicks on non clickable items
|
| This rattled my brain, that this is a feature now, says
| volumes about the quality decline in UI. I am a developer,
| and mainly use tools on the command line, or with TUIs.
|
| But whenever I use android apps and websites, I constantly
| find myself longclicking or rightclicking things, hoping
| for stuff to happen, that just doesnt.
| cout wrote:
| If you really want to go against the grain, may I suggest
| radial menus, which allow the user to muscle-memory through
| menu selections:
|
| https://bindpose.com/custom-marking-menu-maya-python/
| RedShift1 wrote:
| Visually nice but it's almost always going to overlap the
| thing you've right clicked. Under any circumstance I still
| want to see the thing I've right clicked.
| userbinator wrote:
| Interesting concept, but I would add keyboard shortcuts
| (underlined items) to the menu to make it more of a
| reminder than be forced to use the mouse all the time.
| smegger001 wrote:
| That was originally part of the IBM Common User Access
| style guide 80/90s, back when user interfaces for
| software valued function over form.
|
| https://ia800200.us.archive.org/0/items/ibmsj2703E/ibmsj2
| 703...
|
| the figure on page 2 shows exactly what you are
| describing.
| account42 wrote:
| This and many variants of the idea has been explored in
| games a lot - in particular in point and click adventures
| and isometric (or at least top-down view) RPGs. Probably
| also in strategy games and anything else that has both a
| cursor and context-specific actions.
| sph wrote:
| Fly-Pie, a radial menu for GNOME:
| https://github.com/Schneegans/Fly-Pie
| HeckFeck wrote:
| I'm also really not sold on those new "tabs" which are just
| text with an underlined colour. It's low effort and dreadfully
| unclear. I can only vaguely guess what they are based on their
| upper placement, but what's to really distinguish that from a
| menu? or just a descriptive label?
|
| I don't like saying this because I want Linux desktop apps to
| have every success, but these small and pointless frustrations
| kill my enthusiasm.
| adhesive_wombat wrote:
| I spend far too long in GTK apps looking for the right menu to
| do basic stuff. It's like someone once saw an iPad from across
| a room and tried to implement what they remembered of it.
| berkes wrote:
| This is really not the best place to throw condescending
| anecdotes around to insult FLOSS.
|
| What, on an iPad, should a designer look at in detail to
| improve the GTK app, for example?
| michaelmrose wrote:
| The first step is them realizing they have a problem.
| adhesive_wombat wrote:
| Where did I say GTK _should_ follow iOS? All I said was
| that it looks like they did, and did it badly.
| eptcyka wrote:
| Funny, I usually have the same opinion of iOS user
| interfaces.
| [deleted]
| hackmiester wrote:
| You would benefit from the "Button Shapes" option in
| accessibility! It underlines or outlines text-only
| "buttons."
| librarylinux wrote:
| silisili wrote:
| 100% agreed. I want buttons to, at minimum, indicate that my
| click or touch was successful. Even a little wiggle. Flat
| design has me wondering with no visual indication, and I hit
| this all the time.
| adhesive_wombat wrote:
| Misuse (or no use) of affordances is so, so annoying, both in
| software and real life.
|
| Things like having pull handles on both sides of a door that
| has to be pushed from one side. Or having no push plate on
| either side of a glass door. Do I push? Is it a sliding door
| that's not working? Don't know!
|
| My car has the climate controls hidden behind a graphic of the
| current state on the stupid touch screen. It used to be buttons
| that had three zones for head, body and feet, a wheel for fan
| and a wheel for temp[1]. Volvo used to pride themselves on
| having controls you could use with gloves on, so all the
| buttons had 3D features and a positive press feel.
|
| Now it's not even obvious the graphic is a button at all (it's
| also incredibly dangerous as you cannot do anything without a
| multi-click modal process with only visual feedback that you
| have to look at to use). Thankfully the window demister is
| still a physical button because that would be _incredibly_
| dangerous to hide behind a soft screen interface: when you need
| it you need it. However, it 's lost its 3D profile and is now
| just a flat button.
|
| My office has an amusing one: there's a door at each end of the
| building. The building is the same on both sides, neither side
| looks more "fronty" than the other, and the doors are the same.
| Only one of these is the main entrance. The door next to the
| car park (i.e. where anyone unfamiliar with the site will
| arrive) is not the main door. Therefore there are no call
| buttons. However, there's also no indication that there is
| another door on the other side. A whole building basically has
| no obvious start menu. Just...why do that?
|
| [1] https://bparts-eu.s3-eu-
| west-1.amazonaws.com/ftp/azor_2/000/...
| baybal2 wrote:
| chillfox wrote:
| Had that experience before where I spent ages looking for how
| to do something and what I had tough was a label was actually a
| button.
|
| Now if I can't find anything then I just start clicking on
| random design elements in case they turn out to be a secret
| button to a hidden page.
| RachelF wrote:
| > I have had to explain to people tons of times that the random
| word in the UI somewhere in an application is actually a button
| they can press to invoke an action.
|
| Exactly this. I often help others use computers and phones. In
| the old days it was easy to see what could be clicked. Now
| input and output look the same. It makes it harder to use.
|
| In many ways it is a victory of style over substance - UI's are
| now designed by the same crowd who designs high fashion, that
| is clothes not designed to be worn but to be gawked at.
| grishka wrote:
| Yeah I keep saying that modern UIs are designed to be looked
| at and enjoyed like museum art pieces, not to be actually
| used. They look nice-ish when static, but they're unbearable
| in real use.
| hulitu wrote:
| > In many ways it is a victory of style over substance
|
| Or as Statler and Waldorf would have put it: it is a victory
| of care over matter - we ( developers) don't care and you (
| users) don't matter.
| notatoad wrote:
| i don't think flat design is really a question of style over
| substance. flat design has been popularized because designers
| like it, but designers like it because it's easy.
|
| a flat element can be re-coloured without having to worry
| you've gotten the shadows correct on the new color. you can
| put two buttons beside each other without worrying that one
| appears to have more depth than the other. we make things
| flat because we're lazy, not because we think it looks good.
| a culture of lazy designers has convinced people it looks
| good, so we can continue being lazy.
| bobthechef wrote:
| > In many ways it is a victory of style over substance - UI's
| are now designed by the same crowd who designs high fashion,
| that is clothes not designed to be worn but to be gawked at.
|
| Is it? Style is no style at all if the thing in question does
| not fulfill its function. The whole point of something
| stylish is that it accomplishes its end so well and respects
| the appropriate constraints that is pleases the intellect
| when it recognizes this perfection.
|
| So if someone is designing a UI that is difficult to use,
| that is a failure of both style and substance since there is
| no style without substance.
| JasonFruit wrote:
| Fine, a _Pyrrhic_ victory of style over substance.
| HstryrsrBttn wrote:
| lenkite wrote:
| We probably need to start _paying_ UI folks NOT to change
| stuff. They can do all their flat-experimenting in custom
| themes.
| berkes wrote:
| In the case of the article, that is somewhat unfair.
|
| > GTK4 has been in development for a bit and has improved a
| lot of the internals. One of the great upsides is that it
| can take more advantage of the GPU when rendering the UI.
|
| So there was a clear need to rewrite parts to fix
| internals.
|
| > The Adwaita theme has also been nicely carried over and
| looks very similar to the GTK3 counterpart. ... > When I
| want to make a gtk4 application for mobile I would need
| libhandy, but libhandy for gtk4 is not a thing. The
| "solution" is libadwaita. This provides the widgets I need
| but it comes with the downside of having some of the worst
| decisions in application theming.
|
| So, there we have it: it's not "UI folks just changing
| stuff", its a ground-up rebuild of a UI-language.
|
| Now, whether or not that ground-up should be flat, modern,
| or just copy the old, is another discussion.
| dspillett wrote:
| The one that irritates me these days is working out at a
| glance what has input focus. Window borders are so thin, and
| the difference between focused and not minimal, app have
| custom chrome so while titlebars are a good indicator
| sometimes often they are not, or are just two subtle, etc. MS
| Office apps are an offender here.
|
| An example taken right now with Firefox under Windows: https:
| //daveflix.deeohhtee.enneeetee.net/stuff/tmp/FocusNotO...
|
| Which of those has focus? There is actually a difference (and
| to take the screenshot they overlapped making it obvious that
| way) but it is subtle. Try spotting it reliably when they are
| on different monitors.
|
| At some point it'll annoy me enough that I'll write a util to
| scan for the current window that is top of the stack and draw
| a bright green border (or otherwise unmissable clue) around
| it... It'll look ugly, but I'll darn well know where what I'm
| about to type will go!
| chefandy wrote:
| > In many ways it is a victory of style over substance - UI's
| are now designed by the same crowd who designs high fashion,
| that is clothes not designed to be worn but to be gawked at.
|
| Oh? Where do the Gnome designers list their runway
| appearances on their site? https://wiki.gnome.org/Design/
|
| I'm an art-school educated designer, decade+ full-time web
| developer for over a decade and regular FOSS contributor for
| about as long, and regular FOSS users since the late 90s.
| Like most other designer/developers I know-- there are way
| more than you think-- I contribute code regularly but _never_
| design work. Why? Because it 's a sucky experience.
|
| Most FOSS UIs are akin to someone's first website made from
| cargo-culted code from free tutorials. Fixing it is harder
| than starting from scratch and either approach takes
| significant intellectual work before even seriously proposing
| changes... and those proposals are received with something on
| a spectrum of suspicion to outright hostility.
|
| Would you contribute code to a project run by people with no
| coding experience but were extremely opinionated about code,
| bikeshedded and poopooed all code changes as a matter of
| course AND referred to developers and their work with the
| same glib contempt you and so many other developers here
| displayed in your comments? Gosh I hope not.
|
| I often hear FOSS developers lament lack of designer
| involvement, but won't even entertain the prospect of having
| any culpability for that. I mean, come on.
|
| UI design as a discipline fundamentally assumes the person
| designing the interface doesn't intuitively understand what's
| better or what's worse-- they should investigate, check, and
| confirm their strategies. The problems you see in UIs are
| because the people running the projects _Solicited the wrong
| kind of designers_ or let people without subject matter
| expertise trampler on some core features of the design.
| FeepingCreature wrote:
| > UI designer proposing changes is received with hostility
|
| > solicited the wrong kind of designers
|
| This points to me that the root problem is that we _can 't
| tell what kind is the wrong kind._ It's a trust issue, but
| also a competence legibility issue.
|
| That said-
|
| > referred to developers and their work with the same glib
| contempt
|
| Uh yeah? Developers absolutely refer to developers with
| glib contempt.
| chefandy wrote:
| > can't tell what kind is the wrong kind
|
| To some extent you can tell from their title and previous
| work, just like with developers. Foe example, I had an
| entirely non-technical boss that understood I might not
| be the guy to re-write some printer drivers because I was
| a web developer. He didn't know the specifics, but being
| in charge, knew he had to ask someone who did, or do
| enough research to figure it out.
|
| Likewise, UI designers will specialize in designing UIs
| and be better at making buttons look like buttons than
| Graphic Designers, and Experience Designers will be
| better at integrating user feedback and research into
| projects. Just like you wouldn't trust any one developer
| to implement critical functionality you don't understand
| without outside input, you probably shouldn't rely on one
| designer to that either. If you maintain a project,
| though, you can't expect designers to instinctually work
| around what you don't know. Being in charge means that
| you're in charge of figuring out how to evaluate it. I'm
| positive that a "I'm not sure how to interface with this
| sort of thing. Let's work through it so I can figure it
| out." will be received kindly by people you should
| consider working with. Good design proposals should
| already come with explanation and justification to help
| you down the path
|
| This is a random selection from a google image search of
| proposal ideas. It was from another post where I was
| talking about higher-level topics but the principle is
| the same. Changing a set of control widgets should
| require no less thought and explanation.
|
| https://github.com/openstreetmap/iD/issues/759
| https://github.com/stashapp/stash/issues/1549
| https://github.com/newrelic/nr1-groundskeeper/issues/3 ht
| tps://github.com/creativecommons/creativecommons.github.i
| o... https://github.com/godotengine/godot-
| proposals/issues/1823
|
| > Developers absolutely refer to developers with glib
| contempt.
|
| ok-- now copy and paste the rest of what I wrote. An
| overly opinionated, defensive person with veto powers
| that understands the purpose and value of your work is
| fundamentally different.
| xg15 wrote:
| > _UI design as a discipline fundamentally assumes the
| person designing the interface doesn 't intuitively
| understand what's better or what's worse-- they should
| investigate, check, and confirm their strategies._
|
| As a developer who always had an interest in UI design but
| has zero formal education in the field, I be really
| interested to know more about this. Could you maybe explain
| some of those strategies?
|
| My subjective impression is that design has shifted from
| building a consistent "language" to a more goal-driven and
| data-driven approach today. The product owner defines a
| list of user stories and UI is primarily concerned with
| making those user stories as frictionless as possible -
| even if this means a less consistent overall design snd
| even if it means that less common features become harder to
| use. Performance is measured in a feedback loop through
| telemetry and A/B tests.
|
| I might be wrong though, so I'd be interested in a
| qualified opinion.
|
| (Also disclaimer: I grew up with Windows 98, ME/2000 and
| XP. So I guess this is my "good old times" spot then, where
| I'm wearing the rose-coloured glasses.)
| chefandy wrote:
| Yay! UI design is cool. I really love helping people
| solve their problems with software and often find the
| intellectual work involved with crafting their
| interactions to be far more interesting than getting the
| best algorithm for something, implementing the most
| reliable architecture, etc.
|
| What I believe you're noticing is the the adoption of
| ideas under the (poorly named, IMO) UX umbrella. UI
| design is either considered part of it, or close enough
| to get the UX/UI slash treatment. It's not quite there as
| an idea-- people can't decide if UX people are the same
| or UX Researchers are different than UX Designers or if
| UX Designers just do wireframes and user flows or also
| design UIs or if that's left to Interaction designers,
| blah blah blah. The base ideas seem to be an amalgam of
| human factors engineering, graphic/media design
| communication theories, and quantitative marketing type
| work.
|
| While there are hundreds of trillions of articles on the
| topic by people thirsty for medium claps, I think the
| most interesting jumping-off point might be an image
| search for _ux design process_ and using the charts you
| see to guide an exploration. The Nielsen Norman group has
| a TON of stuff online about the topic. Not just design
| itself, but measuring the maturity of usability
| organizations, research techniques, best practices and
| data strategies... I mean all kinds of stuff.
|
| I think a lot of the ideas are tremendously valuable but
| much of what's written about it feels a little bit too
| much like marketing material. The ideas are presented a
| bit too confidently considering how often they change,
| and too much has that LinkedIN magic bullet kind of vibe.
| Also, like tech, the industry is subject to spike trends
| (like tech saw with NoSQL databases) and pendulum swings
| (like centralization vs. decentralization of services,
| thin vs thick clients, etc.) For something a bit more
| structured, the former Lynda.com, now LinkedIn Learning
| has some really fantastic educational resources on modern
| design of nearly any stripe.
|
| I'll swing back through if I can think of any specific
| resources worth checking out.
| sime2009 wrote:
| The complaint about flat design isn't levelled only at
| FOSS, but at the whole industry. Your points may explain
| the situation in FOSS, but it doesn't explain the poor work
| being put out by the thousands of designers and UI/UX
| people working as professionals in industry.
|
| The failings of flat design are _everywhere_.
| chefandy wrote:
| First, I was addressing design in FOSS because:
|
| a) there probably aren't many lead designers, creative
| directors and art directors on this developer-centric
| site b) interface choices for most commercial products
| are deliberately made by other people c) interface
| choices for most FOSS projects _are_ made by developers
|
| Second, I didn't directly address the criticism for the
| same reason I don't go into game forums and argue with
| the inevitable teen tech wizard lobbing glib,
| unsubstantiated technical criticism at the "stupid devs."
| Their peers might believe their saying that a
| "microservices architecture" caused low frame rates in
| the last release, but professional developers will roll
| their eyes hard enough to sprain an eyelid.
|
| I won't waste my time with a point-by-point teardown, but
| if you're actually interested, here's the first half
| dozen unsubstantiated assumptions I've seen here about
| design/designers and the design process:
|
| - 'Flat designs' are uniform enough to judge their value
| as a unit. - A bad flat design was bad because it was
| flat-- not the hundreds of other problems a design can
| have. - Designers change things solely to suit their
| taste or follow trends - Designers don't commonly test or
| measure usability with quantifiable, auditable data - Bad
| usability is acceptable if it looks good. - How well you
| parse something is representative of how everybody else
| does regardless of their culture, age, experience with
| other objects, experience with computers, vision,
| disabilities, etc. - Skeuomorphism was the most effective
| form to convey those visual cues.
|
| aaaand the list goes on. It's _fine_ that many developers
| don 't totally understand how design works because nobody
| expects you to be a subject matter expert in anything
| other than development. That said, confidently making
| sweeping judgements about design and designers when you
| don't understand some important fundamentals is just bad
| form.
| berkes wrote:
| I'd go as far as to say that these failings started in
| proprietary software, hyped, marketed and then copied by
| FLOSS.
| ansible wrote:
| Part of me wants to throw up my hands in the air and cry
| out "Why, God, why?" when I encounter yet another UI with
| flat design.
|
| It is like a mass delusion or something that some segment
| of the population seems to think it that flat design is
| actually useful for the everyday user.
|
| We've seen other stupid useless crap spread like a wave
| across our industry, across our society... so I guess I
| shouldn't be surprised. Though I've started to question
| my own sanity.
| brimble wrote:
| Modern UI design is optimized for screenshots in a
| PowerPoint, and from there, to screenshots in a portfolio
| and on marketing pages where the audience that needs to
| be satisfied is marketing themselves, and especially
| people very concerned that every piece of everything be
| "on brand" and who are entirely sure this matters a ton
| for making sales.
|
| That's what's going on, as far as I can tell.
| thawaya3113 wrote:
| I like some parts of the flat design. The lists being flattened
| out (even without borders) looks immeasurably better, IMO.
|
| However, buttons should have still remained buttons. I don't
| understand why buttons need to look like Labels.
|
| This is disappointing and I hope the Gnome folks revisit this
| decision with the next iteration of libadwaita.
| Aeolun wrote:
| Is it that hard to make a legacy theme for libhandy/GTK4?
|
| Edit: Elsewhere in this thread it is implied that it was
| deliberately made impossible.
| kirbyfan64sos wrote:
| Posted in another comment:
|
| > This is an unfortunately very common misconception: you can
| still set GTK_THEME on libadwaita apps, it's only the gsettings
| configuration that doesn't work (due to implementation
| constraints, unfortunately).
| dheera wrote:
| UIs go through 3D and 2D in phases.
|
| Windows 2.0 - 3.1: 2D
|
| Windows 95 - 7: 3D
|
| Windows 8 - 10: 2D
|
| MacOS 6 - 7: 2D
|
| MacOS 8 - 10: 3D
|
| MacOS 11: 2D
| myl wrote:
| Going flat seems a bit late. Apple are in some places
| backtracking and (although slowly) going back to some form of 3D.
| Have a look at the logic UI evolution. 10.4 was flat, 10.5 partly
| undoes the madness.
| patientplatypus wrote:
| Flow wrote:
| I really miss a consistent user experience. A core idea that I as
| a user can rely on to predict how a new app will work. I was in
| awe when I discovered as a kid that user interface were a
| research area. Things like Fitt's Law and so on. It was not just
| opinion.
|
| Today I get the feeling it's mostly just opinion. Either the
| designer's opinion or the wish to copy the look of something.
|
| Whenever I see a hamburger menu I silently think "Here someone
| has given up".
|
| And there are a lot of behaviors that are not functioning well.
|
| Is something a button? Should I click it or double-click it? How
| about long-press on it? How can I know when there's no visual
| clues?
|
| Things like "Hide cursor while typing" in Windows. It has not
| worked properly for decades and today only work in some super old
| apps like Notepad.
|
| Another thing is type-ahead. I remember in classic MacOS, people
| pressed shortcuts and started to type the filename or whatever.
| It was all perfectly recorded and replayed. In modern Windows,
| press Win-key and start to type, oops, it missed the first
| keypresses, presented the completely wrong results and made a
| mess of your workflow.
|
| I feel confused and disrespected as a user every day and I've
| been using WIMP graphical user interfaces since 1986. Sure,
| computers do more today, but there's less consideration of almost
| everything.
| nojs wrote:
| > Whenever I see a hamburger menu I silently think "Here
| someone has given up"
|
| Can you explain what you don't like about hamburger menus?
| jug wrote:
| Isn't it because it's the "Misc" counterpart to the
| preferences tabs?
| eitland wrote:
| It is just a menu.
|
| But instead of being an ordinary honest menu where half the
| items has their defined places on each OS and the rest can be
| found easily it is a jumbled mess.
|
| And since there are no standards as for where to put things
| in a hamburger menu they can move around between each release
| of the application.
|
| And the only reason to use it instead of an honest menu is
| because Chrome does it so therefore it must be a good idea.
| Period.
|
| It is somewhat ironic that even as desktop screens get larger
| and larger applications has to "maximize real screen estate"
| by removing menus, while simultaneously working to remove
| real screen space improvements like the option of Tree Style
| Tabs on Firefox (yes, it kind of works and it is still
| awesome but it get harder and harder by the year).
| toxik wrote:
| It is the "etc" of UI design. It's a cop out most of the
| time.
| happymellon wrote:
| Is a dumpster of features, you have no idea what you'll find
| in there.
|
| Has someone hidden the zoom buttons in there? How about
| print? Perhaps that's also where save is, or tab colour? Most
| things in the hamburger menu are completely unrelated but
| exist for the removal of context. Button outlines so you have
| no idea what you can and cannot click on as well, which is
| mentioned in the fine article, are all modern design
| patterns. Looks over functionality.
|
| Hamburger menu is just peak modern menus. Lazy.
| ratww wrote:
| _> Is a dumpster of features, you have no idea what you 'll
| find in there._
|
| I feel the same way about notifications. Both native
| notifications and notifications via e-mail.
|
| It is no longer easy to find out if something changed or
| happened in most websites/applications. You must be
| bombarded with notifications all the time, and god forbid
| you take an extended break or something goes into your spam
| folder, because if you snooze you lose.
|
| JIRA for me is the worst in this regard.
| gigaflop wrote:
| One of the first things I do with a fresh work inbox is
| set rules to push things into non-default folders. And
| then, I proceed to never look at them unless I'm digging
| for something.
|
| 61 unread notifications from Az Devops? Nah, I don't
| _need_ to read those. I was watching that build in the
| background, I _know_ it failed.
|
| Mobile notifications should offer more filtering options
| at the system level. Why do I need to trust an app
| developer to respect my notification preferences? Why
| should I rely on the developer to build granularity into
| their push notification frequency?
|
| It all gets simpler when you can filter at the 'inbox'.
| rezonant wrote:
| So on desktop applications, I assume you prefer all your
| functions to be on toolbars, and you have similar disdain
| whenever you encounter a File menu? I guess if there's a
| lot of functions, you probably need some tabs on your
| toolbar- so the Office Ribbon interface is idyllic I
| assume?
| samtheDamned wrote:
| The ribbon menu was actually a step in the right
| direction for desktop only UI paradigm
| eqvinox wrote:
| The difference between a file menu and an hamburger icon
| is that the file menu hides file operations while the
| hamburger icon hides... anything. something. dead bodies.
| rezonant wrote:
| Almost every desktop application has a File menu whether
| or not it deals with files. The File menu has an "Exit"
| item. Does it Exit the File? OBS has "Always on Top" as
| an option within "File".
|
| Or we can look at it from the other side. "Where do I
| find the settings for this app?". Is it in File, Edit,
| View, Tools or Help. The answer depends on the app. Menus
| can be well organized or poorly organized but I don't
| think we should be banishing menus. The hamburger icon is
| just an iconic, space efficient way to say "menu"
| hulitu wrote:
| > The File menu has an "Exit" item. Does it Exit the
| File?
|
| Does it ? This is the issue when people see no more as
| their own OS.
|
| In the past, just like today, there were multiple modes
| to exit a program. One of them is to press Exit and the
| programm will exit cleanly. The other is to press the X
| in the window corner in Windows ( or send a close message
| from a window manager) which, depending on the
| implementation, might lose data. There is also the option
| to kill the process. Now in my opinion this Exit is a
| good thing and it is clear what is doing.
| thesuitonym wrote:
| This is a problem of poor app design, not the stunning
| indictment of traditional menus that you seem to think it
| is.
|
| A poor menu layout can be fixed. A hamburger menu will
| always be a byzantine mix of everything because
| everything has to be in there. There is no organization,
| except flyout menus--which were a problem with
| traditional menu designs, but you could organize without
| them.
|
| Hell, some applications have just moved the traditional
| menu behind the hamburger. Why? Because that was a good
| way to organize operations, even if it wasn't perfect, or
| wasn't always perfectly implemented.
| danieldk wrote:
| On macOS, both the _Quit_ and _Preferences_ items are
| consistently in the application menu (the menu left of
| "File" that has the name of the application). And the
| shortcuts are consistently Cmd + q and Cmd + ,
|
| Well, unless it's an Electron app. Which is another good
| reason to avoid them altogether.
| heisenzombie wrote:
| There are guidelines for what should be in menu bars,
| what order the items should be in, and how they should
| behave for different sorts of application.
|
| For example, on Mac:
| https://developer.apple.com/design/human-interface-
| guideline...
|
| And on Windows: https://docs.microsoft.com/en-
| us/windows/win32/uxguide/cmd-m...
|
| > "Where do I find the settings for this app?". Is it in
| File, Edit, View, Tools or Help?
|
| On Mac, it should be in the "App" menu and called
| "Preferences...", it should be the first item in the
| menu, except if you have an "About YourAppName" item
| which always goes at the top with a seperator underneath.
|
| On Windows, it should be in the "Tools" menu, and called
| "Options...". 4 On Linux, it should be under the "Edit"
| menu, and called "Preferences".
|
| If it's not, then the app (in my opinion) is broken. Of
| course, many apps are lazily ported across platforms or
| "hamburgerized". The Windows situation is obviously also
| more messy because of the newer "ribbon" standards
| complicating things a bit, but there _are_ right answers.
|
| (edit: fixed links)
| rezonant wrote:
| Of course there are ancient, rarely updated guidelines
| that almost all applications ignore. Microsoft indeed has
| that great guide, and yet their own applications
| implement it inconsistently, and often incorrectly
| according to the guidelines. Apple is a tad bit better,
| but third party apps rarely get it right. The best thing
| Apple has going for it is specifically on the question of
| where Settings is: there is a dedicated app menu, so it
| just makes logical sense to put Settings there. Or was it
| Preferences? Options.
|
| > On Linux, it should be under the "Edit" menu, and
| called "Preferences".
|
| This one is a stretch, there are no such consistent and
| agreed-upon guidelines.
|
| My point here is that just because things can be abused
| (or even, in the case of desktop applications, are almost
| _always_ abused), doesn't mean the general concept is
| useless or should be removed from applications. I would
| recommend instead of trying to cram a hundred possible
| actions into a tiny icon bar at the bottom of your
| iPhone, or removing 97 of those actions from the app
| itself and leaving just the most basic three down there,
| to maybe consider building a sensible and well-arranged
| menu layout _if and when_ you need more than those three
| that you can fit at the bottom.
| dmitriid wrote:
| > Of course there are ancient, rarely updated guidelines
|
| You mean well researched guidelines with tons of evidence
| behind their decisions [1] that are as relevant today as
| they were 20 years ago.
|
| > almost all applications ignore.
|
| That most current applications ignore because people
| think they are ancient rarely updated guidelines.
|
| This is especially evident in the MacOS world. HIG were
| _the_ guide on the platform, and developers tried to
| adhere to them. And then the new breed of "designers"
| took over and even Apple breaks nearly every single one
| of them [2]
|
| Microsoft has always been worse when it came to enforcing
| consistency of user interfaces, but even their choices
| were never random until quite recently [3].
|
| [1] Apple's original HIG even had a bibliography section
| because it was actual research, and not some Dribble
| showcase: https://twitter.com/andy_matuschak/status/14474
| 0917559669965... and https://twitter.com/andy_matuschak/s
| tatus/144771024771228057... etc.
|
| [2] See, e.g. their abomination of an App Store
| https://grumpy.website/post/0RsaxCu3P
|
| [3] Even the ribbon menus they introduced in Office
| weren't a random choice. They surely are now. See the Why
| the UI blog series: https://web.archive.org/web/200803161
| 01025/http://blogs.msdn...
| RMPR wrote:
| > For example, on Mac:
| https://developer.apple.com/design/human-interface-
| guideline...
|
| > And on Windows: https://docs.microsoft.com/en-
| us/windows/win32/uxguide/cmd-m...
|
| Both links return 404.
| rezonant wrote:
| Somehow that feels about right.
| cornel_io wrote:
| Wait, there's a _standard_ for ribbon menus??? I thought
| that was just a horrible failed experiment that drove a
| huge number of people away from the MS suite towards
| Google Docs and was abandoned...
| dmitriid wrote:
| Originally it was a well-researched and executed concept,
| see https://web.archive.org/web/20080316101025/http://blo
| gs.msdn...
|
| _Nowadays_ it 's just a random hodge-podge no one knows
| how to use properly.
| [deleted]
| eloisius wrote:
| Yep. It's the miscellaneous everything bucket. It also
| seems to only be motivated by either scarce screen real
| estate (it first showed up in mobile interfaces), or
| graphic designers who think everything is "clutter" and by
| sweeping it away into the hamburger menu they can have
| their beautiful screenshot-worthy interface. I have a 27"
| monitor, but tons of websites and even Firefox itself hide
| half the functionality behind a hamburger.
| prox wrote:
| Originally the top menu was to have a way to access to
| all functions. Many still do (say LibreOffice)
|
| The hamburger is kind of a weird breed of design
| signaling because of it. In some desktop apps it still is
| the original top menu, but not always. On websites and
| apps it can vary tremendously.
|
| However, a top menu is not an expert level mode, it's a
| beginners / proficient level mode. Expert level means
| using keyboard shortcuts.
|
| Context driven display and modes are far more valuable
| when meeting spacial constraints. But that can be hard
| when you are dealing with many form factors and so the
| quick fix is the hamburger.
| hulitu wrote:
| > Expert level means using keyboard shortcuts.
|
| This is true when you use only an editor and a debugger.
| When you need to use 10 programs each with its own
| keyboard shorcuts (which, BTW you need to search in
| internet which they are because the company doing the
| software did not bother to make them accessible in a help
| menu) you're gonna have a hard time. In the (1985) past
| you had for such things a holder attached to your
| keyboard where you had a listing of those keyboard
| shortcuts. Now the world has evolved and we have ...
| tada... the hamburger menu. P.S. I would not feel good as
| a developer to know that someone , somewhere curses me
| and my family constantly for the work i done.
| danieldk wrote:
| _which, BTW you need to search in internet which they are
| because the company doing the software did not bother to
| make them accessible in a help menu_
|
| At least on macOS and Windows the shortcuts are shown in
| the (traditional) menu bar. With GNOME's use of
| hamburgers, it's anyone's guess. As someone who likes
| shortcuts, I found it very hard to figure out shortcuts
| in GNOME apps that have a lot of functionality hidden
| away. (Aside from keyboard shortcuts not being very
| consistent between apps on Linux.)
| hulitu wrote:
| In Excel 365 pressing ALT shows the shortcut key in the
| ribbon ( if enabled in options). The issue is that the
| ribbon looks now like google maps. In Edge pressing ALT
| sets the focus to the "...". What to do next is left as
| an exercise for the reader. In Teams, pressing ALT does
| nothing and the Help button has only "Themes", "News" and
| "Training" .
| nojs wrote:
| I see what you mean. Brave on desktop comes to mind as an
| offender.
| lelanthran wrote:
| > And there are a lot of behaviors that are not functioning
| well.
|
| The worst of which are dropdowns, lists or menus that inserts
| new items right over where your mouse is so that you
| accidentally click on the wrong thing.
|
| All browsers do this for the dropdown that appears when typing
| in the URL bar. I type a few letters, see the site I want is 3
| down in the dropdown, hit the down arrow three times and press
| enter, only to find that the item changed as I was hitting the
| down arrow.
|
| And don't get me started on user elements that have a new
| position in the menu system for every release, if they even
| have a decent menu system.
| mjevans wrote:
| That is the worst thing. Updating a UI while the user is
| interacting with it.
|
| Everything that reaches the screen should remain FIXED in
| place unless moved //by the user//.
|
| This might happen E.G. because something was loading and now
| gets a resize event; so some list suddenly changes the
| position of everything rather than force the user to click
| something else to resize the misbehaving entry. (Scrolling
| could also do this, if it's based on a distinct UI element
| that is not 'activate the list'.)
|
| I think of this frequently when I interact with bad
| offenders, Like Waze on my phone. I have like 2 addresses
| starred in addition to the home and work slots. It should PIN
| those, in a fixed (probably alphabetical) order under the
| home and work slots. If it's not going to do that for starred
| items (maybe I have 300 addresses?) it should give me a
| different widget to pin them.
| kaba0 wrote:
| I would add that adding to an end of a list dynamically can
| be okay (if it doesn't cause previous content to jump as
| you mention).
| mjevans wrote:
| It's less egregious, but remember that clicking away from
| the list (e.g. to close it) is also often an input
| option. Even though that's a lower input priority it
| could still disrespect the user's desires if they were
| trying to leave the list.
| copperx wrote:
| I estimate I have about 100 daily counts of frustration
| because of elements moving while I'm interacting with the
| UI. It drives me crazy, and I assume it drives younger
| people even crazier because they have quicker reaction
| times.
|
| It's a disgrace that modern UIs haven't dealt with this.
|
| I had high hopes for Windows Phone because it was the only
| mobile OS that had a realtime UI. I don't care how long an
| operation takes. Just give me immediate feedback! And
| respond to my input as if it was mission critical. Why is
| it so hard?
| donatj wrote:
| The app search in both iOS and Android do this to this day.
| Every time I launch an app I didn't intend to launch because
| it popped into the results suddenly, I nearly throw my phone.
| It's literally rage inducing.
|
| How hard is it just to grep The list of local apps on a
| device _entirely_ before showing me the results? Why on earth
| does it even take a notable amount of time?
|
| I don't say this lightly when I say someone should be fired.
| Everyone on every level of every who let this exist should be
| blackballed by the entire industry. Managers, QA. Someone
| should've spoken up. It's an absolute moral failure.
| bacheaul wrote:
| Oh, don't get me started... MS Teams has been doing this
| recently at work. Everyone is pinning messages, because when
| you hover over the Edit menu item for a message and go to
| click it, two more menu items load asynchronously below it,
| and switch the Edit button out for a Pin Message button right
| when you go to click it. And it's not even consistently like
| that, just sometimes. It's infuriating...
| GekkePrutser wrote:
| Yes!! This seems to be something from the last couple of
| months. It's so annoying. Though in terms of teams it has
| many annoyances to compete with..
|
| Also for some reason I often seem to bring up the edit menu
| on the comment above the one I wanted to pick
| thesuitonym wrote:
| I recently had to use the Outlook web client to send an
| email and the experience was nothing short of horrendous.
| The autocomplete feature kept eating keypresses unless I
| typed exactly what it was expecting, or accepted what it
| wanted me to say, and pressed tab. Of course, I can type
| faster than it can predict, so I'd be done with a word
| before the prediction would show up, and the damn thing
| would eat the space and the first two or three letters of
| the next work.
|
| Who the hell is working on this stuff?
| avip wrote:
| The teams share screen "menu" is stubbornly stack on a
| strategic real estate with no way to hide or minimize.
| Consequently, it usually hides the browser tab I'm on.
|
| But the best part is throwing in some rdp. The teams share
| screen rect is carefully designed to cover the entire
| Remote Desktop title which is required to resize it.
| watwut wrote:
| Personally what I hate the most is heart icon randomly
| suddenly appearing exactly where I wanted to click
| resulting in me adding hearth icons to completely
| nonsensical messages.
|
| Teams are the worst.
| 0x38B wrote:
| Related: If I type 'ha' for "Hacker News" in Safari's address
| bar on my iPhone, by the second letter it'll show "Hacker
| News". But if I'm too quick to hit "Go" on the keyboard,
| Safari instead searches DuckDuckGo for "ha".
|
| The UI must update sooner than some underlying state; this
| bites me multiple times a day.
| ghostpepper wrote:
| I was just thinking about how windows xp and old linux DEs
| (Gnome 2, KDE3) somehow felt snappier and now I'm wondering
| if the rise of multicore/multiprocessing is to blame. When
| the windowing stack is running in the same physical core as
| the kernel maybe it's harder for these things to become
| disconnected.
| brimble wrote:
| Mobile Safari didn't _used_ to do that. I wanna say they
| introduced that bug a year or two ago. It annoys me
| constantly and it 's worrisome that they haven't fixed it
| yet.
| porker wrote:
| > In modern Windows, press Win-key and start to type, oops, it
| missed the first keypresses, presented the completely wrong
| results and made a mess of your workflow.
|
| On Win10 I'm getting regular delays in keypresses and just
| enough lag when typing to be noticeable.
|
| I've been trying plugging in two USB keyboards as a poor man's
| split keyboard, and the amount of software (looking at you
| IntelliJ in particular) that _does something_ that means the
| characters arrive out of order when typing is hugely
| frustrating.
| sgt wrote:
| Delays on keypresses.. in 2022. Are we going backwards?!
| Moru wrote:
| When I was in school we had 286 computers with windows on
| them. Some of them had input lag of about 7 seconds in the
| text editor we were using. Think it was Word but not sure
| any more. But at least they didn't miss keyboard input,
| every key stroke came out, just with more or less delay. I
| did most of my text editing at home on my Atari where there
| was no delay at all.
| cornel_io wrote:
| IntelliJ is really bad about this sometimes. I get that
| their software does an incredible amount of really tough
| stuff behind the scenes (which is why I won't be switching
| any time soon), but God I wish they prioritized input
| responsiveness over everything else.
| mike_hearn wrote:
| They actually did:
|
| https://blog.jetbrains.com/idea/2015/08/experimental-
| zero-la...
|
| There were big improvements over time. IntelliJ
| performance seems to vary a lot between people. For some
| (like me) it's great. Others complain of huge delays.
| Probably, the differences are OS related and/or project
| size or plugins related. There are so many different
| configs possible for an app like that.
| peebeebee wrote:
| Haha, I love the "My IDE is so sluggish, it must be doing
| important stuff". It really isn't. IntelliJ is just
| horribly laggish. VSCode, an electron (!) app with 100
| plugins isn't even that slow.
| ratww wrote:
| Yes. Even if it were doing important stuff, this
| "important stuff" shouldn't be affecting typing. We have
| multicore machines now, there's no excuse anymore.
|
| Imagine if it were the opposite, and moving the mouse or
| speaking into a microphone caused the compilation to fail
| in subtle ways. Well, background
| compilation/typechecking/whatever is messing with user
| interaction.
| kaba0 wrote:
| Jetbrains really should just update the JDK they use.
|
| With a slightly larger max memory setting than default
| and using at least G1 garbage collector (ZGC for even
| better results) they would get a buttery smooth editor,
| but it is configured quite badly by default.
|
| Though sometimes they just have threading issues, which
| won't be solved by above.
| Hackbraten wrote:
| Even Apple's bootloader on Macs is dropping keypresses now!
|
| Starting some time in 2020, the FileVault password dialog
| will drop characters whenever I'm typing quickly. And it
| never dropped characters before 2020 - even though I've had
| FileVault 2 on for many years.
|
| And that's at bootloader runtime, with not a single bit of
| the macOS kernel loaded yet!
| hulitu wrote:
| Yes.
| ephbit wrote:
| Related, about latency:
| https://news.ycombinator.com/item?id=16001407
|
| links to: https://danluu.com/input-lag/
|
| Title: Computer latency: 1977-2017
| hutzlibu wrote:
| No, forward. Because the delay is probably because all of
| the telemetry and tracking, that has to be activated and
| synced with the servers, before it can responds to your
| request. All that amazing technology, unthinkable 20 years
| ago.
|
| So definitely forward to big brother Panopticon.
| fxtentacle wrote:
| Oddly enough, I switched towards the JetBrains IDEs precisely
| because my impression is that they never lose keystrokes or
| change the ordering.
| thrower123 wrote:
| > today only work in some super old apps like Notepad.
|
| Old applications that actually follow the platform UX and
| accessibility guidelines
| fho wrote:
| > In modern Windows, press Win-key and start to type, oops, it
| missed the first keypresses
|
| This does not seem to be the case, is it? I recently,
| accidentally hit Win+term+Enter into a Windows VM (intending it
| to hit the Linux host machine) and was surprised when a
| terminal popped up.
| adhesive_wombat wrote:
| If it's some kind of timing/performance/hardware interface
| issue, it's quite possible different machines will act
| differently.
| Moru wrote:
| It might also be working today but not tomorrow, then you
| accidentally start "Archies terminologies dictionary" as a
| websearch instead.
| adhesive_wombat wrote:
| Just call it fuzzy search and now it's a feature.
| wolpoli wrote:
| > In modern Windows, press Win-key and start to type, oops, it
| missed the first keypresses, presented the completely wrong
| results and made a mess of your workflow.
|
| Every time I bump into these interaction issues, my stomach
| churns a little bit.
|
| Right now, Windows 11 is especially bad because they have new
| and old code working side by side. It'll take a few years for
| Microsoft to rewrite enough of the Shell so everything will be
| consistent again.
| tonyedgecombe wrote:
| By then Microsoft will have moved on to the next bit of Apple
| envy and it will all be out of sync again.
| thomastjeffery wrote:
| Windows 11 is that next bit. They never finished windows
| 10.
|
| I still have to dig through windows 7's control panel to
| change my microphone volume.
| WesolyKubeczek wrote:
| Windows 11 looks like KDE envy tbh
| spoils19 wrote:
| > I feel confused and disrespected as a user every day
|
| I definitely agree with this, and I like your use of the word
| disrespect. I think the younger generation has encroached onto
| the sanctity of "the platform", if you will, and now us old
| timers are suffering. I time myself for my actions every day
| since I started noticing these despicable UI trends, and on
| average I waste about 2-3 hours a week trying to discover what
| behaviors work with flat UI applications.
|
| But, take a natively designed application from Windows 2000,
| and it's extremely easy to understand and use! And, dare I say
| it, more pleasing to the eye than flashy, animated graphics of
| today.
| Hendrikto wrote:
| > But, take a natively designed application from Windows
| 2000, and it's extremely easy to understand and use!
|
| Because that's what you are accustomed to.
| AnonCoward4 wrote:
| > But, take a natively designed application from Windows
| 2000, and it's extremely easy to understand and use! And,
| dare I say it, more pleasing to the eye than flashy, animated
| graphics of today.
|
| Coming from that era, I strongly disagree. While I agree with
| the article, that some elements are harder to spot as
| interactable, I would still say that they are way more
| coherent than programs from W2K era and that one just got
| used to the broken design of the UIs of that era/platform.
|
| While usually understanding the UI even in W2K, I don't think
| that the dumbing down of UI (and reducing palette/layers adds
| to that) for the dumb users is necessarily a bad thing. At
| the end of the day I am also a dumb user.
|
| Actually using GTK3 for a while now and moving to GTK4
| however might also trick me to not notice a downgrade in
| discoverability, so in that particular instance I might get
| tricked by getting used to a certain design language even if
| they simplify it to the point of actually decreasing UX for
| users that are unfamiliar with GTK compared to GTK3.
| GekkePrutser wrote:
| At least in the windows 2000 time every app was using the
| same UI toolkit. That helped a lot
|
| What made some stuff hard was that there were not many
| pixels available for icons due to the more resolutions in
| those days, which made icons hard to recognise.
| ephbit wrote:
| > While I agree with the article, that some elements are
| harder to spot as interactable, I would still say that they
| are way more coherent than programs from W2K era ...
|
| Maybe that's the thing. More coherence might be _nicer_ ,
| yes. But it might also _not_ make UIs easier to use. Maybe
| sqeezing apps into a tight framework of UI coherence, makes
| the overall appearance of what 's on the screen more
| appealing but at the same time loose usability.
|
| Think of special applications like technical ones (Blender)
| or office (Thunderbird, LibreOffice) and also simple ones
| like a notepad application. Now try to find a common set of
| UI elements to use for all of them. What you'll probably
| get, is an OK notepad but a disturbingly bloated Blender.
|
| TLDR Niceness does IMO conflict with usability and the
| former sure shouldn't be prioritized over the latter.
| AnonCoward4 wrote:
| > Maybe that's the thing. More coherence might be nicer,
| yes. But it might also not make UIs easier to use. Maybe
| sqeezing apps into a tight framework of UI coherence,
| makes the overall appearance of what's on the screen more
| appealing but at the same time loose usability.
|
| It's a balancing act and you can screw up in either
| direction. What's clear is that limiting options and
| limiting depth is at a certain point really better from a
| UX standpoint - and I'd say old Windows toolkits are an
| example. It doesn't even mean there is missing anything,
| but that it is structured differently.
|
| > Think of special applications like technical ones
| (Blender) or office (Thunderbird, LibreOffice) and also
| simple ones like a notepad application. Now try to find a
| common set of UI elements to use for all of them. What
| you'll probably get, is an OK notepad but a disturbingly
| bloated Blender.
|
| Neither of these apps would have a problem with a GUI
| framework/toolkit per se. It's more an implementation
| detail of the specific frameworks/toolkits and the apps
| in question (also consider the time when they were
| founded).
| dm319 wrote:
| Goodness the start bar on Windows. For something that is meant
| to be a key part of both the mouse and the keyboard workflow,
| how can it be so slow? My work computers can hang for so long
| on it, that it is quicker to find the application shortcut on
| the desktop.
| hulitu wrote:
| Maybe because telemetry :).
| donatzsky wrote:
| I believe it's not really an integrated part of the Explorer
| shell anymore, but rather a separate process that gets
| launched every time you open the start menu.
| coffeeking wrote:
| Yes, there are separate processes, however a new instance
| is not started each time you open it - the same window is
| re-shown. Taskbar: explorer.exe
| Start menu: StartMenuExperienceHost.exe Searching:
| SearchApp.exe
|
| So, when you hit a key with the start menu focused, it
| closes the start menu and opens the search window (with the
| search text initialised with that key).
|
| Perhaps keystrokes are lost during the switch.
| dspillett wrote:
| _> how can it be so slow?_
|
| Because it is trying to be all things to all people:
| including supporting sponsored content and integrating with
| any fancy new/copied idea that the company is pushing (which
| may be quietly deprecated in the next major revision, but the
| hooks left adding abstraction load to everything else so that
| the few who actually found it useful don't complain).
| totalkrill wrote:
| Just you wait until they want to be able to run apps inside
| of it. Because they probably will want to do that.
| Unfortunately
| dspillett wrote:
| They've sort of already tried that, with animated smart
| tiles that were used by apps on Windows Phone and Win8.
| Not something I've seen recently, not sure if that is due
| to it being deprecated of if people just aren't using it
| on desktop as the menu is never visible for any
| considerable length of time.
| AnIdiotOnTheNet wrote:
| Computers are ludicrously fast nowadays. Games are capable
| of doing a whole lot of shit in <16ms consistently while
| responding to user input, so I don't buy this "it's doing a
| lot!" argument, it is coded badly.
| drdec wrote:
| I imagine the hold up is that it is connecting to an
| external service.
| account42 wrote:
| Some games also connect to an external service.
| geon wrote:
| When swiping between fullscreen windows, Macos sends the
| keystrokes to the last window until the animation has
| completed. The "g" of all my git commands ends up in vs code if
| I'm too quick. Very annoying.
| marwis wrote:
| Indeed Windows sucks but PowerToys has a much faster launcher
| replacement on alt+space
| hn_version_0023 wrote:
| This reminds me of one of my personal bugaboos, which seems
| especially bad in Microsoft Windows: windows that spawn child
| windows that require input focus, but that don't grab focus
| leaving you typing into nothing at all!
|
| Truly its crazy making.
| drdec wrote:
| IMHO, a worse practice is when you are happily typing along
| and the system throws up a dialog randomly, grabbing the
| focus and thereby "pressing" one of the buttons when you
| thought you were typing. Who knows what you just agreed to.
| account42 wrote:
| I'm glad that KDE has options to prevent that: https://docs
| .kde.org/trunk5/en/kwin/kcontrol/windowbehaviour...
|
| Generally if you were interacting with the computer then
| whatever new thing should get focus iff its appearance was
| a direct result of your current interaction.
| gurkendoktor wrote:
| > Things like Fitt's Law and so on. It was not just opinion.
|
| Here's another one: "users were roughly 37% faster at finding
| items when visual indicators varied both in color and icon
| compared to text alone"
|
| Source: https://www.nngroup.com/articles/visual-indicators-
| different...
|
| The whole point of the settings app shown in the OP's
| screenshots is to quickly find the relevant section in the
| sidebar. But even before the great design madness of 2012,
| designers have started to remove icon colors everywhere.
| (Except for app icons, where Google and Apple have now removed
| shapes instead, sigh.)
|
| From the sidelines, it doesn't look like the trend is reversing
| in GNOME land.
| https://twitter.com/hadessuk/status/1506316793413087241
| tauntz wrote:
| > "users were roughly 37% faster at finding items when visual
| indicators varied both in color and icon compared to text
| alone"
|
| Reminds me of https://i.kym-
| cdn.com/photos/images/newsfeed/001/927/386/c4d...
| lkxijlewlf wrote:
| Used to be they had _time_ to get UI better. Now, if you have
| the same UI for 6 months people think you 've stalled and start
| looking for new. Everything has to be constant churn, constant
| change. Far too many people today get bored way too easily.
| fxtentacle wrote:
| I still remember the good old days where keyboards had Function
| keys and apps would prominently display a F2 next to the save
| button, an F10 next to quit. Even for computer illiterate
| people, that made using keyboard shortcuts a bliss. Save was
| ALWAYS on F2 no matter what you did, so people would put
| physical stickers on their keyboard to make the F2 button say
| "Save" on the keycap.
| hnlmorg wrote:
| What system was this? I've used every version of Windows
| (literally), DOS since the 80s, Macs since the 90s, Linux
| since the 90s, Atari ST, and several different 8-bit micros
| and I don't recall ever using F2 to save. I do believe your
| anecdote but it's completely escaped me what platform might
| have used F2.
|
| Also worth noting that keyboards do still have function keys.
| In fact I use F2 as my `tmux` control prefix. :)
| garaetjjte wrote:
| mcedit does have save on F2 (which I guess is carried over
| from DOS Norton Commander):
| https://rubenerd.com/files/2009/3612703566_52304223da_o.png
| ogurechny wrote:
| Borland IDEs, Norton Commander (and its alternatives)
| built-in text editor, and programs that mimicked those
| green-grayish or blue-grayish text mode windows. Or those
| simply made with Turbo Vision.
| hnlmorg wrote:
| Ah yes, I now remember using F2 on Turbo Pascal. Thanks
| for the reminder :)
| dspillett wrote:
| I remember F2 being save in the DOS era, or maybe I'm
| misremembering and it was F3...
|
| But for many years I've associated F2 with edit or rename.
| hnlmorg wrote:
| I do remember when ctrl+shift+insert was common for paste
| (rather than ctrl+v). I can't remember off hand was copy
| was beyond it being a similar key combination. Still
| trips me up these days using cmd instead of ctrl on macs.
| dspillett wrote:
| ctrl+insert for copy and shift+insert for paste are still
| a thing in the majority of places in Windows, though I
| think only the ancients like me use them (people newer to
| the game being taught ctrl+C & ctrl+V from the start).
|
| Not long ago I even spotted it being usable in an app
| that blocked ctrl+C/ctrl+V.
| linguae wrote:
| I feel the same way. It's like we're back to the MS-DOS era
| where every application had its own interface and you had to
| learn each application's way of performing tasks. macOS and to
| a lesser extent Windows prided themselves on consistency across
| applications. But this required developers to voluntarily
| conform to those platform's guidelines, and in the case of
| Windows, the goal of consistency was challenged by (1) Windows'
| backwards compatibility and (2) Microsoft's own disregard for
| consistency at times, such as Microsoft Office using its own UI
| toolkit instead of relying on the UI elements of the version of
| Windows Office is running on (for example, Office 97 introduced
| flat toolbars, a different style of menu bar, and the Tahoma
| font, which deviated from Windows 95/NT 4 and its button-style
| toolbars and its use of MS Sans Serif); this theme even carried
| over to Windows NT 3.51 where Office's UI was out of place; see
| http://toastytech.com/guis/nt351word.png for a screenshot).
| Contrast that with the Web, where there are no common UI/UX
| guidelines. Sadly this philosophy has spread to the desktop,
| where increasingly each application seems to have its own UI/UX
| without regard for the platform's guidelines.
|
| There is one good thing I could think of about the loss of
| consistency across applications: the underlying operating
| system matters less when the application works the same across
| platforms. Ironically this may help with the adoption of
| desktop Linux; Chrome, Slack, Zoom, and VSCode generally work
| the same. To paraphrase, this fulfills Netscape's vision in the
| mid-1990's of reducing the operating system to a bunch of
| device drivers.
|
| One would think that Microsoft and Apple don't want Windows and
| macOS to be reduced to a bunch of device drivers. Then again,
| perhaps Microsoft's and Apple's business models don't require
| the long-time maintenance of these desktop-oriented operating
| systems. Microsoft makes a lot of money from Office and Azure,
| and Apple makes a lot more money from the iOS platform than
| from the Mac.
|
| Still, I personally lament the rise and triumph of the siloed
| app, and the decline of platforms that promoted UI/UX
| consistency through a set of standard human interface
| guidelines, and I feel personal computing is generally getting
| worse instead of better.
| hulitu wrote:
| If you look at Windows 1.0 GUI and Windows 10 UI they look
| verry similar. Makes you think what Microsoft was doing all
| these years.
| pjmlp wrote:
| Internal political fights between DevDiv and WinDev.
|
| If you are aware that DevDiv controls managed languages,
| and WinDev Windows/C++, it becomes quite clear why the back
| and forth between those UI frameworks, given who happens to
| be on top on a specific time.
|
| And now there is Azure + WebUIs to add up to those resource
| fighting, oh well.
| ho_schi wrote:
| I've never seen any consistency MS-DOS, Win9x and WinNT. The
| worst offender is Microsoft itself with the file-browser,
| settings and office-suits. They don't maintain and evolve
| their toolkit, they just add new ones and recommend to use
| them instead: Win32: Win32, Windows Forms,
| WPF, MAUI, UWP, WTL, WinUI, MFC and probably more
| Gtk: Gtk+, Gtk2+, Gtk3+, Gtk4 Qt: Qt1, Qt2, Qt3, Qt4,
| Qt5, Qt6
|
| Gtk and Qt didn't just maintain but provides major upgrades
| and changes. People complained that Gtk changed stuff, which
| is unfair. The various feature removals in GNOME3 after the
| first release provided bigger problems. I'm rather sure the
| changes between Qt major release also require work from
| developers. Custom theming is an issue with Gtk but also
| something I cannot recommend as developer and user. It is
| complicated on toolkit side and faulty on user side. Qt seems
| do to better in this regard but the user side problems
| remain. Apple just says just no to theming at all. I've also
| never felt the desire to theme Gtk because it looked good by
| default since Gtk3+ and even backported to some stuff to
| Gtk2+. There is of Java and Swing, yes, but I'm afraid the
| first error was including a toolkit into a language library.
|
| With Gtk and their HIG most stuff looks decent and usable.
| Windows? Nobody cares about the HIG. Micrsoft provides more
| toolkits than I know. And a lot developers just do whatever
| they want on Windows. Or worse, they use Electron. Microsoft
| Teams is the worst "application" in this regard.
|
| By the way:
|
| https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
|
| The font rendering issue. I recommend ignoring the blaming
| (users) and ignoring (developers) on both sides and instead
| reading the details involved. Looks like mostly intended and
| used during development on HiDPI-Displays and they need
| people experienced in font drawing matters. Some fixes are
| landing already. Taking into account how much effort was put
| in Harfbuzz, Freetype, Pango and Cairo I think they can only
| learn from this - being more careful and keeping backward
| compatible solutions alongside until the new stuff is working
| fine for all.
| pjmlp wrote:
| The big difference is that with any of the Windows
| toolkits, an application written on their heyday will keep
| working today, good luck doing the same with any Linux
| toolkit.
|
| Also only Qt is comparable in the full stack experience
| offered by Windows frameworks (and MacOS/Android/iOS/...),
| with the caveat it is anyway cross platform and not Linux
| specific.
| bajsejohannes wrote:
| > Another thing is type-ahead. I remember in classic MacOS,
| people pressed shortcuts and started to type the filename or
| whatever. It was all perfectly recorded and replayed. In modern
| Windows, press Win-key and start to type, oops, it missed the
| first keypresses, presented the completely wrong results and
| made a mess of your workflow.
|
| The arguably worst offender in MacOS these days is the emoji
| picker. Press ctrl+cmd+space, and depending on how recently you
| opened it, it can take some hundreds of milliseconds to open
| (on an m1). All while eating your keypresses.
| Aeolos wrote:
| Yes, this one is particularly weird.
|
| How can a grid of unicode characters take 500-1000ms to
| display on a machine with an m1, 16GB of memory and a blazing
| fast NVME disk?
| armagon wrote:
| Huh. I didn't know this existed.
| k8sToGo wrote:
| Notepad is not old anymore because it has been recently
| replaced.
| hulitu wrote:
| > Notepad is not old anymore because it has been recently
| replaced.
|
| They said the same thing about my parents dog which died last
| year.
| InCityDreams wrote:
| "Notepad", cool name for a dog.
| marcus_holmes wrote:
| I would love it if we could all just decide on a single WIMP
| interface and stick to that.
|
| I understand that this would annoy designers. But they're
| annoying me so I think this is fair.
|
| My go-to example at the moment is Figma, which is a design tool
| that I find almost impossible to use because it has so many
| hidden, unexplained "features" in its UI. If I accidentally
| brush the keyboard I have to quit the application and restart
| because I have no idea how to get back to the state I was in.
| DrBazza wrote:
| > Is something a button? Should I click it or double-click it?
| How about long-press on it? How can I know when there's no
| visual clues?
|
| Since Windows 7 (or 8, I can't remember) and the "Metro" style
| apps, in the Control Panel in particular one of the controls
| (IIRC it was something like the 'show/hide icons in task
| tray'), that was previously a button, became a "hyperlink",
| essentially clickable text. Clickable text that was _the same
| colour as unclickable text_. What. The. **
| Derbasti wrote:
| > In modern Windows, press Win-key and start to type, oops, it
| missed the first keypresses, presented the completely wrong
| results and made a mess of your workflow.
|
| The worst offender is the login prompt. In Gnome, from the lock
| screen, I simply start typing my password. As soon as I type
| the first letter of the password, the password prompt appears,
| and when I'm done I hit enter and it unlocks.
|
| On Windows, the first letter merely makes the prompt appear,
| but does not yet type into the prompt. In fact, it will only
| start feeding letters into the prompt once the little prompt-
| appearing-animation has finished. If I just start typing my
| password, it will eat the first three or four letters. So I hit
| enter, wait for the animation to finish, and only then start
| typing.
|
| That's not the end of the world, honestly. But it is a learned
| gesture that the system taught me by failing to do what I'd
| asked it to do. It just goes to show the attention to detail
| that makes a UI feel fluid and frictionless.
| copperx wrote:
| It's certainly not the end of the world, but it's death by a
| thousand papercuts. I find macOS has fewer sharp edges (but
| still has plenty of them), and Linux too, once the system is
| configured and only used for writing code.
| formerly_proven wrote:
| iirc this is a Windows 8/10 regression and worked perfectly
| on Windows 7.
| fxtentacle wrote:
| That is one of the main reasons why I switched from XCode to
| CLion. XCode lost keystrokes, which drove me crazy. The other
| thing was that I could reliably type faster than XCode could
| display the letters, which made me feel like I'm drunk.
|
| CLion seems to be quite excellent at recording and replaying
| everything, including stuff I type while the auto-completion
| is loading. Plus it has a really fast key to screen loop.
| natdempk wrote:
| All of the Jetbrains editors also have these bugs in some
| places too unfortunately. The main one I run into is when
| you open the fuzzy goto modal (CMD + O) there's a delay
| before the window opens where if you paste/type anything it
| goes into the file you're editing instead of the search
| box. It's been like this for at least 5 years.
| cerved wrote:
| The quality of JetBrains products are overall high
| copperx wrote:
| JetBrains develop the only modern software that makes me
| go "wow, that's amazing."
|
| Ok, maybe not. Honorable mentions to some Adobe's
| algorithms and Apple's Sidecar / Universal Control
| functionality.
| andai wrote:
| JetBrains did a lot of work to reduce typing latency of
| their IDEs:
|
| https://blog.jetbrains.com/idea/2015/08/experimental-zero-
| la...
|
| As an aside, I find it amusing that more latency is
| introduced by a USB keyboard than existed in an entire 80's
| computer (from keypress to rendering on screen). See also:
| Carmack's rant about how it takes longer to put a pixel on
| the screen than ping across the Atlantic.
| WayToDoor wrote:
| Link to the rent
| https://superuser.com/questions/419070/transatlantic-
| ping-fa...
| jordibc wrote:
| About the USB keyboard, that may be true only for the
| cheapest keyboard you could find, but basically not
| applicable anymore nowadays. Rather than giving you the
| details, let me link to this video, which is awesome at
| explaining it and much more -- the USB vs PS/2 part
| starts here:
| https://www.youtube.com/watch?v=wdgULBpRoXk&t=1766s
| NovemberWhiskey wrote:
| > _As an aside, I find it amusing that more latency is
| introduced by a USB keyboard than existed in an entire 80
| 's computer_
|
| Uh what?
| the_pwner224 wrote:
| Most normal keyboards, mice, and USB HIDs report events
| at a rate of 125 hz == 8 ms between reports.
|
| Gaming mice usually go up to 1000 Hz / 1ms, the wireless
| ones usually let you configure down to 500/250/125 Hz if
| you want a bit more battery life. I'm sure that gaming
| keyboards also have a high refresh rate.
|
| If you have a 144 Hz monitor that actually means your
| (normal) keyboard and mice are reporting events less
| often than your display is updating.
| formerly_proven wrote:
| A lot of gaming hardware is trash. 1000 Hz on the
| package, endless latency inside, buggy firmware, buggier
| and resource-hogging companion apps, which are always
| Windows-only, and there are still even "gaming keyboards"
| which are 2KRO, bad materials and so on
|
| That being said pretty much any 1000 Hz mouse is better
| than any 125 Hz mouse when using high refresh rates
| because the discrepancy between the 125 Hz mouse poll
| rate and the 120 or 144 Hz display causes very noticeable
| jitter. If you have a mouse where the poll rate can be
| adjusted, this can be easily A/B tested; it's quite
| visible in high-framerate recordings as well (this can be
| done in OBS by using the fractional frame rate selector
| and just inputting 144:1).
| andai wrote:
| Found the article I was thinking of:
|
| >at the time I did these measurements, my 4.2 GHz kaby
| lake had the fastest single-threaded performance of any
| machine you could buy but had worse latency than a quick
| machine from the 70s (roughly 6x worse than an Apple 2),
| which seems a bit curious.
|
| >We can see that, even with the limited set of keyboards
| tested, there can be as much as a 45ms difference in
| latency between keyboards. Moreover, a modern computer
| with one of the slower keyboards attached can't possibly
| be as responsive as a quick machine from the 70s or 80s
| because the keyboard alone is slower than the entire
| response pipeline of some older computers.
|
| https://danluu.com/keyboard-latency/
| aitchnyu wrote:
| When I log into a Win 10 virtual desktop with 1024*768, the
| login form with 2 text fields and a button gets shoved into a
| box and I have to scroll down to see it fully.
| hulitu wrote:
| Win 10 tought me to type again at least CTRL+ALT if i want my
| password to be accepted from the first time. Clicking with
| the mouse sometimes works before entering the password. It
| seems that at MS and also in other areas (Android, Gnome)
| people want just to code new things but not debug or fix
| bugs. They also must be as simple as possible because: 1.
| code reuse sucks. 2. Thinking is hard.
| d1sxeyes wrote:
| > That's not the end of the world, honestly. But it is a
| learned gesture that the system taught me by failing to do
| what I'd asked it to do.
|
| Although I agree this is annoying, to be completely fair, it
| doesn't suggest that you should start typing your password
| immediately.
|
| You could also start typing 'news.ycombinator.com' and it
| wouldn't browse to HN, but you wouldn't say that it failed to
| do what you asked it to.
|
| Arguably, you have been 'taught' or you have inferred
| yourself that you should expect a sleeping system to
| immediately accept your keypresses as a password, which
| although reasonable is not necessarily a good practice.
|
| For example - I have two computers connected to the same
| keyboard, one is indeed Gnome, the other Windows. I have
| twice now typed my password into what I thought was my
| sleeping Gnome system, hit enter, only to have to apologise
| to someone on Teams because I accidentally sent them my
| password because my keyboard was sending my keypresses to the
| Windows PC.
| OrderlyTiamat wrote:
| I... am sorry, but I think that is extremely bad practice.
| You should not put yourself in that position, and your
| experience in that position does not excuse the design
| flaws in windows.
|
| > You could also start typing 'news.ycombinator.com' and it
| wouldn't browse to HN, but you wouldn't say that it failed
| to do what you asked it to.
|
| Well firstly, that isn't what the prompt is for, so I'm
| struggling to see the relevance. However it is a good
| example for me- When I type C-l right now, I can
| _immediately_ start typing 'news.ycombinator.com'. There is
| no delay, no animation, nothing. I didn't go through a
| learning experience of finding out how long I should wait
| before typing- it's just ready.
|
| Fundamentally: _why_ should I have been "taught" anything
| about how long I should wait? I don't have to do that on my
| ubuntu laptop. I don't have to do that on firefox in the
| example you handed to me. It's bad when I have to learn
| that. The computer should never make me wait unnecessarily,
| and I find it worrying that people are so readily accepting
| of it.
| d1sxeyes wrote:
| > I... am sorry, but I think that is extremely bad
| practice.
|
| Completely correct - I'm not excusing my lack of
| attention there.
|
| > Well firstly, that isn't what the prompt is for
|
| That's exactly my point. There is no prompt displayed on
| the screen, you have not been asked for input. You are
| pre-empting the next prompt before the system is ready
| for it.
|
| > When I type C-l right now, I can _immediately_ start
| typing 'news.ycombinator.com'. There is no delay, no
| animation, nothing. I didn't go through a learning
| experience of finding out how long I should wait before
| typing- it's just ready.
|
| Agreed - but that's with the application already open.
| From the lock screen, it won't do what you intend. With
| Firefox running and in focus, Ctrl + L tells the
| application to focus the address bar, but it only works
| in that context, you first have to prepare the correct
| context (computer unlocked, Firefox running, in the
| foreground and focused).
|
| On Windows, Ctrl + Alt + Del tells the system to wake,
| not 'the next characters entered will necessarily be the
| password of the most recently logged in user'.
|
| In fact, I tested a little bit, and often Ctrl + Alt +
| Del on a sleeping system actually asks me to enter a
| username first, not a password, although in some cases
| the username is pre-filled for me, and the password
| prompt will be focused. I cannot necessarily know a
| priori which I will be asked for until the system wakes
| and decides.
|
| As soon as Windows displays the prompt, you can type into
| it (same as Gnome). The only difference is that Windows
| requires you to first wake and then authenticate once the
| system is woken, while Gnome allows you to do both
| simultaneously.
|
| There is one particular 'pro' to the Windows approach of
| requiring Ctrl+Alt+Del which is that it's an interrupt
| sequence. If a malicious actor created a full screen
| application that mimics the Windows password prompt, it
| would not be effective because the Ctrl+Alt+Del sequence
| cannot be handled by an application. The same is not true
| for Gnome - if a malicious actor created a full screen
| application that mimics the login prompt on Gnome, you
| could be tricked into entering your password.
| tsimionescu wrote:
| GP's (I think reasonable) point was that typing A on the
| keyboard of a locked (or worse, sleeping) computer has no
| reason to be interpreted as "input the letter A into the
| password field that will be displayed on screen", which
| is what the original post is assuming it should mean.
| There's no real reason it should even mean "input the
| letter A into the first field that comes into focus",
| which may anyway not be the password (it could be the
| Username field in certain setups).
| kaba0 wrote:
| Well, you usually see the logged in user's name and icon
| on the screen, and presumably you left your own computer
| there.
|
| And frankly, UX is about finding the little practices
| that make the experience better -- arbitrarily waiting
| for windows to bring up a prompt is not making me any
| good, since I _know_ what I want to do. So in my opinion
| in this very special case, windows is simply doing an
| incorrect thing -- making the common case slow.
| d1sxeyes wrote:
| > Well, you usually see the logged in user's name and
| icon on the screen
|
| I don't have this experience. On Windows (10, at least),
| normally I see either a black screen (if it's asleep) or
| a wallpaper, clock, and a message saying 'Press Ctrl +
| Alt + Delete to unlock.'
|
| > arbitrarily waiting for windows to bring up a prompt
|
| I don't think it's arbitrary. It's doing something - it's
| calling Winlogon, spinning up disks and reading
| hibernation data into memory, restarting power to powered
| down components, probing authentication methods available
| (eg: fingerprint/card readers), in case of domain joined
| computers, validating whether the domain is available
| (which means firing up network interfaces), and if so,
| whether the user's password has changed, etc.
|
| There are definitely downsides to Microsoft's approach
| here - as you mention, in a large number of cases, it
| takes more time to unlock the computer.
|
| However, there are also upsides if you accept that UX is
| only one consideration when designing a secure log on
| prompt, and there may be other priorities.
| klibertp wrote:
| > Arguably, you have been 'taught' or you have inferred
| yourself that you should expect a sleeping system to
| immediately accept your keypresses as a password, which
| although reasonable is _not necessarily a good practice_.
|
| I fail to see why that wouldn't be a "good practice". Last
| weekend I read some articles on Canon Cat[1], and Jef
| Raskin referred[2] to the feature as something desirable:
|
| > In many ways it was, for 1987, far ahead. [...] instant
| on with any keystroke (and you didn't even lose the
| keystroke)
|
| He goes on to explain why it's a good idea to do so in the
| article, it's a good read.
|
| [1] https://en.wikipedia.org/wiki/Canon_Cat
|
| [2] https://www.apple-history.com/gui_raskin2
| d1sxeyes wrote:
| Thanks for sharing. I can definitely see why it might be
| appealing. However, using Ctrl + Alt + Del guarantees
| that _only_ Winlogon can handle the logon, no other
| process can be simulating the login prompt.
|
| My dad told me about a program he wrote for a PDP-11
| which would just simulate a login prompt. When a username
| and password were entered, it would append it to a file
| somewhere, then print the 'Incorrect username or
| password' message, and exit silently.
|
| The user would assume they'd fat-fingered the password,
| and try to log in again (successfully) and be none the
| wiser that their password had just been stolen.
|
| The Windows dependency on Ctrl+Alt+Del makes this type of
| attack impossible, while systems that don't require a
| Secure Attention Sequence (as apparently it is called) to
| log in are susceptible to a slightly more sophisticated
| version of this attack.
| klibertp wrote:
| I see. It makes sense, and it's a valid concern that I
| didn't think of. Personally, I prefer the convenience of
| continuing where I left off with as little friction as
| possible, so I don't even lock the session when the
| screensaver kicks in. But I never take my laptop outside,
| and the threat of malware is considerably lower under
| Linux. If that wasn't true, I would probably also want to
| err on the side of caution. Choosing a specific key (I
| have a very conveniently positioned X86WakeUp physical
| button) or combination for waking up and getting to login
| prompt seems like a good idea in that case.
| inetknght wrote:
| > _In Gnome, from the lock screen, I simply start typing my
| password. As soon as I type the first letter of the password,
| the password prompt appears, and when I 'm done I hit enter
| and it unlocks._
|
| Congratulations! You were able to recognize that it's a
| _login screen_ without seeing that there's a hidden password
| field.
|
| The first time I booted to Gnome I waited damn near ten
| minutes for it to tell me it's ready for my login before I
| decided to start typing things to see if it was stuck.
|
| It's _not_ intuitive.
| brimble wrote:
| Miming mobile OS lock screens is one of the weirdest damn
| things about modern desktop trends. It's so obviously a bad
| idea. I can't even figure out what useful functionality
| anyone _thought_ that would provide. It 's a fucking
| desktop, there's plenty of room to stick notifications or
| the weather or whatever on the same screen as the login
| prompt, if that's what you want.
| dylan-m wrote:
| One unfortunate reality is, for a lot of new users -
| especially people who haven't used desktop computers
| before - their first computer was a mobile device. If we
| don't want Apple and Google to take over the entire
| space, we need to meet them halfway.
|
| The lock screen is weird, though, I agree. The newer
| (blurry background) one is better than the old one with
| the tedious swipe animation, but really could use a
| persistent "do this to unlock" prompt / button, because
| many people just aren't comfortable poking their computer
| unless they know what it is going to do. A lot of modern
| UI design unfortunately forgets that.
|
| For what it's worth, the original design for GNOME's
| current lock screen involved bridging the gap between it
| and the login / switch user screen, which _would_ involve
| some more UI elements, but the actual implementation must
| have stalled somewhere.
| ehnto wrote:
| Part of the discussion is that user interface is now a conduit
| for branding, probably the major conduit for software focused
| companies. You can't have consistent UI branding across devices
| unless you replace the UI to suit your branding. So rather than
| user interface being refined over the years into a consistent
| usable tool for each platform, by people specifically
| interested in UI and the paradigms of that platform, it's re-
| implemented year-over-year, with UX playing second fiddle to
| branding and design.
| yhbtgvrfc wrote:
| I hate rounded corners, giant title bars, no clear borders or 1px
| borders for grabbig, disappearing scrollbars. I hate when artsy
| minimalistic designs waste my screen space. Win95 & co got these
| right for desktop. (touchscreen would be a different matter I
| admit)
| jl6 wrote:
| I sorely miss the days when it was possible to explain to someone
| the principles of how an OS UI worked, and for those principles
| to be reusable across a wide array of applications.
|
| Today, every application seems to just do its own thing, and
| continually churns its own UI, chasing trends.
|
| There was a time when an elderly relative would say "computers
| are too hard to use", and I could recommend a book or manual that
| would help make it clearer.
|
| Nowadays I tend to just agree with them.
| gjsman-1000 wrote:
| Backstory: https://stopthemingmy.app
| phkahler wrote:
| Getting rid of themes is a decision distinct from that of
| choosing the one true theme. Going with FLAT was a poor choice
| and is what the current discussion is about. If there is any
| irony it's that more people will want to change the theme now,
| since the default is worse than before.
| naoqj wrote:
| You can't get any more arrogant than this.
| MereInterest wrote:
| Wow, that's definitely something. Implying that tinkering with
| the low level aspects of a system are acceptable, but don't you
| dare apply a different stylesheet, because adjusting colors is
| delicate work that shouldn't ever be done by anybody but the
| developer.
| jeroenhd wrote:
| I agree with the key points though, which is that distros
| need to stop messing with themes unless they can validate
| that all applications work with custom themes.
|
| They bear no ill will against users who download or make
| their own theme.
| malermeister wrote:
| They might not bear any ill will, but they don't mind them
| being collateral damage either.
| wolpoli wrote:
| I don't understand why modern toolbar icons are basically
| abstract shapes represented by lines. It's 2022, we have 32 bit
| colors, but toolbar icons have less color than back 30 years ago
| in Windows 3.1.
| airstrike wrote:
| The reason is because colorful designs were ugly AF in
| virtually all but the very best (or native) applications so
| users developed an allergic reaction to them. Minimal design
| felt fresh and it's harder to fuck it up...sadly it's also
| harder to tell icons apart
| Aeolun wrote:
| > I don't understand why modern toolbar icons are basically
| abstract shapes represented by lines
|
| Much, much easier to style based on whatever the surroundings
| are. Also easier to maintain a good look if you switch to a
| completely different theme, and for third party icons to mesh
| with the OS set of icons (only so many ways you can mess up the
| sillouette of the shape).
|
| Oh, and they scale to basically infinite proportions without
| looking weird, which cannot be said for color vector icons.
| anthk wrote:
| >Oh, and they scale to basically infinite proportions without
| looking weird, which cannot be said for color vector icons.
|
| Check Haiku OS.
| Izkata wrote:
| > I don't understand why modern toolbar icons are basically
| abstract shapes represented by lines.
|
| Eventually it'll mutate into cuneiform and no one will realize
| they've learned an ancient script.
| zozbot234 wrote:
| Old win 3.1 toolbars had tiny 16x16px icons, that could be
| quite colorful without being overly distracting even on a
| lower-resolution screen. With the new emphasis on "touch"
| readiness combined with higher screen resolutions we get bigger
| icons but simpler, black-and-white shapes, which helps tell
| apart simple toolbar functions from icons that might represent
| all sorts of other things within an application.
| dv_dt wrote:
| Can I also mourn the loss of title bars as I carefully hunt for a
| spot to grab a window to move it?
| eMSF wrote:
| For me, what you're referring to is one of the reasons I don't
| like to use Windows as a desktop OS (because you need to hunt
| for these relatively small target areas to organise multiple
| windows). The alternative which I greatly prefer is outlined in
| the other responses.
|
| In the past, I used to disable title bars entirely even on
| full-sized monitors. These days it's not so easy to do that,
| though.
| godshatter wrote:
| This is one of my pet peeves, too. I shouldn't have to find
| some pixels of unused space on a title bar before clicking on
| it lest I bring down another menu or launch something.
| Microsoft programs seem to be enamored with the "search input
| box in the title bar" concept. Give me a magnifying glass, and
| drop down the input box or something. I want to be able to just
| grab the title bar and move the window.
| jms55 wrote:
| You can grab any part of the headerbar to move the window -
| even buttons and other widgets. It won't trigger them, it will
| just move the window.
| jeroenhd wrote:
| For what it's worth, I recently discovered that I can move
| windows on GNOME by holding down the Windows/super key and
| dragging. It's a small thing but it's actually quite nice.
| stjohnswarts wrote:
| the ones for resizing and moving are quite handy indeed.
| Learn them. Sometimes windows have bugs and get bizarrely
| huge and this is a way to get them back down to a reasonable
| size
| worg wrote:
| that has been the case in gnome since the 2.x days
|
| edit: #dyac
| drekipus wrote:
| What's also good, is windows/super key and dragging right
| mouse button -> resize window.
|
| I don't remember if that's enabled by default, or you have to
| install some gnome tweaks to do it, but it is nice.
| ho_schi wrote:
| The font rendering issues:
|
| https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
|
| I recommend ignoring the blaming (users) and ignoring
| (developers) on both side both reading the details involved.
| Looks like mostly intended and used during development on HiDPI-
| Displays and that they need people experienced in font drawing
| matters.
| seltzered_ wrote:
| After sharing this in
| https://www.reddit.com/r/gnome/comments/tn8why/the_end_of_th... ,
| a commenter pointed out an issue going into more detailed
| discussion around these buttons and some of the tradeoffs to
| consider in having outlines or not:
| https://gitlab.gnome.org/GNOME/libadwaita/-/issues/228
| nyanpasu64 wrote:
| > The only issue with it is that font rendering looks horrific,
| but that might just be my machine.
|
| This is because GTK4 enables pixel/scaling-independent fractional
| vertical positioning, even with hinting enabled. There's a long
| (somewhat ongoing) discussion at
| https://gitlab.gnome.org/GNOME/gtk/-/issues/3787, though I
| haven't followed the last few months of discussion.
|
| Even though GTK4 aims to achieve scale-independent layout, the 4
| horizontal/vertical positions still produce a bit of judder, and
| fonts do not scale smoothly (even with bilinear interpolation)
| with hinting enabled, and (unless fixed) there are rendering
| issues due to failing to clear the texture atlas properly:
| https://gitlab.gnome.org/GNOME/gtk/-/issues/4322
|
| Interestingly there's a proposal to switch GTK4 fonts to SDF-
| style rendering. This is somewhat like what Qt Quick 2
| implemented already (and KDE turns off and reverts to FreeType
| rendering, to make QML apps mimic Qt Widgets font rendering
| more): https://blogs.gnome.org/chergert/2022/03/20/rendering-
| text-w... However, I looked at https://github.com/behdad/glyphy
| and it seems to implement _vector_ -based SDFs, instead of
| earlier texture-based SDF/MSDFs used by Valve games and Qt Quick.
| rayiner wrote:
| > The overarching goal is to get to more linear layout, so
| things don't wiggle around as you animate and transform them.
|
| Lol so make it look like crap the 99% of the time you're not
| animating or transforming the text.
| layer8 wrote:
| "Scale-independent layout" (layout that ignores pixel aliasing)
| really requires PPI over ~200, that is, more than most desktop
| monitors provide. We're still just not there.
| jug wrote:
| They should take note of Windows 11 and the fallout from new
| menu item style due to the font no longer scaling properly at
| DPI "100%". Many reported it as a bug! But it's per design in
| the new Segoe Variable file where hunting breaks down at
| "low" (i.e. normal, non-hi) DPI.
| jchw wrote:
| It's going to be a bloody mess for a long time, because the
| choices for how to handle resolution independence are all
| inherently filled with compromise.
|
| With font rendering, I think there is hope. Horizontal
| subpixel positioning with vertical hinting seems like a good
| tradeoff to me. Grid fitting vertically is not too jarring,
| and grid fitting horizontally to subpixels instead of pixels
| looks pretty good too, on low resolution displays.
|
| But it really is a son of a bitch elsewhere. For example, if
| you want a crisp 1px border on 96 dpi, you could specify it
| to be a 1px border at 96 dpi... but then what happens at 1.5x
| or 1.75x scale? From a purely logical position, the blurry
| line is actually the general case, and the integer scale case
| is actually an edge case. That desktop UIs aren't blurry
| basically always is because we define them in terms of 96 DPI
| displays.
|
| It gets worse for APIs, because APIs that want to present a
| resolution-independent world will cause difficult to tolerate
| bugs. The VS Code terminal will often be blurry at non-
| integer scales because it is using HTML canvas. If the canvas
| width or height is not a multiple of the size of a CSS pixel,
| it will cause the internal buffer to be scaled horridly. The
| fix might be a new API that reveals true coordinates... very,
| very nasty.
|
| Apple's solution was extreme: dump all font hacks, always
| render apps at 2x, then scale the whole framebuffer for
| different scale factors. It's somewhat blurry, but avoids
| many ugly pitfalls in the common case, and makes apps
| simpler.
|
| Unfortunately, the rest of the world is just stuck with
| really bad scaling and more often blurring on 96 DPI
| displays, the worst of both worlds.
| divingdragon wrote:
| > The fix might be a new API that reveals true
| coordinates...
|
| We already have this with `ResizeObserver` using the
| `device-pixel-content-box` option. [1]
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/API/ResizeObser...
| jchw wrote:
| Pretty sure this API is brand new (last ~year or so) but
| I honestly had no idea it landed into the standards.
| Cool, although still, ugly :/
| hedora wrote:
| I really don't understand what was wrong with the X11
| approach. I had a high DPI monitor in 2001. I typed the DPI
| into /etc/XFree86.conf or whatever, and it all Just Worked
| (TM).
|
| Edit: I think modern web browsers implement ctrl-+ and
| ctrl-- the same way, except X11 apps kept separate
| directories of icons rendered for different DPIs, because
| 1GHz single core still seemed luxurious. Web browsers scale
| the bitmaps using some reasonable algorithm. Other than
| that, arbitrary zooms work with zero blur.
|
| For what it's worth, PostScript also got this right back in
| the 80s.
| account42 wrote:
| > I think modern web browsers implement ctrl-+ and ctrl--
| the same way, except X11 apps kept separate directories
| of icons rendered for different DPIs, because 1GHz single
| core still seemed luxurious. Web browsers scale the
| bitmaps using some reasonable algorithm. Other than that,
| arbitrary zooms work with zero blur.
|
| Web browsers scale bitmats if no other version is
| available but you can provide different bitmaps for
| different pixel ratios to avoid any blurryness [0].
| Resolution independence is one thing that the modern web
| stack gets right - even 1-pixel borders/lines and space
| between elements generally works as expected for
| different scales.
|
| Of couse *mobile* browsers made the IMO stupid decision
| of only activating these scaling features when you add a
| special tag to your HTML header.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Learn/HTML/Multimed...
| jchw wrote:
| Well, how much it Just Worked really depended on what you
| were doing and how. At a point, it all stopped Just Work-
| ing.
|
| Old old X11 apps used X11 drawing commands. These sucked,
| and nobody liked them. If you think you liked them,
| please show me your clean Xlib codebases for proof :P As
| far as I can recall, these still dealt with pixels, so
| clients were on the hook for dealing with scaling, though
| in theory it wasn't too bad. They don't really solve any
| of the pixel perfection issues that I am discussing,
| though.
|
| More modern apps (-- early 2000s should be "modern"
| enough by X11 standards, but my memory is foggy and I'm
| too young to really be an expert here --) instead blit
| pixmaps sent over shmem, defeating both network
| transparency and the inherent "vector" nature of many of
| the old drawing commands. X11 didn't really handle
| anything other than knowing the DPI (... that you _told_
| it ...)
|
| At that point, up to GTK+2 and Qt 3, which is to say,
| even quite a while After 2001, you had at best limited
| scalability. If you had your CRT cranked up to around 150
| PPI, everything was OK -- you could get _text_ scaling
| and the disparity wasn't so bad. However, GTK+2 and Qt 3,
| and their ancestors, were not built with DPI
| independence. At best, they could adjust vector text
| sizes according to DPI and scaling preferences. Again,
| this looks OK for nvidia-xsettings and a modest PPI
| increase, but it's absolutely terrible for anything more.
| Margins don't adjust, padding doesn't adjust, icon sizes
| don't adjust, _nothing_. There's no blur or jankiness
| because there's no true scaling.
|
| (Just as a quick note, this is literally the reality of
| GIMP _today_ , right now. It's still on GTK+2, and so the
| best you can get is text scaling, or flat out _nothing_.)
|
| And that's to say nothing about what happens if the DPI
| _changes_ , which requires you to effectively restart
| everything. And that also doesn't help people who have
| two different displays with different PPIs. The ever
| common case of the high DPI laptop with a cheap LCD
| plugged in. Have fun with _that_ crap.
|
| Modern Linux can do better. The Wayland protocol comes
| with DPI negotiation that allows naive clients to get
| blurry upscaling, "simple" clients to pick a set of
| scales they can support and have the server adjust for
| whatever one they decide to render to, and advanced
| clients can render at any DPI, in response to the server
| advertising what DPI the current display is. With
| atomicity of configuration changes that allows a properly
| written client and server to never render an
| "intermediate" incorrect frame, and scaling that ensures
| that surfaces across multiple displays display at the
| correct DPI on all of them (albeit with either upscaling
| or downscaling on some of them.)
|
| And that still does absolutely nothing to solve the fact
| that pixel perfect layouts are inherently not perfectly
| "scalable." Because truly scaling some vector drawing
| commands that just happen to be pixel perfect at one
| resolution will not always result in pixel perfect
| rendering in another. You would need code that
| compensates for the scaling. Old X11 apps did not do
| this.
|
| Of course I could be _completely_ wrong and old X11
| could've had some amazing DPI scaling technology that I
| somehow missed for decades. I don't _think_ so. My memory
| is that when I finally hooked up a high DPI display to
| Linux, I experienced tiny Skype, Pidgin (GAIM) with tiny
| icons and large text, and nvidia-xsettings with weird
| hinting /kerning. I'd like to move on from _that_ kind of
| scaling.
|
| P.S.: PostScript doesn't do anything magic either.
| Everyone's graphics systems were PostScript inspired, and
| yet macOS wound up with the same DPI scaling conundrums
| as anyone else. Most people wouldn't tolerate desktop
| apps as blurry as a PDF at 96 DPI.
| jcelerier wrote:
| > More modern apps (-- early 2000s should be "modern"
| enough by X11 standards, but my memory is foggy and I'm
| too young to really be an expert here --) instead blit
| pixmaps sent over shmem, defeating both network
| transparency and the inherent "vector" nature of many of
| the old drawing commands. X11 didn't really handle
| anything other than knowing the DPI (... that you told it
| ...)
|
| This is entirely untrue. Did you even try ? Qt even at
| version 6 still supports rendering through X11 commands,
| and afaik does that by default when ssh'ing on Debian
| distros.
|
| And I can set my Xft.dpi to, say, 144, ssh -X somewhere
| and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will
| so far all use the correct local DPI. Which other remote
| UI technology supports that ?
| jchw wrote:
| > This is entirely untrue. Did you even try ? Qt even at
| version 6 still supports rendering through X11 commands,
| and afaik does that by default when ssh'ing on Debian
| distros.
|
| When you connect over SSH, it will fail to setup XShm and
| then it will work as expected, only slower than the speed
| of smell, because now it's shipping pixmaps over the
| network. Not all X11 clients continue to work properly if
| XShm can't be established, and hardware acceleration is
| basically a no-go despite OpenGL/glx theoretically being
| a client/server ordeal.
|
| > And I can set my Xft.dpi to, say, 144, ssh -X somewhere
| and the apps I launch (tried gtk2, gtk3, Qt 4 to 6) will
| so far all use the correct local DPI. Which other remote
| UI technology supports that ?
|
| Waypipe. Unlike X11, Wayland doesn't _start_ with network
| transparency as a principle, but it is completely
| possible to proxy it. Other than not being able to get a
| hardware-accelerated OpenGL or Vulkan context, a client
| connected over Waypipe is _very_ similar to a local
| client. The proxy can handle things like serializing data
| sent over shared memory, so UI toolkits and other client
| code doesn't need to behave any differently over the
| network; it just needs to use synchronization primitives
| correctly.
| jcelerier wrote:
| > When you connect over SSH, it will fail to setup XShm
| and then it will work as expected, only slower than the
| speed of smell, because now it's shipping pixmaps over
| the network.
|
| no, this is _false_. Here 's a video of dolphin, KDE's Qt
| 5 file manager, run over ssh on another computer: does
| that look like it's blitting pixmaps over the network ?
|
| https://www.veed.io/view/d822f1b3-305a-4af1-8df6-61439515
| ccc...
|
| When checking nload, this uses ~8 megabyte/second, I can
| let you imagine how much it would be to blit a constantly
| scrolling UI at 140 fps - I can assure you that even
| gigabit ethernet does not cut it unless compressing a lot
| :-)
| [deleted]
| jchw wrote:
| Honestly, I regret arguing on this point. There's no
| reason for me to continue on it, since it has nothing to
| do with what I was really trying to discuss about X11
| apps. Still, 8 MiB/s is a shit ton of data, and given
| that it is screen data I'm sure it would zlib compress
| very well. Is it shipping the whole app as one pixmap? I
| am not really making that claim, though I actually
| thought they dropped XRender based QPainter somewhere in
| Qt 4, but it's not plainly obvious that they did. I'll
| concede on that. It's still _mostly_ shipping pixmaps
| either way, especially depending on how things nest,
| because the text is absolutely all pixmaps, but it would
| be more efficient by a decent bit than shipping the
| entire app as pixmaps due to being able to do compositing
| on-server.
|
| It doesn't change anything about DPI independence,
| because neither XRender nor the basic X drawing functions
| provide you with scalability built-in.
| jcelerier wrote:
| > Still, 8 MiB/s is a shit ton of data,
|
| it is _minuscule_ , and it is the peak I managed to get
| when moving as fast as possible. At the same refresh
| rate, blitting, say, 1024x1024 pixmaps would yield
| 576MiB/s so here we are talking about 72 times less. And
| it's while running a moderately image-heavy app with most
| likely room for optimization. One I often use is
| pavucontrol-qt: this one gives me less than 1MiB/s of
| network traffic when resizing it madly.
|
| > It doesn't change anything about DPI independence,
| because neither XRender nor the basic X drawing functions
| provide you with scalability built-in.
|
| when I set Xft.dpi to 144 on my machine and run the same
| thing over ssh I see this:
| https://i.imgur.com/JQhEcvG.png
|
| icons are scaled, images are scaled, text is scaled...
| what is missing ?
|
| Also, regarding zlib: I took a screenshot of this window
| and compressed it as png (which uses zlib if I'm not
| mistaken ?) which gives me 137KiB, or 19MiB at 144fps. So
| more than twice as much as what X11 manages (and that is
| raw X11, IIRC there are X11 protocol extensions which
| also pass the X11 messages through gz, but I've never
| felt the need for that as things are already perfectly
| fast).
|
| If you can show me any video-compression-based
| implementation that allows me to get this close to zero
| latency with zero image degradation (especially for text,
| you really don't want subpixel font AA to be video-
| compressed) and as little network overhead as what Qt
| gives over X11 I'll be super happy, but I really think it
| is unrealistic.
| jchw wrote:
| > it is minuscule, and it is the peak I managed to get
| when moving as fast as possible. At the same refresh
| rate, blitting, say, 1024x1024 pixmaps would yield
| 576MiB/s so here we are talking about 72 times less.
|
| If 70% of the pixels are the same shade of gray, that's
| not impressive at all. If you are serializing image data
| and storing it over the network, you can do better than
| uncompressed with virtually no CPU load increase. Even
| moreso if you're doing multiple correlated frames.
|
| > when I set Xft.dpi to 144 on my machine and run the
| same thing over ssh I see this:
| https://i.imgur.com/JQhEcvG.png icons are scaled, images
| are scaled, text is scaled... what is missing ?
|
| Nothing.
|
| That scaling is done by Qt, and has all of the
| aforementioned issues with regards to scale factor.
| That's why we're talking about X11; there is no "X11" way
| of handling scaling. X11 clients are responsible to scale
| things. Even events do not get their coordinate spaces
| scaled, either.
|
| The point of this thread is not that you can't scale UIs.
| It is that GTK+4 looks bad on low DPI monitors because it
| has stopped attempting to do pixel perfect UI and instead
| uses truly scalable layout and rendering. In the truly
| scalable world, 96 DPI is as blurry as 200+, only you
| don't see it when there are more pixels.
|
| That said, Qt has _plenty_ of UI scaling bugs.
|
| > Also, regarding zlib: I took a screenshot of this
| window and compressed it as png (which uses zlib if I'm
| not mistaken ?) which gives me 137KiB, or 19MiB at
| 144fps. So more than twice as much as what X11 manages
| (and that is raw X11, IIRC there are X11 protocol
| extensions which also pass the X11 messages through gz,
| but I've never felt the need for that as things are
| already perfectly fast).
|
| Yeah, because even raw X11 with pixmaps won't redraw the
| whole screen at once. It will use dirty rects. When
| scrolling this could still be a substantial amount of
| data, but nonetheless.
|
| As I suspected, as far as I can ascertain, it really is
| just shipping pixmaps. 8 MiB/s sounds very consistent
| with what bug reports are saying;
|
| https://bugreports.qt.io/plugins/servlet/mobile#issue/QTB
| UG-...
|
| https://bugreports.qt.io/plugins/servlet/mobile#issue/QTB
| UG-...
|
| https://bugreports.qt.io/plugins/servlet/mobile#issue/QTB
| UG-...
|
| https://bugreports.qt.io/plugins/servlet/mobile#issue/QTB
| UG-...
|
| This was changed in Qt 4.8, exactly like I remember it.
| But what I didn't know was that XRender rendering was
| _reintroduced_ in 5.10, because of this exact problem.
|
| (Just to be clear, that means you get efficient SSH for
| most Qt apps, which have native mode enabled, from Qt 4.0
| to 4.8, then 5.10 onward. A substantial slice of history
| to be sure, but more limited than it seems people think.)
|
| If you're on 5.10+, you should be able to get
| _dramatically_ better performance with `-graphicssystem
| native`
|
| > If you can show me any video-compression-based
| implementation that allows me to get this close to zero
| latency with zero image degradation (especially for text,
| you really don't want subpixel font AA to be video-
| compressed) and as little network overhead as what Qt
| gives over X11 I'll be super happy, but I really think it
| is unrealistic.
|
| What can do better? Yes, it's true, compressing text with
| lossy algorithms could pose a problem.
|
| However, consider the following: if you _wanted_ to
| compress frames, you would Never ship PNGs over the
| network, at least not like this. You'd get dramatic
| savings just by XORing the current frame with the last
| frame and the RLEing that. Boom, smooth scrolling
| achieved. Combine it with dirty rects and possibly some
| other techniques and it should be good enough.
|
| Besides, at 8 MiB/s, lossless video codecs are pretty
| doable for fullsceen UI. _Modern_ VNC implementations
| (Ultra, Tiger, etc.) make a joke of this figure and can
| still get good text quality.
| jcelerier wrote:
| > Besides, at 8 MiB/s, lossless video codecs are pretty
| doable for fullsceen UI. Modern VNC implementations
| (Ultra, Tiger, etc.) make a joke of this figure and can
| still get good text quality.
|
| Here's how tigervnc looks on the exact same situation:
|
| https://www.veed.io/view/0ca6898a-a535-4f0a-accb-b22e2e18
| 4b0...
|
| Sure, it uses less bandwidth (between 2 and 2.5 MiB for
| the busy part of this video) but it is also full of
| artifacts (https://i.imgur.com/4QrV9xl.png), super slow
| compared to X11 and does not respect my local settings.
| no thanks !
| jchw wrote:
| True! VNC is not ideal because it's pretty old by now.
| Chrome Remote Desktop would've been a better example, and
| even _that_ is behind what _can_ be done, as I believe it
| still uses VP8. It 's possible even a lossless codec like
| ffv1 could be plausible in the window of 8 MiB/s, but I'm
| not sure it's necessary, as even old h264 does a pretty
| convincing job at very low bitrates.
|
| Here's a snippet of my 2256x1504 screen, uncompressed:
|
| https://files.catbox.moe/9k6cnm.png
|
| Here's a snippet of my 2256x1504 screen from an OBS
| recording:
|
| https://files.catbox.moe/va46ze.png
|
| This is using x264 at just 0.5 MiB/s. Not even pegging a
| CPU core.
|
| If you move really fast, then there are some artifacts
| during motion (same recording):
|
| https://files.catbox.moe/myhnc7.png
|
| ...But they are not really noticeable in motion, and it
| clears up quickly.
|
| I don't have a high framerate, high DPI display to test,
| but I'm guessing most people will only strongly care
| about one or the other since displays that do both are
| pretty expensive.
|
| And yeah, chroma subsampling on subpixel rendering should
| impact legibility, but in practice it's difficult for me
| to tell any difference.
|
| I've played around for a bit and I don't go above 1 MiB/s
| so far. I probably would need to play a video for that.
| jcelerier wrote:
| > Here's a snippet of my 2256x1504 screen from an OBS
| recording:
|
| I wouldn't be able to stand something like this at all,
| it looks horrible to me. The text is all smudged.
| jchw wrote:
| The only place where the text looks remotely smudged to
| me is in the low contrast bits in the header. It's very
| difficult for me to tell the difference otherwise,
| especially considering that it's high DPI.
|
| And h264 is old, and I'm using software x264 with fairly
| modest settings. More modern general video codecs like
| h265, VP9, perhaps even AV1 can eek out slightly better
| fidelity at similar bitrates, at the cost of higher
| complexity. (But if it can be hardware accelerated at
| both ends, it basically doesn't matter.)
|
| And these codecs are designed for general video
| content... it would be instructive to see exactly what
| kind of performance could be achieved if using lossless
| codecs or codecs designed for screen capture like ffv1 or
| TSC2.
|
| It would be... but honestly, there's no point, because
| all I was trying to illustrate is that I sincerely doubt
| 8 MiB/s is the best that can ever be done for a decent
| desktop experience. Judging by Qt issue reports, it's
| worse than what Qt _used_ to be able to accomplish. If
| you really like your X11 setup, there's no reason to
| change it, because it isn't going to become unusable any
| time soon. Even if you switch to Wayland in the future,
| you should still be able to use `ssh -X` with Xwayland as
| if nothing ever really changed.
|
| This is all a serious tangent. The actual point was that
| again, X11 doesn't have any built-in scaling. All along,
| it was Qt 4+, GTK 3+, and other X11 clients that have
| been handling all of the details. And traditionally, it
| wasn't good. And even contemporarily, it still has
| issues. Beckoning to the "way X11 did it" makes no sense
| because 1. X11 as a protocol or server never did anything
| 2. Even then, historically toolkits have had a lot of
| trouble dealing with it. The fact that you set the DPI
| for Xft _specifically_ , which is _just_ a font rendering
| library, hints at the reality: what oldschool X11
| "scaling" amounted to in the 2000s was changing how font
| sizes were calculated. Modern toolkits just read this
| value to infer the setting, and it still isn't good
| enough for many modern setups that Linux desktops _want
| to support_.
| zozbot234 wrote:
| > For example, if you want a crisp 1px border on 96 dpi,
| you could specify it to be a 1px border at 96 dpi... but
| then what happens at 1.5x or 1.75x scale?
|
| The border width should get snapped to the physical
| (sub-)pixel resolution as part of rendering. Typically,
| this should come with changes in contrast too, such that if
| a line is forced to become thinner it also gets drawn with
| higher contrast wrt. the surroundings, and vice versa. All
| of this stuff can be made to work.
|
| Also, if you are forced to render a canvas at a resampled
| resolution because existing APIs give you no other choice,
| at least do it right using a proper Lanczos-style
| resampling. This might end up with a quaint "watercolor"
| effect but guess what, that's a lot better than a blurry,
| eye-fatiguing mess.
| jchw wrote:
| > All of this stuff can be made to work.
|
| We've tolerated a great degree of complexity just to make
| fonts look good at 96 DPI. Looks like we're able to
| tolerate a bit more complexity to enable GPU rendering.
| However, many years into having high DPI displays, it's
| not obvious people are willing to take the complexity to
| make low DPI and high DPI screens look good
| simultaneously.
|
| The thing is, with _fonts_ , we already bear the burden
| of font rendering being complex because that was needed
| for 96 DPI displays. But, we won't need much of this
| magic or complexity when a vast majority of people are
| using higher DPI displays, because at >200 PPI the
| difference between a blurry line and a sharp line is
| basically nil. That is obvious enough on Apple platforms,
| where many are perfectly happy with the scaling even
| though it uses 2x as a base for all scales.
|
| I think the future is simply pain. People want cleaner
| graphics pipelines, and only high DPI displays will get
| them anywhere.
| hedora wrote:
| Can't the font renderer render a straight line? Like sans
| serif "I"?
|
| The font rasterizer already exists (unless it is a bitmap
| font UI, but those aren't common any more).
|
| How does adding additional mechanisms make for a simpler
| or cleaner rendering pipeline?
| jchw wrote:
| The font rasterizer is a massive hack in modern UIs.
| Subpixel rendering is a serious pain in the ass. When you
| render text using subpixel rendering, you render the
| actual vectors at 3x the spatial resolution. But, not
| simply _as if_ the vectors were 3x wider, because that
| would look too sharp: it needs to render as if there was
| 3x as many pixels, which is different.
|
| Then there's compositing. Normal layers can be composited
| using alpha blending, assuming some sane format like
| premultiplied alpha RGBA. But not subpixel rendered text,
| because alpha blending the components will fuck up the
| subpixel rendering.
|
| And it goes on, because if you want to handle text like
| everything else, you need special cases for it to look
| right. Rotation? Need to render the vectors rotated;
| can't rotate in raster. If you need to render to a
| surface then transform that surface, you're SOL; it can't
| go to rasters until the end.
|
| Normal surfaces can also be rendered at subpixel
| positions, and of course this does not work for surfaces
| containing text, because again, it will destroy the
| subpixel rendering.
|
| OK. So you can get rid of the subpixel rendering and
| render slightly blurrier glyphs instead. (R.I.P. anyone
| trying to tell hanzi/kanji apart.) It's still going to
| murder legibility if you move it over by a subpixel value
| because text is already on the edge of readability at 96
| DPI.
|
| I haven't considered gamma correction, hinting, blending
| different colors, different blending modes, GPU
| acceleration, etc. because I simply don't have the brain
| power to try to reconcile it all. It's a nightmare.
|
| We already did some of this for _text_. Which is a
| herculean effort. We use a freakin _virtual machine_ to
| power font hinting, and ugly, complex, slow special
| casing at many layers of already ridiculously complex
| vector graphics stacks (I mean if you disagree with that
| assessment, you may just be smarter than I am, but I have
| serious trouble following the Skia codebase and I doubt
| Cairo is really that much better.) And speaking of which,
| there only really seems to be a _handful_ of them out
| there: there's Skia, used by most web browsers; Cairo,
| used by GTK; Direct2D, in Windows; Whatever modern macOS
| uses that isn't QuickDraw anymore; and I guess there's
| Mozilla's pathfinder, a promising Rust-based vector
| graphics engine that was built as part of Servo and
| seemingly mostly abandoned, much to the world's
| detriment. This work is _hard_. It can be done, but it's
| not something I think a single engineer can do, if you
| want to build one that competes with the big boys even
| disregarding a few things like performance. I'd love to
| be wrong, but I have a sinking feeling I'm not.
|
| Even text isn't done being overcomplicated. As nyanpasu
| has mentioned above, some software have started
| implementing SDFs for font scaling. We do this because
| text legibility is really that important, whereas a line
| in the UI being slightly blurry for users on older
| screens is really just not that important. Some languages
| flat out can't be read with crappy font rendering, and
| any of them will give you eyestrain if it's ugly enough.
| As much as it sucks, a blurry border on a button doesn't
| have an accessibility issue. And rendering at 1x and
| making the compositor upscale is not a great solution
| either because again, it's already hard enough to read
| text in some languages; the added blurriness of scaling
| text and ruining subpixels is basically intolerable.
|
| These hacks aren't free, and with high DPI displays,
| they're not needed. There's a reason Apple did what they
| did.
| audidude wrote:
| > some software have started implementing SDFs for font
| scaling
|
| My "wip/chergert/glyphy" branch of GTK 4 does rendering
| using https://github.com/behdad/glyphy which uses fields
| to create encoded arc lists and are uploaded to the GPU
| in texture atlases. The shaders then use that data to
| render the glyph at any scale/offset.
|
| Some work is still needed to land this in GTK 4,
| particularly around path simplification (mostly done) and
| slight hinting (probably will land in harfbuzz).
| hedora wrote:
| OK, but there's clearly an existence proof, and it ran
| fine on 32 bit machines with slow processors (or even
| embedded CPUs in the 80's!) way before all the piled
| hacks you are describing were invented.
|
| As I understand it, all that's needed is a vector
| renderer, and you keep everything (even text) in vector
| format as long as possible. RGBA then becomes a special
| case, as it must be for any DPI independent rendering
| pipeline.
|
| Trying to compose rendered vectors using pixel based
| operations is madness, so... don't?
|
| That means you can't have a bitmap-based compositor. So
| what? GPU's are great at rendering vectors. Composite
| those instead of bitmaps.
|
| Or, just don't composite at all. A decade later, Linux
| desktop compositors are still an ergonomic regression vs.
| existing display drivers with vsync and double buffering
| support.
| jchw wrote:
| > OK, but there's clearly an existence proof, and it ran
| fine on 32 bit machines with slow processors (or even
| embedded CPUs in the 80's!) way before all the piled
| hacks you are describing were invented.
|
| Yes. Driving ~1024x768 framebuffers, on single core
| processors, with far less demanding workloads, but still,
| yes. (They still badly needed good glyph caching to
| accomplish this.) (I'm assuming a Windows XP-tier machine
| since that was the era most people started using
| ClearType/subpixel rendering.)
|
| (Single core processors are obviously _slower_ than
| multicore processors, all else equals, but exploiting
| multi-core processors effectively is harder and often
| leads to code that is at least a bit slower in the
| single-core case...)
|
| > As I understand it, all that's needed is a vector
| renderer, and you keep everything (even text) in vector
| format as long as possible. RGBA then becomes a special
| case, as it must be for any DPI independent rendering
| pipeline.
|
| I don't want to sound like I'm being patronizing, but I
| get the feeling that you may not be grasping the problem.
|
| We can't just use text rendering logic to power other
| vector graphics. For many reasons. Text is _not_ just
| rendered like vectors, as that would simply be too blurry
| at 96 DPI. Old computers used bitmap fonts or
| _aggressive_ hinting, and newer computers use anti-
| aliasing, often with subpixel anti-aliasing. Doing that
| with every line on screen isn't feasible even if you
| wanted to write the code. Here's an attempt to enumerate
| just the obvious reasons why:
|
| - It's slow. Yes, old 32 bit computers could do it, yadda
| yadda ya. But they did it _for text_. At the _glyph_
| level. And then _cached it_. They were most certainly
| _not_ rendering anything near the entire size of the
| framebuffer at once.
|
| - It's difficult to GPU--accelerate. GPUs can do vector
| graphics and alpha blending _fast_ , but subpixel
| rendering as its done with text is not something that can
| be done using typical GPU rendering paths. It could still
| be made to exploit GPUs, but it requires more work and is
| slower.
|
| - Fonts achieve better crispness on lower DPI displays
| using hinting VMs. Without them, many glyphs would be
| quite blurry. Hinting VMs allow typographers making font
| outlines to make specific decisions about when and how
| vectors should be adjusted to look good on raster
| displays. In case it isn't obvious, the problem here is
| that doing this for every line on the screen requires you
| to write _special casing_ for every line on the screen.
| Maybe you could come up with a general rule that makes
| everything look good and doesn't wind up with uneven
| looking margins or outlines ever (you really can't,
| but...) -- you have to run this logic for _every line_.
| That's an increase in complexity.
|
| - Glyphs only need to care about their relationships with
| eachother. UI elements on screen have arbitrary concerns.
| They have relationships with other things on screen; they
| line up with other shapes and the whitespace between them
| is significant. Glyphs only care about other glyphs
| horizontally adjacent to them (or vertically in some
| scripts, perhaps) but other UI elements care about their
| relationship with potentially any neighboring UI
| elements.
|
| - UI rendering code does not exist in a vacuum. At some
| point, apps will need to do something that requires them
| to know the size of something on screen either in
| physical or logical dimensions. Normally, this isn't a
| problem, but if all vector rendering was as complex as
| text, it would absolutely be an issue. The naive way of
| handling it would seem correct in many cases, but it
| would be wrong in many others, just like how old APIs
| that expose pixels instead of logical units tend to lead
| to apps with subtle scaling issues.
|
| > Trying to compose rendered vectors using pixel based
| operations is madness, so... don't?
|
| Yes, of course.
|
| Except that, too, is hard. Think about web browsers: they
| need to support arbitrarily large layers for composition
| (like extremely long text in an overflow: scroll div,)
| and these layers can nest in arbitrarily deep and complex
| trees. Any node on this tree can apply transformations,
| masks, filters, drop shadows... In theory, most of this
| stuff _should_ be doable without ever leaving vector
| land, but it's absolutely not without its challenges.
|
| > Or, just don't composite at all. A decade later, Linux
| desktop compositors are still an ergonomic regression vs.
| existing display drivers with vsync and double buffering
| support.
|
| Hrm... I'm not talking about _desktop_ compositing. Even
| modern desktop compositors render surfaces at pixel
| positions, so it doesn't really cause any additional
| issues. I'm talking about the kind of compositing that
| GTK or Firefox do.
|
| That said, I do agree that desktop compositing on Linux,
| especially X11, has been less than ideal. However, it
| certainly isn't standing still; the situation with
| compositing on Wayland and open source GPU drivers has
| been much more promising. You still get a lot of the
| trademark issues with compositing that are pretty much
| inherent, but I have perfect vsync with good frame pacing
| and a solid 2 frame latency end-to-end in Chromium on
| SwayWM. I believe that's close to ideal for a surface
| running under a compositor. A far cry from the
| compromise-riddled world of old GPU accelerated
| compositing.
| zozbot234 wrote:
| The underlying logic for rendering "hinted" line borders
| and UI widgets is a lot _simpler_ than for hinting
| arbitrary text. It 's a matter of snapping a few key
| control points to the pixel grid, and making sure that
| key line widths take up integer numbers of pixels. Much
| of the complexity you point out only arises because we
| now insist on having physically sized rendering for
| "mixed-DPI" graphics, like a single window spanning both
| a low- and a high-resolution display. That's not
| necessarily a very sensible goal, and it's not something
| that would've been insisted on back when achieving "pixel
| perfect" rendering was in fact a major concern,
| regardless of display resolution.
|
| A similar concern is the demand for arbitrary subpixel
| positioning of screen content, that basically only
| matters in the context of on-screen animations. Nobody
| really cares if an animation looks blurry, but it's
| somewhat more important for static content to look right.
| Trying to have one's cake and eat it too will always be
| harder than just focusing on what's actually important
| for good UX.
| jchw wrote:
| > The underlying logic for rendering "hinted" line
| borders and UI widgets is a lot simpler than for hinting
| arbitrary text. It's a matter of snapping a few key
| control points to the pixel grid, and making sure that
| key line widths take up integer numbers of pixels.
|
| This is exactly what I was "hinting" at when I said
| coming up with a universal function that would work for
| anything. You can't just snap some/all things to a pixel
| grid; it would look absolutely terrible because it would
| make lines and whitespace uneven. Even font autohinting,
| which does exist, is more sophisticated than _just_
| aligning key control points to a pixel grid.
|
| > Much of the complexity you point out only arises
| because we now insist on having physically sized
| rendering for "mixed-DPI" graphics, like a single window
| spanning both a low- and a high-resolution display.
| That's not necessarily a very sensible goal, and it's not
| something that would've been insisted on back when
| achieving "pixel perfect" rendering was in fact a major
| concern, regardless of display resolution.
|
| It's not. Even under Wayland, which _can_ achieve this,
| the application would only render one surface at a
| specific resolution at any given time. Nothing I've been
| talking about is related to being able to split a window
| across different DPI screens.
|
| > A similar concern is the demand for arbitrary subpixel
| positioning of screen content, that basically only
| matters in the context of on-screen animations. Nobody
| really cares if an animation looks blurry, but it's
| somewhat more important for static content to look right.
| Trying to have one's cake and eat it too will always be
| harder than just focusing on what's actually important
| for good UX.
|
| If you scale a UI that was designed for 96 DPI pixels to
| a screen that is around 160 DPI, you already have
| subpixels. If you then attempt to snap to a pixel grid
| instead of rendering elements at subpixel positions, then
| you have uneven, ugly looking UI elements.
|
| This unevenness is arguably _more_ tolerable for text
| than it is for UI elements, but Microsoft actually took
| the approach of not having it for text regardless; to
| make text look cleaner, text uses more aggressive
| gridfitting in Microsoft UIs, resulting in each _glyph_
| being gridfit. This is exactly why _old_ Windows UI
| scaling lead to cut off text and other text oddities;
| it's because the grid fitting lead to text that had
| different logical widths when rendered at different
| resolutions!
|
| You can't just wish away subpixels. Numbers that just
| happen to be whole numbers are the real edge cases in a
| world with arbitrary scale factors.
| zozbot234 wrote:
| > it would make lines and whitespace uneven
|
| Are we talking about single-pixel rounding errors, or
| something else? The former are already practically
| undetectable at 1080p, and nearly-so at 768p. Given a
| high standard of "pixel-perfect" rendering, there's
| basically zero reason to push resolution any higher!
|
| Of course one _can_ even make pure subpixel-based
| rendering (no fitting-to-pixels at all) look correct, by
| starting either from pure vectors or from a higher-
| resolution raster and then using a Lanczos-style filter
| to preserve perceived sharpness near the resolution limit
| of the display. This gets us as near as practicable to
| something that 's almost "pixel perfect", without
| distorting spatial positions to make them precisely fit a
| pixel grid.
| layer8 wrote:
| I've come to the same conclusion. Making hi(-ish)-DPI
| work would be possible with the right APIs. But it's
| virtually impossible to also make it work for traditional
| low-DPI displays at the same time. The departure from
| pixel-art icons to vector icons alone has already
| degraded the low-DPI experience substantially. It doesn't
| help that developers and designers tend to not use low-
| DPI displays anymore. But many regular users will,
| because it continues to be the cheaper option, also in
| GPU terms for gamers. Full-HD monitors won't be going
| away anytime soon. Meanwhile, the mid-DPI space (e.g.
| 1440p) is in an uncanny valley, often requiring
| fractional scaling (more than 100%, less than 200%)
| unless you have excellent eyesight.
| charrondev wrote:
| This is the reason I skipped 1440p altogether and jumped
| to 1080p@2x.
|
| My eyesight isn't the greatest so to run 1440p I need to
| run 1.5x which makes a lot of things work really badly.
| zozbot234 wrote:
| You could do text hinting (snapping to the (sub-)pixel grid)
| _after_ layout, based on some kind of auto-hinting
| heuristics. Arguably, this is needed anyway because text gets
| "laid out" all the time as part of advanced typesetting,
| including all sorts of complex microtypography that doesn't
| really play well with the old-fashioned "bitmap font" type of
| hinting.
| nyanpasu64 wrote:
| I proposed and implemented snapping vertical positions to
| the pixel grid _after_ layout: https://gitlab.gnome.org/GNO
| ME/gtk/-/issues/3787#note_127656...
|
| The maintainer responded that "[c]hanges to the rounding
| behavior of glyph positions really belong into pango,
| though". I understand, but I don't know whether he's
| suggesting fractional layout but integer-rounded rendering,
| or integer-rounded line heights and layout and rendering.
| And I don't know how to change Pango, and lost interest in
| digging further.
| wakeupcall wrote:
| Which is why QtQuick controls always looked like absolute
| garbage. And firefox degraded as well when webrender got
| enabled.
|
| I'm not sure I follow the upstream reasoning, in either
| gtk/qt/firefox/chrome... I'm reading text all day. The UI is
| still built around 90%+ text, except in very few edge cases.
|
| I'm using 4k monitors, and I'm still a minority. Despite this,
| at 4k, we're still several years away from the point where we
| can turn off hinting. Probably a decade away for universal
| support. A lot more if we include existing monitors.
|
| Between 92 and 270 dpi text _still_ looks bad without proper
| grid fitting. Under 120dpi we 're talking about garbage-level
| quality. And between 250-300 the difference is still noticeable
| to make it worth it.
|
| I'm not sure what these people are smoking.
| zozbot234 wrote:
| It looks like garbage _because_ of poor rendering quality.
| There 's no theoretical reason why a screen could not look
| quite sharp even at 768p, and literally perfect at 1080p;
| anything higher would then be pure overkill or at best
| catering to a tiny minority of users with superhuman
| eyesight. You don't even need hinting or fitting to a pixel
| grid for "correct" rendering, it's just generally easier that
| way. But you can't let the rendering itself blur stuff and
| waste screen resolution - you need a good resampling filter
| to preserve sharpness even at the highest spatial
| frequencies, and the typical bilinear/bicubic approach
| doesn't do that.
| tshaddox wrote:
| > The dark theme, while not officially supported as a normal
| application theme, works absolutely brilliantly and is a great
| example of how to design a dark theme.
|
| There are only three small screenshots of UI in the dark theme,
| but to me it looks very clearly like a naive "invert all the
| design token colors and call it a day" implementation.
| eternityforest wrote:
| Flat design is pretty awful. It really does seem to be popular
| because it's the minimum possible amount of design.
|
| Skeuomorphism definitely is harder to get right and different
| elements can clash. But that's less of an issue when you're
| making one unified theme for all.
| hoistbypetard wrote:
| The old button was good in the desktop context, but I can't get
| behind this point:
|
| > The design even works very well on Linux phone formfactors.
|
| The author must mean something very different when they say
| "works very well" than I do when I say that. As much as I want it
| to, nothing about GTK works well in a phone form factor, IME. I
| look forward to continued improvement that will make that
| statement incorrect.
| xedrac wrote:
| I for one don't want the phone form factor to influence my
| desktop experience. They are two completely different workflows
| that have conflicting needs IMO.
| zozbot234 wrote:
| The main influence so far has been enabling smaller window
| sizes for gtk+3/libhandy apps, which is good for all users
| especially those on older, lower-res hardware. Hopefully
| libadwaita can get forked into something like a libhandy
| equivalent for gtk+4, that otherwise preserves sane defaults
| doesn't enforce their silly "flat" theme choices.
| traverseda wrote:
| >The main influence so far has been enabling smaller window
| sizes for gtk+3/libhandy apps
|
| I don't think so, touch targets are a lot bigger. Using the
| default theme for both a KDE App with equivalent
| functionality will take a fair bit less space than a
| similar gnome app. Of course I think plasma mobile uses a
| theme that makes the touch targets bigger...
|
| KDE also manages to get a lot more functionality into their
| similarily sized windows. Take a look at this page showing
| comparisons:
|
| https://www.linuxadictos.com/en/aplicaciones-de-gnome-y-
| apli...
| linguae wrote:
| Agreed. The major sin of modern UI/UX is the desire to create
| a one-size-fits-all experience that works for both touch
| devices and desktops, when in reality the work styles of
| touch devices and desktops are very different. Unfortunately
| Windows (since Windows 8), macOS (since Big Sur), and GNOME
| (since GNOME 3) have sought (and continue to seek) these
| unified designs that work okay on touch devices but are a
| downgrade on desktops. The desktop reached its zenith in the
| late 2000s with Windows 7, Mac OS X Snow Leopard, GNOME 2,
| and KDE 3, and today's desktops are a downgrade from these
| (though KDE Plasma is nice and is an improvement over KDE 3).
|
| I'll go as far as to say that the desktop experience hasn't
| received much love by major software companies; since the
| late 2000s the money has gone toward smartphones, tablets,
| and the Web. Since those platforms get the attention, the
| desktop is increasingly getting populated with ports of
| smartphone and Web apps; hence, Windows Metro/UWP, Catalyst,
| Electron, and the like.
| userbinator wrote:
| > TASKS WILL APPEAR HERE
|
| Another one of those things that irritates me about "modern"
| design --- instead of showing an empty list, which would've been
| obvious that it was empty by having subtle cues like gridlines
| (also now disappeared by this trend), it decides to treat you
| like an idiot and show a giant banner stating what should be
| obvious. The "Add Tasks" button probably disappears after you
| make the list non-empty, and just looking at that UI, I'm not
| sure where the "normal" one is. But I guess it gave a designer an
| excuse to create some more bland Corporate Memphis art?
| alexchamberlain wrote:
| I think the Disney+ app has to be rock bottom of button design -
| the blue rounded one is selected, the white flat one is not. I
| always get it the wrong way around, even after several months of
| making the mistake.
| j1elo wrote:
| > _I feel like the designers of this new theme have never sit
| down with anyone who 's not a "techie" to explain to them how to
| use a computer._
|
| The designers of this new "everything is flat and devoid of
| visual hinting" trends are maybe, at most, enthusiast, but not
| professional designers. I don't mean professional in the "hired
| for work" sense, but in the "really has the knowledge and has
| studied the psychology behind what makes a good UI design for
| human beings". Otherwise, nobody with solid background,
| experience, and/or scientific studies in their hands would in
| their right mind sketch the current shape of mindless "modern"
| UIs on a paper and feel like that's a very well thought out work
| right there.
|
| And here I'm bashing not only OSS designers that think a bland
| and unclear design is the best that can be done, but also the
| same for designers of big companies that get paid for their work.
| Althought ironically now that I think of it, maybe the latter are
| somewhat less to blame, knowing how the corporate world works and
| knowing that they possibly don't agree with the results but their
| boss insists on how all buttons should lack any depth. So in the
| sense of not having a pushy boss with an agenda to fullfill...
| yeah it seems to me that OSS designers are acting _worse_ by
| voluntarily pushing these supposedly "better", but almost quite
| objetively worse designs, into users' throats.
|
| /rant
| eterevsky wrote:
| > nobody with solid background, experience, and/or scientific
| studies in their hands would in their right mind sketch the
| current shape of mindless "modern" UIs
|
| So... Since you are talking about scientific studies, could you
| please reference some studies that back you up and show that
| flat design is in some way inferior?
| pornel wrote:
| macOS has the same problem: everything is flat. There are no
| borders around many buttons. It's hard to tell what is a label
| and what is a button, or which controls are disabled, and which
| are merely de-emphasized.
|
| Apple used to be held as the pinnacle of design, but what does
| it say when their latest UI is indistinguishable from an
| amateur design?
| pessimizer wrote:
| Apple _marketed itself_ as the pinnacle of design.
| eru wrote:
| To slighly go off on a tangent:
|
| You note that visual and UI design in open source and in
| proprietary applications show some of the same idiosyncrasies.
|
| You conclude that this makes open source designers more
| blameworthy.
|
| I would suggest instead, that this is evidence that those evil
| management overlords in the corporate world are perhaps
| convenient scapegoats, but actually less to blame than we might
| think?
| girvo wrote:
| To back this up, the "actually has a degree in HCI" UX
| profressionals I worked with at a previous job railed against
| flat design and ensured our output was clear and intuitive.
| Though there was only two of them, so I can't say _all_ of them
| would be like that!
| sgt wrote:
| > I personally don't like the flat look. I think Microsoft was
| stupid for doing it. I think Apple is stupid for doing it and
| I've been praising Adwaita for being the sane option in an insane
| world.
|
| I partly agree. Flat look done poorly is terrible. Apple is the
| only company who's been semi-consistently doing this well.
| id02009 wrote:
| I think designer's easily forget that trends exist, and what
| people want is a mix of what's useful but also new and popular.
| ajyotirmay wrote:
| As he mentions at the 4nd of his blog, Qt/KDE is his only option
| if he actually wants decent software specially one where he wants
| to be heard.
| phendrenad2 wrote:
| You can't make an omelette without breaking a few eggs. (You
| can't break the back of modularity-induced fragmentation and make
| a consistent GUI without making a few people unhappy with the UI
| design that the majority chose).
|
| That is Gnome. Gnome has become a top-down project that values
| consistency/coherency over modularity/theming. It's an extreme,
| and I suspect that they went too far, but with it comes a number
| of benefits, such as a unified visual style across all apps, and
| an easy to use internationalization/localization subsystem.
| phkahler wrote:
| >> You can't break the back of modularity-induced fragmentation
| and make a consistent GUI without making a few people unhappy
| with the UI design that the majority chose
|
| Not sure what that even means. The majority are not the Gnome
| developers, and many users will just adapt to whatever they're
| fed, even if it's worse.
|
| >> That is Gnome. Gnome has become a top-down project that
| values consistency/coherency over modularity/theming.
|
| No. People aren't complaining about a lack of consistency or a
| lack of theming (some do). They are complaining about a shitty
| design where the elements are consistently nonsensical and
| harder to understand than past version of the same.
|
| Top-down means a few people who are at "the top" think they
| know better. Not that they're great designers either - they are
| copying stupid trends that other "design" people came up with.
| This stuff is complained about on all OSes these days. It's not
| a vocal minority either, and you can tell because nobody
| complained that GTK was falling beind and needed to update to a
| modern "flat" design.
| phendrenad2 wrote:
| What you're not understanding is, just because something
| seems nonsensical to you doesn't mean that the majority of
| users don't find it perfectly reasonable. But you've already
| waved that possibility away by saying that most users will
| take whatever they're given, so I don't suppose you'll
| consider it.
| qalmakka wrote:
| > That is Gnome. Gnome has become a top-down project that
| values consistency/coherency over modularity/theming
|
| They care about that so much that they break Gtk+ every few
| version, to the point that in 2022 there are still Gtk+ 2 apps
| around, and there will be Gtk+ 3 apps following old design
| paradigms for years to come. So much for consistency.
|
| It's 2022 and I don't see Qt 4 around anymore, or apps using it
| still being widely in use. Guess why? Because Qt developers
| actually give a damn about people using their library, and they
| give a damn about people using the _latest_ version of it.
|
| What GNOME is doing today is telling everyone to go fuck
| themselves, and pushing people towards writing their next app
| in Qt, which by the way integrates nicely with GNOME and does
| not look like garbage everywhere else. Now with PySide being
| finally a first class citizen and working well with QML there's
| not even the "but C++ is ugly" card to play against going Qt.
| fxtentacle wrote:
| No, this will just fragment app developers into those that use
| GTK4 and those that keep using GTK3.
| zozbot234 wrote:
| Gtk+ 3 with a custom theme allowed for a unified visual style
| across _all_ desktop environments, not just GNOME. I could use
| a MATE- or Xfce-bundled app and not have it look out of place
| in a GNOME desktop, or vice versa. It 's sad to lose this
| because of a combination of pointless churn and active
| hostility ("don't theme my app") to outside efforts that might
| improve the ecosystem.
| ricardobeat wrote:
| > In this dark theme the edges and divider in the theme suddenly
| become light. I find this really jarring and it looks like it's
| just an inverted theme
|
| You're just used to the wrong approach, the old one actually is
| an inverted-grayscale theme.
|
| The new one correctly follows the principle that foreground ==
| lighter, background == darker in dark mode.
| blacklion wrote:
| Why. Does. These. Interfaces. Have. This. Amount. Of. Empty.
| Space?!
|
| Looks like all these "Connected - 1000Mb/s" can be 2-2.5 times
| more compact in V direction. And huge spaces between labels and
| controls. Why do we need these?!
|
| It is plague of last years. You have FullHD screen, you see 3-4
| options in FireFox settings,when "old skool" UI could pack all of
| them onto one FullHD screen.
|
| It is everywhere. Huge spaces, scrollbars (which doesn't work
| with keyboard, as controls intercept focus)... Scrollbars are for
| text, not for GU!
| smoldesu wrote:
| I've always thought that GTK was great at filling the screen
| with interactive elements. Almost too good, actually. The GTK
| versions of certain apps like Handbrake and Transmission have
| almost no whitespace...
| minroot wrote:
| I saw a few screenshots of GTK4 apps, it looked nice. But today
| tried a simple one, as like the author, I was disappointed.
| mise_en_place wrote:
| The Linux ecosystem is having a similar identity crisis as
| Microsoft and Apple. Some are of the opinion it should be mobile
| first, desktop first, or server/IOT/embedded. These are all
| competing concerns and will lead to further fragmentation in an
| already fragmented ecosystem.
|
| The design of libadwaita is very reminiscent of the time I was at
| Apple. Around the time they decided to unify the codebase and lay
| off the entire OS X team and reorg it into a new software team. I
| noticed the design changes as part of dogfooding internal OS X
| versions and design changes were jarring to say the least.
|
| In short, a product cannot be all things to all people. It should
| play to its strengths and delight it's existing and new
| customers/users.
| jh721 wrote:
| There is actually a thread about the flat buttons on the issue
| tracker of libadwaita:
| https://gitlab.gnome.org/GNOME/libadwaita/-/issues/228
| woah wrote:
| Non techies have been using flat design interfaces for like a
| decade now and the world hasn't ended. If you personally like
| another style, totally fine. But it's odd that programmers always
| think they know more about usability than people who study it for
| a living.
| throw_m239339 wrote:
| The problem isn't techies but non techies, unless you think
| only techies should be using Linux GUI...
|
| > I have had to explain to people tons of times that the random
| word in the UI somewhere in an application is actually a button
| they can press to invoke an action.
|
| There is a reason why Apple backpedaled on all that flat
| insanity for MacOS and iOS. Graphic designers and trendsetters
| usually know very little about usability, these are 2
| completely different disciplines, and the Flat style was
| imposed by graphic designers, not UX people.
| linguae wrote:
| Do non-techies have a choice, though? Given the lack of theming
| in many modern apps, its not like users have a choice between
| flat design and the designs of the 90s and 2000s. What about
| sticking to old versions? I can only use old versions of
| software for so long before it becomes infeasible for many
| reasons (security and interoperability being the biggest
| reasons), and even on Linux where users have a great deal of
| control, not all GUI software is themable.
|
| It's not just programmers who complain about modern UI/UX
| trends. The Nielsen Norman Group, a UI/UX consulting group that
| was founded by HCI legends Don Norman and Jakob Nielsen, have
| written articles against the overuse of flat design
| (https://www.nngroup.com/articles/flat-design/).
| Aeolun wrote:
| > But it's odd that programmers always think they know more
| about usability than people who study it for a living.
|
| I'm sure it has something to do with them needing to justify
| their existence. No reason to have a designer if nothing has
| changed in the world of design. Programmers learn new languages
| (or go back to old ones), designers do the same with interface
| design principles.
| StewardMcOy wrote:
| I tend to see it from the opposite perspective. Physical
| looking buttons, borders, and always-visible controls were
| designs born from rigorous user testing in the 1980s and early
| 1990s. The push to flat design that really picked up steam
| around a decade ago did not have, as far as I can tell, the
| same level of testing, and was promoted largely by programmers
| who wanted designs that were easier to implement.
|
| Platform developers were incentivized to go flat because it
| lowered the cost of development and development time if
| developers were using fewer, simpler custom assets. At this
| time, both Apple and Google were bragging about how many apps
| were on their stores, and how fast they were growing, and
| neither wanted to fall behind the other.
|
| But admittedly, my perspective was that of a third-party
| developer. I have no direct knowledge of why Microsoft, Google,
| and Apple all embraced this trend, and I have only anecdotal
| evidence that it made things more difficult for novice users.
| There could be a treasure trove of research showing that flat
| is better, but I have never seen it presented.
| reidrac wrote:
| > The feedback I get is that I should move to QT/KDE [...]
|
| That, at least, has been consistent since first release of Gnome
| 3 over 10 years ago.
|
| Honestly, I don't know why I tried that hard to like the new
| Gnome. I'm so much happier using XFCE.
| loeg wrote:
| > Now one of the worst parts is that everywhere I only even hint
| at not completely loving the new libadwaita theme I instantly get
| shut down and disagreed with before I can even get the chance to
| give some feedback. Apparently not liking flat themes makes me a
| madman in this world. Why am I not allowed to even have opinions
| about the look of the operating system I'm using?
|
| Ah, it was the same way if you didn't love the direction they
| went with GNOME 3. If you don't love the design-of-the-day GNOME
| is chasing, they don't want you. I recommend KDE.
| Andrew_nenakhov wrote:
| Gnome3 is a disaster. When Ubuntu made the switch to Unity and
| dropped Gnome2 support, I played around it and said, "nah", and
| went for Gnome... And after using it a bit I suddenly thought
| they Unity Desktop is not all that bad. With time it even grew
| on me, especially the saved vertical space.
|
| Current Gnome is still unusable crap, with all those ugly
| buttons in window titles and lots of wasted space.
| malermeister wrote:
| libadwaita is very unfortunate in general and the zeal of the
| GNOME community has been very off-putting
| naoqj wrote:
| Can you elaborate? Especially about the first part
| smoldesu wrote:
| They're probably referring to the functional regressions it
| made with it's first official release, and how it furthers
| the idea of GNOME/GTK lock-in. libadwaita has made it
| extremely difficult to package cross-platform desktop apps,
| especially while appearing native on different desktops (eg.
| adopting the native Breeze look on KDE while retaining the
| native Adwaita look on GNOME). The lack of this functionality
| at launch (and subsequent empty promises of a replacement)
| have rightfully left a bad taste in some people's mouth,
| particularly now that much of the GNOME leadership denies
| that this is a problem in the first place.
| Gualdrapo wrote:
| I don't think adwaita is that bad, but rather feel like they
| _yet_ have to polish some small details.
|
| Like the interline spacing on things, sometimes it feels
| inconsistent. KDE menus, for example, have a nice spacing -
| but GTK ones feel cramped. And those submenus that they place
| on things like the top-right menu on the panel have different
| line heights.
|
| Some other third party apps, for example that mail client I
| tried the other day (it wasn't evolution, but I can't
| remember its name) had serious layout issues. libadwaita was
| supposed to fix those inconsistencies and make devs lifes
| happier, but...
|
| And speaking of buttons and top right corners, I will never,
| ever get why they place the open/save/select dialog buttons
| in the top right corner of the dialog. Where you are used to
| find the 'close' button. Why?
| pmlnr wrote:
| >Now one of the worst parts is that everywhere I only even hint
| at not completely loving the new libadwaita theme I instantly get
| shut down and disagreed with before I can even get the chance to
| give some feedback.
|
| Gtk2 -> Gtk3 dejavu.
| rwmj wrote:
| To be honest they all look terrible. The clearest design I've
| seen recently is in Haiku. https://www.haiku-
| os.org/slideshows/haiku-1/
| pmontra wrote:
| Wait ten years. New people will start working, old people will
| move on to other things. The new people will change stuff, mostly
| for the sake of it as it always happens, and one of the results
| will be less flat interfaces. Old people will be infuriated by
| the change. Very old people will rejoice but also complain that
| those UIs are not as good as the really old ones. New people will
| shrug them away and keep changing stuff mostly for the sake of it
| as it always happens.
| zozbot234 wrote:
| It's already happening, new interfaces from both Apple (see Big
| Sur/Monterey) and Google (Material design) are noticeably less
| "flat" and going back to 3d effects for "active" widgets. The
| effects are much as seen in GTK+ 3 - just subtle enough to not
| look overly confusing when compared to a totally "flat"
| screenshot, but still helpful to unfamiliar users.
| pmontra wrote:
| So maybe GTK 5 will take notice 10 years from now, when GTK 4
| will start looking outdated in 2024.
| michaelmrose wrote:
| This presumes that all things are equally good and the only
| difference is familiarity. This isn't generally true of other
| functional areas of endeavor. Neither computers nor cars are
| all alike save aesthetics. I see no reason why it would be true
| of UIs.
| kzrdude wrote:
| To say that it is the pinnacle of design is a wide stretch give
| what they did to menus in all the apps. Obscure buttons and
| burger menus replaced menus..
| dm319 wrote:
| I suppose the price you pay of having a consistent desktop
| experience is that changes to the desktop look affect the look of
| your app, and you don't have much control over this.
|
| From a user perspective, I prefer this the hodge podge on Windows
| which I find disorientating. But I agree that a bit of non-
| flatness can be very helpful for the eyes.
| MarkusWandel wrote:
| When it comes to UI stupidity in general, here are two from my
| work machine (Windows 10 laptop).
|
| - there's the prominent notification speech bubble on the bottom
| right, which seems to be very inconsistently used. Almost all the
| notifications are duplications of an already popped-up
| notification, and a lot of important stuff doesn't end up in
| there. So it's just a nuisance. The worst is that for one
| application, the notification essentially says "you need to push
| this button to proceed" while covering up the freakin' button I
| need to push!
|
| - If you have a Word document already open and minimized, and you
| open up a second one - at least triggered from the browser in
| Sharepoint - what happens is the already open document opens up,
| with the newly opened one underneath! If these are based on a
| common template, I frequently find myself scrolling up and down
| looking for the graphic I need to refer to, only 20 seconds later
| realizing I'm in the wrong document again.
|
| These don't have much to do with UI skin annoyances, but they do
| have to do with this:
|
| Apple stuff had really good UI while Steve Jobs was in charge.
| Someone powerful enough to get _anything_ changed who is
| fanatically devoted to good, usable UI was gold there. All these
| weird inconsistent UIs are "design by committee" or worse, no
| design at all. Nobody has overall veto power, or at least nobody
| who cares enough.
| wubbert wrote:
| What is the reason for everything having flat UIs now?
| zem wrote:
| basically fashion. e.g. if you asked people to describe this
| app http://ptkdb.sourceforge.net/demo.html i'm sure a lot of
| them would use the word "dated", but the actual widgets are
| pretty similar to what we're using today, and layout hasn't
| changed much either. it's just the theming fashions that keep
| changing so radically.
| seanhunter wrote:
| Just last week I found myself in a position where I was at a
| major event (SXSW in Austin TX) having to support normal users
| trying to do various things on mobile and it's really eye-opening
| when you see first-hand how bad the experience is. I had a
| conversation with a user recently which went something like this:
|
| 'Yeah I know they have an app but your thing won't show up in the
| app for about a day so you need to go to their website on mobile
| to see it. Right, you're on the mobile website and I know your
| thing is still not showing up now. To see it, go to the hamburger
| menu in the top right. Yeah I know it doesn't look like a menu,
| or a hamburger. The three lines, that's a menu. Now go "account
| -> profile". Now you see the text where it says "XXX"? That's
| actually a tab. I know it doesn't look like a tab, just a word.
| You can't see any of the other tabs because they are actually off
| the right-hand side of the screen. I know it doesn't look like
| you can scroll, but just drag it across and you'll see the other
| tabs. Ok now click on the tab marked "YYY"'
|
| Trying to figure out this user flow for myself so I could help
| people reminded me of charging around hitting random walls in
| "Dark Souls" trying to find out which ones were illusory. It's
| really embarrassing how bad things have got.
| bredren wrote:
| What was sxsw like this year? Haven't been for a while, but am
| curious after the break and current covid context.
| seanhunter wrote:
| It was awesome actually. My first time but the vibe was
| fantastic. Lots of long-term "southbyers" said to me that it
| was because of a general feeling of being delighted to be
| back.
| RamblingCTO wrote:
| Sorry but this does not look good. Never looked as good as macOS
| UI sadly.
| mro_name wrote:
| > I instantly get shut down and disagreed with before I can even
| get the chance to give some feedback.
|
| ouch. Diversity of opinion is hard to stand but crucial.
| dm319 wrote:
| While I'm here, what is wrong with menus? The ribbon interface
| needs me to learn what 100 symbols refer to, or else hover
| repeatedly to find what I'm after. I can read. Been doing it for
| a while.
| maxloh wrote:
| As someone who born in the smartphone era, I don't found it ugly
| but a major design improvement.
|
| Maybe the author should embrace the latest trends in UI design,
| instead of insisting the old way.
| godDLL wrote:
| I've been using computers since ZX Spectrum days. I've seen all
| kinds of design-activity and design-philosophies. What's missing
| from today's design-thinking for me, is context-appropriate
| direction.
|
| Some things should be flat, or more precisely - subdued. An
| Instagram photo page shouldn't be all buttons and underlined
| links, sure - the photo is the important part so that the rest
| should be subdued. But the settings page should be all
| skeumorphic buttons and links and dials and switches, that's what
| it's for.
|
| It looks to me like there is an unhealthy tribalism invading
| design-thinking. As long as I have the correct ideology, no
| matter the context - my design is "good". Get on the flat-design
| bandwagon. Forget decades of UI research. Think in screenshots,
| doesn't matter if it's all jank and moves things in and out from
| under the user's fingers. Put everything on one screen, don't
| contextualize.
|
| "I'm being paid to deliver", not to think through. To ship, not
| to test.
|
| My designs require a gaming PC to run a document-like page, and
| don't scale down. "I'm designing for the future", it will all
| work out. Eventually. For some.
|
| My tools and my education are a sliver of what a designer used to
| think about, so I can't really do anything about it anyway,
| that's just the way it comes out. You don't honestly expect me to
| learn about the systems and devices my users are running this on,
| do you? That would make me a coder, that is to say not a
| designer.
|
| How did that happen?
|
| How did being knowledgeable and well-rounded at your industry
| become rare? Business reasons? How did using a computer become
| constantly surprizing and never straightforward? Business
| reasons? Why do I have this and that humongous app just for one
| or two things it does, and now there's 200+ apps in there? Always
| waiting for something to load all that, just so I can do this one
| thing. Business reasons?
|
| It's not business reasons. OSS is no better.
|
| Maybe it's that the approach that got us to where we are, the
| moving fast and breaking things, keeping your nose down in your
| own corner isn't what will get us out of here?
|
| I mean, my computer usage went down over the last 12 years, like
| 5x. I just don't want to. I'm more or less done with all of it.
|
| It all feels like it got bolted on, and then bolted on, and then
| ducktaped around.
|
| Terminals, mobile UI, desktop apps, the Web, games, appliances,
| work tools, control systems; ALL OF IT.
|
| Sure, there's loads of it, and it's cheap. But there is still no
| choice, not really. This jank or that, it doesn't do it for me.
| I've checked out, more or less.
|
| I stopped looking at new laptops, and when my phone breaks I pull
| a couple of old ones from the drawer and make me a working
| something. I'm not giving them my money, why would I? They got
| nothing I want. Apple, Google, Lenovo and the rest of them
| equally.
|
| The last MS product I enjoyed using was MASM. That's until I
| found out about NASM.
|
| There is no dumb car I can buy. Everything is finicky touch and
| not user-serviceable. Many things are so flimsy you can't lean on
| them at all.
|
| But then, one has to understand that if the whole world around
| you seems to have lost the plot, chances are it's you. So, is it
| me, what do you think?
|
| Because I can't handle it, I'm legit checking out.
| seltzered_ wrote:
| The other nice thing about "the nice GTK button" is that it feels
| consistent enough with the current tab buttons styling in
| Firefox: https://imgur.com/a/OEKc4So . It also just feels better
| for direct manipulation (touch).
|
| Is there any way to vote for keeping it? Does 'high contrast'
| mode possibly bring it back?
| bodge5000 wrote:
| Perhaps I'll be crucified for saying this, but I actually like
| flat design. Or at least, I think I do. I always thought flat
| design was as the name suggests; flat. As in, no gradient, no
| faux 3D, and I guess no borders. I'm not such a fan of rounded
| buttons, I think they often scale badly (pretty much anything
| round will unless its a vector I guess), but I didnt think that
| was a requirement of flat design.
|
| That being said, I'm not sure what it is now, because that
| original button looks like flat design to me. The only "non-flat"
| element of it is the 1px border, but surely thats not the source
| of all this commotion?
| Aeolun wrote:
| > I think they often scale badly (pretty much anything round
| will unless its a vector I guess)
|
| I don't think anyone makes UI these days and not makes it a
| vector.
| zozbot234 wrote:
| The original button has gradients and 3d-lighting effects.
| They're just subtle, but suffice to convey useful information.
| forgotmypw17 wrote:
| I'm so grateful for today's software diversity which allows me to
| so easily abandon and unsubscribe from non-consensual interface
| changes such as this one completely and switch to a different
| environment as many times as I need to until I find one which
| just maintains the interface which I want.
|
| (Which is basically Windows 95 with a few minor additions.)
| zzo38computer wrote:
| I dislike GTK; my opinion is that Xaw is better in many ways.
|
| GTK has problems including bad designs of many things including
| file selection dialog box, scrollbars (which are not always
| consistent), bitmap fonts sometimes don't work properly, always
| uses Unicode and although you can enter Unicode control
| characters they are not displayed while editing (which makes it
| difficult to use), some things are not documented well,
| configuration is difficult, kerning in editable text, etc.
|
| So, I do not use GTK in my own programs.
|
| (Some people say that if a program does not need to be documented
| then it is easy to use, but I disagree; a program is difficult to
| use because it is not documented well.)
| zmmmmm wrote:
| I keep wondering how long it will take for putting borders and
| edges or some graphical hint around functional UI elements
| (whether 3d or not) to come back into style. It's such a clear
| example of form over function to remove these (and if you ask me
| it doesn't even look good anyway, but let's put aesthetics
| aside).
|
| I would love to hear from any actual UX professional who wants to
| try to defend that making functional elements look identical to
| non-functional ones is a good idea. I would be fascinated to hear
| what the argument in its favor could possibly be.
| torginus wrote:
| >Now one of the worst parts is that everywhere I only even hint
| at not completely loving the new libadwaita theme I instantly get
| shut down and disagreed with before I can even get the chance to
| give some feedback.
|
| This is so typical for the open-source community. For a
| supposedly 'open' culture, its full of ivory towers and (layers
| of) cool kids clubs, meaning if you want to build an app, or
| change something you don't like, and want others to be able to
| use your changes as well, you are met with layers of people who
| are at best indifferent, and at worst hostile, but the thing is
| you absolutely NEED their approval unless you can make your own
| distro (your own club) and fork their code and try to somehow
| keep up with the main branch.
|
| The last thing I want to do with my free time, is solve an issue,
| only to be met with draconian authority telling me how to build
| my app, and then have to solve my issue again in 6 months, when
| the platform people break everything.
|
| I think the culture of abusing volunteers on a volunteer-driven
| project is exactly why desktop Linux can't break out of the niche
| OS category.
| smoldesu wrote:
| GNOME is pretty much the worst offender here, which really
| makes it all the more baffling. They constantly wax
| helplessness, begging for more contributors or feedback on
| their OS, and when people try to contribute or give feedback on
| their OS, they say "no not that part!" and go redesign
| something they don't take personally. It's especially ironic
| considering how they worship "usability" in the other hand,
| insisting that their lack of functionality is so that they can
| better emulate macOS. It's remarkably frustrating.
|
| But it's also the sort of behavior that keeps other developers
| going. KDE is great at soliciting user change, and nothing is
| "off the table" for scrutiny or redesign. Many other desktops
| share that same philosophy. The pockets of high-and-mighty
| developers are what end up shooting desktop Linux in the foot,
| and while I do happily daily-drive Linux, I can say with
| certainty that it will never hit the mainstream with
| maintainers like these driving the best-funded desktop
| environment.
| jraph wrote:
| It seems like KDE and Plasma is the place where look and feel is
| constantly _but_ incrementally refined; we 've been saved from
| this flat design trend so far _and_ things keep looking pleasant
| and modern and being usable. We know they care, and have great
| attention to details because that 's documented weekly [1].
|
| I find the Breeze theme really well done and its GTK port, Brise,
| is also very nice, to the point Gnome looks good in it.
|
| There was just the KDE 4 era where I didn't like Oxygen at all
| (and indeed I used to change the theme to Fusion there) but
| that's over. KDE 3 was fine and KDE 5 is great. At this point,
| most things that are not Breeze don't look great to me now.
|
| As for the customization and theme support, that's supported and
| it works well, they prove that it's nothing insurmountable too.
| KDE comes with themes that look like Windows 95, Motif, Adwaita,
| GTK 2 and other things and you can download more if you want.
|
| I'd be curious to have a review of Breeze / KDE by Martijn.
|
| [1] https://pointieststick.com/
| bmn__ wrote:
| > we've been saved from this flat design trend so far
|
| That's false, see https://news.ycombinator.com/item?id=26582009
|
| Also in System Settings 5.24:
|
| * switch to sidebar view and examine the buttons at the top of
| the sidebar
|
| * go Workspace - Workspace Behaviour - Desktop Effects and
| examine the buttons at the right
|
| * go Workspace - Workspace Behaviour - Virtual Desktops and
| examine the buttons at the right
|
| * go Workspace - Workspace Behaviour - Activities - Activities
| and examine the buttons at the right
|
| * go Workspace - Window Management - Window Rules and examine
| the buttons at the right
|
| * go Workspace - Startup and Shutdown - Autostart and examine
| the buttons at the right
|
| * the most egregious example: go Personalisation - Regional
| Settings - Formats and examine the whole dialogue, it is
| entirely made of frobable regions
|
| * go Network - Connections and examine the buttons at the
| bottom of the connections list
|
| * go Hardware - Printers and examine the buttons at the top of
| the dialogue
|
| I do not understand what goes on in the responsible
| programmers' heads. Why does the implementer reinvent buttons
| badly, instead of using a standard button? Is there no one
| reviewing? Is there no one saying "no, we cannot burden a KDE
| user with this bad usability, I will not merge this code"?
| jraph wrote:
| Indeed, you are right, those buttons have no border and no
| background.
| paldepind2 wrote:
| > I'd be curious to have a review of Breeze / KDE by Martijn.
|
| He mentions KDE in the blog post:
|
| > The feedback I get is that I should move to QT/KDE, but I
| think that theming has had the same issues for way longer
| already and I do really like the Gnome HIG.
| malermeister wrote:
| How's KDE/Plasma with touch these days? I'm running GNOME on my
| Surface right now because it does pretty well with both Desktop
| and Tablet modes, but I'm pretty unhappy with the at times
| patronizing philosophy behind the project.
| traverseda wrote:
| The biggest complaint from steam deck users seems to be the
| virtual keyboard isn't reliable, which is a pretty big issue.
| aidenn0 wrote:
| I have a pine-phone and the virtual keyboard just refuses
| to pop up for some apps (like firefox!!). I keep looking in
| the settings for "force virtual keyboard on" or something
| but can't find it.
| traverseda wrote:
| Firefox does use GTK unfortunately.
| aidenn0 wrote:
| But this was running under Plasma Mobile
| linmob wrote:
| The Plasma Mobile Maliit keyboard works with GTK apps on
| Manjaro Plasma Mobile.
|
| There must be some way to make this work on other Plasma
| Mobile distributions.
| jraph wrote:
| It indeed works now. Firefox was unusable on Plasma
| Mobile in 2020, it now mostly works on an updated
| Pinephone Pro (can't click on those popups when you try
| to install an extension, but the virtual keyboard shows
| up and seems to work ok).
| aidenn0 wrote:
| I'll try Manjaro then; it definitely doesn't work on an
| up-to-date postmarketOS on a (non-pro) pinephone.
|
| [edit]
|
| Can confirm keyboard works in FF on Manjaro, but it has
| other jankiness (e.g. it seems to think it is much wider
| than the screen).
| aidenn0 wrote:
| Turning scaling down to 1.8 (default 2.0 on
| Manjaro/Plasma) or lower lets Firefox work on the screen;
| I didn't have this problem on pmOS; either the default
| scaling is lower on pmOS, or they have some other
| workaround.
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1579348
| prmoustache wrote:
| > It seems like KDE and Plasma is the place where look and feel
| is constantly but incrementally refined;
|
| Every time I see a comment like that, I try again KDE, only to
| leave it 15 minutes later because it is a huge mess. Everytime
| I try configuring the panel to my liking nothing goes where I
| want to and I end up with widgets everywhere.
| eru wrote:
| XMonad has also escaped the visual design fads quite well.
| iso8859-1 wrote:
| Does it have any visual elements at all, isn't it only
| showing other applications visual content?
| eru wrote:
| Well, I was a bit tongue in cheek.
|
| There's some minimul visual elements, eg if you choose the
| tabbed layout.
|
| So the comparison for XMonad wouldn't be all of KDE or
| Gnome, but just how those two choose to decorate their
| windows. Eg their 'minimize' and 'close' buttons and window
| borders.
|
| To be slightly more serious than my original comment was:
|
| If you can rethink your UI in such a way that some things
| can become invisible, that can be a very ergonomic choice.
|
| To give a better example: look at the bad old days of C and
| memory management via malloc and free.
|
| One direction you can go into is Rust. Compared to C, Rust
| has a greatly improved user interface [0] for handling
| memory allocation.
|
| Another direction you can go into is Python. Compared to C,
| memory management is basically invisible in Python. It just
| works.
|
| Now, of course, Python gets to simplify its UI by
| essentially removing control from the user. But for many
| programming tasks, that's a good trade-off to make.
|
| Similarly, iOS gets to drop the UI elements associated with
| manipulating windows, because it puts every app in full
| screen. (And XMonad greatly discourages you from fiddling
| with Window placement and layout manually; but has some
| less-intuitive less-discoverable means to do that manual
| fiddling, if you need it.)
|
| [0] The user of Rust being typically called a 'programmer'.
| berkes wrote:
| How is KDE these days?
|
| I abandoned KDE during the KDE-3 (edit: to 4) migration
| apocalypse, when nothing worked as it did before, or at all,
| and everything looked like it needed at least another year of
| refinement.
|
| Is this settled and past now? Is KDE still adament on making
| virtually every other pixel configurable?
| arendtio wrote:
| KDE 4 has been fine since 2012 or so.
|
| I used KDE 4 from the first alpha versions (~2007) and never
| quit using it. However, I had friends who didn't like the
| mess that KDE 4 was in the beginning and who were very
| verbose about the good KDE 3 features they were missing and
| the new behavior they didn't like.
|
| However, at some point they saw that the very few things they
| were still missing were neglectable compared to the good
| things that KDE 4 brought with it.
|
| Nevertheless, 2007 to 2012 were _5 years_ during which it
| wasn 't easy to be a KDE user ;-)
| jraph wrote:
| KDE 3 was rock solid. They did break a lot of stuff when
| releasing KDE 4. That was very unstable / crashy. At that
| time I moved to Gnome 2, and moved back when Unity was
| shipped by default in Ubuntu. The late KDE 4.X releases were
| rock solid. I didn't like KDE 5 at first. A lot of things
| felt unfinished / not ready. but KDE 5 has been rock solid
| for years now, and from what I understand they have promised
| they would make more incremental changes from now on (so no
| more KDE 4.0-like disruptions). They are currently focusing
| on ironing out the small things instead of breaking stuff
| every month.
|
| Now the world seems more mature: Cinnamon, KDE and The Ubuntu
| favor of Gnome seem to work very well (Each time I see Ubuntu
| Gnome I think "wow, that looks good!"). Xfce have been rock
| stable and reliable for years and years for people who like
| it. Still looks the same as when I discovered it 17 years
| ago. I've heard people like the current versions of Gnome and
| that the latest versions are better.
|
| And yes of course everything is still highly customizable in
| KDE. There are people who make it look like old Windows, some
| who make it look like Mac and both work quite well. But you
| are not forced to customize, the default are top notch and
| that's what I use. They've been working on the settings
| center which was a mess and which is still not perfect, but
| it's gone to the point where it is one of the best I've seen.
| In comparison, the Windows' several setting centers are a
| huge mess and the Gnome settings are lacking, and you need to
| install Gnome Tweaks to have some useful stuff and now you
| have two settings panels.
| dm319 wrote:
| Don't forget MATE. It got redone in GTK3, and it is
| terrific.
| zozbot234 wrote:
| Xfce is also based on gtk+3 now. Quite a bit lighter than
| MATE.
| Aisen8010 wrote:
| I would not be so sure. Sooner or later there will be a QT6
| port and most of the work will be lost.
|
| I was a happy GNOME user before the version 3 fiasco. It took
| years to have a usable GNOME desktop again.
| nyanpasu64 wrote:
| Breeze is being ported to Qt 6, and from the screenshots I
| see (https://www.volkerkrause.eu/2022/01/15/kf6-continuous-
| integr..., unsure what others), there are no visual changes
| so far. Time will tell if they change Breeze's appearance
| further before/after Plasma 6's release (I didn't ask about
| KDE's current plans). One possibility is O2
| (https://pinheiro-kde.blogspot.com/), a reworked theme by the
| author of KDE 4's Oxygen, though it's not very far into
| implementation yet.
| bmn__ wrote:
| > Qt 6 [...] there are no visual changes so far
|
| That's false, examine Strawberry 1.0.2 running in KDE 5.
| The menus have the wrong background colour. The font size
| is wrong.
| qalmakka wrote:
| That's because there's no Breeze theme for Qt 6, so it's
| using the builtin Fusion theme which is literal cow dung.
| If you port your theme to Qt 6, the app should look
| identical.
| bmn__ wrote:
| I do not use a theme. I think you have it the wrong way
| around. What's missing here is the Qt6 equivalent of KDE
| System Settings - Appearance, or configuration tool
| <http://qt5ct.sf.net>, and it's not my task as the end
| user to provide these, but the toolkit and desktop
| environment developers'.
| qalmakka wrote:
| You always use a theme with Qt or Gtk. On Plasma the
| default Qt and Gtk theme is Breeze, which has not been
| ported to Qt6 yet. ATM the only Qt Widgets-compatible
| themes I have on my system are "Fusion" and "Windows" (as
| in "Windows 95"), both of which look absolutely horrible.
| Fusion is the default, and it's what you currently see
| when you open a Qt 6 Widgets app (for instance,
| QBittorrent right now).
|
| By the way, qt6ct exists
| <https://github.com/trialuser02/qt6ct>, and it's even in
| Arch's repositories right now. The main issue is that
| it's useless, because there are simply no Qt6 themes out
| there yet and KDE still does not support Qt6 so you have
| to force qt6ct manually.
| qalmakka wrote:
| GNOME 3 was a fiasco not because of GTK+ 3. It was a fiasco
| because they threw 12 years of work and UI/UX design in the
| rubbish bin instead of thinking of ways to improve on it.
| MATE now runs on GTK+ 3 and it's leaps and bounds better in
| terms of UX compared with GNOME > 3. Sure, GNOME now has all
| the eyecandy and stuff, but it still sucks hard compared to
| GNOME 2. GNOME 2 was the pinnacle of UX IMHO, it was a novel
| design that really showed that you could innovate without
| copying others, that there was a third possible way that was
| not either a Dock or a start menu. All wasted, I suppose.
| exciteabletom wrote:
| Anyone else happy with Gnome? It's good to have an opinionated DE
| that just gets out of the way.
|
| It launches apps, provides me with workspaces, and abstracts all
| the low level details away so I can focus on actually using my
| computer.
|
| If people want to customise every minute detail of the themes
| they shouldn't be using Gnome/GTK. The devs don't have to cater
| for everyone's needs, they are allowed to focus on a target
| audience.
| smoldesu wrote:
| I'd be happy with it if the developers listened to the users.
| GNOME 3 had a good balance of "getting out of your way" while
| still giving power users what they want. I had to leave GNOME
| 40 within hours because of its unbelievable changes to the UX,
| and I say that as someone who used to be a pretty big fan of
| the desktop.
| swiftcoder wrote:
| > This has all the features I like from GTK 3. The only issue
| with it is that font rendering looks horrific, but that might
| just be my machine
|
| I don't understand linux users' font tastes, apparently. To me
| the GTK4 screenshots are the only half-way decent font rendering
| in the lot. All the GTK3 shots have broken kerning in headings,
| not to mention the awful (lack of?) antialiasing.
| mikl wrote:
| Yeah, the new GTK4 UI looks like a clone of Apple's UIKit with a
| worse font. Shame that Gnome is following the trend of flat and
| boring UIs.
| Shadonototra wrote:
| GTK4 looks like iOS's UIKit
|
| On macOS Desktop, checkboxes, buttons and everything else are
| still designed for mouse/kb
|
| On gnome things are designed for vertical and touch screens, so
| you forced to endlessly scroll, windows is doing something
| similar, wich is an indication that they target mobile users,
| they are so out of touch
|
| Only Apple knows what they are doing when it comes to UI/UX for
| desktop, and they make sure they don't mix desktop/mobile UX
| smoldesu wrote:
| All of this is pretty much how I feel on the matter, too. GTK3's
| interface was a really lovely blend of skeuomorphism and more
| abstract widgets that came together to make a really unique
| experience. Even if it didn't work in _every_ context, I
| appreciated how well it worked for less complicated applications
| and making great-looking, device-agnostic GUIs. Cawbird was a
| wonderful native Twitter app made possible with GTK3. Curlew
| packed all of the important features of Handbrake /FFMPEG into a
| more streamlined, simple package. Foliate took e-book reading
| into the 21st century. So many amazing apps were enabled with
| this switch, and even though it's still a second-class toolkit,
| it was my guilty pleasure on Linux.
|
| In comes GTK4. Much like the article alludes to, the elegant and
| simple shadow of interactive elements goes _poof_. Developers
| spend hundreds of hours crusading against letting people use
| third-party themes, just so they can simplify and reduce UI
| elements to a nigh-unusable pulp. Developing with GTK4 is a
| nightmare. Using GTK4 is a pain in the ass. For christs sake,
| there was a devastating font-rendering glitch that existed for
| more than _ten months_ after the first GTK4 release that was
| ignored in lieu of simplifying buttons, developing a new forced
| stylesheet and telling people "don't theme our apps!" Whenever I
| take this up with a maintainer, they immediately take it
| personally and write out a litany of reasons why I'm wrong and
| why I'm not allowed to disagree. The priorities here are almost
| unbelievably misaligned, I've pinned my GTK packages at the last
| GTK3 release and await some sort of admission of failure.
|
| I simply can't take it anymore. These are the people making
| desktop Linux miserable, and I frankly feel no remorse watching
| their attempts at "simplifying" the ecosystem crash and burn.
| MartijnBraam wrote:
| This is exactly how I feel about it. The sad thing is that if
| the whole gnome ecosystem burns down I'd have to use the
| alternatives that I like even less.
|
| I'm just not designing gtk4 apps untill it's actually better
| than gtk3
| smoldesu wrote:
| Definitely. Keep on trucking, I'm developing GTK3 apps right
| alongside you!
| amelius wrote:
| The problem with buttons that have shadows (even subtle ones) is
| that you can't rotate the screen 180 degrees and have it look
| nice. This is a problem if you put your phone or tablet flat on
| the table and someone sits opposite to you and looks at the same
| screen.
|
| Better to keep the design flat. It's also simpler.
| layer8 wrote:
| Even assuming that's true, it's totally counterproductive for
| desktop use.
| ben-schaaf wrote:
| The old non-flat button styling looks entirely symmetrical to
| me. Not to mention that designing applications to look nice
| when viewed upsidedown is just silly. Even if it was your
| primary use case to have two people opposite each other view
| your app your biggest problem is all the text being upside
| down!
| superasn wrote:
| I think Don't Make Me Think Book by Steve Krug should be a
| required reading for anybody who is involved with designing UIs
| and websites. That old book has so much wisdom about what happens
| when we see something on the screen and why these little details
| matter so much.
|
| This is right there in chapter 1:
|
| _As a user, I should never have to devote a millisecond of
| thought to whether things are clickable-or not._
| petesergeant wrote:
| Sorry to side-swipe this. The pictures in the article all have a
| fuzziness I've come to associate with Linux GUIs over the last
| couple of decades. Is there a specific reason for it? Is the font
| the problem? Some kind of font-hinting patent they can't impinge
| on?
| pipeline_peak wrote:
| UI themes is the least of GTK's problems.
| tempodox wrote:
| The Flat Design fashion is coming to full rage. Everything looks
| like a bad web page now. Make users waste their time guessing how
| the interface works instead of getting things done.
| taf2 wrote:
| Regarding flat - theme movement... it was iOS7 that my daughter 3
| was happily able to use her new iPad running iOS6 when I set her
| up and she could press play on her show. Then one morning we had
| her in the stroller and taking a walk and I handed her upgraded
| to ios7 iPad... it was instant tears she couldn't figure it
| out... just to get the walk started I pressed the play button for
| her after many tears... later on during the walk her show ended
| and in her frustration at not being able to find the play button
| she raged on the iPad ... that iPad is no more... IMO following
| that experience the flat movement was really bad for usability...
| driven by a form over function that I've seen harm younger and
| older people alike... my then 92 year old grandfather I remember
| also seriously struggling with ios7 compared to 6... just my
| observations... but yeah flat looks better...
| red_admiral wrote:
| I miss the days of GTK2 when you could set colours for things
| individually without having to edit CSS. You could take the
| buttons from this theme and the window borders from that one, and
| then make the active window title bar a different colour to the
| rest. Moving to GTK3/adwaita made that a lot harder for me - like
| yes I can spend a couple of hours editing and testing changes to
| the stylesheet but before there was a button in the settings for
| this.
|
| Look, I get all the advantages of the newer way, but for me it's
| a feature that I can make my UI look the way I want it, even if
| that's not the same as some theme designer's preferences.
| mrlemke wrote:
| Thanks to flat design, Athena widgets are now a minimalist widget
| set. Using X resources, you can even personalize and theme your
| apps.
| iforgotpassword wrote:
| > While a lot of people now instinctively hunt for labels that
| have hover effects, for a lot of people who are just not
| represented in online computer communities because they're just
| using the computer as a tool this is completely weird.
|
| This. This! You see people on Apple devices constantly scrolling
| up and down just a tiny bit while browsing the web. What a weird
| tic I thought, when I saw different people do that. Turns out
| scroll bars are always hidden on Safari for elements that have
| overflow with scroll behavior. So you never know if you're
| reading some important stuff that actually has another paragraph
| you don't see because it's otherwise not obvious you're looking
| at some <div> with limited height. And it seems others are busy
| imitating this, I feel this happens with Firefox in Android now
| too.
|
| Then these new navigation gestures on mobile. Gone are the three
| mighty buttons of Android. When the iPhone released, it was
| praised for cutting ties with anything that was established in
| the old computing world, all the implicit knowledge you had to
| have about how to use a classic desktop os. You could give the
| iPhone to any tech illiterate person and they could figure it
| out. Everything was discoverable, a fresh start with a clean and
| consistent UI language.
|
| But today, not so much. Now phones went through the same
| iterations as the desktop os, and it's ok that you now need to
| learn a gesture to return to the home screen, or go back one
| step. There is no way someone who never used a phone before will
| somehow think "I might have to swipe into the screen from the
| left!" So now, just as the desktop os, we just assume you already
| know how to use a phone, and add "optimizations" on top of that
| that someone needs to tell you about.
| GekkePrutser wrote:
| Not a fan of adwaita at all, I think everything GTK is too
| wasteful in terms of screen space. I think Qt is much more
| efficient. But that's why we have Linux. Everyone can make their
| own choices
| can16358p wrote:
| While I'd like the old button as well, I think flat design is
| great.
|
| When MS brought Windows Phone and then incorporated same language
| into Windows 8 I was like "wow, Microsoft got it right for the
| first time".
|
| Same for iOS 7, same for macOS. I never liked the "Apple" look of
| UIs before they went flat. After they've switched to flat I
| started to really love it.
|
| Not even talking about developers and designers needing to do
| less, and users needing to process less cluttered visual stimuli.
|
| Skeuomorphism and non-flat designs in general had a good purpose
| and they've fulfilled it perfectly by teaching people about how
| UIs work in those OSes of digital world by making elements
| looking like real world things like buttons being 3D-ish. But
| that era is over and we collectively don't need it, so we've
| switched to something simpler and more efficient it many terms.
|
| Of course, taste is taste and one may hate it, but I love flat
| design in almost all aspects, and definitely don't think MS and
| Apple are "stupid" as the blogger says.
| HeavyStorm wrote:
| Reading the comments I get that everyone agrees that UI has
| gotten worse over the past few years.
|
| My word of choice is amateurism.
| lovedaddy wrote:
| Flat I can just about tolerate, the stupid padding round every
| single element is what bugs me.
|
| There has been loads of studies showing the amount of mistakes in
| coding or spreadsheet type work goes up massively with having to
| scroll windows, but yet, gtk3/4 is a bloated, oversized mess.
|
| Mice precision has increased, so why on earth do we need toolbars
| that can take upto 1/8th a 768p screen. Stupid.
| von_lohengramm wrote:
| The font rendering on that example of "the perfect button" is
| rather atrocious. It's kind of sad that Windows is (was?) the
| last bastion of serviceable font rendering.
| smoldesu wrote:
| If you think that looks bad, wait until you see what GTK4 was
| stuck looking like for the first 10 months of it's life cycle:
| https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
| tomduncalf wrote:
| Interesting, I always disliked Windows font rendering and much
| prefer the was MacOS renders fonts. I couldn't explain why, but
| I know many graphic designers who say the same. I guess it's a
| matter of taste!
| von_lohengramm wrote:
| Any font rendering looks amazing on HiDPI panels. Have you
| ever used macOS on a normal monitor? The text looks worse
| than anything else.
| mikl wrote:
| For some value of "normal". 4K (or better) monitors have
| long since become the choice for most of those who cares
| about how font rendering looks.
|
| After a decade of "retina" screens, I'm ruined, I can't
| stand the look of anti-aliased fonts, whether Windows,
| Linux or macOS.
| von_lohengramm wrote:
| > 4K (or better) monitors have long since become the
| choice for most of those who cares about how font
| rendering looks.
|
| This is the hardware solution to something that can be
| solved in software. If your game is laggy, of course
| upgrading to a 3090 is going to help, but that doesn't
| mean you're solving the problem.
| azornathogron wrote:
| It can't be solved in software, due to the Nyquist limit:
| Sharp high-contrast edges (text) necessarily have high
| frequencies, and you need a high sampling rate (pixel
| density) to produce a good approximation of that signal.
| People have spent a lot of effort to push anti-aliasing
| techniques as far as they can go, but displays with
| higher pixel density are just _better_ for displaying
| text.
|
| I agree that if you are making something and your target
| audience will be using non-HiDPI displays, then you
| should actually design your thing on those displays too.
| But no matter how good your software is, pixel density
| places a limit on what you can achieve.
| mrob wrote:
| Bitmap fonts (and hinted fonts are automatically
| generated bitmap fonts) are pixel art, so the Nyquist
| limit doesn't apply. In pixel art, the pixels are treated
| as little squares or rectangles, not band-limited point
| samples. This means you sacrifice the ability to display
| arbitrary shapes, but I'm not trying to reproduce printed
| text so I don't care.
|
| I have perfectly sharp text on a 1080p monitor because I
| disable antialiasing in ~/.config/fontconfig/fonts.conf
| and force full hinting.
| zozbot234 wrote:
| Nitpicking, but a pixel is always a point sample, not a
| little square. The native medium for displaying pixel art
| is CRT displays, where these point samples are used to
| control an electron gun that introduces a Gaussian blur,
| basically the best case for purely analog upsampling (or
| DAC, rather) of a pixel raster. No little squares in
| sight, though! What you're talking about is using pixel-
| perfect control to _reach_ the Nyquist limit, as
| mentioned in my sibling comment.
| mrob wrote:
| Pixel art is defined by treating pixels as little
| squares. There is no single native medium for displaying
| pixel art. The same techniques were used for games on
| portable systems with LCD displays. Additionally, there
| are many examples of printed art using blocky pixels.
|
| The Nyquist limit is irrelevant to pixel art, because the
| Nyquist limit applies only to reconstructing signals from
| point samples. Using pixel art on a monochrome LCD (no
| subpixels), I can display signals with maximum frequency
| limited only by the sharpness of the edges of the little
| squares.
| zozbot234 wrote:
| Pixel-perfect rendering (i.e. hinting) is needed in order
| to _reach_ the Nyquist limit. By forgoing it, you 're
| limiting yourself to an effective resolution that's only
| 0.7x or so the physical one,
| jabbany wrote:
| This.
|
| The devs and designers are all using 4k, 5k displays these
| days. Trying to use modern apps etc. on just "FHD" (1080p)
| displays is painful.
| jandrese wrote:
| Over 2/3 of regular users are still using 1080p[1]. If
| your design looks bad on FHD then it looks bad to most
| people.
|
| [1] https://store.steampowered.com/hwsurvey/Steam-
| Hardware-Softw...
| tonyedgecombe wrote:
| >Over 2/3 of regular users
|
| That isn't going to be the case for Apple users though is
| it. Apple don't have any non retina devices in their
| lineup now. The only Apple users who will see a low dpi
| display are those plugging in a low dpi external monitor.
| They are going to be a minority.
| lmm wrote:
| Right, but it looks good on the designer's screen. That's
| the issue.
| stjohnswarts wrote:
| Just like programmers should have to run their apps on 10
| year old computers and feel the pain, so should designers
| have to try their work on 10 year old monitors.
| badsectoracula wrote:
| Perhaps a better survey would be the one by Firefox[0]
| since it isn't biased towards gamers. Basically HiDPI
| monitors are like a combined 2% of all Firefox users.
|
| 1080p usage is lower than on Steam but that is because
| 768p usage is higher :-P.
|
| [0] https://data.firefox.com/dashboard/hardware
| norenh wrote:
| I guess that is the reason why every musician should copy
| their master to a cassette tape and go to a shitty car
| with a tape-player and listen there, why every developer
| should have a very old crap-computer to run their
| software on and why every UX designer should have a
| crappy screen to view their design on. :-)
| azornathogron wrote:
| This has been debated for decades. Joel Spolsky has a blog
| post about it from 2007.
|
| https://www.joelonsoftware.com/2007/06/12/font-smoothing-
| ant...
| naoqj wrote:
| I agree that the defaults are atrocious, but freetype can be
| configured and the options are limitless.
| TillE wrote:
| Maybe there's some configuration magic you can do, but I
| don't think I've ever seen decent font rendering on a Linux
| distro out of the box.
|
| It's one of the biggest reasons I've never switched to
| desktop Linux, and I'm not even one of those super picky
| people who talk about the intricacies of typefaces all day.
| kasabali wrote:
| Ubuntu's font rendering is really good in its stock
| configuration.
|
| But I understand libre licensed typefaces it ships with
| might not be to everyones liking.
| von_lohengramm wrote:
| Linux font rendering has come a long way in the last couple
| years. With TrueType2 and Windows fonts taken from an
| installer ISO (and not the ancient corefonts package), you
| can actually get some overall mostly okay font rendering.
| Every now and again, the hinting bugs out and it looks
| unreadable, but its far better than the olden days.
| eMSF wrote:
| What exactly has happened in the last couple of years? And
| how would installing those newer Microsoft fonts affect
| font rendering elsewhere than where they are used (not at
| all by the desktop environment by default, and as to web
| sites, it depends on what you use)?
|
| IIRC the last big-ish change for me was around 15 years ago
| when some patent-encumbered patches were enabled by default
| by (some) Linux distributions. Which is okay for me because
| overall I think freetype font rendering is better than that
| in Windows with most fonts, the arguable exception being
| certain Microsoft fonts - however, freetype has the
| additional advantage that it rarely if ever produces
| pixelated ugliness with unhinted webfonts, unlike what I've
| seen happening with Windows.
| zozbot234 wrote:
| > What exactly has happened in the last couple of years?
|
| Some subpixel rendering techniques became unencumbered
| quite recently. So newer versions of freetype should have
| nicer subpixel rendering enabled by default.
| Sophira wrote:
| The design of HN has similar issues, honestly, especially on
| links you've already visited:
|
| https://matrix.theblob.org/hn-original-style.png
|
| Which parts are links? Which aren't? It's a little more obvious
| that the main text is a link but not obvious that you can click
| to view the comments. (It can be inferred, of course, but I don't
| believe that should be necessary.)
|
| A little styling to add underlines back to links, plus a little
| bold to indicate the comments page, fixes this:
|
| https://matrix.theblob.org/hn-my-style.png
|
| Some might say that this looks ugly, and that's a valid view. But
| to me, it's usable.
|
| (Why are both the "time posted" link and the comments link
| bolded? Because they both go to the same place. I didn't even
| _know_ before I made this style that that was the case! I was
| surprised to see that the style I made did both, but I 'm not
| complaining.)
| Ambroisie wrote:
| Could you share your style? I'd like to use it too.
| Sophira wrote:
| Sure! I've cleaned up the CSS a little bit since it was
| originally only for private use, and published it under CC0
| at https://userstyles.world/style/3825/hacker-news-
| underlines-c... . You should be able to use it with an
| extension like Stylus[0].
|
| [0] https://github.com/openstyles/stylus/#readme
| mholt wrote:
| The flat UI trend baffles me. The removal of text from icons and
| buttons baffles me.
|
| For example, in Windows 11 I spent close to a minute looking for
| "Rename" in the right-click menu in Windows Explorer. Turns out
| it's not there! It's been removed out of the flow of the list and
| put in the top of the right-click menu, behind a small, picture-
| only icon that I've never seen before.
|
| MacOS is guilty of this too: Buttons along the top of native apps
| like Finder don't have text anymore, the buttons are flat without
| borders, and the icons are thin lines. How is anyone supposed to
| know what they do??
|
| In most UIs (Apple and Android in particular), I can't tell when
| one of those on-off switches is ON or OFF. Is the dark side ON or
| OFF? Maybe the light side is ON. Oh, it's the opposite when Dark
| Mode is enabled; great.
|
| Bring back text. Bring back nice buttons.
| HeckFeck wrote:
| This is why I have reverted to the CLI whenever possible.
|
| There's something deeply assuring knowing that I don't have to
| relearn my whole workflow every few months when the trends
| change. ls, grep, find, ps, htop will always be what they are.
| Even the Windows CLI is thankfully consistent.
|
| All I want is to get work done the way I want, and I've found
| the CLI is increasingly the path of least resistance.
| flukus wrote:
| > ls, grep, find, ps, htop will always be what they are.
|
| SystemD screwed with a few that I'm still discovering one by
| one. "cron", "shutdown" is no longer in the default debian
| path, I think ulimit was another one.
|
| But at least I don't wake up one morning with the whole
| interface rearranged.
| duskwuff wrote:
| cron is in /usr/sbin (and is a daemon, not a command you'd
| ever run manually); shutdown is in /sbin; and ulimit is a
| shell builtin, not a standalone executable at all.
|
| If I had to guess, I'd say that /sbin and /usr/sbin aren't
| on your $PATH for some reason. systemd is unlikely to be
| the culprit.
| bqmjjx0kac wrote:
| I regret to inform you that the latest release of `find` has
| been renamed to [magnifying glass emoji].
|
| For example, # Find directories the old
| way. find . -type d # The cool new way!
| [magnifying glass emoji] . -[keyboard] [folder emoji]
|
| Edit: HN appears to strip emojis, so my new edited comment
| doesn't pack the same punch.
| snerbles wrote:
| I look forward to hieroglyphic CLI interfaces, where we
| compute like it's 2600 BC.
| josefx wrote:
| At 2600 BC hieroglyphs already included symbols used for
| phonetic spelling, so hieroglyphs are not the way to go
| if you want to get rid of spelled out words unless you
| ban the subset that can be directly mapped to greek
| letters[1]. Otherwise it just ends up a fancy font.
|
| [1]https://youtu.be/NIxn9auks24?t=2009
|
| That literally every ancient civilization went from
| pictures to words as fast as they could should say
| something about modern icon only design.
| andrewf wrote:
| similar c++ proposal from April 1998:
| https://www.stroustrup.com/whitespace98.pdf
| JNRowe wrote:
| You jest, but I'm not sure that is a bad idea. bash/zsh
| seem happy with emojis as function/alias names, and I can
| input emojis easy enough. In fact some emojis are easier to
| type in my chosen layout than the string necessary to
| disambiguate completion for some commands.
|
| Thanks for the idea, and I'll redirect co-worker scorn at
| U+1F984 for `git push` towards you ;)
|
| _Edit to add_ : Using emoji for commands/arguments is
| actually quite workable with global aliases or custom zle
| widgets in zsh, and moderately workable by using $INPUTRC
| to specify text replacements for readline if you're a bash
| user.
| stjohnswarts wrote:
| Had a developer change some config file names to emoji
| based file names. Boss thought his computer was broken
| when he took a look at some output txt file. He wasn't
| amused even though it was April 1.
| Nextgrid wrote:
| > ls, grep, find, ps, htop will always be what they are. Even
| the Windows CLI is thankfully consistent.
|
| Those command-line tools don't have any "engagement"
| opportunities nor are there bloated teams of product managers
| & designers having to justify their salaries by reworking
| them for no good reason.
| dmitrygr wrote:
| sometimes even cli tools go away. eg: ifconfig
| kiwijamo wrote:
| They still exist on BSD! But yes it has gone away on Linux.
| wutbrodo wrote:
| Huh Til that ifconfig is deprecated. I still use it
| periodically, but my work laptop is on 18.04
| HeckFeck wrote:
| It can be restored with the `net-tools` package,
| thankfully. That's among my first installs on a Linux
| box. Never quite got into `ip addr show` when I've most
| of the ifconfig flags memorised from use.
|
| Which may contradict my previous point slightly, but at
| least it is easy to put the system back into a state I
| want and the system will maintain this state.
| jug wrote:
| This is honestly a large part of why I enjoy keyboard
| shortcuts, like F2 to rename on Windows. But it's of course
| also a low grade for their UI design because I like it for
| knowing how to reach it instantly. Unlike by using their user
| interface.
| albert_e wrote:
| This resonates so much with me .. especially the On/Off buttons
| where designers show off how cool and smooth they can make them
| look, usability be damned. Dark patterns especially around opt-
| ins uses these type of controls very well putting a lit of
| mental load on us to opt-out.
| [deleted]
| gjsman-1000 wrote:
| In macOS, you can actually right-click many header bars (like
| Finder) and choose "Icon and Text" instead of "Icon" for what
| shows.
| mholt wrote:
| I do this, but I do not want to do this.
|
| Also it looks funky. The padding is messed up and the text
| doesn't fit.
| duskwuff wrote:
| There's also an accessibility setting (under the "Display"
| section) for "Show toolbar button shapes".
| phkahler wrote:
| >> There's also an accessibility setting (under the
| "Display" section) for "Show toolbar button shapes".
|
| Fascinating. Sounds like if you can't read the mind of
| the desinger you must have a disability. What a great
| attitude :-p
| eyelidlessness wrote:
| 1. Accommodating disabled people is in no way an insult.
|
| 2. Being disabled is a normal fact of life, also not an
| insult.
|
| 3. Accessibility affordances are not only for disabled
| people. Lots of people who wouldn't identify as disabled
| routinely and gladly use a wide variety of accessibility
| features.
|
| 4. Having difficulty identifying actionable elements like
| buttons isn't about reading anyone's mind, and it isn't a
| universal difficulty regardless of their presentation.
| The ability to customize it so it's easier _for you_ is
| inherently an accessibility affordance.
|
| 5. It's entirely possible this setting (along with
| several others under accessibility) may be more helpful
| when needed if they were available in another location,
| but it's also possible that would make the experience
| more confusing, and quite possibly for more people--
| especially for disabled people.
|
| 6. People may benefit from this information--quite a few
| here based on other comments--and it doesn't deserve this
| kind of negativity.
|
| 7. With all of that in mind, while I'm keeping this
| response direct, I took the last point as a prompt to
| edit some of my own negativity out of it. I had a strong
| negative reaction both because I think accessibility is a
| universal good and because I appreciate accessibility
| affordances which help me. But that's not a reason for me
| to be a jerk either.
| phkahler wrote:
| 1. Accommodating disabled people is in no way an insult.
|
| No, but treating non-disabled people as disabled could
| be. Just like offering help to some disabled people
| triggers them.
|
| I was going to respond to these numbered points in turn,
| but that'd be silly. My point is that having basic
| (previously standard) UI cues like buttons is important
| and stuffing that option _anywhere_ is a poor choice. To
| put it under the accessibility options can (if we 're
| even a tiny bit snarky) be seen as an insult - possibly
| to disabled people as well since it lumps a simple
| standard usability thing in with stuff designed for
| people with actual challenges.
|
| It's also not cool for them to make critical UI cues an
| option when they also take away themes which are the
| ultimate option.
|
| Ultimately they have given no valid reason to make so
| many things look the same when they used to be visually
| (and functionally) distinct.
|
| Sorry for the trigger, I didn't mean any insult to anyone
| other than the UI designers.
| eyelidlessness wrote:
| > No, but treating non-disabled people as disabled could
| be. Just like offering help to some disabled people
| triggers them.
|
| Putting this option in accessibility settings does no
| such thing. That assumption is what I take issue with,
| and what prompted all of my points above.
|
| > My point is that having basic (previously standard) UI
| cues like buttons is important and stuffing that option
| anywhere is a poor choice.
|
| I disagree. I often find designs with fewer borders and
| shapes easier to use--that is, more accessible _to me_
| --_because_ there's less information for me to visually
| process to find what I'm looking for.
|
| That said, I'd be perfectly fine if they inverted the
| default... or even just asked on first install/startup,
| with a note on where you can change it later if you
| change your mind.
| cwillu wrote:
| I read the parent as implying that it's the designer who
| is thinking of "disability" as a begrudged requirement
| that is afforded an out-of-the-way configuration option
| so as to not inflict the ugly affordances on the rest of
| the population.
| eyelidlessness wrote:
| That seems like the least charitable interpretation of
| the facts I can imagine. Nonetheless if it's true, Apple
| doesn't just wing it when someone goes rogue on full
| design language redesigns.
| ggm wrote:
| This. Material design relies on the browser hint to inform you
| the mouse/pointer has moved to an active element. Viewed with
| no focus on an active element, how are you meant to tell which
| pane of flat colour is a pressable, actionable element?
|
| It looks great in print. It doesn't respect the modality of use
| for an online world.
|
| I'm tempted to think we have to go to browser vendors and ask
| them to make <blink> happen..
| goosedragons wrote:
| I ended up reverting back to the old context menu. Those icons
| are annoying to parse and I have a tendency to look down each
| row as 20+ years of context menus has taught. And having so
| many options tucked an extra click away.
| ddingus wrote:
| To me it all looks like an effort to push all of the work related
| to discoverability on to the users, in a way not unlike this move
| to self serve self check-out self serve this self serve that...
|
| And it is efficient, from an MBA point of view. This is pushing
| evermore cost and risk away from the enterprise, creating
| externalities along the way. The whole thing is pretty toxic to
| users overall.
|
| And yes, those users can self serve their way back to competency,
| and eventually reach a point where they're productive again, but
| they had to pay a lot harder than they would have otherwise.
|
| Remember all those studies that were done in the 70s 80s and into
| the 90s? IBM did them, some of the major CAD companies did them,
| others did that too, and there's too many to list.
|
| We should do that again. And if we were to do that, we're going
| to find out those other studies weren't bulshit, all those points
| made sense, and what's really changed is the value judgments
| related to the development, and who makes those judgments and
| why.
|
| And I bet the root of all this, is far too many enterprises are
| in a place where they just don't have to care about the users
| anymore, and they know it, and they're acting on it.
| HstryrsrBttn wrote:
| xbar wrote:
| 100% agree.
| landswipe wrote:
| I just want them to fix the mouse wheel...
| gjsman-1000 wrote:
| For everyone mad at at "Don't theme my apps," consider why
| developers are doing it.
|
| Getting complaints about how your app is broken because of an
| overzealous theme that is beyond your control _sucks_. And after
| 10 years of dealing with it, GNOME developers decided it was
| enough.
|
| And... I don't wholly agree, but at the same time, themes had a
| decade to get their act together and stop angering GNOME
| developers. They didn't.
| phkahler wrote:
| Getting rid of themes and sticking to "one true design" doesn't
| mean "use a shitty flat design".
| powersnail wrote:
| To ease the burden of handling bug reports by removing themes
| altogether at a platform level, seems like a bullet-also-kills-
| cancer solution.
| simion314 wrote:
| But why Qt/KDE developers don't lose their minds ? Either GTK
| theming is broken or the GTK app developers are not using it
| correctly or GNOME devs are assholes and really.really want to
| force their branding and vision. The above OR is not exclusive
| so it could be all 3 things.
| arcbyte wrote:
| honestly i would rather remove the ability of developers to
| make shitty controls and widgets. GUIs either ask you for some
| set of data or display it to you. Weve had a basic set of
| controls that work great for decades now. Im all for a platform
| that just requires the use of those and maximizes the ability
| if users to theme away.
| smoldesu wrote:
| I develop GTK3 apps. Theme breakage is generally a very real
| concern, as it usually points towards an issue with either
|
| a. The usage/implementation of widgets in the application
|
| or
|
| b. The stylesheet the end user is implimenting
|
| In either instance, the solution is very simple and within arms
| reach. It will always make more sense to encourage robust
| development practices over building fragile application stacks.
| malermeister wrote:
| The don't theme my app people were complaining about their bug
| trackers being full of theme-related issues. Instead of just
| setting up a filter rule in their tracker so they could ignore
| those issues, they decided to go super draconian and remove
| theming for the entire desktop.
|
| That disproportionate response to what comes down to an
| organizational shortcoming on their end made people upset, I'm
| not sure what they expected.
| jeroenhd wrote:
| Note that they don't care about the themes their end users
| pick, though. You can theme your app just fine. They just
| want operating systems using their software (with their
| logos, trademarks and support links) to stop shipping their
| custom themes by default.
|
| They just don't want Canonical or Fedora to ship a theme that
| makes all applications that didn't come bundled look like
| shit. If you like the Windows 95 Hotdog Stand theme, you can
| configure that and everybody probably agrees that that's
| great. If you inflict that pain upon yourself, that's your
| problem.
|
| The current "solution" to themes breaking applications is to
| just not follow the system theme any longer. Everything gets
| packaged with a hardcoded theme in a sandboxed environment
| and you'll just have to live with that.
| malermeister wrote:
| But end users use the same mechanism to theme their apps as
| vendors and that one is being removed.
| lwkl wrote:
| So what? Why should they continue to support some minor
| feature if it costs them a lot of resources and they
| think it's not worth it because it doesn't really fit
| their project?
|
| If you have a feature that is used by one customer out of
| thousands but it's causing problems at every update you
| push out. It might be better to remove the feature and
| fire the customer, than to keep supporting it no matter
| what.
| smoldesu wrote:
| Then let them enjoy their broken interface, and, yunno,
| let people fix it when it breaks. Like how Open Source
| works.
| malermeister wrote:
| They're not customers though. They're an open source
| community. Not everything is a business and this is an
| anti-community move.
| notriddle wrote:
| Exactly.
|
| Now you know why the application developers are so loud
| and angry. We can't have nice things because
| distributions shipped broken default configurations, and
| that's messed up.
| smoldesu wrote:
| Don't say "the application developers" like we're all one
| person. There are multiple GTK developers in this thread
| that don't care what distros ship with: this is
| exclusively a GNOME complaint. Don't drag the rest of us
| into this.
| MartijnBraam wrote:
| I handle "random theme breaking my app" as a valid bug report,
| it's not that hard.
|
| It's either something I'd have to fix in my app or fixed in
| that theme. Just ignoring the situation is just a shitty
| response.
| gjsman-1000 wrote:
| https://stopthemingmy.app
| MartijnBraam wrote:
| Yes I'm aware of it
| [deleted]
| bjourne wrote:
| It's the cycle of GNOME. Every few years they introduce something
| new that causes lots of regressions. Some of these regressions
| are then being worked at, some are defended as "design decisions"
| (no theming, Nautilus opening a new window for every folder,
| broken filechooser dialog, desktop indexer you can't turn off).
| Bugs are worked on and thing stabilize. People learn workarounds
| for their issues. Then another iOS-inspired thing comes and
| things break again.
| aulin wrote:
| > Then another iOS-inspired thing comes and things break again.
|
| This always puzzled me, there's been a time around 2010-2011
| where everyone thought desktop was doomed, tablets would take
| over its space so you had to design everything to be mobile
| friendly. Those times have fortunately long gone, tablet are
| almost a thing of the past, desktop is here to stay, yet GNOME
| and RH designers still take iOS design as a reference... why?
| johnqian wrote:
| I'm going to take a risk here and say that I'm a designer who
| generally likes flat design.
|
| I see a lot of hate here against flat design, and it makes sense.
| A lot of designers abuse it, making their UIs ambiguous. It's
| probably true that if flat design was never conceived, UIs would
| be less confusing on average.
|
| But it's clearly possible to do flat design well. iOS is mostly
| flat, but it's quite beautiful and user friendly. You usually
| know when something is a button because the context makes it
| obvious. If it's not obvious, it's probably not a critical
| feature, just a nicety for those who discover it. There will
| always be people who hate everything Apple designs, but I think
| they're usually channeling a hatred of something else, like
| monopolies or proprietary things.
|
| Moreover, I think flat design is not a fad but an inevitability.
| As a rule, designs become more abstract over time, because as
| users get more used to UIs, they need fewer clues. It used to be
| that UIs needed to be skeuomorphic to be familiar and
| recognizable, but now simple outlines can do the job.
|
| Why do we need to remove unneeded clues, you ask? To make room
| for more important things. If Instagram was littered with
| gradient buttons and blue underlined links, they'd draw attention
| away from the real content, the pictures. If Figma had too much
| personality, it'd influence users' designs.
|
| You could argue that we've gone too far too fast. I don't have a
| dog in that fight. But I would bet my big toe that we're not
| going to reverse time and end up with skeuomorphism again.
| Instead, we're going to take advantage of faster GPUs to
| visualize abstractions in ways we couldn't before. We're seeing
| that with blurred background effects becoming more common. I for
| one am excited to see what's next.
| Derbasti wrote:
| I'd actually be willing to bet that we will go back to a more
| 3D look before the decade is over. Not my big toe, though. I
| need that. Maybe, a bottle of beer, or something?
|
| I'd argue that the flat 2D look is cool these days because it
| is different from the skeuomorphic 3D look we had before. It
| will look old and faded in a few years, and in the search for a
| fresh look, we'll rediscover a more tactile 3D look.
|
| Anyway, I actually like the flat 2D style as well. It might be
| that many current programs are not doing it well merely because
| they haven't had much experience with it. This will sort itself
| out in a few years. Much like the super-skeuomorphic apps from
| a few years ago that included things like stitching and torn-
| off paper in calendar apps and notepad apps, respectively.
| birksherty wrote:
| > It used to be that UIs needed to be skeuomorphic to be
| familiar and recognizable, but now simple outlines can do the
| job.
|
| Nope. It just makes everything horrible, more pressure on brain
| to find out and slow in the end to do everyday operations. It's
| just the designers who love these just for the looks (they
| don't even know what design actually means), not for any
| usability.
|
| Tech would have better without these type of "designers".
| Findecanor wrote:
| Something you much see too often is that a designer tries to
| copy some design, without understanding _why_ that it had been
| designed that way in the first place.
|
| That is how you got bad flat design.
|
| That is how the idea of metaphors got skewed into skeuomorphism
| -- and likewise, how metaphors got swept away by the movement
| against skeuomorphism.
| pmontra wrote:
| Maybe most designers are not even designers but only
| developers, frontend or backend, and the best they (we!) can
| do is copy something we already used which could come from
| other non designers. All the reasoning is lost in the
| process.
| joppy wrote:
| What do you think of the iOS podcasts app then? I have no idea
| of where to press to view details of a podcast, vs to start
| playing it. On the main page, the black text starts playing a
| podcast, and the purple text shows details. Further into the
| app, the purple text will start playing while the black text
| will view details. While playing, neither the purple nor black
| text do anything (they act as title/subtitle). Clicking on a
| picture is also pretty unpredictable.
|
| This is admittedly not a flat vs non-flat design problem, but
| it is exacerbated by the flat design. If actions which started
| something playing were outlined or something, it would be so
| much easier to use.
| SquareWheel wrote:
| I think this is a fantastic comment. I've always seen design as
| just trends, but you're completely right that is serves a
| specific purpose, and as that purpose changes so does the
| design. There may still be trends, but we can at least reason
| about them.
| solatic wrote:
| > Why do we need to remove unneeded clues, you ask? To make
| room for more important things. If Instagram was littered with
| gradient buttons and blue underlined links, they'd draw
| attention away from the real content, the pictures. If Figma
| had too much personality, it'd influence users' designs.
|
| This is an oversimplification and not always correct in all
| situations. Take the original article as an example. How did 3D
| buttons take away from the "more important things"? Does making
| "New List" a flat button and thus barely distinguishable from
| the "To Do" title help to enhance, somehow, the "To Do" title?
| Does not the strong blue in the flat button ("Add Tasks...")
| draw user attention to it, distracting from the rest of the UI,
| rather than withdrawing from the rest of the screen to allow
| "more important things" to shine?
|
| If flat design really succeeded at helping to direct users'
| attention to what is important, it wouldn't be subject to the
| criticism that it confuses users. Users would be helped, not
| hindered, by such design, no?
| berkes wrote:
| > A lot of designers abuse it, making their UIs ambiguous.
|
| ...
|
| > This is an oversimplification and not always correct in all
| situations.
|
| You are both saying the same thing, I guess. grandparent
| states that it is "possible to do flat design well" and gives
| examples (Apple). I don't have anyhting Apple, don't like it,
| but I do find their designs awe-inspiring.
|
| To me, this comes from their investment in detail. The issues
| you describe "Does making "New List" a flat button and thus
| barely distinguishable" is real and an example of bad design.
| Not a proof that all flat-design always is bad. It shows that
| too little time and effort was poored into this piece.
|
| I'm not sure how I would fix this particular issue. But I'm
| confident that within the contstraints of "flat design" and
| time and effort (investment) in details, this is solvable.
|
| I'm also confident that without the constraints of flat-
| design, the time and effort needed would be far less. But
| here we are.
| danachow wrote:
| > iOS is mostly flat
|
| It's less flat today then it was - because they're clearly
| backpedaling.
|
| > There will always be people who hate everything Apple designs
|
| Apple ripped off flat design from Microsoft.
|
| > Why do we need to remove unneeded clues, you ask? To make
| room for more important things.
|
| Last I checked, some texture on UI elements didn't take any
| additional space.
|
| Your arguments are entirely unconvincing.
|
| Blurred background effects are nothing new - and that's
| something that's been done with GPUs from nearly 20 years ago.
| They haven't been able to make it anything more than a fad.
| dandellion wrote:
| > If it's not obvious, it's probably not a critical feature,
| just a nicety for those who discover it.
|
| That's a really bad way to go about usability. It's pretty
| frustrating you're looking for a feature to have to hunt for it
| like you're playing a point & click game. At that point I
| wouldn't even call it a feature, it's an Easter egg.
| bno1 wrote:
| Exactly my thoughts. Who's to say if a feature is critical or
| not? It's the user.
| raphael_l wrote:
| I would say this is not entirely correct as a standalone
| rule. Just to make it clear, I completely disagree with
| this statement the OP made:
|
| > If it's not obvious, it's probably not a critical
| feature, just a nicety for those who discover it.
|
| There is a huge difference between discoverability and
| hierarchy. If the user can't distinguish between an
| interactive element and a static label, the UI has failed.
| But there is definitely nuance in the degrees of hierarchy
| and importance. If every button looks the same with every
| affordance necessary for a user to recognise it as such, it
| might be great in terms of discoverability, but in most
| cases it would still be bad design because as a user I
| can't easily distinguish between primary, secondary or
| tertiary actions.
|
| This is of course also highly dependent on the business
| goals and overall context of the design. If you have a
| marketing page you might want to clearly distinguish
| actions that lead to the sign up or download of your
| product (this - in most cases - is what you would like your
| users to do and also what your users eventually want to do
| themselves). If you have enterprise software that is highly
| customizable and completely different for each and every
| individual, you might want to shy away from opinionated
| hierarchy of importance. In this case, it would be very
| much dependent on the user and therefor their choice.
|
| Typically the context is - at scale - more on the former
| side than the latter. If I have, for example, a notes app I
| would say the hierarchy favors the creation of new notes
| rather than going into settings to change the appearance of
| my notes. That doesn't mean it shouldn't be discoverable,
| only that the design should clearly dictate what's more
| important (especially on a temporal dimension: I'll add
| notes more often than I would edit the style) and therefor
| influence the appearance of both actions.
|
| Let me know what you think.
| matsemann wrote:
| I disagree on iOS. Give an iPhone to someone never having used
| one before, and I'm sure they won't even be able to unlock it.
|
| I almost cringe when I see UX people with iPhones. Yes, it's
| esthetically pleasing, but please don't take too much
| inspiration from the way things work.
| pmontra wrote:
| The first time somebody handed me an unlocked iPhone asking
| me to send a SMS (she was driving) I wasn't able to do it. I
| had to ask her where to touch. She was really surprised. I
| had a few years of experience on Android and 10+ with feature
| phones.
|
| On the other side, I asked another friend of mine to take a
| picture with my Android phone a couple of weeks ago and she
| (an iPhone user) wasn't able to find the camera app. I had to
| open it for her. It was on the home screen, maybe it's
| different on the iPhone.
| toqy wrote:
| On iPhone you can swipe left on the Lock Screen, or press
| the icon on the Lock Screen, or you can pick it from a menu
| you pull down from the top of the screen, or find the app
| via icon, search, full app list. Maybe other ways I don't
| use or know.
|
| I would assume that it's similar on android, access the
| camera from lock screen or app. I'd probably try the iPhone
| style swipe the lock screen if I didn't see a shutter or
| camera looking icon, otherwise I'd use search (if I could
| find that) to find the app.
| pmontra wrote:
| Maybe that's what happened. I removed everything from the
| lock screen and she could have inadvertently locked the
| screen.
| PennRobotics wrote:
| I had to Google how to turn on an iMac.
| toqy wrote:
| If they can't read "swipe up to open" then they're going to
| have a rough time in life in general
| matsemann wrote:
| But that text is a lie! You can't swipe up to open. You
| have to swipe up _from the bottom_ to open. So not just a
| general upwards swipe.
| michaelsalim wrote:
| Precisely. And the text isn't even guaranteed to be there
| (I don't use iOS).
| Spivak wrote:
| Yes but on the flip side I don't give two shits about
| discoverability, I already know how to use my phone. Snapchat
| is actively terrible for discoverability but it's really
| efficient once you know.
|
| The best design for someone who is unfamiliar and the best
| design for the user that already knows how it works are
| always at odds with one another. Do you balance the game for
| new players or for diamond league?
| michaelsalim wrote:
| Seconded. Wasn't able to unlock one the last time I touched
| an iPhone. And I even owned one - iPhone 5. Some people I
| talk to share similar experience.
| odonnellryan wrote:
| Yeah from someone who supports users sometimes they have no
| idea how to use their iPhones.
| lnxg33k1 wrote:
| --- Now one of the worst parts is that everywhere I only even
| hint at not completely loving the new libadwaita theme I
| instantly get shut down and disagreed with before I can even get
| the chance to give some feedback. Apparently not liking flat
| themes makes me a madman in this world. Why am I not allowed to
| even have opinions about the look of the operating system I'm
| using? ---
|
| But to be honest, isn't it one of the recurring point of people
| running away from gnome? Haven't they just proceeded going ahead
| not listening to anyone?
| [deleted]
| traverseda wrote:
| It's kind of cathartic watching this happen to a new generation
| of developers. They can't say I didn't warn them!
|
| Ultimately I think this will be quite good for QT/kde in the
| long term. Gnome/GTK gets a lot of corporate support,
| especially from red hat, but seeing the issues pop OS had with
| GTK makes me hopeful that more companies will adopt QT.
| aftbit wrote:
| Dropbox desktop app is written in QT, at least on Windows and
| Linux. Mac uses its own custom UI to better fit with the Mac-
| app world.
| lnxg33k1 wrote:
| Also EA Origin is written with Qt no? At least last I ran
| windows?
| naoqj wrote:
| The Blizzard app is.
| lmm wrote:
| I've been hoping that for 20 years but it hasn't happened
| yet. It seemed like American companies always favoured
| GTK/GNOME (I guess because Qt/KDE development was more
| European?), even though Qt/KDE generally managed to do more
| with less. But I can appreciate that if you're aiming for the
| corporate market, customizability may be a downside.
| nine_k wrote:
| I think that Red Hat (now part of freaking _IBM_ ) has
| always been oriented to big corporations, knows how to
| speak their language, and is an obvious choice for
| corporate Linux support. If you're already in bed with RH
| on the server front, it makes obvious business sense to
| also follow them on the (much, much smaller) desktop front.
| Since RH basically owns Gnome development (I know, I know),
| they impressvely used it as a lever to push systemd
| adoption, for instance: major distros had to switch to it
| not (solely) on its merits, but because they could not drop
| Gnome support.
|
| KDE does not seem to have an equivalent behemoth behind
| them, even though Qt enjoys a lot of heavyweight corporate
| support.
| calvinmorrison wrote:
| Which is insane because even back in KDE 3.5 days, and
| Trinity following that, the support for complex user
| environments, security features, using any type of remote
| storage natively through the KIO subsystem, really good
| support for LDAP and AD and other things... it seemed
| like a natural fit for a more complex corporate
| environment. Especially tools like Konqueror and Kmail,
| both of which to me follow a natural progression out of
| the windows of the late 90's era, had really good
| usability and made sense fairly quickly to windows users.
| lmm wrote:
| Yeah. SUSE (at one point owned by Novell) was kind of
| trying to go the same route, but never really got as big
| as RH. (Though again I wonder how much of that was just
| an America/Europe split)
| travisgriggs wrote:
| Or as my office mate always points out:
|
| "Big likes big."
| IshKebab wrote:
| Qt is far more popular in corporate software than GTK. It's
| way better, and companies don't care about Gnome or KDE so
| there's no reason to pick GTK.
| ogogmad wrote:
| Superficial opinion: GNOME 3 is the best-looking DE for Linux,
| but I personally prefer using KDE. It's a shame then that the new
| flat design in GTK 4 looks ugly. I suppose it's all subjective --
| but I'm struck by how viscerally bad most flat designs look to
| me. I suppose it's another "aesthetic movement" that most of us
| philistines won't understand:
| https://en.wikipedia.org/wiki/Brutalist_architecture
| smoldesu wrote:
| That's precisely how I feel. Words can't really describe how
| taken aback I was when I typed in "sudo pacman -Syu" that
| fateful day and rebooted into... whatever GNOME 40 was.
| kuon wrote:
| I don't like flat design. But I do like the new neomorphism
| trend. Not everything, but having clear states (hover default
| active disabled) is nice.
| aidenn0 wrote:
| GNOME is in a damned-if-you-do damned-if-you don't situation
| here; if they don't adopt the flat theme, they look "old
| fashioned" and if they do they have a crappy UI.
| azinman2 wrote:
| So basically the new GTK is iOS but without the professional
| designers behind it.
|
| What I cannot understand is how Canonical, Red Hat, or some rich
| SV person hasn't thrown money at the problem and hired a big wig
| design firm or person to overhaul it all. Johnny Ive is now even
| available (if he'd take the project). But even going thru a site
| like dribbble there are so many amazing designers out there. To
| me it would be a more impressive portfolio piece for a young
| designer to properly design GTK/Gnome and put it out there for
| the world. What is stopping this? It can't be caring with the
| history of people sharing their themes. Is it just taste / money?
| capableweb wrote:
| Easy for someone who works at Apple to say "just throw money at
| the problem" while there is so much more to consider. Design as
| a workflow for Open Source design (as in UI/UX) hasn't even
| been worked on that much. Ideally, open source contributors
| work on projects because they care about it, and want to
| improve it. I'm not sure how many designers are using GTK
| applications day-to-day to care enough about it to start
| contributing. There is a learning curve as well on how to
| contribute to these large projects.
|
| It'd be great if it could be solved with just one pass of
| design work and then it's done, but I'm afraid the task is much
| bigger than that, and "big wig design firms" are expensive, so
| are design people as well. Not to mention the other problems
| around that.
| azinman2 wrote:
| As I mentioned before, Canonical and Red Hat have money and
| could afford proper designers. Programmers are expensive as
| well, and they have plenty of those on staff.
|
| Someone is putting together standard HIGs for Gnome, writing
| these standard themes, designing the base apps, etc. So you
| can't just say it's all decentralized and so there's no hope
| -- there's a ton of collaboration and top-down work happening
| with Gnome. Pulling in great UX/UI design talent should be
| prioritized.
| audidude wrote:
| > As I mentioned before, Canonical and Red Hat have money
| and could afford proper designers.
|
| They do employ designers, including for GNOME. You might
| not like their designs. But to call them anything but
| proper is pretty mean spirited.
| woah wrote:
| Inherently, good design requires top down authority to force
| a consistent look, and implementing it requires a bunch of
| programmers to spend time on boring work. That just doesn't
| work well in open source where people only want to work on
| their own thing, sometimes, and in their own way.
| capableweb wrote:
| Same could be same about good software design (as in
| programming), but we've found to design well written
| software before in a open source manner, I'm sure we could
| (if we focus on it) figure out something for UI/UX design
| as well that works in a open source context.
|
| For example, style guides written and enforced by a small
| team can allow open contributions for the UI design.
|
| I think it's mostly that not many have tried to figure out
| how to organize and actually run large-scale open source
| design work for UI/UX and that's why we haven't figured it
| out, I don't think it's "inherently" impossible.
| woah wrote:
| No, definitely not. Good software does not require all
| the code in it to be written in the same style, and it
| never is.
| lwkl wrote:
| And look at how these projects are organized. Most of the
| time it's pretty much top-down with a. It's why we have
| the term BDFL.
|
| > good software design (as in programming)
|
| That's the second problem. Most programmers probably know
| about about how good software design works, but have poor
| taste and prefer designs that aren't suitable for
| software that is to be used by non-programmers that want
| sane defaults that work and don't overwhelm them.
|
| Just look at the theming debate. People in software
| developer forums are mad about it. Most users probably
| don't even know it exists. They just want settings and a
| UI that's simple enough for them to understand and allow
| for some basic settings.
|
| So you would have to force volunteers to implement a
| design that they feel is bad. And you see how a lot of
| people react to it in the Gnome project where people
| leave because of it. But at the same time Gnome is a good
| example of how to do UI/UX for a big open source software
| project (even if you don't agree with their design
| decisions).
| eru wrote:
| > And look at how these projects are organized. Most of
| the time it's pretty much top-down with a. It's why we
| have the term BDFL.
|
| To make a more general point: top down leadership is not
| inherently bad. But in order for this to work well,
| people need to have the ability to enter and exit a
| project or polity at will.
|
| (See eg how McDonald's doesn't let customers vote what to
| put on their menu, but customers are free to eat at a
| competitor or make their own food at home.
|
| And compare that with North Korea also not letting
| citizens vote on their menu. But also taking steps to
| keep people from switching to a competing provider of
| government services, like South Korea. Similar also for
| the Berlin Wall.)
| calvinmorrison wrote:
| > good design requires top down authority to force a
| consistent look
|
| which hear me out here... was the whole point of having a
| standardized widget set and UI library.
| Flankk wrote:
| Every screenshot in this blog post showcases dated design
| paradigms. Flat UI was popularized around the release of
| Windows 10 in 2015. When I go through dribbble I see a lot of
| mediocre and copycat design. Design is about more than copying
| what Apple is doing. You're not going to get style from fat
| guys with ponytails.
| baybal2 wrote:
| flukus wrote:
| > So basically the new GTK is iOS but without the professional
| designers behind it.
|
| Professional designers seem to be the ones creating these
| problems. Back when it was just programmers you could tell a
| button was a button, a tab was a tab and we didn't hide basic
| functionality behind a swipe gesture or long press that users
| were supposed to just know.
|
| Now everything is pretty but harder to use.
| marcosdumay wrote:
| > you could tell a button was a button, a tab was a tab and
| we didn't hide basic functionality...
|
| Those conventions were created by usability experts after
| years of research. It wasn't simply programmers building them
| back then.
| michaelmrose wrote:
| Arguably you have 4 camps.
|
| 1. Developers with a wide range of understanding of UI from
| negligible to acceptable.
|
| 2. UI experts who actually understand code.
|
| 3. UI "experts" in industry whose only skills are image
| editors.
|
| 4. Academics who did said research.
|
| Seems like the entire problem is the ascendancy of Camp 3
| which decision makers who being ignorant of technical
| matters themselves can't tell from camp 2.
|
| Meanwhile everyone is ignoring camp 4.
| warning26 wrote:
| _> Back when it was just programmers you could tell a button
| was a button, a tab was a tab and we didn 't hide basic
| functionality behind a swipe gesture or long press that users
| were supposed to just know._
|
| Keep in mind that programmers also gave us this:
| http://www.martin-achern.de/wgetgui/images/linux_wgetgui.jpg
|
| People across all disciplines are capable of making poor
| design choices
| ogurechny wrote:
| There are many crappy UIs made by dragging buttons and
| labels in visual editors, but I believe this example comes
| from a discussion of a different problem. Namely, how to
| make a non-shitty non-toy GUI for a console tool. And the
| answer is, you can't, unless you'd already had the mental
| model, the hierarchy of options and modes of operation that
| could be projected onto both types of interaction before
| you made them.
|
| Essentially, this is not even a GUI application, this is a
| printed cheat sheet for console program with interactivity,
| like HyperCard or '90s context help systems, but with
| "callbacks" affecting the program state. It is made for
| people who know and understand the console version, and
| just want to choose options with the mouse. Of course, it
| may be advertised as something made for regular people, but
| that's a honest false belief. It's more of a convenient
| shell alias transferred into 2D, something which is not
| expected to be super nice, or handle all corner cases if it
| helps you in general.
|
| I think it is, actually, something to be encouraged. There
| are some tools that people made in Flash for their own use
| or some fan group because that's what they "programmed" in,
| not to mention big examples like (Visual) Basic, etc. A
| user is not just a consumer of what comes to the dumb
| personal device, a user is someone who can make it work in
| some unique way, because that's what computers are made
| for.
| userbinator wrote:
| _Keep in mind that programmers also gave us this_
|
| You're basically proving the point. That is so much clearer
| and obvious to use than the screenshots in the original
| article, and it doesn't treat you like an idiot.
| notriddle wrote:
| Yes, I know which things are buttons, which things are
| text entry, and which are checkboxes. This was a strength
| of early 2000's UI design, and it's a shame that so many
| applications don't give such clear indicators any more.
|
| This application still has an absolutely crap design.
|
| * How do I specify where the downloaded data _goes_? Why
| are there onscreen options for literally everything else,
| but not that?
|
| * Which text entry fields are disabled, and which ones
| are enabled? This is something Win95 got right.
|
| * What even is "force directories"? And it looks like
| checkboxes are used for both it and "no directories", so
| what happens if I check both?
|
| * What's the difference between Spider and Recursive?
| Those sound like the same thing to me, and I know I'm in
| a pretty elite club just knowing what web spiders are at
| all.
|
| * Are jpeg/gif/etc only used when Reject is turned on, or
| are they also used when Accept is turned on?
|
| * Is the wget-list input field connected to the Input
| file checkbox? It's right underneath it, and presumably I
| have to specify the input file _somewhere_ , but the
| spacing implies it's not.
|
| * What's the difference between "quiet" and "non
| verbose"? What happens if both are turned on?
|
| * The rest of the buttons are pretty well labeled, but
| what's AG?
|
| * Does it really need its own quit button? The window
| manager already provides one.
| userbinator wrote:
| I'm not saying it's perfect, but it's better than the
| "small mysterious monochrome hieroglyphics floating in a
| sea of white/darkness" that "modern" UIs seem to be
| gravitating towards. At least textual labels are
| searchable.
| notriddle wrote:
| > I'm not saying it's perfect
|
| I didn't stop listing problems because I ran out. I
| stopped because I got bored. Now you got me going again:
|
| * Why does input-file have no "Browse" button?
|
| * Why does log file have no "Browse" button?
|
| * What is the point of showing the command line flags?
| I've seen a few GUI apps that let me "export CLI"
| commands that match what I configured in the GUI. That
| would be a much better way to do this.
|
| * Why does nothing indicate that the exclude/include
| lists are only used for recursive fetching?
|
| * Extra Params can potentially be very long, yet the box
| is tiny.
|
| * I assume quota=0 turns the feature off. Why no check
| mark?
|
| * Why do the exclude lists have check marks, when leaving
| them empty should be equivalent to turning them off, if
| quota has none.
|
| Wget's CLI is better than that thing.
|
| > but it's better than the "small mysterious monochrome
| hieroglyphics floating in a sea of white/darkness" that
| "modern" UIs seem to be gravitating towards. At least
| textual labels are searchable.
|
| I did intentionally start my post by saying I agree with
| this part. iOS 7 was a mistake.
| jancsika wrote:
| Were you raised in the desert by a cactus or something?
| Because there is nothing clear nor obvious to me about
| that motif word salad.
|
| Ah, I can just _feel_ it failing to pop up a tooltip when
| I mouse over the "spider" option!
|
| I can also feel the entire window disappearing when I
| click "START wget." Is that what happens? Maybe not, but
| that was par for the course on a lot of those motif GUIs.
|
| And I can definitely _feel_ how the growing information
| density was even frustrating the poor dev. "Load sett.",
| "Save sett.", ah fuck it... "AG"
|
| And again, _feeling_ the disappointment as I mouse over
| "AG" and get nothing...
| hiccuphippo wrote:
| I think the problem Gnome, and Microsoft, have is they keep
| throwing money at designers. So designers keep making designs
| for the sake of designing. They should stop designing, stick to
| the design they already have and only do incremental updates
| when new widgets come out.
| azinman2 wrote:
| It's not like everything was perfect in the past and so we're
| done. Far from it.
|
| Even beyond that, the world is changing. New needs, new
| expectations, new styles in design. Just like we wouldn't
| expect cars to be frozen in time in the 1950s, we shouldn't
| expect UI/UX to be either.
|
| Linux DE's have never had a particularly well thought out,
| well designed look. There's been a lot of themes that people
| create to mimic other commercial systems out there, but not a
| lot of very high quality original work going on. Yet we can
| see plenty of good work technologically. For a long time when
| it was largely grey beards most people didn't mind so much,
| but now people expect good design across all products. The
| standards have risen, and the FOSS world should meet that
| challenge head on.
| MichaelBurge wrote:
| > New needs, new expectations, new styles in design.
|
| The article focus on the settings control panel. What new
| needs and expectations does the new settings control panel
| in 2022 have compared to 2010?
| azinman2 wrote:
| The article is really about GTK3 versus GTK4, using the
| settings pane as an example. My comment is about the
| larger picture. However, take a look at what it meant to
| reset your default settings in 2010:
| https://www.omgubuntu.co.uk/2010/08/restore-default-
| gnome-se...
|
| Settings panes are still largely confusing on all
| platforms, commercial included, as you broaden your user
| base. They've also grown in utility as iOS has pushed the
| idea of a centralized place for settings for all aspects
| of the system (apps included), which you're starting to
| see elements of on other platforms as well. There's
| plenty of room for improvement, including simplifying
| everything down so that few settings can make big
| differences where the heavy lifting is done for you.
| Linux in particular suffers from this, from a legacy of a
| million .conf files everywhere that many people blindly
| copy-pasta'd random configurations they found online (I'm
| looking at you XFree86).
| rtpg wrote:
| To play a bit in this space, if you check out the
| settings panel in Ubuntu compared to, say, the Windows XP
| control panel, you'll see that Gnome's settings panel is
| more usable. Mainly on account of having a single entry
| point, and the search bar on the top.
|
| I think a lot of this is influenced by modern MacOS and
| iOS settings management (much like, to my recollection,
| Gnome 2 settings panels were very influenced by how
| Windows was doing things). It's not like it's 100%
| better, but for my usage it's felt nicer.
|
| There are also a lot more work in this idea that there
| are many different ways to get to a settings pane. That
| way it's easier for people to get to a thing even if they
| have different ideas of where it "should" be
| michaelmrose wrote:
| KDE plasma settings is far more usable because it has a
| single entry point and a search function that actually
| works.
| probably_wrong wrote:
| > _Just like we wouldn 't expect cars to be frozen in time
| in the 1950s, we shouldn't expect UI/UX to be either._
|
| I think your example points to a peculiarity of UI/UX: cars
| have changed a lot since the 1950s, but their interface has
| remained surprisingly constant.
|
| I think there is a point to be made that an interface can
| reach a point at which it cannot be improved, or at least
| not without a whole paradigm change.
| azinman2 wrote:
| But even that is not true. Windows are now mechanized,
| with child locks. The ways to open and lock doors is
| different, both in the car and from afar. The entire
| center console now is different, to the point where Tesla
| has just a touch screen on many models. There are cup
| holders, EVs have fruncks and often are largely driven
| using 1 pedal, side mirrors are adjustable with motorized
| buttons, seat placement is totally different and often a
| setting that can be memorized by the car, stick shifts
| and clutches are largely gone, the wheel inner shapes are
| different and often contain buttons, starting/stopping
| the car is usually a button, etc etc.
|
| If you're focused simply on the steering wheel itself
| that's like saying there's still a mouse and keyboard.
| Yes, that's true -- and even that will likely be
| disrupted over time. But everything else has changed.
| michaelmrose wrote:
| Child locks were patented in 1949. Powered windows in
| 1941. Cup holders in cars date back to designs in the 50s
| popularized in the 80s.
|
| Push button shift considered in 1913. Push button
| starting actually predates keys.
|
| A touch screen UI is indeed new but its a UI horror story
| for something that is expected to be operated while
| driving down the road at 60 mph.
| eternityforest wrote:
| Why are designers so different from the rest of us I wonder?
| They value minimalism above all else, with little debate, but
| everyone else has a lot wider of a range of preferences it
| seems like.
| harry8 wrote:
| If you're Apple and you make your desktop more attractive and
| pleasant you drive sales and market share. If you're redhat and
| you resource that you drive market share, to Ubuntu, who I
| believe still have a policy of never paying for development
| except for Ubuntu things, eg their failed desktop nobody else
| would use, Mir, bzr, etc.
|
| Is that still the case? It would be a huge disincentive for
| other distros to contribute to the commons when ubuntu just
| parasite from it to a big market share.
| michaelmrose wrote:
| You may want to ask yourself why Red Hat despite having a lot
| more money and investing some of it in desktop Linux still
| has a fraction of the market share of Ubuntu. They are in a
| great position to dominate that market.
|
| Instead we get a very rapid iteration with a 6 month release
| cycle that continually pulls in new tech prior to it actually
| being ready while it still has massive issues with end user
| experience including but certainly not limited to gnome 3,
| pulseaudio, gnome 3, wayland by default in 2016 which is now
| 6 years later supposedly almost fully ready for prime time.
|
| My experience running Fedora for 7 years is that each release
| was a chance to play with new tech and fix new broken things.
| In place upgrades were also extremely dicey making a fresh
| install of the new version necessary every 6-9 months.
|
| This is great for a toy less great great for something you
| intend to use. I'm sure current proponents say its great now
| but they literally have been saying the same thing forever.
| simion314 wrote:
| >If you're redhat and you resource that you drive market
| share, to Ubuntu, who I believe still have a policy of never
| paying for development except for Ubuntu things, eg their
| failed desktop nobody else would use, Mir, bzr, etc.
|
| Fact check, Gnome was filled of memory leaks and performance
| issues until some competent Canonical developer started
| working back on GNOME and fixing them.
|
| So while Ubunut was not using GNOME the RH could have safely
| put their money into GNOME and it would not have benefited
| Canonical but the reality is that Canonical had to pay
| competent people to fix GNOME bugs, but probably Canonical
| can't change the desinger dictator so they usewd for a while
| a fixed theme and not the shity GNOME default.
|
| I disconnected myself from Linux news so I don't know what
| drama happened in latest 2-3 years.
| harry8 wrote:
| Who? When? What? They hired Henstridge to work on nothing
| to do with gnome? Redhat hired a bunch of core gnome devs
| to work on gnome? No? Happy to find out I'm wrong if there
| are facts involved...
| simion314 wrote:
| Are you new to GNOME? this is a few years old when
| Canonical dropped Unity. What was happening was that each
| GNOME release fixed some memory leaks but create a few
| new ones, the lag was terrible and when Canonical moved
| back to GNOME a Canonical developer started fixing stuff,
| GNOME devs were blaming the hardware for the bugs or were
| busy with removing features.
|
| https://www.omgubuntu.co.uk/2019/10/ubuntu-improves-
| gnome-sh... you can google the dev "Daniel Van Vugt" and
| check his work on GNOME, or you can google "GNOME shell
| memory leak" , as I said I stopped following Linux stuff
| (I am still a Linux users) and I have no idea what
| happened in recent years except the major things like
| GNOME's reset triggering a new fracture in it's
| community.
|
| Anway, Canonical was not using GNOME so RH did not
| avoided paying for better developers because Canonical
| would benefit. Later when Canonical decided to use GNOME
| they fixed the major performance issues and memory leaks
| and put back some of the features the users wanted but
| designers refused to provide.
| derefr wrote:
| Lots of rich companies threw money at the problem of Linux UI,
| Linux application packaging+sandboxing, and several other
| things. The result is the Android OS ecosystem, where each
| hardware vendor has its own proprietary shell, in capitalist
| competition with other vendors' shells.
|
| I'm not even saying that that's a bad thing. As it happens,
| Android has been generalized and generalized from its original
| use-case until it is today a quite-workable desktop PC OS.
| skykooler wrote:
| That's sort of what happened with ElementaryOS, isn't it?
| azinman2 wrote:
| Sort of. It largely was a copy of Apple, unfortunately.
| However I think it at least pushed the bar of what might be
| possible with Linux, and they're no longer around [1]. I'm
| hoping someone can come and give real high quality work to
| the FOSS community and take on a wider perspective. They had
| to basically do their own thing instead of pushing GNOME/KDE
| along, which may have to be unfortunately the case. It would
| be better if we could leverage the existing code bases rather
| than starting from scratch, but there maybe enough major
| things that need to change and enough resistance from the
| existing communities to allow for that to happen.
|
| [1] https://lunduke.substack.com/p/elementary-os-is-
| imploding?s=...
| chillfox wrote:
| Wut... what, when how???
|
| I love ElementaryOS, it's great, everything just works, I
| didn't have to tweak a single thing or mess with drivers
| earlier this year when I installed it on a new laptop that
| even Mint was having issues with.
|
| Going off to read that link now.
| azinman2 wrote:
| Funny, I tried it last year and keep getting kernel
| panics. That's the thing that's hard about Linux -- a
| million different hardware configurations.
| chillfox wrote:
| yep, If you have troublesome hardware then I find the
| fastest solution is to just cycle through the top 10
| distros to see if it works on any of them. If it does
| then great, you can either stop there or use it as a
| "guide" for how to get your favorite distro working.
| yoasif_ wrote:
| > Below is the full text, as posted to Twitter by
| elementary founder Daniel Fore.
|
| Oh, Lunduke is misgendering people now? I'm sure _that_ isn
| 't on purpose.
| akdor1154 wrote:
| You know what? This shouldn't be so bad. I should just be able to
| change theme to one i like.
|
| However, because gnome no longer respects their users' opinions,
| there is no way to change it.
|
| I mean fuck, if i wanted to use a Mac i'd just use a Mac.
| travisgriggs wrote:
| I don't like conspiracy theories, but I always wondered if the
| flat design trend wasn't a genius way to nullify the advantage of
| higher powered graphic platforms.
|
| "Our stuff looks lickable, buy our expensive hardware."
|
| "Au contraire, design with colored paper and scissors is hipper
| than lickable UIs. Buy our less than stellar hardware."
| zestyping wrote:
| You can get pretty far with one simple principle:
|
| Things that are the same should look the same. Things that are
| different should look different.
| wooptoo wrote:
| All I can hope is that XFCE with its conservative approach will
| never pick up this new design language. Why have changes for
| change's sake?
| bfrog wrote:
| I really like adawaita as well, I'm sad to see the easily visible
| buttons are disappearing into flatland.
|
| I agree with the author, the flat look shown here is missing at
| the very least some outlines on buttons. Hidden UI elements seem
| like an awful idea.
___________________________________________________________________
(page generated 2022-03-25 23:02 UTC)