391–400 of 1001 posts
Even US Navy prohibits touchscreens on weapon systems and radars. Slapping your ship bow from the crest might likely press the wrong coordinate or fire button instead.
I wouldn't mind touchscreens as long as these imbecile developers would strictly limit UI response time to under 16ms. In no world where you're barrelling 3,000+ lbs of mass at tens of miles an hour should you be distracted by some moronic app or subsystem failing to respond in time because it was written by under-experienced software "engineers." Any software running as a part of a motor vehicle should be federally…
I don’t know that would be helpful. I hate digging through my Tesla’s menus to control the wipers even though it is very responsive.
https://www.tesla.com/ownersmanual/modelx/en_us/GUID-A5C33F3....
Other touch screens (or similar things) I dislike:
- the controls on my stove top
- the controls on my monitor
- the controls on my tv
- the controls on my thermostat
- probably more
All of these should have physical buttons for the limited number of functions required. Or, at a minimum, for navigation and confirmation. Touch screens there suck.
My wife's car has a touch screen on the control/infotainment center whatever it's called (where the radio is), and a few physical buttons on the steering wheel. There are two clocks: one on the control center, and one in the main dashboard display.
The dashboard clock is controlled by the buttons (just one for menu nav and one for confirm selection) is super simple and frustration-free to change. The touch-screen controlled one is a shitty pain the ass.
By far the worst though is my touch-controlled stove top. Just give me some damned knobs.
Earlier quoted context omitted.
There's no incentive for an engineer to do that. Saying yes and delivering crap gets you a bonus, hard truths get you shuffled around or made redundant. There's no real consequence for delivering crap, so that's what happens. Contrast this with other engineering fields, where the engineer is truly responsible for the decisions they make. My civil engineer friends face losing their licenses, fines or jail time if they…
The incentive is having a rewarding job where you develop products you are proud of. Once I have food to eat, this is by far the most important incentive for me and it greatly outweighs e.g my desire for promotions, raises and bonuses. If I can have both, great. If I need to choose one, it’s the fulfilling job and product pride every day.
I wouldn't mind touchscreens as long as these imbecile developers would strictly limit UI response time to under 16ms. In no world where you're barrelling 3,000+ lbs of mass at tens of miles an hour should you be distracted by some moronic app or subsystem failing to respond in time because it was written by under-experienced software "engineers." Any software running as a part of a motor vehicle should be federally…
> because it was written by under-experienced software "engineers." I used to be an infotainment software engineer for an Auto maker. There’s this idea in the software industry that because the software behaves poorly on your car’s system, it must’ve been written poorly by someone who didn’t know what they were doing. In my experience it was almost always a matter of the hardware being stretched way past its limits.…
Earlier quoted context omitted.
Yes. The infotainment code is rewritten every time. By different devs. Because that is how automotive industry works. This time BMW wants infotainment and a third party wins the contract (because it's the cheapest usually). For the next BMW car another company wins the contract. Everything is rebuilt from scratch. The components that make up the infotainment a lot of times are actually developed by different companie…
I'm currently going through a quote cycle and one of my requirements for the component is a sub 8min boot, which the tier 1/2s are pushing back on as unreasonable. The insanity is real.
Earlier quoted context omitted.
> because it was written by under-experienced software "engineers." I used to be an infotainment software engineer for an Auto maker. There’s this idea in the software industry that because the software behaves poorly on your car’s system, it must’ve been written poorly by someone who didn’t know what they were doing. In my experience it was almost always a matter of the hardware being stretched way past its limits.…
I believe that the engineers are competent at developing software, and think that a lot of the quality issues are due to engineers abdicating authority over the software to managers and never saying "No, adding in that feature at this point in the timeline is going to make this a steaming pile of shit and I refuse to do it and still call myself a software engineer." I get that we have families to feed, but I've seen…
There is, of course, a time and a place for a hard "no". I've genuinely threatened to quit rather than implement a particularly user-hostile feature in the past.
Earlier quoted context omitted.
Yeah seems like physical controls for input, screen for output is the sweet spot.
Our car UX is becoming terrible for both touchscreens and physical controls. It could benefit from simplification a lot, and I think Tesla had many good ideas, even if they might have over-committed to the touchscreen. For example, VW cars often have multiple knobs and buttons just for controlling the AC, which is far too complicated. If the car is electric, one might also need to put it into a regular mode (non-eco)…
Earlier quoted context omitted.
Seem is doing a lot of lifting there. For one, there is no generation of iPhone that is safe to use while driving. Such that you have a ton more tolerance for a phone than you would a car system. Mostly for good reasons. It doesn't help that iphones from that time frame aren't really in use today. Car systems are.
Yeah, CarPlay is definitely not a thing.. Also, maybe the expected lifetime of something used to turn up and down the volume and show a map while being in a fixed case and not even having its own battery is different than a device running on battery, thrown around in everyday life and literally being pressed on 0-24. And even then an iphone from the last 5 years might well be expected to run for 5 more with a battery…
I did not mean my post to dismiss the idea that we should expect better. I'm just worried that the practices we put up with elsewhere in software would not, necessarily, be the answer.
Earlier quoted context omitted.
I believe that the engineers are competent at developing software, and think that a lot of the quality issues are due to engineers abdicating authority over the software to managers and never saying "No, adding in that feature at this point in the timeline is going to make this a steaming pile of shit and I refuse to do it and still call myself a software engineer." I get that we have families to feed, but I've seen…
Yep. It's part of your job to tell managers "yes, it's possible, but it'll negatively affect performance in a significant way because of such and such hardware limitations, so it's not the most valuable feature to implement at this time".