• henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    149
    arrow-down
    1
    ·
    edit-2
    9 months ago

    At work we have this timecard management system that’s an enormous pain to use. All the bottom rung employees hate it because it’s anything but intuitive. For example, it has stupid things like weekdays sorted alphabetically and a scroll bar to select the day of the month in a form. It’s like the interfaces were tested exactly one time and never visited again, so long as it works minimally.

    What’s this crappy app have to do with big web pages? That application is awful for us worker bees, but management loves it because it produces nice reports. Management is the real customer for which the product is optimized. Similarly, many web pages are awful because they’re mainly rated on how it looks. Nobody is including how fast it loads in the contract, and at the product demo you bet those resources are cached in the browser.

    Ask yourself: who with the money in hand is actually looking at how fast the page loads on a slow connection or low-end devices?

    TLDR: Looks > performance.

    • Fisch@discuss.tchncs.de
      link
      fedilink
      arrow-up
      56
      ·
      9 months ago

      it has stupid things like weekdays sorted alphabetically

      Holy shit, that’s stupid. Why would you even do this in the first place?! I can’t comprehend how anyone could come to the conclusion that that’s a good way to sort it.

    • ilinamorato@lemmy.world
      link
      fedilink
      arrow-up
      21
      ·
      9 months ago

      Friday Monday Saturday Sunday Thursday Tuesday Wednesday

      In its defense, that also flows better if you’re trying to sing it.

    • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      21
      ·
      9 months ago

      At my current dev role I try to do optimizations to make new system area pages pretty lightweight, but it’s a bit of a struggle as I’m working with devs who have been in the same role for decades. WCAG is not prioritized, and they pull in a ton of JS libraries that usually aren’t even used. A lot of the practices I see in use are from 10 years ago, but slowly tidying up the horror show with each dev product meeting.

      Admittedly could be much worse though, at least our pages aren’t 21MB large.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        6
        ·
        9 months ago

        WCAG

        Ours doesn’t even try at all, because we’re largely a B2B shop and we know our customers (in the low thousands). It’s still dumb, because we could totally hire a QA or developer who has some kind of need where accessibility would be helpful, and we even have a couple of colorblind people on the team, yet we don’t prioritize anything. It’s a little disappointing, but I guess the need hasn’t arisen yet.

        We build a very interactive web app with tons of data, and a fresh load is still well under 21MB (looks like ~5MB transferred over the network, ~15MB total). I don’t understand how a typical website could use more than our app when we do lots of complex stuff (2D drawing library, lots of calculations, we’re adding in 3D soon, etc).

    • jaybone@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      9 months ago

      You could probably write a browser plug-in / extension to manipulate the DOM to fix these issues.

      Also yes, some people look at page load times. Our team does this. But apparently not a lot of people do this, judging by the replies in this thread.