Archive

Author Archive

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:

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:

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:

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:

“Stop Using CSS Selectors for Non-CSS”

January 16th, 2018 No comments

I saw Nicole Dominguez tweet this the other day:

say it louder for the people in the backhttps://t.co/prDKo5QaZi

— nicole (@sodevious) January 11, 2018

I wasn’t at this conference, so I have very little context. Normally, I’d consider it a sin to weigh in on a subject brought up by looking at two out-of-context slides, but I’m only weighing in out of interest and to continue the conversation.

The idea seems to be that if you need to select an element in the DOM with JavaScript, don’t use the same selector as you would in CSS.

So if you have…

<article class="article">
</article>

…and you need to apply an event listener to that article for some reason, then don’t use…

$(".article")

(or querySelector or whatever, I assume.)

Instead, apply an attribute intended just for the JavaScript to target, like…

<article class="article" data-hoverable>
</article>

…and target that like…

$("[data-hoverable]")

The idea is that you can separate jobs. The class has the job of styling, and the data attribute has the job of JavaScripting. Both can change without affecting each other.

Seems reasonable to me.

Also seems like there is plenty to talk about here. Performance, I suppose, but that’s probably the least-interesting thing since selectors are generally pretty damn fast these days. We could continue the conversation by talking about:

  • What naming convention?
  • Should you be naming events?
  • What if it needs to be selected for different reasons multiple times?
  • Can you or should you use IDs?
  • Is it worth avoiding DOM selection at all if you can?
  • What other nuances are part of this discussion?

I saw Michael Scharnagl had some thoughts on his own usage of ID’s, classes, and data-attributes that could help frame things a bit.


“Stop Using CSS Selectors for Non-CSS” is a post from CSS-Tricks

Categories: Designing, Others Tags:

Creating a Vue.js Serverless Checkout Form: Setup and Testing

January 16th, 2018 No comments
Vue shop

There comes a time in any young app’s life when it will have to monetize. There are a number of ways to become profitable, but accepting cash is a surefire way to make this more direct. In this four-part tutorial, we’ll go over how to set up a serverless function, make it talk to the Stripe API, and connect it to a checkout form that is setup as a Vue application. This may sound daunting, but it’s actually pretty straightforward! Let’s dig in.

Article Series:

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

What is Serverless?

We’ve covered serverless concepts before but, in case you haven’t read that article, let’s talk for a minute about what we mean by “serverless” because it’s a bit of a misnomer.

The promise of serverless is to spend less time setting up and maintaining a server. You’re essentially letting the service handle maintenance and scaling for you, and you boil what you need down to functions that run certain code when a request is made. For this reason, people may refer to this as FaaS. This is really useful because you pay for what you use, rather than a large container that you might not need in its entirety. You also primarily hunker down and focus just on the code you need to run instead of babysitting a server, which really appeals to a lot of people who’d like to get up and running quickly.

But FaaS isn’t always the right tool for the job. It’s really useful for small executions but, if you have processes that might hold up resources or a ton of computation, being able to communicate with a server as you normally do might be more efficient.

What we’re going to make is a perfect use case for going serverless. Stripe checkouts are pretty seamless to integrate on both the client and server side, but we do actually need to execute some logic on the server, so we’ll use Azure to help us with this. The portal and Github integration are pretty quick to manipulate, as long as you know where to go. So by all means, let’s make it happen!

Sign up for Stripe

First, we’ll create a Stripe account. We verify our new account via email and then we’ll head over to the API section, where we can retrieve two keys. You’ll note that we’re in test mode right now, which is good! We’ll keep it like that for testing, and unveil the testing key token to use while we set up the application.

Once you’re signed in, go to the API section of your dashboard to retrieve your key.

Stripe testing dashboard
The Stripe API screen

You may also want to add a phone number to your account for 2 factor auth as well.

Setting up Our Serverless Function in the Azure Portal

First, we’ll head over to the portal, (or if you don’t already have an account, you can sign up for a free trial here) and select New > Serverless Function

New Function
Setting up a new Servless Function in Azure

When we click on the Serverless Function app, we’ll be taken to a panel that asks for details to help with the setup. As you can see in the screenshot above, it will autofill most of the fields just from the app name, but let’s go over some of these options quickly:

  • Add in a unique name
  • A Resource Group (if you don’t already have one, create one)
  • I use the Windows OS because the Linux is still in preview, so Windows will be more stable
  • I use the Consumption Plan because this is the one that will have payments that scale with the use, and it will also scale automatically. The other option, App Service Plan, is good for people who prefer everything to be a bit more manual.
  • Choose a location that is close to your customer base, or a midpoint between two customer bases
  • Choose a storage, or create one as I’ve done
  • I’ll also check Pin to Dashboard because I want to be able to retrieve my function quickly later
New function settings

This will bring you back to the main portal dashboard and let you know that your function is deploying. Once it’s done, it take you to a main screen that has all of your options. From here, we’ll want to create our function, and it will be an HTTP trigger.

We’ll select Functions under our function name, and you’ll see a little table with a plus that says “New Function”:

New Function in the Portal

Once we click here, we have a few options on what we can create. We’ll pick HTTP Trigger:

Choose HTTP Trigger

We’ll be able to select the language (pick “JavaScript”) and then “Create”:

Pick the Language and Create

The Default Testing Function

From here, we’re given a default testing function which helps us see how this all works. If we open all of these panels and hit the Run button, we’ll see the output in logs.

The initial testing output
Running the function in a test environment

Here’s the code we were given:

module.exports = function(context, req) {
  context.log('JavaScript HTTP trigger function processed a request.');

  if (req.query.name || (req.body && req.body.name)) {
    context.res = {
      // status: 200, /* Defaults to 200 */
      body: 'Hello ' + (req.query.name || req.body.name)
    };
  } else {
    context.res = {
      status: 400,
      body: 'Please pass a name on the query string or in the request body'
    };
  }
  context.done();
};

You’ll see here that we’re passing in the context. That allows us to log, which will be shown in the lowest panel below. In the Test panel on the right, we can pass in a request body that can be used to test our application. When it runs, we see the output with a 200 status and know that everything is working. We also have a context.log for the case that it gives us a 400 error. If you’d like to play around with a serverless function and see it in action for yourself, you can create one with a free trial account.

Next Up…

Now that we have the base of our serverless function, let’s set up what we’ll need to communicate with Stripe! More to come in the next post in this series.

Article Series:

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

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

Categories: Designing, Others Tags:

Should the Web Have a Universal Design System?

January 16th, 2018 No comments

Unlike mobile applications, the web has no set design guidelines to which a designer can refer. Instead, each web project tends to be a blank canvas. There are frameworks like Material, Bootstrap, and others which provide a base, but no set guidelines which span the web as a whole.

The result is a wide-ranging and diverse web, but one with a lack of cohesiveness, particularly in terms of user experience. Navigations differ in placement, structure, and overall design. Layouts alternate in width. Text sizes and typographic scales vary wildly. And a wide range of differing components, interactions, and user interface elements are used.

Design systems ensure consistency between apps, resulting in a more cohesive product

The lack of a set design system for the web is due to its open source nature, and lack of ownership. No company or organization has the power to enforce guidelines or standards. The closest anything or anyone comes to impacting the way we design is Google, who can affect your search rankings based on factors such as user experience, responsiveness, and code structure. On the other hand, mobile operating systems like iOS and Android have the power to enforce certain application structures, user experience practices, and standards. Design systems ensure consistency between apps, resulting in a more cohesive product, and one that is easier to use and understand for the end user. It also enhances performance and optimization, as well as accessibility.

Despite such a defined set of guidelines in both cases of iOS and Android, designers still find ways to differentiate through aspects like color, layout, and design details. In these circumstances it’s still entirely possible to achieve outstanding and unique designs which still fall within the guidelines.

Conversely, the web is an absolute blank canvas. There is the ability to take a design and user experience in any direction desired. On one hand, it’s what makes the web so attractive, diverse, and abundant. On the other hand, it can lead to a confusing experience for many people: one that is highly inaccessible, inconsistent, and uses a variety of sub-optimal and dark user experience practices.

The case of iOS and Android show just how rich and diverse a digital product or ecosystem can be, even under such regulation and moderately-strict guidelines.

This poses the question of whether a set of open source guidelines should be introduced for the entire web. Whether it comes from W3C, is a unified effort between major browsers, or is devised by a group of designers, it could improve the web for all. There would still be great scope for producing unique designs, while ensuring the web reaches much more acceptable levels of accessibility and usability as a whole. Designers and user experience professionals could contribute to this as an open source project, pushing forward the progress of the entire web.

It’s not just web applications this system should apply to. Whether it’s a blog, portfolio, landing page, or wiki, they are all still usable products. They still require important user experience considerations such as accessibility, navigation, color practices, and typography scales. Many companies consider such aspects, while many ignore them either through choice, misjudgement, or lack of consideration. It’s an area which is so fragmented under the current system, and does not work appropriately for everyone. That includes those with a disability, visual impairment, or lack of familiarity with computers and the web. These users should be designed for first.

As it stands, the primary consideration is often the design visuals: making something impressive, unique, and eye-catching. Often this desire to differentiate can lead to oversights with user experience, and design choices like unique navigation solutions which are confusing and unfamiliar to most.

Google is a prime example of a company who have developed a set of guidelines and applied them with absolute consistency across mobile and web. Whether you switch from Google Keep on iPhone, to Google Drive on the web, the user experience and design elements remain consistent. Then when switching between products on the web like Play Store or YouTube, it again remains consistent.

This ease of use and transition from one product or site to another should be a model to follow for others. It puts the user first, making for an entirely accessible and understandable experience. Google is beginning to take this even a step further, as they introduce Android apps and web-based equivalents that work at desktop size. With products like Chromebooks, it makes the transition between devices even more seamless.

The closer we can get to a cohesive design system across the web…the better it will be…for all parties involved

The closer we can get to a cohesive design system across the web as a whole, the better it will be in the long run, for all parties involved. This means having systems span much further than just one company.

IBM or Airbnb may perfect their design systems to the nth degree and apply them with excellent consistency. However, as soon as a user switches to another product or service, their design system is likely to be wholly different, from typography and layout, to navigational practices. That’s why it needs to be looked at as an issue from further afar. And apps are the closest example we have to how successful this can be as a means to improve the everyday lives of users.

Easily Whip Up Custom Videos for Your Brand with Videobolt – only $24!

Source

Categories: Designing, Others Tags:

Meet the New Dialog Element

January 15th, 2018 No comments

Keith Grant discusses how HTML 5.2 has introduced a peculiar new element: . This is an absolutely positioned and horizontally centered modal that appears on top of other content on a page. Keith looks at how to style this new element, the basic opening/closing functionality in JavaScript and, of course, the polyfills that we’ll need to get cross-browser support right.

Also, I had never heard of the ::backdrop pseudo element before. Thankfully the MDN documentation for this pseudo element digs into it a little bit more.

Direct Link to ArticlePermalink


Meet the New Dialog Element is a post from CSS-Tricks

Categories: Designing, Others Tags: