Menu Search
Jump to the content X X
Smashing Conf New York

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Designers: Start Coding With uilang

Editor’s Note: Designers could learn how to code, and developers could learn how to design. Sometimes it might not be an option. In this article, the author makes a suggestion to designers without coding skills on how to start crafting code. You might want to take the suggested tool with a grain of salt (or not) but the idea might be worth looking into.

Designers have widely adopted HTML and CSS for a while now. They usually feel comfortable enough to implement their own designs, at least in a static form. However, they’re often intimidated by JavaScript — and rightly so! HTML and CSS are declarative and, I’d argue, closer to design than programming.

JavaScript, on the other hand, is “real” programming. This means you not only have to learn a whole new and complex syntax but also have to “learn how to think.” The barriers to entry are high and prevent many designers from taking the plunge. uilang1 tries to fix that.

This article will introduce you to uilang’s philosophy and syntax. We’ll start with a simple example to get you comfortable with the basics, before moving to something more exciting. At the end of this tutorial, you’ll (hopefully!) be able to code many typical interface widgets, such as popovers, tabs, overlays and much, much more.

The Bridge Between Designers And Developers Link

I strongly believe that designers should code the interfaces they design. They shouldn’t necessarily write production-ready code, but they should design the behaviors. Designers love these things. They could spend hours tweaking an animation delay or finding the right cubic-bezier curve. They usually just lack some technical skills to do so.

uilang tries to facilitate the communication between designers and developers by giving designers an extremely simple tool to prototype their interfaces. uilang reads like plain English, uses a one-line syntax declared right in the HTML and provides very few options in order to make its learning process and adoption as fast and easy as possible. We’ll cover the syntax in detail later, but here’s a sneak peek at it:

clicking on "button" toggles class "visible" on "div"

uilang is not exclusively a prototyping tool, though. It can safely be used on production websites to create, for example, tabs, photo galleries, popovers and more. Let’s see how it works!

Getting Started Link

uilang is based on a dead simple principle: manipulating classes on your elements. By just adding and removing classes when something is clicked, we can show, hide, transform and animate elements using CSS. This simple logic gives you endless possibilities. Let’s explore one of them by creating a simple notification banner like this:

See the Pen bNWaVz2 by Benjamin De Cock (@bdc3) on CodePen4.

We’ll start with the HTML markup, which is pretty straightforward:

<div id="notification">
  <p>You have 3 unread messages.</p>
  <button class="hide">Hide</button>
</div>

We’ll now use uilang to define a simple behavior: When the user clicks on an element that has a hide class, we’ll add a hidden class to the element that has a notification ID. The translation in actual uilang code looks almost the same as the explanation above:

clicking on ".hide" adds class "hidden" on "#notification"

This line of code should be written in a simple <code> element, right in the
HTML. uilang will automatically find the <code> element containing your
code and will ignore other <code> elements that you might have on the page.
Additionally, you’ll have to download and insert the uilang.js library5 (1 KB).

While both your <code> and <script> elements can
theoretically be inserted anywhere on the page, it’s recommended to place them at the very end of the document, just before the closing </body> tag:

<body>
  <!-- Your content -->

  <script src="uilang.js"></script>

  <code>
    <!-- Your uilang code -->
  </code>
</body>

By respecting that order, you’re making sure to reach the best rendering performance. Thereby, your final HTML markup for the notification banner will look like this:

<body>
  <div id="notification">
    <p>You have 3 unread messages.</p>
    <button class="hide">Hide</button>
  </div>

  <script src="uilang.js"></script>

  <code>
    clicking on ".hide" adds class "hidden" on "#notification"
  </code>
</body>

We’re almost done! Now that the behavior has been defined, we’ll rely on CSS to fade out that notification banner once the hidden class has been applied to it:

#notification {
  transition: .8s
}
#notification.hidden {
  opacity: 0
}

Congrats! You now know how to code! You might not realize it yet, but this simple logic will let you build a wide range of widgets and interactions. Let’s have a closer look at the options provided by the syntax.

Syntax Link

The syntax can be split into four parts:

clicking on ".hide"(1) adds(2) class "hidden"(3) on "#notification"(4)
  1. any CSS selector
  2. adds, removes or toggles
  3. any class name
  4. any CSS selector or the target keyword (which selects the clicked element)

That’s all you need to learn. Keep in mind that uilang is basically just HTML, so you can comment the code similarly:

<code>
  <!-- I'm a comment -->
  clicking on ".hide" adds class "hidden" on "#notification"

  <!-- I'm another comment -->
  clicking on "li a:first-child" toggles class "active" on "target"
</code>

Please note that uilang only supports click events. Hover effects can usually be achieved in CSS, and other events are simply beyond the scope of this language.

We’ve now covered the basics of uilang. It’s time to build a more advanced demo!

Apple-Like Explore Menu Link

We’ll create a collapsible, animated menu similar to the kind you can find on Apple’s website6. Check out the demo117 to see the result.

uilang demo: explore menu8
(See large version9)

HTML Markup Link

Nothing fancy, really, just a simple link to toggle the navigation, and the nav element containing our list of links:

<a class="explore" href="#">Explore</a>

<nav>
  <ul>
    <li>
      <a href="#"><img alt src="images/1.jpg">West Coast</a>
    <li>
      <a href="#"><img alt src="images/2.jpg">Venice</a>
    <li>
      <a href="#"><img alt src="images/3.jpg">Peyto Lake</a>
    <li>
      <a href="#"><img alt src="images/4.jpg">Iceland</a>
    <li>
      <a href="#"><img alt src="images/5.jpg">Golden Gate</a>
  </ul>
</nav>

Now, adding the toggling behavior with uilang will be extremely simple:

<code>
  clicking on ".explore" toggles class "open" on "nav"
</code>

We’ll then use this open class in our style sheet to show and hide the nav. Just before we do that, let’s add a few things to complete our HTML markup: a meta tag for mobile users, the link to our style sheet and, obviously, the uilang.js library! The whole HTML might now look like this:

<!doctype html>
<meta charset="utf-8">
<meta name="viewport" content="initial-scale=1">
<title>Explore menu</title>
<link rel="stylesheet" href="style.css">

<a class="explore" href="#">Explore</a>

<nav>
  <ul>
    <li>
      <a href="#"><img alt src="images/1.jpg">West Coast</a>
    <li>
      <a href="#"><img alt src="images/2.jpg">Venice</a>
    <li>
      <a href="#"><img alt src="images/3.jpg">Peyto Lake</a>
    <li>
      <a href="#"><img alt src="images/4.jpg">Iceland</a>
    <li>
      <a href="#"><img alt src="images/5.jpg">Golden Gate</a>
  </ul>
</nav>

<script src="uilang.js"></script>

<code>
  clicking on ".explore" toggles class "open" on "nav"
</code>

Note: For those wondering about the brevety of the code, keep in mind HTML5 considers as optional the <html>, <head> and <body> tags. Feel free to adopt a different style if you have another preference!

CSS: Where The Magic Happens Link

As always with uilang, the interesting parts of the code are in the style sheet. uilang’s role is exclusively to define the behaviors, not to execute them.

Let’s start by styling and positioning our elements, so that our navigation is ready to be manipulated with uilang. I won’t go into much detail — I assume you’re already comfortable with basic, standard CSS — so I’ve only commented some parts of the code. Please note that irrelevant style declarations, such as for fonts and colors, have been omitted for clarity.

body {
  background: #f3f3f3;
}

.explore {
  /* Make sure the Explore link stays above the nav */
  position: absolute;
  z-index: 1;
}

nav {
  background: #fff;
  box-shadow: 0 1px 2px rgba(0,0,0,.15);
}

nav ul {
  /* Allow mobile-friendly horizontal scrolling when the browser isn't wide enough */
  overflow: auto;
  -webkit-overflow-scrolling: touch;
  /* Force the thumbs to display in a row */
  white-space: nowrap;
  padding: 80px 40px 40px;
}

nav li {
  display: inline-block;
}

Onto the interesting part: coding the toggling behavior! We’ll need two things:

  1. By default, the nav and the thumbs should be hidden. This means we need to initially slide up the nav and make the nav and images transparent.
  2. When the open class defined in our uilang code is applied to the nav, we need to reverse the default state: slide down the nav and fade in everything.

Step 1 is pretty easy: We’ll use translateY(-100%) to slide the nav up, opacity: 0; to hide the nav and images, and transition to animate these elements when the class is applied.

nav, nav li {
  opacity: 0;
}

nav {
  -webkit-transform: translateY(-100%);
  transform: translateY(-100%);
  transition: .4s;
}

nav li {
  transition: .3s;
}

This is not immediately related to uilang but, because uilang does rely on CSS for transitions and animations, we should probably remember a few important principles:

  • You can safely and smoothly animate only two properties: opacity and transform. Force yourself to stick with them.
  • When only the duration is specified in the transition shorthand property, all properties that might change in future will be animated and will use ease as their timing function.
  • Keep your animations fast! Animations are important because they help users to understand the flow between two states, but they should never get in the way. A good transition-duration is usually between 200 and 800 milliseconds.
  • While standard easing keywords are sometimes acceptable (such as with this demo), custom cubic-bezier curves are often preferable. Many tools enable you to find the right curve, such as Matthew Lein’s Ceaser10.
  • The examples in this tutorial use CSS transitions, but feel free to use CSS animations instead when needed! The principle is exactly the same, and keyframes might provide a finer level of control.

Now that our default state has been set up, we can go to step 2 and code the “open” state, which basically means reverting step 1 to the default values for the open class:

nav.open, nav.open li {
  opacity: 1;
  -webkit-transform: none;
  transform: none;
}

nav.open li {
  /* Wait for the nav to slide down a bit before starting the animation on the thumbs */
  transition-delay: .3s;
}

Boom! You now have a fully functional animated navigation menu. A few things are missing that would make it truly great, though, starting with the scale animation on the images. If you look closely at the demo117, you’ll notice that the images not only fade in when they appear but also zoom in a little. Let’s add that behavior by making them slightly smaller by default:

nav li {
  -webkit-transform: scale(.8);
  transform: scale(.8);
}

We’ve already defined that nav.open li will reverse to transform: none; and that all properties will animate, so there’s nothing more to add.

Good! We’re almost done, but one important thing is missing: changing the icon on the “Explore” link when the nav is open or closed. To do that, we’ll need to define a new rule in our uilang code. We’re currently toggling an open class on the navigation to show and hide it; we’ll need to do something similar for the link itself.

<code>
  clicking on ".explore" toggles class "close" on "target"
  clicking on ".explore" toggles class "open" on "nav"
</code>

Here, target represents the clicked element. In this case, you could have just reused .explore instead of target. However, that wouldn’t be the same if you had multiple “Explore” links on the same page (.explore matches any “Explore” link, whereas target selects only the clicked “Explore” link).

Back to the CSS. We’re going to use pseudo-elements to display our icons. .explore::before will represent our grid icon (visible when the navigation is closed), and .explore::after will display the cross when the navigation is open. Both will benefit from the same transition-duration.

.explore::before, .explore::after {
  content: "";
  position: absolute;
  left: 0;
  transition: .25s;
}

.explore::before {
  background: url(grid.svg);
}

.explore::after {
  background: url(close.svg);
  /* Hidden and scaled up by default */
  opacity: 0;
  -webkit-transform: scale(1.8);
  transform: scale(1.8);
}

The grid icon is already visible; the close icon is hidden but correctly positioned, ready to fade in as soon as “Explore” is clicked. We just have to reverse the default state when the close class defined in our uilang code is applied to .explore:

/* When the nav is open, hide and rotate the grid icon… */
.explore.close::before {
  opacity: 0;
  -webkit-transform: rotate(45deg) scale(.8);
  transform: rotate(45deg) scale(.8);
}

/* … and display the close icon */
.explore.close::after {
  opacity: 1;
  -webkit-transform: none;
  transform: none;
}

That’s it! We’ve achieved this pretty cool effect with just two lines of uilang and a few CSS declarations. Note that, while the uilang code might not be used in production by the developers you collaborate with, your CSS is production-ready. Most of the prototyping tools out there force you to build mockups outside of the actual HTML and CSS, which forces developers to reimplement your animations, delays, easings and so on. Details get lost all the time. With uilang, developers can just reuse your CSS and focus exclusively on reimplementing the logic in JavaScript.

Icing On The Cake Link

As a bonus, let’s end this tutorial by having some fun with CSS! The grid and close icons that we’re using on the “Explore” link are actually pretty simple, and using images for them (as we’re doing) would be a shame when we could just draw them in CSS. Let’s do this!

The grid icon is the most interesting one. While it might initially seem counterintuitive, we’re going to use gradients to draw it. The idea is that each of the nine squares will be drawn as a gradient from black to black. When you create a CSS gradient, you’re basically generating an image on the fly. This (background) image can then be sized and positioned anywhere.

grid-icon-info-details-opt12
(See large version13)

Here’s the translation in CSS (available on CodePen14):

.explore::before {
  width: 13px;
  height: 13px;
  background-image: linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000),
                    linear-gradient(#000, #000);
  background-position: 0 0, 50% 0, 100% 0,
                       0 50%, 50% 50%, 100% 50%,
                       0 100%, 50% 100%, 100% 100%;
  background-repeat: no-repeat;
  background-size: 3px 3px;
}

It’s verbose and arguably crazy, but keep in mind that, while we’re essentially doing it for fun, this technique comes with real advantages, the most important one being undoubtedly the HTTP request you save from not requesting a file.

The close icon is much simpler but still requires some tricks to make it look great. We’ll use a similar technique: drawing a gradient from black to black for each bar of the cross in order to form a plus sign, then rotating the plus to make it look like a cross. To prevent the lines from looking jagged because of the 45-degree rotation, we’ll scale up the icon a little using the transform property, which provides us with decent antialiasing.

.explore::after {
  width: 11px;
  height: 11px;
  background-image: linear-gradient(#000, #000),
                    linear-gradient(#000, #000);
  background-position: 50% 0, 0 50%;
  background-repeat: no-repeat;
  background-size: 1px 100%, 100% 1px;
  -webkit-transform: rotate(45deg) scale(1.4);
  transform: rotate(45deg) scale(1.4);
}

Go Create! Link

CSS is powerful, performant yet remarkably easy to use. uilang wants to stay invisible in your workflow and act as a gateway to using CSS to code interactions. After all, CSS might be the best “user interface” for creating prototypes.

Resources Link

(ds, il, al)

Footnotes Link

  1. 1 http://uilang.com
  2. 2 'http://codepen.io/bdc/pen/bNWaVz/'
  3. 3 'http://codepen.io/bdc'
  4. 4 'http://codepen.io'
  5. 5 http://uilang.com/lib/production/uilang.js
  6. 6 http://apple.com
  7. 7 http://demos.uilang.com/explore-menu/
  8. 8 http://demos.uilang.com/explore-menu/
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2015/01/demo-uilang-large-preview-opt.jpg
  10. 10 http://matthewlein.com/ceaser/
  11. 11 http://demos.uilang.com/explore-menu/
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2015/02/grid-icon-info-details-large-preview.png
  13. 13 https://www.smashingmagazine.com/wp-content/uploads/2015/02/grid-icon-info-details-large-preview.png
  14. 14 http://codepen.io/bdc/pen/emYpGJ
  15. 15 http://uilang.com/
  16. 16 https://github.com/bendc/uilang
  17. 17 https://medium.com/@bdc/the-educational-side-of-uilang-92d39da94c13
  18. 18 http://transpiler.uilang.com
  19. 19 https://medium.com/@zackcote_/sublime-text-snippet-for-uilang-efb05fbed0d
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

Benjamin is a freelance icon and interface designer living in Belgium. He specializes in iOS and OS X software design. You'll find some of his work on his Dribbble profile.

  1. 1

    You gotta be kidding me. This is terrible.

    8
    • 2

      I’d be interested in a slightly more elaborated feedback.

      17
      • 3

        Being a designer, I will elaborate. uilang needs a ui, not snippets of code that need to be edited by hand.

        8
      • 4

        Designers should do their job – design. Developers should code. Simple as that. Does your barber make combs, hairbrushes, scissors and hairdriers?

        -12
        • 5

          Designers should design and code. Learning how to code will open lots of possibilities to your design, why would you limit yourself to only design? Why limit yourself at all?

          39
          • 6

            Jack of all trades, master of none. That’s why we have specialization.

            -13
          • 7

            Then they should actually LEARN to code. Learning this weird middle ground that will have ALL KINDS of bad pitfalls isn’t the solution. Its a hacky way of making it such that designers don’t actually have to learn anything at all. Designers should learn to code and developers should learn to design, but hacky things like these are not helping either skillset learn the other.

            12
          • 8

            Also in many ways, learning to code will limit you as a designer. You might be able to design great looking things, but only a real developer will be able to write nice clean code to implement it as it should be. This is why developers hated GoLive and Dreamweaver in the past. The code it writes is awful.
            By your thoughts, you are also suggesting that developers learn to design. In my experience this ALWAYS leads to bad front-end results. Some designers do some coding well, but they are not as good as someone who codes 100% of the time. In many cases, designers will code their designs and when handed off to developers they have to rebuild much of a page.

            1
          • 9

            i do both and i am happy that i started coding :D

            9
        • 10

          Your analogy suggests that designers (and developers) should create the tools they’re designing/developing on. Having designers and coders doing the same job would be like having two barbers; one for cutting your hair and the other for combing it.

          2
        • 11

          Asdrubal Chirinos

          February 12, 2015 9:09 pm

          No, my barber doesn’t, but let me use a more proper example: Fashion designers not only draw sketches they should know about fabrics, patters, sewing. They go from conceptualization, designing and making!

          Modern Web Designers needs to embrace this same process, they should be able to create a concept, design it (Photoshop, Illustrator), and create: HTML, CSS, and some sort of basic JS (perhaps to a JS framework as JQquery) to provide richness and animation to its work

          19
        • 12

          Well, sometimes it helps if you you’re a designer who can code. And I’d say, it is beneficial for a designer who has some minor skills in coding. Not only does he look better on the resume, he also knows what to do and what not to do in web design.

          7
  2. 13

    It might look fancy and easy to use. However it will bloat up your code in no time. I don’t see the actual value over normal Javascript. And what about older browsers, do they support it? I highly doubt it.

    5
  3. 16

    Martijn Hermans

    February 11, 2015 4:43 pm

    2015 has just started, but we already have a winner here… Sorry, but this is very bad.

    This can (so it will) go wrong in so many ways unless of course you stick to the very limited use case: a prototype with UNIQUE class names on a page with only 1 “widget”

    1) it has no context/specificity
    let’s take one of the examples: clicking on “button” toggles class “visible” on “div”
    And now for my next trick: i’m going to toggle the class ‘visible’ to every div on this page.

    2) The transpiler runs ‘e.preventDefault()’ if the target is an ‘A’-element.
    While this sounds like fun: *clicking on “a” toggles class “loading” on “target”* would prevent the page from actually loading, while all i wanted is to add a class for slow connections.
    It will also mess up internal anchors (‘#page-3’ etc).

    3) Why not make delegated event listeners?
    Let’s take a simple use case:
    – clicking on “button” toggles class “class1” on “target”
    – clicking on “button.class1” removes class “class2” on “target”
    Since the events are bound on page load, the second row will never be executed, while my uilang-code clearly says otherwise = sad designer
    Developer now must figure out what the heck designer was thinking and try to explain why it doesn’t work like that. “Yeah i know you can’t code, but let’s start out with the difference between bound events and delegated events”

    4) The transpiler compiles into using ‘classList’. Sounds good and all, but that means no ie8/9 support.

    5) Developers are real humans! Just… ask them to do this for ya?
    Meanwhile, they will gladly fix that you didn’t take context and specificity into account when you said ‘the title’ but actually meant ‘the title of that one element’. And they won’t even mention it…

    6) this could be so much short: clicking(‘selector’).toggles(‘class’).on(‘target’). And it would actually be valid javascript. because it’s javascript. (it’s just an example)

    12
    • 17

      I don’t get your comments about context/specificity. uilang just relies on CSS selectors, so you get the exact same behavior as with CSS. So, instead of doing `clicking on “button” toggles class “visible” on “div”` you’ll presumably do something like ` clicking on “button.menu” toggles class “visible” on “header div.nav”`.

      0
      • 18

        Martijn Hermans

        February 11, 2015 5:30 pm

        Well, imagine it like this: you have 6 cars.
        “clicking ‘garage car dashboard.startbutton’ add class ‘driving’ to ‘car'”

        Now you have 1 car, 5 wrecks, 4 holes in the side of your garage and a very pissed of dealer where your wife just drove her car into the garage for service… Because you just started all 6 of em.

        Context: i just want to start the CURRENT car. that is not possible.
        Specificity: i want to start a car in the garage. The designer doesn’t know the developer has multiple garages and multiple cars. nor should (s)he.

        16
        • 19

          I’m not entirely sure to get your analogy but, as a general answer: yes, uilang is limited and no, you won’t be able to do whatever you want with it. It’s not its goal. You might think that uilang provides a useless simplification and that designers should just learn proper JavaScript but as far as I can tell, many designers never take the plunge. uilang simply tries to de-dramatize getting into programming.

          1
          • 20

            uilang ISNT programming. That’s the whole point. If you want to de-mystify programming, then start with actual programming. This is like saying “I don’t really understand anything about space, so give me an astrology chart and i’ll be able to know some names of constellations”. What you’re actually doing is making it such that after using uilang, no one knows anything about code still, because its not code.

            5
  4. 21

    Wait, it’s not April 1st yet, is it?

    -7
  5. 22

    The article does suggest that this is a useful tool to bridge the gap between devs and designers. As such, I see no problem with designers getting involved with this framework: one can learn about basic conditionals and show their creations to a dev to provoke discussion.

    It’s not production ready code and we know it. That’s okay.

    23
  6. 23

    In case I didn’t make the point for uilang obvious enough in the article, make sure you read this article: https://medium.com/@bdc/the-educational-side-of-uilang-92d39da94c13

    TL;DR : “While this extreme simplification of JavaScript is good to remove the barrier to entry to programming, designers will presumably feel the need to do more than the possibilities uilang provides them with. That’s good. If using uilang for just a few days gets designers excited about code and helps them switch to JavaScript, I’ll be very happy. Mission accomplished. I don’t need people to use uilang forever. It’s a starting point, an appetizer that addresses your first needs and get you excited about the rest.”

    23
  7. 24

    A great tool that allows designers to make themselves their prototype.
    But for sure, this tool shouldn’t be used in production by developers.

    9
  8. 25

    So being a designer I really like it. I can’t talk about the quality of the technical implementation since I’m not a developer, but I can say that for designers, this visual way of constructing code makes a lot of sense! For some of the developers I’ve worked with over the time, this way of writing code could have helped A LOT in communicating and collaborating.

    I would love to see an expanded version of this.

    14
  9. 26

    I find it great that people are trying to find ways to bring more people into coding.

    However in this particular case I don’t see the added value uilang brings compared to jQuery, which also offers a pretty straightforward syntax.

    4
    • 27

      You’re right, jQuery definitely makes things easier, but uilang doesn’t just try to simplify the syntax. In my experience, designers literally don’t know where to start. They don’t have the appropriate mental model (yet!). uilang tries to provides them with clear guidance by giving them very few options and clear examples of popular use cases.

      3
      • 28

        “They don’t have the appropriate mental model (yet!).”

        This is so wrong.
        First, anyone can learn to code, there are resources out there, I learned the basics of jquery in an afternoon through codecademy and can do way more than what uilang can allow. Trust me, if I managed to learn jquery, anyone can. But the worst part is uilang doesn’t seem to teach proper coding. The simple fact you have to repeat “clicking on #mydiv” for every change is terrible IMHO. So what will a designer learn from that? Coding without algorithms is like using Photoshop without smart objects.

        Also, it doesn’t seem easier or simpler than jquery, what you can do with one line of code in uilang you can do with one line of code in jquery and for both you have to learn the syntax. Because uilang’s syntax looks more like plain English doesn’t make it easier to remember for someone who doesn’t code. If they have to look at an example to reproduce what they want, let them learn something they can dive into and improve themselves instead of a quick and dirty solution that’s basically a dead end.

        5
        • 29

          PS : sorry if my message sounds vehement, that wasn’t my intent. I actually welcome the initiative. It’s just the patronizing attitude towards designers that I cannot bear.

          1
        • 30

          Once you grasp the basics, then you can start asking, “how do I improve on it?”

          0
  10. 31

    Really useful! I need to give it a try.

    1
  11. 32

    Are these “Designers” that don’t know how the code, the same people that moved to Web design from Print when that medium hit the wall?

    Being involved in making websites and not know how they’re built is just ridiculous. It’s hardly a massive jump from HTML to simple jQuery.

    I’m a designer and developer. Luckily I don’t have to bridge the gap and leave massive holes in my app.

    1
    • 33

      I’m also a designer and developer, but it’s a bit presumptuous to think that people that aren’t both are necessarily idiots that shouldn’t do this job. Some designers are simply not interested in webdesign’s more technical aspects.

      10
      • 34

        “Some designers are simply not interested in webdesign’s more technical aspects.”

        and that’s is a huge problem for every web-project.

        8
      • 35

        Martijn Hermans

        February 13, 2015 10:09 am

        That is basicly like saying: “I do like performing heart-surgery, i just don’t like the whole ‘how does a heart work’ thingy. Let the other doc fix my mistakes”. For some reason, i wouldn’t like to visit that doc. And while we wouldn’t allow that situation, we are perfectly fine with designers not knowing nor caring about the specifics…

        I’ve previously worked with a designer that started out not knowing much about the technical aspect and possibilities of the web. Once she got the hang of it, it made her a way better designer. Stuff still looked good as always, but now it also worked.

        3
    • 36

      Designers are called Designers for a reason. Most of them can’t code and it’s ok most of the times..

      0
      • 37

        but they should know how the web works. That triangles and flexible circles aren’t easy. What does responsive design mean for images. Some designers that come from print just do not know how the web works and we developers always have to tear their designs apart because 80% just doesn’t work like that or is better done another way.

        In essence: having a designer learn basic coding skills and understanding of the web that’s he/she is supposed to design has only advantages. And I’ll take every designer that’s interetested and willing to learn how the web works over one that doesn’t.

        4
  12. 38

    Ergon Gervalla

    February 11, 2015 6:04 pm

    Developers don’t get designers at all. Stop creating languages for designers. It’s as if designers would create Photoshop tools so that developers could code with instead of programming languages.

    Developers that want to create tools for designers should concentrate on developing visual tools that write clean code automatically. A designer should design fast and efficiently and not waste time coding. Do not build design pattern libraries either! Good designers like to create everything from scratch, so you should develop the basic building blocks only and let designer get creative with them.

    4
  13. 39

    While I didn’t checkout more complex uilang statements, But I personally don’t love the idea.
    Probably for the same reason why I don’t like coffeeScript.

    They can easily save snippets like this and change according to their needs:
    $(.selector).click(function(){
    $(ele).addClass(“class”)
    });

    I am not sure its gonna make the designers life easier.

    4
  14. 40

    Miguel Machado

    February 12, 2015 1:44 am

    I’m a web designer and a front-end dev. I think that when you know about this two things you can think things ahead, is like being an architect and a engineer at the same time. Backend dev don’t see things like us and if we lost a little time learning HTML, CSS and jQuery the result (speaking about pixel perfection) is a lot better. Another thing is when we think in future, when a designer must do more that static websites, we have to deal with a lot of motion, animations, so for me is important to know how tweak every animation, every detail. For me uiland seems to be interesting, because now in CSS3 we can animate a lot, but in some situations we must use jQuery to get job done. I still think that jQuery and some software like edge animate are the best way, but I will give a try…

    7
  15. 41

    Actually, I quite like the idea and I agree that designers should also design the behaviours.

    There is no point for someone with no knowledge of Javascript to learn about a event delegation, etc. Let the developers worry about clean cod, efficiency and the nitty gritty. What developers can’t do is figure out subtle differences in interactions, that’s where designers have to come in, and this tool come very handy IMHO.

    Cheers for the article Benjamin!

    3
    • 42

      It’s a terrible idea, tbh. I’ve had to fix far too many a sloppy work done by programs like Dreamweaver to ever agree to something like this. Want to make buttons work? Then learn the damn javascript, it’s not like it’s rocket science or anything.

      2
      • 43

        Kasey Bonifacio

        February 12, 2015 9:45 pm

        I think you are missing the point of his comment. He isn’t say that this will produce production ready code but it can help the designer explain how they want certain elements elements to work. Web design is more than just how a website looks but also how it behaves and it can be hard to explain how you want things to work/animate without showing the animation. If the developer doesn’t want to edit the bloated code then they can start from scratch, which they would have had to do anyways, but at least they will have a better understanding of what the designer wants.

        2
  16. 44

    Fernando Castillo

    February 12, 2015 11:15 am

    Thanks Benjamin for this tutorial. Got to know a lot about uilang. Syntax is not much tough but i preferred the snippets mostly.

    0
  17. 45

    Seeing tools like this makes me genuinely fear for the future of this industry.

    “Congrats! You now know how to code!”

    /shudder.

    0
    • 46

      I can’t wait for the day when I tell SIRI a declaration in plain english and it spits out a code snippet. Now, thats the kind of future I won’t fear. But every-time I hand my design to a coder, I always fear, because 90% of the time nothing gets implemented properly.

      0
  18. 47

    This is a great tool, and it prefectly fulfills it’s promise. Gotta be useful for people working on quick and dirty prototypes, get investment for their ideas, then throw money at designers and coders. It’s all about speed today. I’ll give it a shot in my next project.
    Good job and nice article!

    1
  19. 48

    Imo this would be a nice introduction to designers who want to prototype in a browser with some degree of interaction. I like the idea of giving those people really simple lines of code they can use withouth knowing all the extra stuff needed in jQuery. Surely I agree with all of the above stating it’s not much of a tool to actually create a working website/app with but that’s not the point right!

    After a couple of weeks they might be a lot less intimidated when you show them how jQuery works and what the simplified lines of code actually do.

    1
  20. 49

    Well I had a look at the sources on github at uilang/development/uilang-1.0.1.js
    and I wonder where are all the semicolons (;) gone ?

    However, I always recommend to spend time learning JavaScript .
    It is not that difficult !

    2

↑ Back to top