161–170 of 198 posts
Earlier quoted context omitted.
I found this advertisement from Mercedes interesting: https://i.redd.it/wwxk8nqh88ex.gif I can't speak for the quality of Mercedes interface (and this is obviously marketing for non-programmers) but LOC seems like an odd thing to be emphasising.
Everyone needs to hit 100,000 LOC this week to hit our target from marketing
rm -rf /
Earlier quoted context omitted.
> like having long and synchronous opening animations in response to an action I love animations when they make the UI more understandable. I can't stand them when they are more than a couple hundred milliseconds though. I don't even think "synchronous" when I think of animations. That sounds terrible. If they are quick animations it doesn't seem as big of a deal as the long running ones though.
For me the most insulting part is the inversion of priorities in these designs. The top priority of a UI designer SHOULD be to make the user as productive as possible, yet making me wait for something that is by definition not necessary (like an animation) is nonsensical. A related backward trend is this idea of pushing something in front of my face as a modal panel, with complete disregard for the fact that I was wo…
To UI designers: Have some consideration for the f user!
Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…
Companies don't make money off of performance.
Earlier quoted context omitted.
Believe it or not, the software quality in these things is often quite cruel, and even a mediocre javascript framework might perform awesome against it. I've seen enough things things like handcoded UI frameworks in C++ (in order to be fast), and then doing things like blocking network calls on the main thread from there. Some newer systems are based on QT or Android. These typically have better performance, because…
I recently got a Mazda3, their newer MazdaConnect system is running an iMX6 (dual CortexA9 w/GPU and video accelerators) and uses Opera as the interface. All of the core UI is written in Javascript. It's also highly hackable. =)
Earlier quoted context omitted.
For what it's worth, there's a specific distinction for software systems like lane assist. The bar for "working" is so high that if it doesn't essentially work perfectly we can't say it works at all. We would expect reviews to point out if a feature such as lane assist fails or has noteworthy failures (such as rapid weaving inside the lane) but maybe not so much if it works properly.
I currently have a Honda Civic with lane keep assist. It doesn't slow down before curves and disengages frequently. Tesla's autopilot works much better from what I have seen.
That's a reason why I don't believe in seeing safe autonomous cars during the next few years at all. But maybe Tesla is that much better - haven't ridden one.
What's with everyone's obsession with React recently? All I see is a template engine and not a particularly good one. You're still left with the same problem mixing your HTML into JavaScript.
JSX is convenient but all React really requires is putting all of the logic to render a component under one method. You could carefully construct a piece of XML or something like that in render and then pass it to a templating engine of your choice°, instead of any JSX.
But JSX is as nice a language as any for templates, and side effects in render are clearly wrong in React so the old issues of turing compete templating are ameliorated.
° You'd have to do a tiny bit of wiring to make sub-components go back into the react pipeline.
Earlier quoted context omitted.
I found the whole update state and have the UI automatically render on state changes a very useful model. You only need to define the UI once, and have the real time rendering left to the state watcher.
It's a useful model, but I've found that it can break down a bit on really large, complex apps. If a piece of state is being passed to multiple places via props (either manually or using something like Redux), it can be difficult to see at a glance every place in an app that a single bit of state is being used. Going back quite a few years now, I once worked on a GWT app that kept its state in a central store, and up…
> it can be difficult to see at a glance every place in an app that a single bit of state is being used
What problems has this caused you? Personally, I find being oblivious to what specifically needs to update is useful but I'm interested in situations where that's not the case.
Earlier quoted context omitted.
I found the whole update state and have the UI automatically render on state changes a very useful model. You only need to define the UI once, and have the real time rendering left to the state watcher.
It's a useful model, but I've found that it can break down a bit on really large, complex apps. If a piece of state is being passed to multiple places via props (either manually or using something like Redux), it can be difficult to see at a glance every place in an app that a single bit of state is being used. Going back quite a few years now, I once worked on a GWT app that kept its state in a central store, and up…