3 ms·

> The church down your street was extremely unlikely to even be impacted by this change Why do you say that? Let's say, for example, that they use Discourse [1

by gw 9y ago

> The church down your street was extremely unlikely to even be impacted by this change Why do you say that? Let's say, for example, that they use Discourse [1] to provide a web forum for churchgoers on their website. Oops! Mobile scrolling is completely broken for them [2] until they manage to update Discourse to the latest version. Is this the flu shot you were talking about? [1] https://www.discourse.org/ https://www.discourse.org/ [2] https://meta.discourse.org/t/mobile-view-scroll-bar-slider-broken-on-android-chrome-56-and-above/57943 https://meta.discourse.org/t/mobile-view-scroll-bar-slider-b...

Klathmon 9y ago
No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. And while they would need to update, if they were using the hosted discourse plan it would have been fixed for them, and if they were using the self-hosted plan, they are running that on a linux server which needs updates and maintenance periodically anyway or a broken timeline will be the least of their problems. Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI. So yes, this is exactly the flu shot I'm talking about. A product was broken in a fairly minor way with this update, and a fix was developed within 24 hours which consisted of 2 lines of CSS (both the same, but in 2 different spots). And now the product and the web as a whole (on chrome) are less laggy and janky on mobile devices.
- gw 9y ago
  > No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response? > Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI. Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.
  - Klathmon 9y ago
    The timeline feature is the sidebar that shows you where in time since the first post you are looking at. When you drag along it, it can move you to that date and time. It's a cool features but not integral to the application. Scrolling still worked... 100% of the time on 100% of devices. And as for the upgrade, if the parishioner can't click [0] in the web UI (a link to which was emailed to them), then I'm not sure how they are using discourse at all. And IMO they have no business hosting anything themselves as it will most likely turn into a DDoS bot within a year. But again, there is no need to do this as the forum software worked completely fine for it's core functionality and only scrolling via the timeline was broken. [0] https://meta-s3-cdn.freetls.fastly.net/original/3X/4/b/4b2ffacebd272016a258764491c5106d9b381967.png https://meta-s3-cdn.freetls.fastly.net/original/3X/4/b/4b2ff...
    - gw 9y ago
      You're showing a pretty serious case of cognitive dissonance here. What previously was a theoretical problem was actualized with a real world example with actual affected users, and you've shifted to an entirely subjective argument that the breakage is "not integral to the application". You also chose to rationalize the breakage by shifting the blame to the victim -- they have "no business hosting anything themselves". Well, great, but that isn't going to stop them. Maybe they want to ensure their web forum isn't censored by a hosting provider. It turns out that people still host their own websites in 2017, and until they all shift to centralized monolithic providers these bugs will persist for years, and you will persist in rationalizing the breakages as "flu shots".
      - Klathmon 9y ago
        Reread my first comment. I pointed out that the breakage would be limited in scope. Very very few applications were broken by this (broken being defined as having it's core functionality unusable). And you seem to be completely ignoring the fact that the upgrade "path" is one click of a button. Whether you agree with my stance on the responsibility of hosting your own internet connected server or not, it's a one click button upgrade, to a fix which was made 24 hours after the problem appeared. If your problem is a minor UI breakage of a side feature of a well maintained web application that doesn't get updated because the admin doesn't know how to click a button in response to a fix which significantly improved scrolling performance for all chrome users, how do you justify any changes at all? Call it rationalizing if you want, I'm saying it's worth the extremely small amount of pain for the bettering of all chrome users. How can you change anything at all if that is your threshold for unacceptable? How can you even update a single line of code if you feel that such a small amount of breakage is not allowed?

by gw 9y ago

Klathmon 9y ago

No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. And while they would need to update, if they were using the hosted discourse plan it would have been fixed for them, and if they were using the self-hosted plan, they are running that on a linux server which needs updates and maintenance periodically anyway or a broken timeline will be the least of their problems. Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI. So yes, this is exactly the flu shot I'm talking about. A product was broken in a fairly minor way with this update, and a fix was developed within 24 hours which consisted of 2 lines of CSS (both the same, but in 2 different spots). And now the product and the web as a whole (on chrome) are less laggy and janky on mobile devices.

gw 9y ago
> No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken. So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response? > Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI. Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.
- Klathmon 9y ago
  The timeline feature is the sidebar that shows you where in time since the first post you are looking at. When you drag along it, it can move you to that date and time. It's a cool features but not integral to the application. Scrolling still worked... 100% of the time on 100% of devices. And as for the upgrade, if the parishioner can't click [0] in the web UI (a link to which was emailed to them), then I'm not sure how they are using discourse at all. And IMO they have no business hosting anything themselves as it will most likely turn into a DDoS bot within a year. But again, there is no need to do this as the forum software worked completely fine for it's core functionality and only scrolling via the timeline was broken. [0] https://meta-s3-cdn.freetls.fastly.net/original/3X/4/b/4b2ffacebd272016a258764491c5106d9b381967.png https://meta-s3-cdn.freetls.fastly.net/original/3X/4/b/4b2ff...
  - gw 9y ago
    You're showing a pretty serious case of cognitive dissonance here. What previously was a theoretical problem was actualized with a real world example with actual affected users, and you've shifted to an entirely subjective argument that the breakage is "not integral to the application". You also chose to rationalize the breakage by shifting the blame to the victim -- they have "no business hosting anything themselves". Well, great, but that isn't going to stop them. Maybe they want to ensure their web forum isn't censored by a hosting provider. It turns out that people still host their own websites in 2017, and until they all shift to centralized monolithic providers these bugs will persist for years, and you will persist in rationalizing the breakages as "flu shots".
    - Klathmon 9y ago
      Reread my first comment. I pointed out that the breakage would be limited in scope. Very very few applications were broken by this (broken being defined as having it's core functionality unusable). And you seem to be completely ignoring the fact that the upgrade "path" is one click of a button. Whether you agree with my stance on the responsibility of hosting your own internet connected server or not, it's a one click button upgrade, to a fix which was made 24 hours after the problem appeared. If your problem is a minor UI breakage of a side feature of a well maintained web application that doesn't get updated because the admin doesn't know how to click a button in response to a fix which significantly improved scrolling performance for all chrome users, how do you justify any changes at all? Call it rationalizing if you want, I'm saying it's worth the extremely small amount of pain for the bettering of all chrome users. How can you change anything at all if that is your threshold for unacceptable? How can you even update a single line of code if you feel that such a small amount of breakage is not allowed?