Also: web layouts are meant to look different on different screens. I had to program my own layouts from scratch for embedded devices and games before. And that occasionally made me wish for CSS.
Yes, but the answer to "how many people clicked that button" is irrelevant if it describes the outside world. This id like concluding something is wrong with umbrellas because none of the users in the desert opened them.
If the questions you have can be answered by simple telemetry you are likely asking the wrong questions. E.g. a confused user will click all the buttons, while one thst efficiently uses your software to solve a very specific problem may always ever press the ssme ones.
The actually interesting questions are all about how your software empowers users to deal with the things they have to deal with. Ideally with as little buttons as possible. And if once a year they need that other button it will be there.
It is very easy to draw the wrong conclusions from telemetry.
I am not sure which profession they are in (software development?), but no. Not everybody is guessing. If they were you would have half of the buildings and bridges collapsing and the other half on fire by bad electrical wiring.
You can legitly learn how to do things properly and people who learnt to do that do the polar opposite of guessing. It is just that the world of software development has yet to be made liable for their results in the same way as civil or electrical engineers. So in software development many are just guessing because guessing wrong won't ruin their life.
Software "engineering" also differs in the way from more formal engineering in that there are very rarely absolutes, there's often many different correct ways to solve a problem, each possessing their own pros and cons. So, it could feel like "guessing" choosing a certain approach over another, but more senior people usually have an intuition brought from experience which one will work better and be more informed of the tradeoffs, so it looks a lot less like guessing.
Yet when we talk about controlling trains, airplanes, freight ships, medical devices, nuclear power plants and space stuff we suddenly know how to do it?
There is software engineering and it is known how to do things that absolutely must not fail. It is just thst these standard are not commonly deployed if nobody forces you to deploy them. And why would you? Costs money and a software error is widely treated like divine intervention.
There is a big difference between knowing something must not fail, and how to make it so it will not fail. The latter is where opinions and approaches often differ, in ways that more formal engineering does not.
I'm very wary of anyone in tech/software eng that says "this is the only right way to do this." I'm aware those attitudes exist everywhere.
I once found a very interesting definition of engineering. It is about making something that just barely does the job. Doing it better costs more usually and doing it worse costs lives.
Not much different in software. There is always many ways of solving problems and that is typical of any engineering. Contrary to sciences.
They are guessing much more than computer scientists would think, typically . A structural engineer does not know: the peak wind force, what the ground under the bridge is really made of, what the actual tensile strength at the weakest piece of material is, what the exact force on the screws were at time of fastening (and after), etc... Heck, they don't even know if euler bernoulli beam theory is actually right about the existence of a neutral axis..They just take their best guesses, add generous safety factors and have the bridge inspected regularly ..
You have abstractions and models for those things. I was formally trained as an EE, so I'm just guessing at how structural engineers do it.
I would expect someone building a bridge to keep the average/peak winds into consideration - and then feed it to CAD or whatever modeling software they use to design the structure. They don't need to know the exact force a screw was tightened with - they do need to give the specs of what range they should be tightened to. Again - considered in CAD. They don't need to know that theory is right - they just need to know it's not wrong to an unacceptable degree.
I'm sure there's some guessing, but a lot of these things are actually factored in.
Well someone had to pay for rich peoples yacht money. And since these 1000x hard workers don't find the amount of money they would earn with a honest product acceptable they buy a good brand and sell it out, riding the lucrative downwards curve at the cost of the environment, the employees, the subcontractors, the customer.
Some people disrespect drug addicts, homeless people or sex workers. To me the people behind such practises are below contempt.
It would be possible to implement age verification in a way that would somewhat work and that would be to use the correct crypto on an government issued ID card. Crypto where the OS (or a website) can ask the card: "Is the holder of that card over X years old y/n?" and the card would just answer with a binary yes no question without exposing any other data while still checking the government signature.
Obviously that won't stop motivated teens from taking their parents ID cards or similar mechanisms. Thst means any system that likes to prevent that needs to additionally ensure the identity of the card holder. And then you create a privacy nightmare.
So my proposal would be to accept that nothing is ever perfect and just use the card and ensure that system works as well as it could.
Of course "card " is a standin for all manner of hardware that can do it, including phones.
> Crypto where the OS (or a website) can ask the card: "Is the holder of that card over X years old y/n?" and the card would just answer with a binary yes no question without exposing any other data while still checking the government signature.
This is the same as "What's the card holders age" by simply binary searching for it. A better way would be:
1. Have the card define the countries age access levels. (Example in Germany: >=16 [Beer/Wine], >=18 everything else)
2. The app can only ask: "Is [BEER] allowed for the card holder y/n?
This makes it immediately cross-legislative and protects the exposed data from meta analysis.
Edit: This would allow for self exclusion too. Make it possible for individuals to give up access to gambling/alcohol/tabacco/porn nationally.
I don't think this belongs on the card to be honest. Otherwide each legislative adjustment would require population-scale updates.
This can go into the reader of anybody who e.g. sells beer to pick your example:
1. Reader knows beer >= 18 because reader is in Germany
2. Reader asks card to verify >= 18
3. etc.
This keeps the many cards simple and safe, while the locale is set to the thing that is both easier to police, to update and to support (far less people sell beer than buy it).
Self exclusion would still be possible if there is a standard for it.
in the Netherlands we have a better system called iDIN; it works like doing an online payment (iDeal / WERO):
* Website asks for age verification
* User is redirected to their bank
* Bank asks the user to log in - username/password, 2fa, bank app (whose login is behind the device's security and a secondary verification like PIN code or biometrics)
* Bank tells the requester that the user is 18+, no more
This leverages a trusted party (your bank, which is subject to heavy IT security regulation and audits) and you need to show ID to open an account anyway), secrets only you know (and your kids can't easily take), phone security systems, etc. Does not require uploading ID to a 3rd party, does not require changing how IDs work, etc.
There are people without bank account. It isn't a big part of the population (estimated to be 0.02% or about 16.000 people in Germany), but I still feel on principle this is a basal governmental function that should remain governmental and not tied to other services that can be denied to you for various reasons. This or you make having a bank account a guaranteed human right. I am fine with both.
If there is a tech-person problem it is this one. I constantly have to interrupt collegues when they try to explain a thing as their explaination attempts are usually way too low level or even bordering on being self-referential. So they explain the concept by using other concepts the listener won't understand either.
In my opinion it all boils down to a lack of ability to remember how one felt before understanding a certain concept. If you did you would have an empathic understanding of how word-salady a lot of the explainations are.
The first thing you need to tell a uninitiated person is simply where to generally put it and how they already know it. If you explain DNS for example you explain it via the domains they know and how it is like a contacts list for webservers so your browser knows where to look when looking for google.com.
Whenever you explain anything you might want to ask yourself why the other side should even begin to care and how it connects to their life and existing knowledge. What problem did it originally intend to solve?
When I taught I often thought of it as explaining in a spiral: first I must go around the concept, before I can dive in to the concept. Going around gives boundary and definition to what I'm talking about, allowing people to place it in the proper spot in their mental framework and to relate it with other nearby things. It also gives some motivation for what this thing is and why they should care. Then when that is done (and it does not take long), the details can be discussed, and they're easier to communicate because people are primed to receive them.
I am a developer, I also have worked enough other jobs to know how important communication is and how bad developers can be at it.
A typical pattern I recognized is that many developers communicate like bad medical doctors: they do "Mhh, Ahh" and then after a way to short period they fire out a diagnosis of what you need, sometimes without you even having said everything relevant yet.
It is nothing new that people in software are at times not the best communicators. For the first part the interesting bit isn't what your clients want, it is what they need. Unless they are the usually rare customer that has a good understanding of how software could solve their problem elegantly, you will have to assume it was someone's job to come up with something and that someone has never written or thought a lot about software before. That doesn't mean their ideas are worthless, but it means the work of finding the requirements and coming up with a solution is usually not done when you arrive. And the way to get it done is communication, by observation and by having them explain the processes.
Many software developers are in fact really not listening in my experience. Not that developers are the only people that happens to, doctors or other technicians also come to mind. They are often trying to quickly come across as competent by showing off their good grasp of the subject. To them you are a clear case of some category of problem they have dealt with a hundred times. This can work for them.. Until it does not.
Yes, all said, developers likely are the worst communicators because they over index on their self-ascribed strengths: logic (and logic bullying). Not so much because they aren't smart or capable.
But singling out specific archetypes is an obvious contradiction of the article, which is weird. Author is in the UX design space so likely has particular lived experience with specifically eng orgs.
it's any technical specialist in any field in my experience. my partner is a doctor (not a kind that needs great people skills) and I see the same problems. luckily I have worked with many many developers so it's quite easy to deal with
I like using units that are already used to describe what is meant, e.g. if you have a periodic frequency Hz is totally fine and easy to math with. Now I wasn't aware of Bq, but it makes sense to have a separate unit for the stochastic equivalent.
The only problem with that unit is that it may require explaination. Hertz is a little bit more commonly understood, while someone seeing 2.5 Bq will very likely wonder what that means.
In the end both Hz and Bq resolve to s⁻¹ or 1/s So maybe request/s is just okay as a unit? In the end it depends also on the surrounding UI.
CSS is fine. Most people just never learned it.
reply