Skip Navigation

You're viewing part of a thread.

Show Context
391 comments

  • Thanks for the extra information, but I still think I’m missing something - what’s the reason behind providing feedback if you don’t want them to do anything about the feedback? Like, you’re just making conversation about it, like sharing funny bugs you had in Skyrim?

    I guess there’s a difference between talking about bugs and UX, because if you said that you prefer Photoshop to GIMP because you think Photoshop’s UX is better, I totally understand that, and “tech support” isn’t really appropriate, but isn’t that different for people who are talking about their specific performance issues? Like, how would you want people to respond to that?

    it may put off some people from joining if the effective experience is less responsive than Chrome

    Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate? I really feel like you’re trying to have your cake and eat it too, here - it feels like you want Firefox to fix performance issues, but you feel like the issues should be fixed without actually giving devs the information they need to fix them. That’s just not going to happen for any app/software, OSS or not

    • Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate?

      No, see, that's my point. There's a whole family of bugs where people don't want to be told how to fix the bug themselves, they want the bug to never have happened in the first place. Or, you know, at best for it to be patched and removed without their intervention.

      Showstopper bugs? Sure, those you just want a way to get past so you can do what you want to do, but experiential bugs, bugs that don't block you but make things slightly more annoying? For most people any additional effort in fixing the bug just makes the bug worse at that point. Especially if it's not an open-and-closed "just do this and it fixes it".

      A slight performance degradation over time that clears up with a reset is not that big of a deal. Being walked through debugging processes I've already tried that won't actually fix the issue is an extra annoyance on top of having to deal with the bug. At best. At worst it feels patronizing, in that hey, I know what I'm doing, right? It's annoying in the way calling customer support and having to go through the dumb easy part of the script where they tell you to turn the thing off and on again is annoying. Except I didn't call customer service, I just complained about the bug and now people on the Internet are crawling out of their hideouts to do customer service at me.

      So no, no every situation calls for trying to walk somebody mentioning a bug through basic QA processes. Software is supposed to just work, and for the average user, if you add homework on top of their software not working, that's just extra incentive to not use the software. OSS fans sometimes miss that small but relevant part of the user experience.

      • Maybe it would be easier to reframe the conversation.

        Imagine that you live in a city that has a garage that gives away free cars. Most people get one and it works perfectly fine, but sometimes people modify them and it causes issues with the engine, nothing major but it’s a minor inconvenience. Maybe turning the car off and on again resolves it.

        When said people have issues and talk about it, people ask them questions like “what changes did you make?” and “what kind of issues are you having?” with the idea of trying to help them, and maybe they’d suggest things like “try checking the on board diagnostics” or “check the spark gap” to try and help.

        Don't you see how saying, “I just expect it to work without having to do any homework or spending any time trying to fix it. I’m not a mechanic.” is kind of absurd in that situation?

        It’s totally unreasonable to expect extremely complex software to always just work with zero bugs, even if you pay $$$$ for it. People can expect it to “just work” all they want - and for Firefox, it does. If you’re adding third party addons that break it, then you don’t have a Firefox problem, you’ve got an addon problem.

        If you don’t want help, you don’t need to post about it. Being honest, you just seem pretty entitled to me, and I’m not trying to insult you, I just genuinely don’t understand what you expect with regards to your own situation. You say that you’re happy with the workaround you have but also that you think it should be fixed and you think it’s a problem with the OSS community that someone tried to help you to get it fixed? I just do not get it.

        • Yeah, no, I'm actively saying just that.

          I'm actively saying that when most people hear a little noise under the hood they do one of two things: ignore it or take the car to a mechanic and use a different transport method for a bit until it's fixed.

          I'm saying that if somebody casually mentions "my car does a little noise" over the watercooler and the other person goes "hey, have you popped the hood and checked the spark gap" or "can you pull up the on board diagnostics and maybe we can go over them now?" the usual reaction is to make up some excuse or get glassy eyed and move on with your day.

          That is absolutely how that goes.

          And no, it's not optimal or even particularly reasonable, but that's the thing, it doesn't have to be. When the average person engages with a market product for fun or casual usage they are often willing to invest zero effort in improving it from the out of the box experience, at least early on. And that's their prerogative. That low barrier to attrition is a key element of UX design, and it absolutely applies to technical issues.

391 comments