Live data from Hacker News

Why Is Google Blocking Inbox on Firefox?

gist.github.com

211–217 of 217 posts

Re: Why Is Google Blocking Inbox on Firefox?

#211
post #95

Earlier quoted context omitted.

They could have made the effort to make this work on firefox from the start, but someone decided the effort wasnt worth it. The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works . Firefox is fast enough if you write code with it in mind. ...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari c…

>The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first): 1) It's in beta, so you want to get it right before focusing on making it work everywhere 2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some exper…

It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

If you plan to support cross platform, do so from the start.

You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.

You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.

I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.

I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.

I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).

Re: Why Is Google Blocking Inbox on Firefox?

#212

Earlier quoted context omitted.

It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.

But we're specifically talking about not hobbling other browsers not supporting them - you (or whoever) said that there are still support costs even when a browser isn't being "supported" (ie enabled to operate with a site at a suitable level).

Did you read the part in the article about CSP?

Re: Why Is Google Blocking Inbox on Firefox?

#213
post #95

Earlier quoted context omitted.

>The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first): 1) It's in beta, so you want to get it right before focusing on making it work everywhere 2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some exper…

It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products. If you plan to support cross platform, do so from the start. You can argue about feature parity and 'first user experiences' all you like, but practically speaking , if you don't support the target platf…

>It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

Maybe in GUI applications, but not so much in web browser applications.

>If you plan to support cross platform, do so from the start.

You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.

Again, your arguments might apply to a OS application, but not to web browser "applications".

Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.

Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.

You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.

Just to finish of,

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...

I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.

Re: Why Is Google Blocking Inbox on Firefox?

#214
post #213

Earlier quoted context omitted.

It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products. If you plan to support cross platform, do so from the start. You can argue about feature parity and 'first user experiences' all you like, but practically speaking , if you don't support the target platf…

>It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products. Maybe in GUI applications, but not so much in web browser applications. >If you plan to support cross platform, do so from the start. You are already close to automatically supporting all platforms. The…

If you put 'applications' in 'quotes' when you refer to websites, we are so far from being on the same wavelength its not even worth continuing the discussion.

I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.

(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)

Re: Why Is Google Blocking Inbox on Firefox?

#215

Earlier quoted context omitted.

"Support cost" doesn't apply only to customer support.

Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky. What cost is there? If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are us…

Even if they don't support customers they still have to support internal customers (everyone that works for Google). I worked on a project recently that didn't support IE8. Nevertheless, the day after release there were a ton of emails from one particular office that the site didn't work. There was a bit of a panic, various theories thrown out (it's working for everyone else, why is it not working for this office, networking issues?). A couple of hours (and who knows how much money) was wasted in an all-hand-on-deck meeting to fix the issue before it was found out that this particular office had an IT department that only allowed XP+IE8 machines.

When you get bug reports from internal customers it's never "the site isn't working in Firefox 33 with all extensions turned off. It loads but is a little slow.". The bug report you get is simply "it isn't working, you get a blank page".

Answering those types of emails cost real money.

Re: Why Is Google Blocking Inbox on Firefox?

#216
post #192
post #51

Earlier quoted context omitted.

yes. and much more. for example, even when using open source web kit or chromium they actively removed all options to disable referrer. go on. try to find it on your current chrome build. or even on chromium thanks to their legacy. then remember that referrer with its most exposing setting is required for Google to monetize both their organic and paid search.

The only way to do it in Firefox is through the scary and arcane about:config (or an extension). Historically, methods to remove that have not been provided by browsers, whether Google-developed or not. I've always done it via Privoxy, never the browser.

> scary and arcane

i use it every day.

even on firefox mobile!

and it serves my purposes just fine. not to mention you are not exactly right. as you can update those values via user scripts that can be easily distributed or even made as an extension that change those values for you and/or provide a new settings controller UI.

Re: Why Is Google Blocking Inbox on Firefox?

#217
post #216
post #192

Earlier quoted context omitted.

The only way to do it in Firefox is through the scary and arcane about:config (or an extension). Historically, methods to remove that have not been provided by browsers, whether Google-developed or not. I've always done it via Privoxy, never the browser.

> scary and arcane i use it every day. even on firefox mobile! and it serves my purposes just fine. not to mention you are not exactly right. as you can update those values via user scripts that can be easily distributed or even made as an extension that change those values for you and/or provide a new settings controller UI.

Yeah, and I use the command line every day. Whenever people see it on my screen, they think I'm "hacking".

There are Chrome extensions to do it as well. The point is, the lack of a UI control usable by the average user is not some Google conspiracy. It's always been the standard in pretty much all browsers.

Post reply on HN