|
|
|
|
|
|
by rorykoehler
3049 days ago
|
|
|
From the UX I've studied it seems that ethics is unrelated. Typically in consumer apps the goal is to increase MAU and engagement and UX is dictated by whatever moves the needle on those areas. It's hard to separate whether people are using the app more because of it's better design through UX design feedback loop iterations or if it is a dark pattern. For example it is entirely plausible that the sms notification being sent once you put in a 2FA number is completely unrelated. In a normalised database there will only be one phone number for multiple uses. If notifications are set to send to the phone number by default and 2fa uses that phone number the app will not necessarily have knowledge whether the phone number was entered due to a 2fa prompt or something else. It only checks for a phone number and acts accordingly. The 2 people/teams who designed each feature would most probably have no idea how else the number is being used such is the nature of complexity. |
|
|
No! Normalization does not mean keeping only one copy of each piece of data, regardless of category and context. I see this behavior all the time in junior and even some senior devs, both in databases, and when they code.
A piece of information has a type, but it also has a context. A 2FA phone number is different than a marketing contact phone number. It should never be normalized into just one field.
My favorite example of this is people re-using a constant in multiple places in code just because it happens to have the same value. Imagine you have a constant defined as `USER_DISPLAY_AS = 'first_name'`. Then, somewhere, you are building sorting and want to be able to sort by first name or last name. You notice you already have a constant that contains a value 'first_name', so you use it. Not you have tied two completely different things together in your code because you thought you are being DRY.