[Theodores]

I think that we still need some explaining to do when it comes to developer friendly website design.

Truth is that, right now, in 2018, we can get rid of the hacks, libraries, polyfills and everything else needed to support old browsers. The old 'block layout' methods need to be forgotten and the new CSS grid method can be adopted by new developer/designers. Then this CSS grid needs to be specified with CSS variables for all the bits that change. Then media queries and vanilla javascript can be used to adapt to viewports and cater for interaction. There is not much too it unless you are writing a replacement for Excel in javascript for the web. But then you are writing an application and not designing a website of content.

Then there is the truth about design. A lot of 'design' has been artistic flourish that does not need to be there. We kind of know where the search box goes and what icon it has, there is no need for that to be 'designed' by someone that can't code. This is particularly the case when the 'design' places the search box in the footer with an eyeglasses icon just because the 'designer' thought that they could add their artistic flourish in such a way. (This did happen circa 2010).

The convention based UX that has won out over 'artistic flourishes' means that there is less to 'design'. Choosing fonts and colours is also a bit of a luxury, an existing brand will already have these things. If you were designing for Ford you have a good idea of what colour blue the headings and buttons will be coloured. Equally, if you are creating a site for just yourself then you can experiment with these things as you build out the content.

Anyway, this 'web design crash course' hinted at some of the CSS goodness we have today, e.g. the use of CSS variables, but I am wanting more, a wholesale forgetting of the hacks and cruft with a simple way to do stuff effectively and in a maintainable way with the new CSS shiny.

[debaserab2]

> Truth is that, right now, in 2018, we can get rid of the hacks, libraries, polyfills and everything else needed to support old browsers

Oh how I wish that was true

[RobertRoberts]

The way I have dealt with this issue for the past decade+ is to simply offer multiple tiered pricing for my clients.

By default, the lowest price is design that supports the most modern browsers. The older and more problematic the browser support required, the more it adds to the project cost.

This cuts out 99% of all the old browser support issues in my business. Very rarely does someone need more than "just ok" support for even IE 11 these days. And that isn't so bad even with css grid/flexbox.

Supporting old browsers isn't a technical problem, it's a time/cost problem.

[debaserab2]

Yeah, it just depends on your audience. It's still a problem in B2B situations. Most notably when a customer's IT is contracted. Unfortunately for me it's not a matter of price tiering, it's about producing a product that has been working for customers in outdated browsers that continue to expect it to work that have signed annual+ contracts.

[RobertRoberts]

Negotiations and communication can help resolve these kinds of problems. (in my experience)

The core motivator to start the discussion can be simply profit margin. I've hit points where it's not profitable, and therefore gets cut from our offerings. But if someone wants to pay extra, we can accommodate.

Is it possible that by changing the requirements/costs of the product you would lose the account/business?

The way I started this discussion is with the phrase "web standards", and these are cheaper to build towards. So "non-standard" systems cost extra to support now. But this also meant I could lower my costs on some other work, so it wasn't smoke and mirrors, it was legitimately easier and less time consuming. (also, makes everyone happier to work on standards instead of spending most of our time with hacks and debugging because reasons)