4 ms·

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

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.
- shadowmint 12y ago
  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)

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.

shadowmint 12y ago
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)