6 ms·

If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn

by phpnode 12y ago

If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn a non trivial percentage of early adopters off the entire product. They cannot win here, it was a bug in FF, it is now fixed, presumably they'll stop blocking when the fix is more widely available.

shadowmint 12y ago
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 crashes screw them for not using android right? Its Business Politics at play, not technical restrictions.
- aroberge 12y ago
  If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...
- andybak 12y ago
  > Its Business Politics at play Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss. Even in a company as awash with money as Google, someone has to justify budget choices.
- Tehnix 12y ago
  >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 experimental webkit features, which are either not available in Firefox/gecko 3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things. And just to point out, >dont release product until it works is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.
  - abraham 12y ago
    *experimental Blink features
  - Touche 12y ago
    My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".
  - endemic 12y ago
    I'm sure it's different for large projects, but for my own work, if I wait until the app is "finished" (or at least in a workable state) before working on cross-browser compatibility, I hate my life and want to die. YMMV, but I find that working on compatibility from the start is the way to go. That said, if there indeed is a big performance bug in Firefox, that would totally be a valid reason not to support it (for now).
  - shadowmint 12y ago
    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).
- msabalau 12y ago
  I would have expected this sort of comment in most forums, but not necessarily in a community where many members actually deal and grapple with questions of "what platform gets supported when" and understand that "effort not worth it" is not the same thing as "business politics" I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out. And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.
- TeMPOraL 12y ago
  > The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite? By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.
akavel 12y ago
In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.
- louthy 12y ago
  Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.
danielweber 12y ago
This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."

by phpnode 12y ago

shadowmint 12y ago

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 crashes screw them for not using android right? Its Business Politics at play, not technical restrictions.

aroberge 12y ago
If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...
andybak 12y ago
> Its Business Politics at play Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss. Even in a company as awash with money as Google, someone has to justify budget choices.
Tehnix 12y ago
>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 experimental webkit features, which are either not available in Firefox/gecko 3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things. And just to point out, >dont release product until it works is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.
- abraham 12y ago
  *experimental Blink features
- Touche 12y ago
  My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".
- endemic 12y ago
  I'm sure it's different for large projects, but for my own work, if I wait until the app is "finished" (or at least in a workable state) before working on cross-browser compatibility, I hate my life and want to die. YMMV, but I find that working on compatibility from the start is the way to go. That said, if there indeed is a big performance bug in Firefox, that would totally be a valid reason not to support it (for now).
- shadowmint 12y ago
  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).
msabalau 12y ago
I would have expected this sort of comment in most forums, but not necessarily in a community where many members actually deal and grapple with questions of "what platform gets supported when" and understand that "effort not worth it" is not the same thing as "business politics" I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out. And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.
TeMPOraL 12y ago
> The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite? By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.

akavel 12y ago

In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.

louthy 12y ago
Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.

danielweber 12y ago

This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."