Archive

Archive for January, 2018

The Ultimate Guide to Headless CMS

January 18th, 2018 No comments

(This is a sponsored post.)

The World Has Changed—So Must the CMS

Having a responsive website is no longer enough. Your audience expects a seamless and personalized customer experience across all their devices—the age of headless technology is coming.

Headless CMS is the next generation in content management for brands that want to stay ahead of the curve by engaging customers through the growing number of channels.

Download The Ultimate Guide to Headless CMS ebook for a deep look into what headless CMS is, and why it should be at the top of your list when choosing a new CMS.

Download the ebook now!

Direct Link to ArticlePermalink


The Ultimate Guide to Headless CMS is a post from CSS-Tricks

Categories: Designing, Others Tags:

Get Ready for `display: contents;`

January 18th, 2018 No comments

Last year I asked, “Will we be flattening our HTML for CSS Grids?

The issue is that the only way for elements to participate in the same CSS grid together (or flexbox for that matter) is for them to be siblings. So, in some cases we might be incentivized to forego HTML semantics for the benefit of layout (not great).

One answer to this is display: contents;—a magical new display value that essentially makes the container disappear, making the child elements children of the element the next level up in the DOM.

Fast forward to today, Chrome is shipping it, WebKit is shipping it, and Firefox has shipped it. Vote for it in Edge here.

Wanna understand it better? Rachel Andrew wrote “Vanishing boxes with display contents” and clarifies how it all works:

This value becomes useful if you want to add some element because it makes sense in terms of document semantics, but doesn’t in terms of display. Perhaps you have some content that makes sense marked up as an article, that article is then a flex item in your layout BUT the elements you really would like to be flex items are nested inside that article. Rather than flattening your markup and remove the article element to enable these inner elements to be part of the flex layout, you could remove the boxes generated by article using display: contents. You then get the best of both worlds, semantic markup plus the visual display your design requires. That sounds good to me.

Manuel Rego takes a stab at explaining it as well:

display: contents makes that the div doesn’t generate any box, so its background, border and padding are not rendered. However the inherited properties like color and font have effect on the child (span element) as expected.

There is also a very related subject to all this: subgrids. Probably literally display: subgrid;. It’s probably less important in terms of maintaining semantics than display: contents; but also different.

Eric Meyer called subgrids essential:

Grid layout is the first serious candidate to fill that hole in the past two decades, and I don’t want to see them hamstrung from the outset. Subgrids are essential to the adoption of grids. I hope they’ll be implemented as soon as possible

And to understand the difference, Rachel Andrew also wrote “Why display: contents is not CSS Grid Layout subgrid“:

You won’t get far through a conversation about subgrid in CSS Grid Layout without someone suggesting that display: contents solves most of the problems anyway, so do we really need subgrid? This really isn’t the case, display: contents does indeed solve a class of problems, but these are different problems to those that subgrid would help us with.


Get Ready for `display: contents;` is a post from CSS-Tricks

Categories: Designing, Others Tags:

Creating a Vue.js Serverless Checkout Form: Application and Checkout Component

January 18th, 2018 No comments
birds eye view of the application structure

This is the third post in a four-part series. In part one, we set up a serverless Stripe function on Azure. Part two covered how we hosted the function on Github. This post will focus on wiring everything up as a Vue.js application.

Article Series:

  1. Setup and Testing
  2. Stripe Function and Hosting
  3. Application and Checkout Component (This Post)
  4. Configure the Checkout Component (Coming Soon)

Stripe has a number of ways to build out a checkout form, the most basic being a single button on the page that you trigger to pull up their custom modal. There’s a repo and component for this, but as easy as that is to implement (it’s probably the most simple way to do it), I wanted a little more customization and wanted the checkout flow to be part of the page and application. This approach wouldn’t work for my needs.

Stripe Elements

Stripe also offers a thing called Elements. Elements allow you to integrate Stripe’s payment system into your own checkout form and style it like your own site for a cohesive experience. It won’t feel like you’re using a third party plugin. They do have some pre-styled examples if you prefer something you can use right out of the box.

Luckily for us, there’s a really nice repo with a Vue version of Stripe Elements called vue-stripe-elements. The repo’s documentation is really nice, so you could check that out. Here’s how I put it to use:

npm i vue-stripe-elements-plus --save

…or using Yarn:

yarn add vue-stripe-elements-plus

Now let’s talk about our cart and integrate it.

The Cart

Here’s what everything looks like as a birds eye view of the application. We’ve already addressed the function and stripe pieces, now let’s dig into the application itself.

birds eye view of the application structure

We’re not going to go through setting up the entire application in these posts, rather just the Cart and Checkout. I’d suggest checking out the following links before continuing if you need to catch up on the basics of Vue, Vuex, and Nuxt:

In our general store set up with Vuex, we hold a manifest of all of our product data used to populate the pages with items. We’ll also use that information to populate a (currently empty) cart object where items can be added for purchase. We’ll use that data on a page called `Cart.vue` in the pages directory. If you’re unfamiliar with Nuxt.js, it allows us to use .vue components as pages by creating them in this pages directory. We can still populate these pages with components from the components directory to create a more modular application. Here are the parts we’re discussing now:

Showing we're discussing cart.vue and vuex in the application

We’ll need two pieces of information from that store in Vuex: the contents of the cart and the cartTotal.

We’ll use computed properties in pages/Cart.vue to fetch that information so that we can cache and use them in the cart.

computed: {
  cart() {
    return this.$store.state.cart;
  },
  cartTotal() {
    return this.$store.state.cartTotal;
  },
  ...
}

…and we’ll create a new computed property that will store the monetary total of the items in the cart as well:

computed: {
  ...
  total() {
    return Object.values(this.cart)
      .reduce((acc, el) => acc + (el.count * el.price), 0)
      .toFixed(2);
   }
}

The first thing that we’ll do is see if the cart has items in it. If it does, then we need to check that the payment hasn’t already been processed. We need to do this because there’s no need to display a checkout form if there are no items in the cart or if payment has already been processed for the items that were added.

<div v-if="cartTotal > 0">
  <!--we'll add our checkout here-->
</div>

<!--If the cart is empty, give them the ability to get back to the main page to add items-->
<div v-else-if="cartTotal === 0 && success === false" class="empty">
  <!--we'll add our empty state here-->
</div>

<!--If there's a success, let's let people know it's being processed, we'll add a success component later on-->
<div v-else>
  <!--we'll add success here-->
</div>

We’ll also create a success property in our data that we’ll initially set to false and use later to record whether or not a payment was successfully submitted.

data() {
  return {
    success: false
  };
},

We want to show cart items if they exist, their individual totals (as we can have multiple counts of the same item) and the final total.

<div v-if="cartTotal > 0">
  <h1>Cart</h1>
  
  <div class="cartitems"
    v-for="item in cart"
    key="item">
    <div class="carttext">
      <h4>{{ item.name }}</h4>
      <p>{{ item.price | usdollar }} x {{ item.count }}</p>
      <p>Total for this item: <strong>{{ item.price * item.count }}</strong></p>
    </div>
    <img class="cartimg" :src="`/${item.img}`" :alt="`Image of ${item.name}`">
  </div>

  <div class="total">
    <h3>Total: {{ total | usdollar }}</h3>
  </div>

  <!--we're going to add our checkout here-->
</div>

We’re using a filter to format the prices in US dollars. I format them this way instead of hardcoding them in case I need to support other currencies in the future.

filters: {
  usdollar: function(value) {
    return `$${value}`;
  }
}

Setting up the Checkout Component

Now we’re going to create our checkout component, which will hold all of the Stripe checkout logic and connect to the serverless function we set up in Part Two. We’ll register the component in the Cart.vue file:

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

export default {
  components: {
    AppCheckout
  },
  ...
}

Here’s where we’re at now:

Showing the Cart.vue in pages, as well as the checkout component

And, in the checkout component itself, we’ll bring over the base for the file that we saw in the vue-stripe-elements repo documentation:

<template>
  <div id='app'>
    <h1>Please give us your payment details:</h1>
    <card class='stripe-card'
      :class='{ complete }'
      stripe='pk_test_XXXXXXXXXXXXXXXXXXXXXXXX'
      :options='stripeOptions'
      @change='complete = $event.complete'
    />
    <button class='pay-with-stripe' @click='pay' :disabled='!complete'>Pay with credit card</button>
  </div>
</template>
<script>
import { stripeKey, stripeOptions } from './stripeConfig.json'
import { Card, createToken } from 'vue-stripe-elements-plus'

export default {
  data () {
    return {
      complete: false,
      stripeOptions: {
        // see https://stripe.com/docs/stripe.js#element-options for details
      }
    }
  },

  components: { Card },

  methods: {
    pay () {
      // createToken returns a Promise which resolves in a result object with
      // either a token or an error key.
      // See https://stripe.com/docs/api#tokens for the token object.
      // See https://stripe.com/docs/api#errors for the error object.
      // More general https://stripe.com/docs/stripe.js#stripe-create-token.
      createToken().then(data => console.log(data.token))
    }
  }
}
</script>

Next Up…

So far, this is what the component looks like out of the box. We’re going to have to update this component a bit to fit our needs, but not too much. Stay tuned tomorrow for the final installment when we connect our component to our serverless function and finish up the checkout!

Article Series:

  1. Setup and Testing
  2. Stripe Function and Hosting
  3. Application and Checkout Component (This Post)
  4. Configure the Checkout Component (Coming Soon)

Creating a Vue.js Serverless Checkout Form: Application and Checkout Component is a post from CSS-Tricks

Categories: Designing, Others Tags:

Learning Elm From A Drum Sequencer (Part 2)

January 18th, 2018 No comments

In part one of this two-part article, we began building a drum sequencer in Elm. We learned the syntax, how to read and write type-annotations to ensure our functions can interact with one another, and the Elm Architecture, the pattern in which all Elm programs are designed.
In this conclusion, we’ll work through large refactors by relying on the Elm compiler, and set up recurring events that interact with JavaScript to trigger drum samples.

Categories: Others Tags:

The Freelancer’s Guide to Success and Happiness

January 18th, 2018 No comments

In 2016, 34% of the US workforce worked as freelancers, and by 2020, it’s estimated that number will rise to 43%. Freelance opportunities aren’t going anywhere, and more professionals are swapping in their office key cards for a home office.

While the idea of sitting around in sweatpants or relaxing on a beach while working sounds like perfection, freelancing isn’t always a walk in the park. From juggling business responsibilities and invoices to finding your next gig, freelancing comes with its issues. Despite these challenges, a few tips can help you find success and happiness in your career.

1. Believe in Your Worth

Particularly when you’re new to freelancing, it can be intimidating to set your fee. While some projects or jobs may entail negotiation, it’s best to set your rates and stick to them. Depending on your niche, you may work on an hourly rate or quote per project. Set a rate that’s on trend with your industry rather than settle. While you may find more gigs when charging less than the industry average, you’ll experience more stress trying to juggle enough projects to meet your income goals.

2. Network Even When You’re Not Seeking Work

Networking is the lifeblood of freelancing; it’s necessary to keep your business alive. Even when you have contracts, freelancing jobs can be unpredictable. You may have ten small projects one month and three ongoing projects another month.

Finding yourself low on projects can be stressful to your mental health and your wallet. Keep networking with other professionals, freelancers, and potential employers even with plenty of projects on your plate. This effort makes it easier to find a job when you’re looking for your next gig.

3. Hire an Accountant

If you make a single business investment, hire an accountant. Unlike W-2 employees, who have a portion of taxes paid by their employers, freelancers have to cover all of their own taxes and manage their own expenses.

During tax season, it can be confusing and overwhelming to determine the tax credits for which you qualify and what taxes you owe. Working with an accountant not only makes it easier to track expenses and save on taxes but also gives you clearer insight into how much you’re earning after taxes.

4. Set a Schedule and Stick to It

Working the standard nine-to-five Monday through Friday can feel restrictive, but businesses are onto something when they adhere to a consistent schedule. Whether you prefer to work late at night or early in the morning, set a regular schedule for your work week, including the days and hours you’ll work. Aim to schedule four days of work and one day for handling administrative tasks, such as following up on emails, taking care of bills and invoices, and networking. A regular schedule helps you get into a work mindset each time you start your day.

5. Don’t Skimp on Business Necessities

Working as a freelancer means wearing a business-owner hat too. While it’s tempting to cut back on costs wherever you can, it’s worth investing in the tools you need to do your work efficiently. One service you should never skimp on is a reliable high-speed internet connection for communicating with employers and completing projects. Take the time to find the fastest internet in your area and calculate your bandwidth needs based on the type of work you do. With a fast connection, you can complete your work faster and avoid the frustrations of lag.

6. Don’t Be Afraid to Say “No”

When you determine your income, it’s easy to make the mistake of taking on too much work. If you’re tempted to take on another project for the additional income, consider the cons: additional stress and less time to decompress. Don’t risk your mental health for a bump in pay. Before agreeing to any new project, look to see if it will realistically fit into your schedule. If it won’t, turn it down or explain what deadline would work for you.

Working as a freelancer is an exciting career move, offering independence and opportunities to challenge yourself and enhance your skills. While freelancing isn’t the easiest gig, following these helpful tips can help you find happiness and success in your career.

1800+ Unique Hi-Res Patterns from Animals to Donuts – only $9!

Source

Categories: Designing, Others Tags:

33 Bold Fonts for Your Flyers, Posters, and Brochures

January 18th, 2018 No comments

As a designer, you can never have too many fonts. The projects are way too diverse, and the supply is massive: this makes it easy to always use new fonts. Handwritten, more rough fonts have been the center of attention in the past months, but classic sans serif and modern, yet bold fonts are in demand as well.

While we already checked if the fonts are also free to use for commercial use, you should still always double check that yourself. When in doubt, ask the originator.

Enjoy these 33 high-quality turnkey fonts.

Accent

License: free for commercial and private use

Berg

License: free for commercial and private use

Font

Rise

License: free for commercial and private use

Font

Sophia

License: free for commercial and private use

Font

Carosello

License: free for commercial and private use

Font

Glamor

License: free for commercial and private use

Font

Streetwear

License: free for commercial and private use

Font

Polya

License: free for private use

Font

Break

License: free for private use

Font

Debby

License: free for commercial and private use

Font

Adam

License: free for private use

Font

Farray

License: free for private use

Font

Aventura

License: free for commercial and private use

Font

Cornerstone

License: free for private use

Font

Peace Sans

License: free for commercial and private use

Font

Moon

License: free for private use

Font

Lemon Bird

License: free for commercial and private use

Font

Alcubierre

License: free for private use

Font

Smoothie Shoppe

License: free for private use

Font

Majestic Inline Grunge

License: free for private use

Font

Pea Soup

License: free for commercial and private use

Font

Kidzonia

License: free for private use

Font

Quick Caps

License: free for private use

Font

Brux

License: free for commercial and private use

Font

Shkoder

License: free for private use

Font

Gothic Modern

License: free for private use

Font

Muller Narrow

License: free for private use

Font

Carraway

License: free for commercial and private use

Font

Humblle Rought

License: free for private use

Font

Westfalia

License: free for commercial and private use

Font

Just Smile

License: free for commercial and private use

Font

Giraffey

License: free for private use

Font

Moderne Sans

License: free for commercial and private use

Font

Categories: Others Tags:

Creating a Vue.js Serverless Checkout Form: Stripe Function and Hosting

January 17th, 2018 No comments
actual function with testing request body params

We’re now in the second post of a four-part series where we’re creating a checkout form application in Vue.js that can accept payments via the Stripe API. In part one, we looked at the concept of serverless functions, set one up in Azure, and connected it to a Stripe account. In this post, we’ll focus on setting up Stripe as a serverless function and hosting it all on Github.

Article Series:

  1. Setup and Testing
  2. Stripe Function and Hosting (This Post)
  3. Application and Checkout Component (Coming Soon)
  4. Configure the Checkout Component (Coming Soon)

First, we’re going write our function and test it out in the portal, but eventually we’re going to move it over to Github and have Azure pull in the code. I’ll explain why we do this in a moment.

For now, in order to get it working and testable, we’re going to write it in the portal and fill in the request body to perform the test. But we need to know what Stripe will expect from us first.

Dun dun dun…

Working With Stripe as a Serverless Function

If you check out Stripe’s documentation, you can see that we’ll need to grab the Stripe token in the dashboard. This will eventually mirror the POST parameters submitted by our form. Stripe makes it easy, so it’s fairly straightforward to use their library for the server-side function with Express:

app.get('/', (req, res) => res.render('index.pug', { keyPublishable }));

app.post('/charge', (req, res) => {
  let amount = 500;

  stripe.customers
    .create({
      email: req.body.stripeEmail,
      source: req.body.stripeToken
    })
    .then(customer =>
      stripe.charges.create({
        amount,
        description: 'Sample Charge',
        currency: 'usd',
        customer: customer.id
      })
    )
    .then(charge => res.render('charge.pug'));
});

app.listen(4567);

We won’t need to set up all of Node and Express for this, though, as what we really need is the amount, the currency, the description, and the token, which we can integrate with the testing code we were provided earlier in the portal’s view of our function. So, let’s head over to the Azure portal where our function lives and update that default testing code to accept the parameters we need for Stripe, and also populate the request.body in the test panel.

We’ll add our Stripe testing key and kick everything off. To be totally sure, we’re going to log what we’ve gotten started:

var stripe = require('stripe')('sk_test_whateveryourtestingkeyisgoeshere');
// ^ this is a stripe testing key

module.exports = function(context, req) {
  context.log('starting to get down');

If we have a request body, an email, and a token, then let’s get started. We’ll create a customer from the email and then use that customer to create the Stripe charges, passing in the amount of the charge as we do so.

if (
  req.body &&
  req.body.stripeEmail &&
  req.body.stripeToken &&
  req.body.stripeAmt
){
  stripe.customers
    .create({
      email: req.body.stripeEmail,
      source: req.body.stripeToken
    })
    .then(customer => {
      context.log('starting the stripe charges');
      stripe.charges.create({
        amount: req.body.stripeAmt,
        description: 'Sample Charge',
        currency: 'usd',
        customer: customer.id
      });
    })
      ...

We also want to test if this all completed successfully, or if it errored out. If it did error, we need to log what that error is. We’ll also see if the whole thing errored entirely, making sure we’re logging everything appropriately along the way.

You’ll note that I log a lot. I think it’s not enough to know that something has errored. I want to know when the error happened and why so that I can track it down. This makes it much easier to debug if something were to go wrong.

      ...
      .then(charge => {
        context.log('finished the stripe charges');
        context.res = {
          // status: 200
          body: 'This has been completed'
        };
        context.done();
      })
      .catch(err => {
        context.log(err);
        context.done();
      });
  } else {
    context.log(req.body);
    context.res = {
      status: 400,
      body: "We're missing something"
    };
    context.done();
  }
};

In the testing area on the right side of the portal, we’ll fill the request.body with the stripeEmail, stripeToken (a testing token in this case), and some random amount for the charge. When we run this, we can see that it works! We get a 200 OK Status, and we’ve logged This has been completed in the output.

actual function with testing request body params
Testing the request body parameters with the actual function in Azure.

Github-Hosted Serverless Function

Let’s put everything in Github now that it’s working. One big reason we want to do this is because our function will have a dependency on Stripe’s library. If you head over to the sample-stripe-handler repo I’ve created for this tutorial, you’ll see a package.json file. The most important lines in that file are these:

"dependencies": {
  "stripe": "^5.3.0"
}

This tells the function to pull in the correct version of the Stripe API that we need to use in order for our app to properly function. As a note, you could also use this method to write other kinds of functions using other libraries. This means the possibilities for what to create are endless!

We’ll pull everything from our function into this repo. This includes the function itself, the package.json file, as well as the contents of the function.json file that you’ll see in the “View Files” tab on the right in the Azure portal.

Once we have that all in ready to go in a Github repo, we’ll head back over to the Azure portal, because now we have to let Azure know that we’d like to use this repo to host our function instead of our test. We can still test our function inside the portal—we just won’t be able to edit it via the GUI anymore.

Click on the “Platform Features” tab and select the “Deployment Options” item.

Azure Portal Deployment Options

From here, click “Settings” then “Choose source” and a number of options will be provided. I’m going to choose Github because that’s where I want to host mine, but you can see that there are a lot of other ways we could have done this.

Choose github
Deployment settings source options, including Github.

Once Github has been selected, you will be able to configure which repo you would like to use as your deployment source. I chose the sample-stripe-handler repo that we created earlier.

Choose github repo for deployment option
Configuring Github as the deployment source.

After we’ve done this and it’s loaded, you’ll be taken to a “Deployments” screen that shows the last commit that you made to the repo. That means everything’s working correctly!

first deploy

Let’s test this a little further. My function didn’t work properly the first time because I was using ES6. I could have added in Babel, but I just converted it back to ES5 and pushed to the master branch. You can see the function.json becomes inactive as the last deployment, and my latest commit message—which is mostly me grumbling—is now the latest deploy! Awesome.

New deployment working

We can’t be too careful so, to check that these tests did indeed work, I’m going to head over to the Stripe dashboard. Sure enough, there are testing charges showing up in our dashboard ?

Stripe dashboard with a little activity

One last thing!

We would be remiss to exclude our good friend CORS, which we need to properly enable for everything to communicate as it should. Let’s go to our function in the dashboard, and select CORS:

select cors

In the prompt that appears, we’ll whitelist our localhost dev server, as well as our final URL for the site. Voila! We’re all set.

whitelist localhost

Next Up…

We got a lot done in this post! Next, we’ll want to learn how to move away from testing only within the function and get this sucker communicating freely with a checkout experience that we’ll build within a Vue.js application. Stay tuned!

Article Series:

  1. Setup and Testing
  2. Stripe Function and Hosting (This Post)
  3. Application and Checkout Component (Coming Soon)
  4. Configure the Checkout Component (Coming Soon)

Creating a Vue.js Serverless Checkout Form: Stripe Function and Hosting is a post from CSS-Tricks

Categories: Designing, Others Tags:

Understanding And Using REST APIs

January 17th, 2018 No comments

There’s a high chance you came across the term “REST API” if you’ve thought about getting data from another source on the internet, such as Twitter or Github. But what is a REST API? What can it do for you? How do you use it?
In this article, you’ll learn everything you need to know about REST APIs to be able to read API documentations and use them effectively.

Categories: Others Tags:

8 Sites That Work Just Fine Without JS, Thank You

January 17th, 2018 No comments

Gather ’round, ladies, gents, and children. Lo, before your very eyes, we shall reveal several freaks of the Internet! Behold! Websites that don’t need JavaScript to display their god-given content!

Oh, you think I’m kidding? Websites that are presented by plain old HTML and CSS are becoming increasingly rare. At this juncture, I don’t know who to blame, and is it really worth blaming anybody? I could point finger at whomever or whatever I think is to blame, or I could point fingers at creative and sometimes large websites that do it right!

Now, what do I mean about “doing it right”? Some of these sites, you might notice, do implement some things with JavaScript. But here’s the secret: if you turn JavaScript off, these sites still work just fine. The content doesn’t just disappear. The JavaScript effects and features have fallbacks! Sites are progressively enhanced, or they degrade gracefully.

Either way: they work. And they’re kind of hard to find, these days.

1. Amazon

You might expect a site with as much information present on any given page as Amazon has to use a mountain of JavaScript to, in some way, organize it more efficiently. Not so. Turn off the JS, and you can buy stuff just fine.

2. The Warren Trust

The Warren Trust is another one that degrades quite gracefully. With JS on, the site uses AJAX techniques to load content from other pages without technically leaving the home page. Turn off the JS, and it won’t work quite like it does with the JS on, but it does work. You can still see every page, but, you know, on its own page.

3. Stuff & Nonsense

Stuff & Nonsense was created by known and self-admitted web designer Andy Clarke. So yeah, it work with and without JS just fine. It’s a lovely example of a site that (mostly) works perfectly fine either way.

The only thing that doesn’t work when JS is turned off is the audio player. That is kind of to be expected, really. I can’t take many points away for that.

4. Mike Mai

Mike Mai’s site is proof enough that your site can be plenty creative—if a little odd in this case—with or without scripting. And I do mean “odd”, and I really do mean “little”.

It may not be the poster-site for visual accessibility, but it does show what kind of things can be accomplished in plain old HTML and CSS by those just crazy enough to try it.

5. Solace House

Solace House is a sobering example of a site that absolutely needs to work any time, under any circumstance, no matter which technologies are or aren’t working. It’s a suicide prevention center, after all.

You might be able to argue that your target demographic should just have JavaScript enabled at all times in some circumstances, but there are some services that are just too vital to ever leave to chance.

6. Twitter

Yeah, that Twitter. It was while researching this article that I found out Twitter works well enough without JavaScript. Well, their solution is a bit convoluted, perhaps, but it’s effective.

In short, Twitter will actually redirect you to a pared-down, mobile version of Twitter. It’s fully functional, except for features like feeds that update live, and so on. Who says social media needs JavaScript?

Truth be told, Twitter never felt faster.

7. Slack

You might need JavaScript to actually run a Slack chatroom, but the rest of the client-facing site looks and works just fine. It even has a condition in the URL for no JavaScript. And when you need to enable JS to make things run, they tell you! They actually tell you!

No seriously, it’s a thing that lots of sites would rather let you stare at a blank page than even say, “Woops! Looks like the JS broke, or you need to enable it.” I dislike this thing.

8. WebdesignerDepot

No, seriously, try it out. You’ll see a few visual downgrades, but everything essential looks fine, and works well. This is what it’s all about, people!

I’d love to take some credit for that, but I just write here on occasion. I guess this is my official letter of congratulations to the designer!

In Conclusion

I just wanted to show people what could be done. That’s it. I’m not saying you should ditch JS entirely, but I do believe that we should be a lot more considered about what we do and don’t implement in JavaScript.

Look at the sites I’ve listed here. Look at your own. For every thing you implement with a script, ask yourself if you really, really need to make it a script. For that matter, do you really need HTML?

Okay, okay. That’s going way too far.

Mac Photo Enhancement Tool Bundle: Noiseless & Intensify – only $34!

Source

Categories: Designing, Others Tags:

A Comprehensive Guide To UX Research

January 17th, 2018 No comments

(This is a sponsored article.) Before embarking upon the design phase of any project, it’s critical to undertake some research so that the decisions you make are undertaken from an informed position. In this third article of my series for Adobe XD, I’ll be focusing on the importance of undertaking user research.
Your job title might not be “design researcher”, but that doesn’t mean you shouldn’t at the very least inform yourself of your users and their needs by undertaking at least some initial scoping research before you embark upon a project.

Categories: Others Tags: