Show HN: Slalom – creating declarative touch interactions with constraints(iamralpht.github.io) |
Show HN: Slalom – creating declarative touch interactions with constraints(iamralpht.github.io) |
Only this morning I was thinking of how to implement a few of these types of interactions for a web app I'm developing - I actually might adapt some of the source code for my uses (assuming that's allowed under the License?).
If you're still working on a syntax for this, maybe you'll want to have a look at uilang or uiscript (both on Github) or Grid Style Sheets (http://gridstylesheets.org/).
That said, this paragraph struck me as a great illustration of why I tend to prefer procedural layout systems to declarative ones, at least in production code:
Also note that there's slip! If you drag from the middle of the box, you'll see that the part of the image you grabbed slips out from under your finger. That's because the manipulator is just operating on the box's y coordinate. If we wanted to avoid slip then we'd have to create a new variable when the finger goes down, relate it to y (that is, fingery = box.y - 123 times scale, based on the current scale and finger start position) and then manipulate fingery instead of box.y. This isn't very hard, but the current manipulator code doesn't support it.
There will always be some situation the layout system's designer didn't predict. With procedural layout, you can write the procedure yourself. With declarative or constraint-based layout, you're stuck, since there's no way to express your special case in the limited language provided. Declarative systems are great for demos or rough prototypes, but when you want full control, there's no substitute for the power of procedural code, IMO.
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.
I've been meaning to get my head around cassowary for a while now. I think your project is the motivation I need to get to it :)
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.
Your constraints abstraction looks very promising. Now all you need is to package it up. The examples are excellent.
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! :).