i_am_ralpht

vehicle.software | pacific timezone | full-time | software engineer

vehicle.software is creating a new infotainment platform to redefine the in-car experience. We are focused on bringing excellent user experience to electric vehicles: beautiful visualizations, deep integration of connected services, and continuous improvements via regular software updates. Over the last decade, our team led development of Tesla's award-winning car software, widely adopted smartphone system software, and more. We are based in Palo Alto, California, and our customers are established car companies all over the world.

We are super excited to be using Rust, and we are hiring software engineers, for more details please visit https://vehicle.software/careers/

Totally agree; it's really fun to hear how things like autocorrect evolved over the development of the iPhone, and really how the designers and engineers thought about their work at the time. It's also nuts to think that so much of the iPhone software and experience was done inside of 18 months.

When the basic essential interactions like "select" feel natural and unambiguous -- holding your hand in place for Kinect wasn't a good replacement for "click"/"tap".

The recall problem was caused by software -- where are the software gods who write machine code instead of using compilers? ;)

By some wonderful coincidence I need to implement antialiased line rendering this afternoon. Previously I'd done the 6-triangle method (but I also rasterized any kind of path with all sorts of fancy fills, and it made more sense for that).

Thanks for such a clear write-up and all the links.

Shadow DOM is a DOM structure that's hidden under a tag (for example, the <video> tag has a Shadow DOM which provides the controls and timecode UI).

Virtual DOM is (typically) a pure JavaScript object-based DOM representation that gets somehow flushed to actual DOM (or to WebGL or anything else). You as the programmer use the Virtual DOM directly and try to avoid talking to the real DOM underneath. Virtual DOM has a few advantages, but the one that stands out in today's browsers is limiting DOM thrashing where you query the DOM (requiring an expensive recalc) and then modify the DOM (invalidating what was recalc'd) in a loop.

The license is Apache 2, so go for it! Thanks for the pointers on uiscript and uilang; I'll check them out. GSS is also on my list :).

Thanks!

Regarding your point on declarative vs imperative I think it depends on your pain threshold--you can't accomplish everything you want with CSS layout, but that doesn't mean not very useful. Crucially CSS has the escape hatches that you need to go and do your own layout if you need to (the escape hatches in CSS aren't very good, IMO, but they're there).

So I do believe that this work could be broadly useful. I frequently use apps where the panels don't incorporate momentum properly, or the motion feels disconnected from my actions.

If I were to build on this work, then I'd want to create a system where it's easier to do something pretty good than not, but you can still escape and grab full imperative control if you need to.

Thanks!. For now the source of the examples is the best reference (and is commented with the intent of the constraints):

https://github.com/iamralpht/iamralpht.github.io/tree/master...

I will do some proper documentation and package Slalom up as a library in the future.

Thanks! It's a really fun problem space to work in.

As I mentioned, this work was borne out of my frustration from writing a bunch of touch handlers (taking days/weeks for the tricky ones, to get all the weird wobbles out, and do the right thing with momentum in pagers, etc). I could have saved a bunch of time if I'd had something like this earlier! :).

Smalltalk as a live environment blurs the boundaries between runtime and editing code. There's a video on ThingLab[1], a constraint solver, from 1978 where Alan Borning draws constraints graphically and then switches view to show the code that was generated. When he manipulates a constraint the runtime creates and compiles a new method based on the system that was graphically defined. That kind of thing would still be pretty awesome today (who generates JS at runtime for performance?).

Your comment reads a bit like "we cargo-culted the things we could see in the Smalltalk environment, but didn't understand the underlying philosophy or elegance of what had been made; what's left to learn?" (I know that's probably not what you meant, but I feel like there's a lot left to learn from Smalltalk and the tools that were built with it).

[1]: http://en.wikipedia.org/wiki/ThingLab (see link 4 for the video; it's really fun to watch).

Also check out: https://github.com/cdglabs/thinglab -- there's a link to a St-78 image with ThingLab. Also interesting to note proportional fonts, text selection (by Larry Tesler) and popup menus, all of which I thought came later...

Not me; I want a thin retina laptop with long battery life...

I wonder what the incremental process and cost for building these will be?

Intel used a silicon interposer to support a large amount of eDRAM in the recent IRIS graphics chips. It'd be amazing to have an ultra wide memory bus on mobile silicon...

What's the status of QtWebKit now? It was removed from WebKit trunk about a year ago...

Where is the original open source release from Silicon Graphics which Yahoo based this work on? Did they ever make one?

Is that a language feature or a runtime/library feature though?

What algorithms are there for inferring the calculation?

I'm playing around with a tool for building touch gestures visually, and I have some problems that look a bit like that (want to infer a function from some examples) but I don't yet know how.

Nice spring stuff, I hadn't seen it written up like that before. I did my own in JS recently (also based on solving the damped spring equation as a 2nd order ode; I copied my solution out of a physics textbook): https://github.com/iamralpht/iamralpht.github.io/blob/master...

I think the main advantage of using physical models is that you can feed velocity (from a touch gesture) into them. You can't really do that with the Penner equations (you could compute duration based on the derivative at t=0, but it won't feel very nice).

I wrote up some of the advantages of using physical models for UI animations and interactions here: http://iamralpht.github.io/physics/

It's Intel's money; they've been rumored to be doing whole BOM subsidization (so the x86 is almost zero, and the non-Intel components are subsidized too).

This is how INTC booked a $1B loss on $1M revenue for mobile in the most recent quarter. Cynically I wonder if they just merged mobile with the revenue positive CPU business to better bury the bad news every quarter.

Next stop Windows! Then they can use all the modern C++ constructs they like...

Sorry, I didn't try any polyfills; I had a few hours on a weekend and compatibility wasn't on my list. I did do that for a previous project[1] and it was more work than I had time for. I'd love it if Firefox included a CSSMatrix implementation, it's incredibly useful. That and a method to get the absolute transform of an element including all the fiddly transform-origin stuff would be wonderful (I remember roc talking about something like this, but don't remember what happened).

[1]: https://github.com/iamralpht/tboard a spelling game for my kids, inspired by the worksheets they get at school.

My bad, I updated it with APSLv2. If that's no good then send me an email (my address is in the page) and we can figure something out. Happy hacking!

Circle masks are part of Material Design, but I haven't seen anything with draggable Floating Action Buttons (prior to making this). Obviously they've had a draggable circle for the insecure lock screen for a while, but (to me) it never felt as good.

As I mentioned in the notes, Facebook Home was my main inspiration for this work. It's kind of a mash-up of that and Material...

Here's the source https://github.com/iamralpht/iamralpht.github.io/tree/master... although it's not terribly beautiful...

I love the way Material Design looks, but I think there's still a way to go with how it responds to input. I made a prototype last weekend of a more fluid Floating Action Button:

http://iamralpht.github.io/fab

Maybe the business week puff piece on Sundar (which somewhat atypically spent a page complaining about Andy)?

Funny how everyone was doing the General Magic-style UI (where you had to navigate down the street to the post office to send email) back then.

I have to imagine that $150 blows the SS10 away massively (yesterday's Nexus Player is $99 with Bay Trail silicon with a solid GPU...) -- the speed of commoditization of hardware this cycle has been pretty amazing.

The SGI guys had a similar experience when Nintendo bulk produced the N64 and sold it for $200. It was most of a $5000 workstation with better graphics hardware!

The Cray guys had their own funny culture as well, though. Cray was incredibly process-based, whereas SGI was entirely seat-of-the-pants product driven. Merging those two cultures was incredibly painful; ultimately the Cray guys won out and SGI became process driven[1]. There's a really twisted article in Wired after Cray got spun out where they complained about all the money they got from SGI because it came with sandals and pets-at-work-allowed rules.

From the Cray culture (and some of the Cray employees) we got the IRIX release train, where we'd ship a new QA'd release every quarter. If a feature wasn't ready it just got pushed out to the next release, no big deal (sometimes this didn't work out; bizarrely one of the biggest screwups came from the CXFS guys who were working in the old Cray campus in Eagan, MN).

[1]: Though as I read Zero to One it's interesting to see Theil's perspective on process-vs-product outlook. Definitely the product-driven SGI was the more optimistic one.

SGI wouldn't have been able to manage that business as well as Sun did; at least the E10K was successful somewhere.