I write English / Escribo en Español.

Vidya / videojuegos. Internet. Cats / Gatos. Pizza. Nap / Siesta.

This user’s posts under CC-BY-NC-SA license. Ask me if you need a different permission.

  • 13 Posts
  • 877 Comments
Joined 2 years ago
cake
Cake day: July 26th, 2023

help-circle




  • UI is not really a problem. Every time I hear complains about a given FOSS client of something “UI” not being “modern” it’s basically complaining “waaa waaa this does not look exactly like Discord, I can’t find a thing that is obviously labelled as a button!” or some such thing. Which is weird because, honestly, all chat apps like Signal, Telegram, Conversation or Gajim do basically have the exact same look: a pane for chatrooms, a pane for current chatroom, and a pane for typing. There: that UI was literally solved in the 90s.

    Speaking of 90s, Winamp is from the 90s and the UI is doing quite well, to the point more modern programs intentionally want to look Winampy (eg.: Audacious).

    UX however… it has quite a number of issues, such as there not being a practical way to know if all of the client, the server and service you want to use support the features you want, in particular encryption and message archiving.

    Even the “beforehand” / “onboarding” UX is annoying: would anyone here be able to point to the “join-lemmy” equivalent of the XMPPverse? Or point to a generalist server with long-term lifetime, kinda like how freenode was (note: was) for IRC?

    If I had to venture, I’d say if an important group actually put effort into setting up and servicing long-term XMPP infra in the style and generalism that freenode was, then probably it could gain some good traction. If anything, it could help doing the join between “upgrade people from IRC” and “upgrade people from modern silos”.










  • They can stop telegraphing some of this information, but then the websites won’t render properly (they use this information to display the website properly),

    Pretty much none of the information is necessary to ever render a site properly.

    OS and CPU architecture? Ireelevant to whether you are sending a JPG or PNG background. Nearly irrelevant to whether you are using a vertical or horizontal screen (and browsers adverstise that info separately anyway, it’s even part of CSS media queries).

    Accelerometer and gyroscope? The only reason that could ever be needed for rendering is if the user is moving so incredibly fast that red pixels in their screen would become green due to shifting. And in any time between 2025 and 2999, if you have someone moving that fast, you have worse problems than the site not rendering adequately.

    Keyboard layout? If the rendering of a site depends on whether I’m pulsing “g” vs “j” while it loads, then that’s quite stupid anyway because that boldly assumes the app focus is on the page.

    Proximity sensor? Again: absolutely useless unless rendering environment moving at incredibly superhigh speed (at which the sensor might be reading data wrong anyway).




  • They literally describe their infra as “Gnome OS”. They spoke loudly in the previews to Gnome 3 against terminal users having the right to customize their terminal. They want every Gnome install to carry and be limited to the “Gnome brand”. They are drunk on the corporate kool-aid and I would surmise it won’t be long before we see Activate your Gnome account" and “GnomePilot”, considering they are also drunk on Microsoft influences.

    They are, currently, a net negative for the classial Linux experience.