This is why I personally am very reluctant to the sharing of well founded ideas on platforms such as github, in hackathons, in competitions, in recorded speeches etc. How unlikely it may seem, this is a great example that ideas with traction do get picked up and copied, and the originator screwed over. I honestly sometimes feel as if the openness is pushed and saluted, but with the ulterior motive to skim for ideas.
Yes, I agree, and everyone (devs) should think about who they’re really trying to make things easy for.
If you simply say follow the ISO standard you’re essentially making it easy for yourself and hard for the users. Sprinkle that with a drop down day picker as in the example, and you’re really in control of what the input will be. Not much chance of faulty input, right?
However, the ISO will not be relatable for many people and the drop down is a UI nightmare.
The user will be spending much more time with the form than devs (runtime), so this of thinking should definitely be avoided (during programming time).
I feel like it’s a behavior encouraged by Googles Material design or derived projects: slide details in and out of the screen (google maps pin details, for example), hide input boundaries (no border on search text input fields), tons of sporadically placed spinners.
I really dislike that tendency in design and behavior and find it counterproductive.
I find this interesting as I had a somewhat opposite experience when I tried a dark restaurant when visiting Berlin (eating in complete darkness). It was surprisingly rest to relocate utensils and my glass of beer, as I went back and forth between them, stopping and raining to eat.
Of course, the room wasn’t empty and void other sounds, which may have helped me build a general sense of direction and thereby helped me.
Isn’t the point here that it was the path the free information ideology inadvertently produced: (free) information served with ads (because everyone needs butter on the bread)? And because of that ingrained ideology, it’s still difficult to charge for the actual information product?
That’s why I always push the message that we choose the right amount of bureaucracy for the task at hand. Simple change / feature? No need to make a lot of documents for that? Fluffy idea that several people needs to work on? We need some mocks, diagrams and take requirements from client.
I think that’s a healthy way of doing it, but sadly many almost have to be pushed to do it, even with bigger things.
Yes, I understand. While I’ve never only attributed that to Agile alone, but also this sort of brogrammer-code-is-the-real-product, it sometimes feels like a maturing industry sort of rolled back into its teenage years. Diagrams? Solution models (up front thinking)? Document for future reference? Nah, we don’t want to do that.
It’s sad. Just recently had an experience like this with developers I manage. I do loathe the brogrammer culture more than anything...