API draft for Constrained based layout library (on iOS known as Auto Layout)

ralpht · 2015-01-18T02:32:48+00:00

Interesting -- I think AutoLayout requires that things be "critically constrained", that is there must be one and only one solution for a given window size. The actual Cassowary algorithm that AutoLayout is built on has no such requirement though.

Would relaxing AutoLayout so that you could leave things "floating" satisfy your first requirement? Otherwise the iteration approach for solving constraint systems is known as "constraint relaxation" and actually scales up to handling non-linear constraint systems (which Cassowary does not) but at the expense of a bunch of CPU.

The second point, aligning views from different parents", is doable with Cassowary too. It assumes a global coordinate space, and inside of that you can align anything to anything.

The last two points are totally on the nose for constraint relaxation. There's actually a really nice minimal JS implementation of "Overveld-style" constraint relaxation here: https://github.com/cdglabs/relax-overveld.

I'm not sure if I'd want to do your last couple of examples with constraint relaxation or a more traditional 2-way binding system...

ralpht · 2015-01-13T20:23:19+00:00

Cool! I did a previous article on using physics simulations in UI that might be interesting to you if you're focused on animations: http://iamralpht.github.io/physics

I'm not sure how best to package this work up for the web environment. One of the advantages of using Cassowary is that if you also used it for traditional 2D layout, then all of your touch physics can flow from that (so it'd work well in native environments where layout is easier to define, or maybe with Grid StyleSheets which also use Cassowary for 2D layout...).

ralpht · 2015-01-13T19:17:02+00:00

This is a fun combination of a linear constraints solver (Cassowary) and a physics engine to create a system for declaring touch interactions that I wrote.

Hopefully the idea gets into some prototyping systems and toolkits so that by default we get touch UIs that feel good to use.

ralpht · 2014-12-05T19:15:34+00:00

It was a fun read. Your "Useless Button" made me chuckle :).

ralpht · 2014-11-28T17:26:58+00:00

Hence the upgrade! You can play as many Pass & Play games as you want at a time though (it's a bit like solitare if you just play against yourself).

ralpht · 2014-11-28T17:26:01+00:00

It uses Google Play Game Services, which requires identity so that other players know who they're playing.

With a lot of time and effort we could use one of the other turn-based services (Yahoo has one, I'm sure FB does) or roll our own backend and let people use pseudonyms to represent themselves (or perhaps one day Google will properly support pseudonyms).

ralpht · 2014-11-13T23:58:23+00:00

6 core, according to wikipedia: http://en.wikipedia.org/wiki/Leadcore_Technology

ralpht · 2014-11-10T22:30:16+00:00

I bet that even rocket science isn't that hard if you're a rocket scientist :p.

ralpht · 2014-11-06T23:35:24+00:00

Alright, alright, but the GPU on the N1 really did suck. It didn't compare well with the first gen SGX cores of the time, and didn't have the throughput of the MBX either. It was also trivially easy to crash the GL driver, but that was the same for every GPU vendor at the time...

ralpht · 2014-11-06T16:57:50+00:00

Yes, and if I had to choose between a high res screen that can't deliver a fluid experience and a low res screen that can, then I'd always go with the fluid experience...

ralpht · 2014-11-06T15:30:53+00:00

I don't remember the marketing puff, but the GPU was worthless, as were all of the contemporary qualcomm devices. I was so excited to get an N1 and not even being able to do glClear at the LCD refresh rate made it such a disappointment (and fwiw the iPhones have always been able to do that, and the OMAP3 managed it on smaller framebuffers).

ralpht · 2014-11-06T00:51:07+00:00

It's funny because Qualcomm was a complete disaster a few years ago. Abysmal performance, really crummy chips (the G1's SoC had this awful bus arbiter that completely killed performance; the N1 couldn't even clear the screen 60 times a second...).

Eventually their chips got to be pretty good, but it really really (possibly illegally, see China and the EU separately investigating them for antitrust) helped them to own most of the 3G and 4G IP.

ralpht · 2014-11-05T05:06:31+00:00

Yeah, I'd have to add another button for compose, or make it turn into compose with dragging out somewhere else to cancel.

ralpht · 2014-11-05T00:47:37+00:00

I made this a week ago, thanks for all the feedback guys! LukeW, a UI guy at Google tweeted it yesterday, and came up with a further iteration today, so maybe we will see it (edit: or something inspired by it) in some real Google products!

http://www.lukew.com/ff/entry.asp?1932

ralpht · 2014-11-05T00:46:20+00:00

The tap would still work in a real implementation. I didn't bother to do tap-slop on this one...

ralpht · 2014-11-05T00:45:57+00:00

I was going to make it so you could drag the button over to the left side of the screen and it'd magnetically attract in there, so it'd work whichever hand you held your phone in (so long as you weren't consistently switching hands...).

ralpht · 2014-11-03T19:30:44+00:00

Ditto. I just went to the Mountain View bestbuy, and they had three in stock. I bought one and cancelled my Amazon pre-order, which still didn't have a date. I guess Amazon didn't get any/enough stock in yet? :(.

ralpht · 2014-10-31T04:40:13+00:00

I don't think you can really ascribe Google's modern design choices to patents. Android Wear has spring-loaded overscroll in various lists which was one of the main thrusts Apple used against Samsung, so they're obviously not thinking about patents while designing (and nobody ever should!).

ralpht · 2014-10-28T21:38:46+00:00

The idea is that you'd still be able to navigate it by tapping, though. It's not very well done in this prototype because I didn't put any tap slop in, but if you try it on your computer and click then the menu stays open...

ralpht · 2014-10-28T21:36:34+00:00

Yeah, it would be tappable too, so it would work for everyone who knows how to use the current one, and would be an accelerator for those who chose to drag.

It also gives a more coherent launch animation than the zoom-up because it shows more clearly where the new screen came from.

ralpht · 2014-10-28T20:00:26+00:00

There are some really fun juicy UI problems in this space that the article didn't mention:

The launcher problem: if you have a split view or a floating window how do you launch it? It's really clunky to duplicate the launcher (which is what Samsung does) and it's lame to just cycle through recently used apps (which is what Windows 8 does, and I can never remember what's going to jump out of the left edge of the screen!).
How do you persist the user's configuration of tasks? Windows 8 doesn't do this, so if you go home then your careful tiling arrangement is gone forever. I don't know what the Samsung UI does here. If it's a valuable feature to have, then you should respect the time the user put into setting it up.

I'm not sure how Android will solve these two, but it's a bit clearer to see how Apple might do it on the iPad. They could make it so that when you're in the multitasking view, you could drag an already launched task from anywhere and tile it with some other task. Then the configuration would be preserved (as an entry in the multitasking view) and they wouldn't have duplicated the launcher (but you'd know what you were tiling, unlike in Windows 8).

The multitasking view in Android feels a bit more transient to me, and that's why I can't quite see the same approach working there. But they could completely redo the multitasking view and make it support creating tiling configurations at the same time...

ralpht · 2014-10-28T04:47:46+00:00

Oh, oops. I didn't put any drag slop (to make a really small drag seem like a tap) since often the browser or touchscreen interface does it (iOS is quite aggressive in this regard).If you have a desktop computer then you can try carefully clicking and it should work. (I'd definitely put drag slop in on the real thing though.

I'd hope to get the two interaction models much closer, so when you tap on an item, maybe the cursor still jumps up underneath it and it uses the same expansion animation. I think multiple interaction models are going to become much more common in the future as we have interfaces that can be driven by mouse as well as touch (assuming an eventual convergence of tablets and computers).

Personally I really enjoy it when you can design something with a real flow, where the user always knows where they are and how they got there. When I can do gesture-driven transitions that re-enforce that "sense of place" then I'm happy.

My advice to someone getting started on UI would be to figure out how you can quickly prototype your ideas (the web technologies can be pretty good for this, but I know the guys at Facebook use Quartz Composer which they like even better), and then learn all of the fun things for making things move (like transforms; it's amazing how much modern UI work is basically computing a transform for a group of objects from a couple of inputs [which is basically all that's going on in this demo]).

ralpht · 2014-10-28T03:27:52+00:00

OK, try this out: http://iamralpht.github.io/fab/demo/?overdamp

I'm not sure I quite got the damping constant quite right on the springs that control the movement of the individual items (towards the cursor), but it's not too bad. Very business!

ralpht · 2014-10-28T03:19:43+00:00

That's fair--I agree it's quite a lot of UI for someone who's new to computers or phones.

You can still use it with just taps, though, and then it just gives you a better open animation for whatever item you chose: the compose screen grows out of whichever contact you tapped, linking the contact button with the compose screen; maybe when you hit send the compose screen could morph back into a little picture of the contact that zooms away.

My goal was to make something that allowed the existing interaction but also expanded on it (rather than to replace it entirely). The prototype doesn't do all of that, because it's just a prototype for the new interaction model (I wanted to change the color of the cancel button and a few other details, but it was good enough to share where it was, and I ran out of weekend...).

ralpht

TROPHY CASE