Hacker News Reader

Comment by wongarsu | Hacker News Reader

It makes perfect sense. For a question like "which types of waste do you transport" you ideally want to differentiate between "None, I don't transport waste", "Other, I transport waste that isn't on the list", "I don't know/don't want to tell you" and "I forgot to answer this question". But it's really easy to design a form so that all of these map to not checking anything, which will probably lead you to drawing wrong conclusions when looking at results with lots of no-answers.

And in this case they did the right thing and don't allow you to both check "none" and any of the other checkboxes, preventing you from giving nonsensical answers.

View on HN

They do have logic for reconciling the responses so you can't check "some" and "none", yes. But the article states:

> Finally, we also added some JavaScript code to prevent users from ticking the ‘none’ checkbox as well as one of the others. This is to avoid users giving contradictory answers.

I hope they have server side checks as well because this enhancement comes at a cost of state management that isn't guaranteed to happen if JS is the only barrier to reconciling incompatible selections.

Why would the server side code have to change for this? A none checkbox could just be translated to an empty array and passed down to the server as if none of the options were checked.

A particularly annoying problem with front-end validation is that it's not difficult to circumvent the Javascript logic, check both 'None' and 'All', and send it to the server. It becomes the server's responsibility to make a decision about whether 'None' or 'All' takes precedent.

In this case the server likely doesn’t have a ‘none’ option. The none option in the client will be translated into an empty array (or false for all the other options). So circumventing the client isn’t likely to get you very far.

But 'None' is an invalid, nonexistent option on the server. It's like circumventing validation to send the option 'Foobar'. Or in other words, if the server still accepts this the problem already existed long before.

From what I understand, this is a client side feature. Ticking 'none' after this feature is rolled out is the same as leaving nothing ticked before.

>I hope they have server side checks as well because this enhancement comes at a cost of state management that isn't guaranteed to happen if JS is the only barrier to reconciling incompatible selections.

GOV.UK are pretty good when it comes to this stuff and focusing on progressive enhancement.[0]

[0] https://www.gov.uk/service-manual/technology/using-progressi...

Where I work, there is an internal form, which has a drop down menu that defaults to "unspecified".

The aggravating thing is that it has two distinct meanings. It can mean "nobody has specified this value" or it can mean "this value has been determined by the relevant authority to be unspecified".

But the distinction has to be tracked externally somehow, because there's no way to change the menu.

The infamous difference between 0 and null. It's a surprisingly tricky concept for a lot of non-programmer folks to grasp it seems.

It makes perfect sense because people already implement it that way. As the document says:

>Use this new feature wherever services already have a ‘none’ checkbox.

Reply on news.ycombinator.com