4 ms·

>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 argu

by 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).
- Tehnix 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. 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.

by Tehnix 12y ago

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).

Tehnix 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. 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.