A minimal, UI-focused programming language for web designers (opens in new tab)

It makes easy things slightly easier, and slightly harder things impossible. Stupid idea.

This is cool even though not immediately practical. Quite similar to my project shorthand.js - http://splatcollision.github.io/shorthand.js/

Mine is a little nicer (IMO of course) and supports a little more than just class toggling (the workhorse of interaction design) such as multiple chained actions per target, and more.

I've always thought of this as an intermediate step - designers for whom this type of thing would be useful would know CSS selectors at least, and could work with a bootstrap-alike. The more useful state would be to expose something like this directly in a web preview environment.

All of the examples are basically differently-styled variations of "clicking on X adds/removes class Y on element Z". Is this all it can do? Would have liked to see some slightly more varied use cases.

I think this is a solution to a problem that doesn't exist.

That's not to say it's not a great bit of effort, but I can't think of anybody that has a job to build widgets like on the demo page, yet cannot build them via pure CSS2/3 or JQuery.

I'm no designer, but i'd find it easier using CSS examples I find off the web combined with the information-glue that is StackOverflow, if something goes wrong with UILang, I'm on my own.

I really like this. I think its an interesting approach to a problem designers have.

I personally teach all of our designers enough jQuery so they can animate their designs. The issue is its a steep learning curve and to be honest the Javascript is normally throw away as once we come to build the interface we normally use a framework like Ember or Backbone.

Nice work Benjamin!

This seems to be implemented as an external DSL, with a brand new syntax and semantics. So my question is, why do that instead of implement it as an embedded DSL?

(Disclaimer: this is an honest question out of curiosity. I don't mean to imply that an embedded DSL is the right way, or that it's better -- but I do believe there's a tradeoff here and am interested in how that tradeoff factored in to the decision to implement this as a separate language.)

Chiming in with a few others here - I think uilang looks like a lovely idea, and very clever really given how few line of code are required, but I'm not sure it's genuinely all that useful.

I used to work with a brilliant designer (seriously great - he could realise the most terrible and tangled client ideas in the most stunningly creative and beautiful ways), but code was just gibberish to him. He'd managed to muddle his way through doing simple interactions in ActionScript 2 with the help of several developer friends, but the move to ActionScript 3 had completely defeated him.

I gave him a set of little snippets ("This is how you make something clickable: <code>") and once he had that, he was off. He never properly understood things like for loops, but it didn't really matter to him too much since he was perfectly happy copying and pasting since the end result looked no different.

I don't think having to learn a precisely structured invocation in English (with particular CSS selectors in it) would really be any better for him than just copying in `$("#foo").on("click", function() { $("#bar").addClass("hide"); });` as long as someone had told him "#foo" was what you were clicking on and "#bar" was what you were hiding.

I actually think the other problem with this idea is that the CSS is probably harder to understand than the JavaScript, and the number of people who can write `transform: translateY(80%) scale(.8); transition-timing-function: cubic-bezier(.3, 0, 0, 1.3);` but can't write just a couple of lines of jQuery must be vanishingly small.

The designers I know, at least, either know no CSS and JavaScript at all, or minimal amounts of CSS and JavaScript, or a lot of CSS and the basics of JavaScript - I don't really know any in 2014 who are experts at CSS but have no JavaScript (but I'm happy to be proven wrong on that).

In case you're interested in learning more about the motivation behind creating uilang, I wrote a little piece on Medium: https://medium.com/@bdc/the-educational-side-of-uilang-92d39...

Reminds me of Hypercard. I can't think of many better compliments than that.

There's nothing you can do with Hypercard that you can't do in C, and there's lots of things that you can do in C that you can't do in Hypercard. But there's a lot of people who could manage Hypercard to do basic things who probably would never master C. That, I think, is the problem uilang is trying to solve.

There's also no reason why you can't use uilang to do simple things and roll your own code for more complex ones on the same page.

As an aside, back in GNOME 2 it took me perhaps half an hour's reading to get into UI themes and adapt existing ones to suit my preferences, even start designing my own. It was limited but fun to play with. Then comes GNOME 3 with all its fancy CSS and I just can't be bothered to hunt down how I can make a thicker border on the button with tab focus without the buttons jumping around a few pixels whenever I tab to the next one. Sometimes, less is more. (Long live MATE!)

A simple language could be a benefit for all, not only for beginners.

Extend uilang with more commands (like "after that", "then") and conditions and it would be really powerfull language, that can be used for complex things too.

At the moment every developer with little complex instructions have to comment the code, uilang can reduce this work.

A separate npm module and source files with uilang could be parsed and compiled (like browserify) - (reactjs is a good example for that, include directly in frontend or compile jsx in backend).

I really think you should rethink the project and focus not only on beginners. -> i am not sure they will use it, because you find tons of ressources for things like bootstrap, purecss, ....

This tool would be better named "ClassAdder", the extent of what it does is "add, remove, or toggle classes." The headings on the different examples on the homepage ("Accordion", "Tabs", "Animated Switch", "Overlay" etc.) suggests that the tool itself does all these things, when in fact the tool itself just handles adding/removing classes, and the fancy transitions are from the CSS (not bundled with the tool). This feels a bit misleading.

Incidentally I did not know that element.classList had these methods (add/remove/toggle https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... ) so it was worthwhile reading the source to learn this! https://github.com/bendc/uilang/blob/master/development/uila...

-1000 for no comments in the source code. No,

   function InstructionParsing(instruction) {
     var separator = instruction.charAt(0)
     var instructionSplit = instruction.split(separator)
 
     this.clickSelector = instructionSplit[1]
     this.classBehavior = instructionSplit[2].trim().split(" ")[0]
     this.classValue = instructionSplit[3]
     this.targetSelector = instructionSplit[5]
   }

is not "self-documenting." Tool is not useful but it is a cool study in writing a limited DSL. Kudos to author for this.

AppleScript for the web? Awesome!

However, I'd think that support for more than just click events will be needed to make this worthwhile. 'hover', 'tap' and 'drag'/'drop' seem pretty logical.

I like this. Hate his non xhtml-strict compliant markup (old school).

This is a very creative way to tackle a problem and I love the fact that his JS doesn't add any elements to the existing markup. I feel that once your JS starts drawing dom elements, you've messed up somewhere (unless your front-end is completely JS, different topic). There are of course cases where it is necessary -- supporting older browsers or shimming functionality -- but I've grown to love the separation of markup and interaction.

One could probably build on this idea (wrap your favorite lib) and do things like:

'clicking on ".selector" sends post ".selector[:href]" ..."

But that may make things a bit more complicated in the long run.

Either way, should be fun seeing the 2048-ification of this in the upcoming weeks

This is a neat extension of CSS to allow designers to create simple interactions. I like it as a mechanism targeted slowly at that use case, and I like it even more for determinedly limiting itself to solving that use case well.

The same design taste is evident in the project webpage itself.

If updating CSS classes of some elements when clicking on other elements is all your website needs, then uilang might be the right choice for you. For everybody else, there's web development.

There's a bit of discussion over on DesignerNews (https://news.layervault.com/stories/32423-uilang--a-minimal-...) with a link to Shorthand which is similar, but seems a little better to me (uses <script> tags and clearer language).

http://splatcollision.github.io/shorthand.js/

It's kind of fascinating / scary that this is running on only 100 lines of javascript..

Kind of a cool way to let designers dive into interactive layouts, if only for just prototyping. I could see it being fleshed out into something that could make a big splash, but it seems really limited at the moment to simple CSS toggles..

Where is the Github project?

Is there a page which documents all of the possibilities? Or is it just a series of:

  clicking on "..." (adds|removes|toggles) class "..." on "..."

along with the "target" selector?

Reminds me of Rexx, AppleScript and localized programming languages…

For anyone who might be looking, here's the Github repo: https://github.com/bendc/uilang

wow this reminds me some years ago I toyed with a mash-up language for the web. The whole idea was attempt to combine css declarations vs js imperative.. code looked like this.

  <script type="text/x-dont-remember-what">

  .button:click {
    this.addClass('foo');
  }
    
  #foo a:click(e) {
    this.hide();
    parent.show();
    e.stopPropagation();
  }
  </script>

I think its a good idea, but it needs a bit more work.

This will be an amazing tool for designers.

This could compile to React code and make beautiful standalone components.

Clever idea, but please don't use it.

Bon boulot Ben!