Chat bots, virtual reality and conversational design are just a few of the hot topics that are about to change the way we craft digital experiences. So, it’s a good time to rethink current practices and prepare for what’s about to come, don’t you think?

To give you an early head start into the future of designing meaningful experiences, we are honored to live stream the interview session which Adobe will hold at the Awwwards Digital Design Conf in London today.

The post Live Stream From Awwwards London Conference: Chat Bots, Virtual Reality, And The Future Of UX appeared first on Smashing Magazine.

We’ve all seen Comic Sans; the typeface that’s both loathed and (secretly) admired—some people have even dedicated a website to educating people about the very limited use cases of comic sans! It’s made a huge global impact in the decades since its original use-case, Microsoft’s Bob program.

By 1996, it was popular enough to be preinstalled on every Macintosh computer that rolled off the assembly line, but how exactly did this font come to be? What mind was behind this ultra-kiddy font?

Check out this video and meet Vincent Connare, for all intents and purposes, the father of Comic Sans. When he came up with the idea for the font, he looked through stacks and stacks of comic books, which is probably unsurprising. In particular, he leafed through DC Comics’ Batman and Watchmen stories…and he was inspired!

Commissioned by Microsoft to create a font, Connare came up with a font that resembled the comic lettering he’d noticed in the stories’ speech and thought bubbles.

Unfortunately for Connare, his boss at the time, one Robert Norton, disliked his comic-inspired typeface. Norton thought the face ought to be more “typographic” and had something against its overall quirkiness and weirdness. Connare persisted and defended Comic Sans’ ability to stand out, as it looked markedly different than anything people would look at in their school textbooks. Even so, Comic Sans didn’t make it into Bob’s final release, but ultimately, Connare had the last laugh.

Today, comic sans is freely viewable all over the world! While the font is definitely overexposed, Connare does nonetheless get a huge amount of gratification from all the places he’s seen the font when he travels. Whether it’s in neon signs for small businesses or on war memorials and packages of bread, Connare is vindicated.

To hear Connare put it, he has no regrets surrounding the font. On the contrary, while he freely admits that comic sans definitely isn’t one of the better forms of art, it is still, conceptually, the very best thing that he’s ever accomplished in his career, in all likelihood.

All told, not a bad outcome for a guy who worked as a typographic engineer at Microsoft and, arguably, whose most famous font never saw the light of day in the original Microsoft program for which it was intended. Interestingly, Connare was also a contributor for other famous faces such as Trebuchet.

To understand why he came up with comic sans in the first place, we have to understand his philosophy on art. Good art was art that was noticed while bad art was art that no one noticed and, therefore, was a failure.

Amberlight 2: Create fantastic swirls, light trail images & animations – only $29!

Source

My name is Mason Ellwood and I’m currently working on Flatiron School’s Online Full Stack Web Development Program. Each week, I’ll be writing about my experience, what I’m learning, and tips on learning to code.

So the other day I was encountering a lot of issues with one of my lessons with The Flatiron School. Me and one of the instructors were having some issues with getting some of the test to pass and he mentioned he could get a more senior instructor to screen share with me. I did not know this was an option and it was an awesome experience. They use the software TeamViewer which I have installed earlier but never really have used it before. Once I gave him the necessary authentication, he logged into my computer and was able to test what I was doing on his end with me. While he was showing me this he also got to show me some other shortcuts and bash commands that would help me further in personal projects.

This was an awesome addition to what The Flatiron School offers with its tuition. It was great to see a fast response to my question as well an in-depth look at other ways I could perform the same task.

The instructor also gave me insight to the structure of the school and the importance of moving linearly through the school. I was excited to hear the in the beginning, they keep you constrained to a closed environment (learn.co IDE). Then, with progress, they slowly integrate you to an open sandbox environment on your local machine.

They do this because most students are not ready to have full control of their environment prior to understanding some of these foundational concepts. Once you progress further in the school you will gain a greater understanding of the structure of programming, they introduce these core concepts linearly so you have a smooth transition to an open local sandbox environment.

But enough about that!

Intro to loops:

So a method, which we covered earlier is a form or abstraction. Within methods, loops allow us to tell the program to do something over and over again. Allowing us to abstract away the actual mechanics of enacting the same or similar lines of code.

The above code runs the puts “something” command 10 times. There are a few different ways of doing this, but the simplest way is using the loop keyword.

Enacting this, puts “something” an infinite amount of times because we never specified where to break out of our program. Remember use control + c to break out of program.

Remember that loops start with the loop keyword and are opened by the following do and end block. We can use the break keyword inside the body of our loop to exit our loop and continue with the rest of our program.

This will run the loop the amount of times specified until the counter is greater than or equal to 10, thus printing our message 10 times and breaking. With this construct we can break a loop on any condition.

While and until loops:

The while construct will keep executing a block as long as a specific condition is true, unlike the until condition which is the inverse of the while loop. And until loop will keep executing a block until a specific condition is false.

Loops are a foundational concept of most programming languages including Ruby. If you understand loops and their purpose you will get a better grasp of what you are able to accomplish with that language.

Read More at My Journey Of Learning Programming Through Flatiron School #9

This is the third part in a five part series about the JavaScript framework, Vue.js. We’ll cover Vue-cli, and talk a little more about real-life development processes.
This is not intended to be a complete guide, but rather an overview of the basics to get you up and running so you can get to know Vue.js and understand what the framework has to offer.

Vue-cli and build processes

If you haven’t yet read the last section on Vue.js components and props, I highly suggest you do so before reading this section, otherwise, some things we’ll cover will lack context.

Vue offers a really nice cli that gets you up and running with your choice of a few build tools, and really nice simple starter boilerplate. It’s a lovely tool. Before installing vue-cli, you might want to check that your versions of node, and npm or yarn are up-to-date. You’d first want to install vue-cli (the -g helps you install it globally)

$ npm install -g vue-cli

There are many builds available to you, but in our example, we’ll use webpack:

$ vue init webpack

You can go through the commands that the output will give you, which will help you cd into the directory, install everything, set up your `package.json` file, and then finally serve up a local dev server at localhost:8080 with the command:

$ npm run dev

You’re up and running! I love that the setup is so clean. You’ll start off with an App file in your `/src/` directory with a `Hello.vue` file in the `/components/` directory. This is really nice because you can see already how you’d set up these files, and how imports and exports might work.

Let’s go over this new `.vue` file extension for a moment, because if you haven’t worked with vue, you won’t have come across it before.

In your `.vue` file, you can place everything you need for your component. We no longer have to wrap our templates in , now we’ll more semantically create files that follow this logic:

<template>
  <div>
     <!-- Write your HTML with Vue in here -->	
  </div>
</template>

<script>
  export default {
     // Write your Vue component logic here
  }
</script>

<style scoped>
  /* Write your styles for the component in here */
</style>

I’ve made a repo of Vue snippets for Sublime Text to quickly spin up boilerplate like this for `.vue` files (this is what the snippet vbase would output). There’s also this one for atom, (though it specifies version 1+, and Vue is at v2), and this for vscode.

A few things to note here: just like in React, you have to return exactly one enclosing tag, here I’ve used a div. I’ve also used elements in SVG. It can be anything, but the entire template must be wrapped in the one tag.

You’ll see that we’ll use export default here to write our scripts such as the data function or methods we used previously, but if we were to use components as children in this `.vue` document, we would also have to import them (more on this in a minute).

You can also see that we have a special scoped value on the style tag. This allows us to very easily scope the styles for this component to only this component. We could also use just and it would create styles for the whole application. I typically like to create a base stylesheet for the whole application with common styles like fonts and line-heights, which I’ll @import into the tag of the App.vue file with the help of vue-style-loader. I’ll then use the tag for very particular styles for the template when it calls for it, but really to each their own on this one! The nice thing is that Vue-cli lets you decide how to organize it, and you don’t have to add any other dependencies or modules to scope our styles this way. *heart eyes*.

We spoke briefly about slots before, when we use slots in Vue components with the scoped style tags, they apply to the component that has the slots. This is so helpful, because you can switch out components and change the appearance out very easily. *heartier eyes*

I have to say that in terms of development workflow, working within each particular `.vue` file for my HTML, styles, and JS has been extraordinarily helpful. I love that things are separated enough to see each piece clearly, yet close enough together that I’m not context-shifting. It speeds up my development, and I’ve noticed that markup stays pretty semantic.

You also might notice that your syntax highlighter doesn’t automatically recognize `.vue` files, so I’ve installed this for Sublime Text.

Here is the most basic way of importing/exporting components into a file (vimport:c in vue-sublime snippets)

import New from './components/New.vue';

export default {
  components: {
    appNew: New
  }
}

For more of a real-life example, let’s look at a sample of that last wine-label demo we used, with the components separated out into their own templates:

App.vue:

<template>
  <div class="container">

  <main>
      <component :is="selected">
        <svg class="winebottle" aria-labelledby="title" xmlns="http://www.w3.org/2000/svg" viewBox="0 155 140 300">
          ...
      </svg>
      </component>
    </main>

    <aside>
      <h4>Name your Wine</h4>
      <input v-model="label" maxlength="18">
      <div class="button-row">
        <h4>Color</h4>
        <button @click="selected ='appBlack', labelColor = '#000000'">Black Label</button>
        <button @click="selected ='appWhite', labelColor = '#ffffff'">White Label</button>
        <input type="color" v-model="labelColor" defaultValue="#ff0000">
      </div>
    </aside>

  </div>
</template>

<script>
  import Black from './components/Black.vue'
  import White from './components/White.vue'
  ...
  export default {
      data: function () {
        return {
          selected: 'appBlack',
          label: 'Label Name',
          ...
        };
      },
      components: {
          appBlack: Black,
          appWhite: White,
          ...
      }
  }
</script>

<style>
  @import "./assets/style.css";
</style>

Black Component:

<template>
  <div>
    <slot></slot>
  </div>
</template>

<style scoped>
  .label {
    fill: black;
  }
  .bottle, .wine-text {
    fill: white;
  }
  .flor {
    fill: #ccc;
  }
  .bkimg {
    filter:url(#inverse)
  }
</style>

Note that I’m using the component here to style each slot differently, that’s a really nice way of working, but it’s only one way. There are endless ways you can compose your application with components, slots, and props. The code here also only shows a piece of what’s happening. I’ve made a repo for you to explore, having used Vue-cli from the start to construct this. I highly recommend using Vue-cli in tandem with reading this and building out some components and passing state with props in a simple manner, just to get accustomed to the workflow. It’s very intuitive and quick once you get past the initial setup!

Lifecycle Hooks

Before we talk about lifecycle hooks, we need to backtrack a little and talk about the virtual DOM I mentioned in the first article. I noted that Vue.js has a virtual DOM, but not really what it does.

When you work with something like jQuery, in essence you’re listening to the DOM, and changing things based on those updates. We end up spending a lot of time checking what the DOM is up to, and storing state there. In contrast, a virtual DOM is an abstract representation of a DOM, sort of like a copy, but in this case it will be our master copy. When we work with state the way we have been with Vue in these articles, we’re creating the state ourselves, and then observing when the state changes.

When a Vue instance updates, Vue will check to see if it’s different from what we had previously. If it is indeed different, it will call some of these lifecycle methods, and patch the actual DOM with changes. This is for efficiency, this way the DOM is only updating what it absolutely needs to.

The lifecycle hooks provide you a method so that you might trigger something precisely at different junctures of a component’s lifecycle. Components are mounted when we instantiate them, and in turn unmounted, for instance when we toggle them in a v-if/v-else statement.

Some of the hooks available to you are: beforeCreate, created, beforeMount, mounted, beforeUpdate, updated, activated, deactivated, beforeDestroy, and destroyed. The API docs do a good job of describing each if you’d like to dig in further. Here’s a small demo to show how some of them work (check the console):

const Child = {
  template: '#childarea',
  beforeCreate() {
    console.log("beforeCreate!");
  }, 
 ...
};

new Vue({
  el: '#app',
  data() {
    return {
      isShowing: false 
    }
  },
  methods: {
    toggleShow() {
      this.isShowing = !this.isShowing;
    }
  },
  components: {
    appChild: Child
  }
});

<div v-if="isShowing">
  <app-child></app-child>
</div>

See the Pen by Sarah Dransner.

Note that we use v-if here instead of v-show, as v-if will actually mount and unmount the component, while v-show will only toggle visibility (but it will remain mounted and stay in the DOM). Similarly, will not be mounted or unmounted, but rather become activated and deactivated- as the component remains mounted, but is not in use.

Just as the methods available on the component bind this automatically, lifecycle hooks also auto-bind to the instance so that you can use the component’s state, and methods. Again, you don’t have to console.log to find out what this refers to! *heartiest eyes* For this reason though, you shouldn’t use an arrow function on a lifecycle method, as it will return the parent instead of giving you nice binding out of the box.

In the following I’m moving a ton of elements when each component is initially mounted, so I’ll use the mounted hook to trigger the corresponding animation for each component. You may have to hit the rerun button in the bottom left corner to see the starting animation.

See the Pen Vue Weather Notifier by Sarah Drasner (@sdras) on CodePen.

 mounted() {
    let audio = new Audio('https://s3-us-west-2.amazonaws.com/s.cdpn.io/28963/rain.mp3'),
        tl = new TimelineMax();

    audio.play();
    tl.add("drops");

    //drops in
    tl.staggerFromTo("#droplet-groups g path", 0.3, {
      drawSVG: "0% -10%"
    }, {
      drawSVG: "100% 110%",
      repeat: 3,
      repeatDelay: 1,
      ease: Sine.easeIn
    }, 0.5, "drops");
 …
}

There are also beautiful and sophisticated and components that Vue offers and we use elsewhere in this demo, and we’ll cover these, and why and when to use each in the last post of the series on Animation.

---

Intro to Vue.js: Vue-cli and Lifecycle Hooks is a post from CSS-Tricks

AMP is wildly polarizing.

Huge tech companies evangelize for it. It has loads of tech partners and loads of publishers using it. Well-respected companies are building things for it.

There is also a ton of backlash. It’s too easy to break. It gives Google far too much control. It’s not entirely progressive enhancement friendly. Offline development is harder. The caching layer means clicking a link from Google search results shows the site without ever leaving google.com, which is concerning for any number of reasons, a small one being that it makes sharing the URL weird. That’s just a few. I’ve heard quite the laundry list of complaints.

On this episode of ShopTalk we discuss all things AMP with someone on the AMP team (and who’s own blog is entirely AMP) and an entrepreneur building a service around AMP. Do they wonder if AMP is helping or hurting the web? They do.

Direct Link to Article — Permalink

---

ShopTalk 248: AMP is a post from CSS-Tricks

When learning to write JavaScript without jQuery, I found posts like this (also on SitePoint) quite helpful to reference. Now we’re going through that again, in a way, with ES6 replacing some of what we used libraries to help with.

Direct Link to Article — Permalink

---

10 Lodash Features You Can Replace with ES6 is a post from CSS-Tricks

Ire Aderinokun:

There are 6 stages to the CRP –

1. Constructing the DOM Tree
2. Constructing the CSSOM Tree
3. Running JavaScript
4. Creating the Render Tree
5. Generating the Layout
6. Painting

I imagine if you’re really getting into performance work, you’ll want a firm understanding of this. There are lots of ways to block/delay parts of this process. The job of a perf nerd is to understand when and why that’s happening, evaluate if it’s necessary or not, and tweak things to get to that painting step as soon as possible.

I’m curious if this is generic enough that 100% of all rendering engines work 100% the same way, or if there are significant differences.

Direct Link to Article — Permalink

---

Understanding the Critical Rendering Path is a post from CSS-Tricks

Digital products will always need to be redesigned. Styles progress, hardware technologies advance, and development possibilities are ever-increasing. Just in the past year the potential for implementing microinteractions, and processor-intensive animations and graphics, has come along at a fair pace. Product teams are continuously looking to iterate and stay ahead of or pass the competition. This is ever important in furthering the design and development industries, and delivering to the consumer the very best product available.

The process of redesigning is not always so straightforward. There are times when teams and individuals have to decide whether to redesign from the ground up, or iterate on the current product. In this article we are going to look at both options and analyze just why redesigning from scratch should be avoided in the majority of cases.

Redesigning from scratch

To begin, redesigning from scratch should not always be avoided. On occasion, a company can inherit a product simply for the user base, domain name, or because they see the potential to completely re-engineer the product from the ground up, into something completely different.

One example of a product that completely redesigned from the ground up is Bebo. What was once a fast-growing social network has since become multiple new products as a result of complete redesigns. In its latest relaunch, it has been developed into a messaging app, somewhat reminiscent of Slack.

The issue with redesigning from scratch, is you pose the risk of alienating users. In certain cases, the product can have such underperforming design and UX, that it leaves this as the only appropriate course of action. The issue is when products are redesigned for little reason other than for change for its own sake.

It’s important to ask two questions when pondering this decision:

• Does my vision for the product clash considerably with the current design and framework?

• Is the current product posing multiple substantial design and UX issues for users?

If the answer to either is yes, then this may well be the most appropriate course.

If you believe a redesign may cause a loss of users, answering yes to either should override any worries you have of this being the case. Sometimes, and only sometimes, a small proportion of the existing user base who are entirely opposed to change has to be discounted in order to move the product forward. You just have to be sure you are truly moving the product forward with a complete redesign—there has to be clear underlying reasons such as above.

Redesigning in iterations

For most cases, this should be the route to take. By continuously iterating on a product, you avoid alienating the current user base by by slowly but surely introducing new UI and UX enhancements with each version. This is a lot easier to digest for users, and typically helps avoid having them move to competitors. It also allows for the removal of a feature if proven not to be effective or useful for new and existing users.

Redesigning in iterations can also often result in the best possible product. When you are constantly redesigning from the ground up, it eliminates the positive effects of stepwise refinement.

Take Google’s core search product, for example. I’d argue they have never redesigned completely, and instead continuously iterated over multiple decades. With Google, they have an incredibly complex product, but a simple interface, and have iterated upon this in small steps to the point now where the product is extremely refined, powerful, and easy to use.

Another such example is InVision. A few years ago, they could have completely wiped the design which was looking tired and outdated. Instead of building something new with the latest short-term style trends, they chose to iterate on the current version one step at a time with the outlook of creating one of the finest design industry tools. All the while, they kept existing users satisfied by not overhauling every feature and layout.

In the above examples, you can see just how the product has progressed from something very dated, to a cutting-edge, industry leading product design—all through continuous iterating on the features, layout, and styles.

This approach also excludes the issue of overhauling a design every time the design team or lead is changed. It provides a consistent approach over long periods of time, and avoids individual designs and styles making their mark at the users’ expense.

Next time you are working on a design, ask yourself: should I really redesign this product from scratch, or can we achieve better long-term results with stepwise refinement?

Amberlight 2: Create fantastic swirls, light trail images & animations – only $29!

Source

The problem is not as severe as it was several years ago. Nonetheless, even today, too many people are still surfing using an outdated browser. If your website is very up to date in terms of web standards, these people won’t be able to enjoy that. So, before they get angry at you, just give them a friendly notification that they are surfing on yesteryear’s tech.

Sorry, But Your Browser is Ancient.

Whistleblowers like “Outdated Browser” were everywhere a couple years ago. But none of them looked as good as the one that I’ll present to you today. “Outdated Browser” comes in many different languages, as a combination of JavaScript, and CSS. The tool is available for free on Github, under the MIT license, and is free of dependencies. Thus, you can use it as an independent solution.

The JavaScript’s compressed version only weighs about 3kb. The compressed CSS weighs 1kb. Different languages are included as HTML files. Each of these makes up about 0.3kb.

Using it is simple. You need the compressed JS, as well as the CSS, and the folder lang. All required files can be found in the download archive. Set up the package in your webspace, and integrate the files in the head (CSS), and body (JS) of your website, respectively. Right behind the opening body is were you place a Div with the ID outdated. This triggers the JavaScript.

The integration and activation of the solution only takes a few minutes. You could adjust the appearance, but as it’s already designed in modern flat style, it should already be handsome enough for the most application cases out of the box.

Now, if the page is accessed with a modern browser, nothing happens. If a user visits from an outdated browser, a header will give him a friendly notification that there’s a newer version for his browser. If the user clicks on the notification, the following, politically correct, overview will be displayed.

It’s important to know that the solution targets desktop browsers, and can only be used for those. Before you criticize that, you should ask yourself if there are outdated browsers on mobile devices. Not really, right? Okay, maybe if you’re still rocking Android 2.01, but if that’s the case, web usage is not your biggest problem anyway.

Outdated On All Levels

Those that take a closer look at the JavaScript and CSS will probably throw their hands up in despair. The code truly deserves the label outdated. However, the reason for that is simple, and logical. In order for “Outdated Browser” to work in old browsers, it has to be written for these old fellas. There’s no room for modern approaches.

“Outdated Browser” is a solution by the Portuguese design agency Buro, and is available for download and participation on Github. Users of self-hosted WordPress installations can directly use the tool as a plugin, making the integration easier. For the sake of completeness, I should mention that there are other ready-made modules, for Ruby, Drupal, Magento, Contao, and Yii2.