Andy Adams released a book for aspiring WordPress freelancers. It’s meant to take a lot of the guesswork and the roadblocks that many folks often hit when making the decision to fly solo and rely on WordPress development for a stable source of work and income.

Aside from being included in it (and Andy being an all-around great guy), I want to share the book with y’all because WordPress and freelancing are two topics I care deeply about, particularly because the WordPress platform and community helped me crack into freelancing when I made that decision five years ago.

What I’ve seen over the years is a delta between what is perceived about WordPress freelancing and the actual reality of it. Sure, all you need is a computer, a text editor and a free download of WordPress to get started. That’s the easy part, but there’s much, much more that’s worth considering. Finding clients is hard. Managing those clients is hard. Pricing work is hard. Proposals are hard. Taking time off is hard. These are among the things Andy covers in the book and the advice he provides is something that will benefit anyone breaking into freelance work.

Direct Link to Article — Permalink

The post Successful WordPress Freelancing appeared first on CSS-Tricks.

React 16.6.0 was released October 2018 and with it came goodies that spice up the way we can develop with React. We’re going to cover what I consider the best of those new goodies with examples of how we can put them to use in our work.

React.memo() avoids unnecessary re-rendering

There are situations where a component re-renders, even if neither its state nor its props changed. That adds up and can be an expensive operation.

Here’s an example of a counter to show what we’re talking about:

See the Pen
React counter w/o React.memo() by CSS-Tricks (@css-tricks)
on CodePen.

We have a child component that receives a specific value as props that do not change.

const Child = props => {
  console.log("rendered");
  return <React.Fragment>{props.name}</React.Fragment>;
}

The child’s value is determined by the state of the App component. It’s state doesn’t change. It’s props remain the same.

class App extends React.Component {
  state = {
    count: 1,
    name: "Jioke"
  };

  handleClick = () => {
    this.setState({
      count: this.state.count + 1
    });
  };

  render() {
    return (
      <React.Fragment>
        <Child name={this.state.name} />
        <div>{this.state.count}</div>
        <button onClick={this.handleClick}>+</button>
      </React.Fragment>
    );
  }
}

Yet, each button click results in two things happening: the value of count is incremented and the child component is re-rendered. Just watch:

We could resolve this with a class component using the shouldComponentUpdate() lifecycle hook, which would look like this:

class Child extends React.Component {
  
  // No re-render, please!
  shouldComponentUpdate(nextProps, nextState) {
    return nextProps.name != this.props.name
  }
  
  render() {
    console.log('rendered')
    return <React.Fragment>{this.props.name}</React.Fragment>
  }
}

That’s where React.memo() comes into play. It’s a higher-order component we can wrap around the child and, presto, now the child is shielded from unnecessary additional rendering.

const Child = React.memo(props => {
  console.log("rendered");
  return <React.Fragment>{props.name}</React.Fragment>;
});

See the Pen
React.memo 2 by CSS-Tricks (@css-tricks)
on CodePen.

React.lazy() makes importing files a breeze while Suspense provides a fallback UI

Code splitting is crucial in web development—it enables us to import only the files we, which is not only reduces an application’s initial load, but is a core principle of the React framework.

Well, React now enables code splitting using React.lazy() and suspense right at the component level.

By default, if making use of a component (even if its usage depends on a condition), then we import it into the file where you will be using it. React.lazy() can now handle the importation like this:

const MyCounter = lazy(() => import("./Counter"));

This single line returns a promise that resolves to the imported component. From here, we can use the component as we normally would.

const App = () => (
  <div>
    <MyCounter />
  </div>
);

There are cases where we might want to render a fallback UI before the component is ready to render. For example, it might take a moment for an API call to fetch and return data. This is a great opportunity to show a loading state while the user waits. Suspense can do just that.

// Using React.lazy() to import the Counter component
const MyCounter = lazy(() => import("./Counter"));
const App = () => (
  <div>
    // Using Suspense to render a loading state while we wait for the Counter
    <Suspense fallback={<div>Loading...</div>}>
      <MyCounter />
    </Suspense>
  </div>
);

Suspense’s fallback prop can accept a React element, so go nuts. It can be used to display whatever fallback UI we want while the component loads.

contextType accesses provider context and passes state without render props

The Context API made it possible to share state among multiple components without having to make use of a third-party library.

Well, React 16.6 makes it possible to declare contextType in a component to access the context from a provider. This saves us from having to make use of render props to pass down context to the consumer.

See the Pen
React contextType by CSS-Tricks (@css-tricks)
on CodePen.

First, let’s create our context:

const UserContext = React.createContext({});

const UserProvider = UserContext.Provider;
const UserConsumer = UserContext.Consumer;

We’ll make use of the provider in the App component:

class App extends React.Component {
  state = {
    input: "",
    name: 'John Doe'
  };

  handleInputChange = event => {
    event.preventDefault();
    this.setState({ input: event.target.value });
  };

  handleSubmit = event => {
    event.preventDefault();
    this.setState({ name: this.state.input, input: '' })
  };
  render() {
    return (
      <div>
        <UserProvider
          value={{
            state: this.state,
            actions: {
              handleSubmit: this.handleSubmit,
              handleInputChange: this.handleInputChange
            }
          }}
        >
          <User />
        </UserProvider>
      </div>
    );
  }
}

The provider passes the state and the methods to consumer components that will make use of them via the value prop. To access the context, we’ll make use of this.context instead of making render props like we normally would.

class User extends React.Component {
  static contextType = UserContext;
  render() {
    const { state, actions } = this.context;
    return (
      <div>
        <div>
          <h2>Hello, {state.name}!</h2>
        </div>
        <div>
          <div>
            <input
              type="text"
              value={state.input}
              placeholder="Name"
              onChange={actions.handleInputChange}
            />
          </div>
          <div>
            <button onClick={actions.handleSubmit}>Submit</button>
          </div>
        </div>
      </div>
    );
  }
}

We set static contextType to UserContext which we created earlier. With that, we are able to extract the context which includes the state and methods from this.context. We make use of ES6 destructuring to get the values so we can make use of them in the User component, which is the consumer. This looks so much cleaner and is easier to read compared to doing this with render props.

getDerivedStateFromErrors()

We have error boundary to handle errors, which makes use of componentDidCatch() and that gets fired after the DOM has been updated. It’s well suited for error reporting. But now we have getDerivedStateFromErrors() to render a fallback UI before the render completes if an error is caught. Sort of the same concept as Suspense, but for error states instead of loading states.

See the Pen
React getDerivedStateFromError by CSS-Tricks (@css-tricks)
on CodePen.

Let’s create our error boundary component to capture the moment something goes awry:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      hasError: false
    };
  }
  
  // If hasError is true, then trigger the fallback UI
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }
  
  // The fallback UI
  render() {
    if (this.state.hasError) {
      return (
        <h1>Oops, something went wrong :(</h1>
      );
    }
    return this.props.children;
  }
}

We make use of getDerivedStateFromError() to spot that an error was caught by the error boundary and then return hasError as true when an error occurs. When this happens, we want to display a message to inform the user that an error has encountered.

class Counter extends React.Component {
  state = {
    count: 1
  }

  handleClick = () => {
    this.setState({
      count: this.state.count + 1
    })
  }

  // If the count is greater than 5, throw an error
  render() {
    if (this.state.count > 5) {
      throw new Error('Error')
    }
    return (
      <div>
        <h2>{this.state.count}</h2>
        <button onClick={this.handleClick}>+</button>
      </div>
    )
  }
}

That’s going to trigger an error when the value of count is greater than five. Next, we need to wrap our Counter component as a child of ErrorBoundary component to apply the error conditions to the component:

const App = () => (
  <div>
    // Wrap the component in the ErrorBoundary to attach the error conditions and UI
    <ErrorBoundary>
      <Counter />
    </ErrorBoundary>
  </div>
)

We can even limit the error to the specific piece that is broken. So, for example, let’s take a listing of locations. Instead swapping the entire list of locations for the error UI, we can slap it at the specific location where the error happened.

See the Pen
React getDerivedStateFromError 1 by Kingsley Silas Chijioke (@kinsomicrote)
on CodePen.

Pretty nice, right?

React continues to add a bunch of useful features while making it easier to write code with each release and v16.6 is no exception. If you’ve already started using any of the latest goodies that shipped in this release, please let me—I’d be interested in seeing how you’re using them in a real project.

More Information

• React v16.6 Release Notes
• React.memo() Documentation
• React.lazy Documentation
• static contextType Documentation
• static getDerivedStateFromError() Documentation

The post React 16.6.0 Goodies appeared first on CSS-Tricks.

Designing Emotional Interfaces Of The Future

Gleb Kuznetsov

2019-01-23T13:00:12+01:002019-01-23T13:58:59+00:00

Emotions play a vital role in our decision-making process. One second of emotion can change the whole reality for people engaging with a product.

Humans are an emotionally driven species; we choose certain products not because of what makes sense, but because of how we think they will make us feel. The interfaces of the future will use the concept of emotions within the foundation of product design. The experiences that people use will be based both on intellectual quotient (IQ) and emotional quotient (EQ).

This article is my attempt to look into the future and see what interfaces we will design in the next ten years. We’ll be taking a closer look at the three mediums for interaction:

1. Voice
2. Augmented Reality (AR)
3. Virtual Reality (VR)

Developing For Virtual Reality

It’s not that difficult to create content for VR nowadays. Still, if you’re looking for a way to get a better understanding of VR development, working a demo project can help. Learn more ?

Practical Examples Of Future Emotional Interfaces

How will interfaces look like in the future? Even though we do not have an answer to this question just yet, we can discuss what characteristics interfaces might have. In my opinion, I’m sure that we will eventually move away from interfaces full of menus, panels, buttons, and move towards more ‘natural interfaces’, i.e. interfaces that extend our bodies. The interfaces of the future will not be locked in a physical screen, but instead they will use the power of all five senses. Because of that, they will require a less learning curve — ideally, no learning curve at all.

The Importance Of EQ Emotional Intelligence In Business

Apart from making the experience more natural and reducing the learning curve, designing for emotion has another benefit for product creators: it improves user adoption of the product. It’s possible to use humans’ ability to act on emotions to create better user engagement.

Voice Interfaces That Feel Real

Products that use voice as the primary interface are becoming more and more popular. Many of us use Amazon Echo and Apple Siri for daily routine activities such as setting an alarm clock or making an appointment. But a majority of voice interaction systems available on the market today still have a natural limitation: they do not take user emotions into account. As a result, when users interact with products like Google Now, they have a strong sense of communicating with a machine — not a real human being. The system responds predictably, and their responses are scripted. It’s impossible to have a meaningful dialogue with such a system.

But there are some completely different systems available on the market today. One of them is Xiaoice, a social chatbot application. This app has an emotional computing framework at its core; the app is built on the idea that it’s essential to establish an emotional connection with the user first. Xiaoice can dynamically recognize emotion and engage the user throughout long conversations with relevant responses. As a result, when users interact with Xiaoice they feel like they’re having a conversation with a real human being.

The limitation of Xiaoice is that it’s a text-based chat app. It’s evident that you can achieve a more powerful effect by making voice-based interactions (the human voice has different characteristics such as a tone that can convey a powerful spectrum of emotions).

Many of us have seen the power of voice-based interactions in the film “Her” (2013). Theodore (the main character played by Joaquin Phoenix) fell in love with Samantha (a sophisticated OS). This also makes us believe that one of the primary purposes of voice-based systems of the future will be a virtual companion to users. The most interesting thing about this film is that Theodore did not have a visual image of the Samantha — he only had her voice. To build that kind of intimacy, it’s essential to generate responses that reflect a consistent personality. This will make the system both predictable and trustworthy.

Technology is still a long away from a system like Samantha, but I believe that voice-first multimodal interfaces will be the next chapter in the evolution of voice-enabled interfaces. Such interfaces will use voice as a primary way of interaction and provide additional information in a context that creates and builds a sense of connection.

The Evolution Of AR Experience

Augmented Reality (AR) is defined as a digital overlay on top of the real world and transforms the objects around us into interactive digital experiences. Our environment becomes more ‘intelligent’ and users have an illusion of ‘tangible’ objects on the tips of their fingers, which establishes a deeper connection between a user and a product (or content).

Reimagine Existing Concepts Using AR

The unique aspect of AR is that it gives us an extraordinary ability to physically interact with digital content. It allows us to see things that we could not see before and this helps us learn more about the environment around us. This AR property helps designers to create new level experiences using familiar concepts.

For example, by using mobile AR, it’s possible to create a new level of in-flight experience that allows a passenger to see detailed information about her class or current flight progress:

AR helps us find our way through spaces and get the required information at a glance. For example, AR can be used to create rich contextual hints for your current location. The technology known as SLAM (Simultaneous Localization And Mapping) is perfect for this. SLAM allows real-time mapping of an environment and also makes it possible to place multimedia content into the environment.

There are massive opportunities for providing value to users. For example, users can point their devices at a building and learn more about it right there on their screens. It significantly reduces the effort and allows for an emotional experience of ease by allowing navigation and access.

The environment around us (such as walls or floors) can become a scene for interactivity in ways that used to be limited to our smartphones and computers.

The concept that you see below does just that; it uses a physical object (white wall) as a canvas for the content usually delivered using a digital device:

Avoiding Information Overload

Many of us saw the video called “HYPER-REALITY”. In this video, the physical and digital worlds have merged, and the user is overwhelmed with a vast amount of information.

Technology allows us to display several different objects at the same time. When it’s misused, it can easily cause overload.

Information overload is a serious issue that has a negative impact on user experience and avoiding it will be one of the goals of designing for AR. Well-designed apps will filter out elements that are irrelevant to users using the power of AI.

Advanced Personalization

Personalization in digital experience happens when the system curates the content or functionality to users’ needs and expectations in real time. Many modern mobile apps and websites use the concept of personalization to provide relevant content. For example, when you visit Netflix, the list of movies you see is personalized based on your interests.

AR glasses allow creating a new level of personalization, i.e. an ‘advanced’ level of personalization. Since the system ‘sees’ what the user sees, it’s possible to utilize this information to make a relevant recommendation or provide additional information in context. Just imagine that you’ll soon be wearing AR glasses, and the information that is transferred to your retina will be tailored to your needs.

Here’s a foretaste of what’s in store for us:

Moving From Augmented Reality Towards Virtual Reality To Create An Immersive Experience

AR experience has a natural limitation. As users, we have a clear line between us and content; this line separates one world (AR) with another (real world). This line causes a sense that the AR world is clearly not real.

You probably know how to solve this limitation, i.e. with virtual reality (VR), of course. VR is not exactly a new medium, but it’s only been in the last few years that technology has reached a point where it allowed designers to create immersive experiences.

Immersive VR experiences remove the barrier between the real world and digital. When you put on a VR headset, it’s difficult for your brain to process whether the information that you are receiving is real. The idea of how VR experiences can look in the nearest future is well explained in the movie “Ready Player One”:

Here is what designers need to remember when creating immersive virtual environments:

1. Write a story
   Meaningful VR has a strong story at its core. That’s why before you even start designing for a VR environment, you need to write a narrative for the user journey. A powerful tool known as a ‘storyboard’ can help you with that. Using a storyboard, it’s possible to create a story and examine all the possible outcomes. When you examine your story, you will see when and how to use both visual and audio cues to create an immersive experience.
2. Create a deeper connection with a character
   In order to make users believe that all things around them in VR are real, we need to create a connection with the characters played by the users. One of the most obvious solutions is to include a representation of users’ hands in the virtual scene. This representation should be of actual hands — not just a rigged replica. It’s vital to consider different factors (such as gender or skin color) because it’ll make interactions more realistic.
   

   

   It’s also possible to bring some objects from real life to a VR environment in order to create this connection. For instance, a mirror. When the user looks at a mirror and sees their character in the reflection, it enables more realistic interactions between the user and virtual characters.

   
   

3. Use gestures instead of menus
   When designing immersive VR experiences, we can’t rely on traditional menus and buttons. Why? Because it is relatively easy to break a sense of immersion by showing a menu. Users will know that everything around them is not real. Instead of using traditional menus, designers need to rely on gestures. The design community is still in the process of defining a universal language for using gestures, and taking part in this activity is fun and exciting exercise. The tricky part is to make gestures familiar and predictable for users.
   

   

4. Interact with elements in the VR environment
   To create an environment that feels real, we need to give the user the ability to interact with objects in that reality. Ideally, all objects in the environment can be designed in a way that allows users to touch and inspect them. Such objects will act as stimuli and will help you create a more immersive experience. Touch is extremely important for exploring the environment; the most important information that babies get in the first days is received through touch.
5. Share emotion in VR
   VR has a real opportunity to become a new level of social experience. But to make it happen, we need to solve one significant problem, i.e. bring the non-verbal cues into the interaction.

   When we interact with other people, a significant part on information that we get comes from body language. Surprise, disgust, anger — all these emotions are in our facial expressions, and during face-to-face interactions, we infer information from the eye region. It’s important to provide this information when people interact in a VR environment to create more realistic interactions.

   The good news is that the head-mounted devices (HMDs) will soon cover emotion recognition. Almost any area of human-to-human interaction will benefit from facial expressions in VR.

   

6. Design sound and music suitabke for a VR environment
   Audio is a huge component of the immersive experience. It’s impossible to create a genuinely immersive experience without designing sound for the environment. The sound can both be used as a background element (i.e., ambient sound of wind) or directional. In the latter case, the sound can be used as a cue — by playing with directionality (where the sound comes from) and distance (it’s possible to focus user attention on particular elements).

   When it comes to designing audio for VR, it’s essential to make the sound 3D. 2D sound doesn’t work for VR very well because it makes everything too flat. The 3D sound is the sound that you can hear in every direction around you — front, behind, above and beyond — all over the place. You don’t need specialized headphones to experience 3D sound; it’s possible to create it using standard stereo speakers of HMD.

   Head tracking is another critical aspect of a good sound design. It’s vital to make sounds behave in a realistic manner. That’s why when a user moves his head, the sound should change according to the head movement.

7. Prevent motion sickness
   Motion sickness is one of the primary pain-points in VR. It’s a condition in which a disagreement exists between visually perceived movement and the vestibular system’s sense of movement. It’s vital to keep users comfortable while they experience VR.

   There are two popular theories what causes motion sickness in VR:

   • ‘Sensory Conflict’ Theory
     According to this theory, motion sickness occurs as a result of a sensory disagreement between expected motion and motion that is actually experienced.
   • ‘Eye Movement’ Theory
     In the book “The VR Book: Human-Centered Design For Virtual Reality”, Jason Jerald mentions that motion sickness occurs because of the unnatural eye motion that is required to keep the scene’s image stable on the retina.

   Here are a few tips that will help you prevent users from reaching for the sickbag:

   • Physical body movement should match with visual movement. Sometimes even a small visual jitter can have an enormously negative impact on the experience.
   • Let users rest between moving scenes (this is especially important when the VR experience is really dynamic).
   • Reduce virtual rotations.

Conclusion

When we think about the modern state of product design, it becomes evident that we are only at the tip of the iceberg because we’re pretty limited to flat screens.

We’re witnessing a fundamental shift in Human-Computer Interaction (HCI) — rethinking the whole concept of digital experience. In the next decade, designers will break the glass (the era of mobile devices as we know them today) and move to the interfaces of the future — sophisticated voice interfaces, advanced ARs, and truly immersive VRs. And when it comes to creating a new experience, it’s essential to understand that the only boundary we have are our brains telling us it’s got to be how it’s always been.

(cc, ra, yk, il)

This resonated pretty strongly with people:

I’d watch a documentary series of developers giving a tour of their codebases.

— Chris Coyier (@chriscoyier) January 6, 2019

I think I was watching some random Netflix documentary and daydreaming that the subject was actually something I was super interested in: a semi-high-quality video deep dive into different companies codebases, hearing directly from the developers that built and maintain them.

Horror stories might also be interesting. Particularly if they involve perfect storm scenarios that naturally take us on a tour of the codebase along the way, so we can see how the system failed. We get little glimpses of this sometimes.

Probably more interesting is a tour of codebases when everything is humming along as planned. I wanna see the bottling factory when it’s working efficiently so I can see the symphony of it more than I wanna see a heaping pile of broken glass on the floor.

Or! Maybe the filmmaker will get lucky and there will be some major problem with the site as they’re filming, and they can capture the detection, reaction, and fixing of the problem and everything that entails. And sure, this isn’t wildlife rescue; sometimes the process for fixing even the worst of fires is to stare at your screen and type in silence like you always do. But I’m sure there is some way to effectively show the drama of it.

I’m not sure anything like this exists yet, but I’d definitely watch it. Here’s a bunch of stuff that isn’t a million miles away from the general idea:

• This Developer’s Life was damn well done and ran mostly from 2010-2012, but with an episode as recent as 2015.
• The History of the Web is a blog/newsletter about… that.
• There is a subreddit for /r/WatchPeopleCode. But there is a crapload of coding videos on YouTube and Twitch and all over that are equally sufficient.
• It’s been a few years since a new episode has been released, but readthesource shows developers going through the source code of big projects they’re working on.

Design is lucky, they’ve got a bunch of great high-budget documentaries like Objectified, Helvetica, Design & Thinking, Design Disruptors, Design is Future, and Abstract.

The post Would You Watch a Documentary Walking Through Codebases? appeared first on CSS-Tricks.

(This is a sponsored post.)

Let’s say you were going to design the easiest way to deploy a static site you can possibly imagine. If I was tasked with that, I’d say, well, it would deploy whenever I push to my master branch, and I’d tell it what command to run to build my site. Or maybe it has its own CLI where I can kick stuff out with as I choose. Or, you know what, maybe it’s so accommodating, I could drag and drop a folder onto it somehow and it would just deploy.

Good news: Netlify is way ahead of me. Netlify can do all those things, and so much more. Your site will be hosted on a CDN so it’s fast as heck. You can roll back to any other deployment because each build is immutable and trivially easy to point to. You can upload a folder of Node JavaScript functions and you can run those so you can do back-end things, like talk to APIs securely. Heck, even your forms can be automatically processed without writing any code at all!

It’s almost shocking how useful Netlify is. I recommend giving it a try, it might be just that empowering tool you need to build that next project you have in mind. ?

Direct Link to Article — Permalink

The post Netlify Makes Deployments a Cinch appeared first on CSS-Tricks.

For some reason, I’ve lately been thinking a lot about what it takes to break into the web design industry and learn CSS. I reckon it has something to do with Keith Grant’s post earlier this month on a CSS mental model where he talks about a “common core for CSS”:

We need common core tricks like this for CSS. Not “tricks” in the old sense (like how to fake a gradient border), but mental patterns: ways to frame the problem in our heads, so we can break problems into their constituent parts and notice recurring patterns. Those of us who deeply understand the language do this internally. We need to start working on distilling out these mental patterns we use for understanding layout and positioning and working with relative units, so that we can articulate them to others.

On this note, Rachel Andrew also wrote about how to learn CSS, but in this case, she focuses more on technical CSS specifics:

For much of CSS, you don’t need to worry about learning properties and values by heart. You can look them up when you need them. However, there are some key underpinnings of the language, without which you will struggle to make sense of it. It really is worth dedicating some time to making sure you understand these things, as it will save you a lot of time and frustration in the long run.

This ties in nicely with Andy Bell’s “CSS doesn’t suck” argument. Andy says that perhaps the reason why people attack CSS so often is because they simply don’t fundamentally understand it and thereby don’t respect why it works the way it does:

It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.

As I read these and other posts, I couldn’t stop thinking about the advice that I would give to a fledgling developer who’s interested in web design and CSS—where would I recommend that they start? There’s so much to cover that merely thinking about it gives me a headache.

Personally, I often start with the basics of HTML and slowly introduce folks to CSS properties like color or font-family. But this sort of advice is generally only useful if you’re sitting right next to someone and have the time to explain everything about HTML and CSS: how to lay out a page, how to handle performance, how to think about progressive enhancement, etc. These topics alone are worthy of a month-long workshop—and that’s only the beginning!

Where to get started then? What sort of advice would help a student in the long run?

My experience in the industry probably matches that of a lot of other web designers: I didn’t go to school for this. I figured things out by myself while using referential sites like CSS-Tricks and Smashing Magazine to fill in the gaps. I would start with a project (like making a website for my high school band—and no, I will tell you the name of it), and in the process, I would haphazardly learn about typesetting, Sass, build tools, as well as accessible, hand-written markup.

Hear me out, but I don’t think the best way to get started in the web design industry is to learn the latest doodad or widget. Yes, you’ll have to get to that eventually. Or maybe not. At some point, getting a firm handle on flexbox and grid and memorizing a few properties is a good thing to do. But I want to teach web designers to fish and make sure that they can set themselves up for the future. And the best way to fish for CSS probably won’t be found in a particular book or classroom curriculum. Instead, I think it’s best to recommend something else entirely.

My advice can be summarized in just four words: Get an RSS reader.

After thinking about this, I figured out that the most useful advice I can give is to get involved with the community—and, for me, that has been via RSS. Find a ton of blogs and subscribe to them. Over time, you’ll not only learn about the craft, but have a hefty (and hopefully organized) set of resources that cover basics, tricks, standards, personal struggles, and news, among many, many other things.

This is still how I learn about web design today. RSS is the most important tool I have to help me continue learning about the web—from working with tiny CSS properties to giant frameworks. Sure, Twitter is a good place to learn from (and even connect with) heavy hitters in the web design industry quickly, but there’s no better technology than RSS to constantly keep yourself informed of how people are thinking about CSS and web development.

With that, I encourage you (yes, you) to get an RSS reader if you don’t already have one, or dust off the one you do have if it’s been a while. I use Reeder 3 on OSX and iOS and pair that with Feedbin. From there, subscribe to a ton of blogs or follow a lot of folks on Twitter to find their websites. There’s no shortage of material or sources out there!

This sounds like a silly thing to recommend but fitting yourself into the web design community is more important than learning about any cool CSS trick. You’ll be creating an environment where you can constantly learn new things for the future. And I promise that, once you start, finding people who care about web development and, ultimately, learning about CSS, isn’t as intimidating as it could be on your own.

Which websites should you subscribe to? Well, Stuart Robson made a wonderful list of all the websites that he subscribes to via RSS—you should be able to download that file and drop it straight into your RSS reader. Also, Rachel Andrew made a great list of websites a while back when she asked what’s happening in CSS? And of course our very own newsletter, This Week in Web Design and Development, is certainly a good place to start, too. Speaking of email and newsletters—Dev Tips by Umar Hansa is another great resource where I’m constantly learning new things about Chrome’s DevTools.

What websites do you like though? What’s the best resource for keeping up with CSS? Let us know in the comments below!

The post The Secret Weapon to Learning CSS appeared first on CSS-Tricks.

Many of us follow @horse_js on Twitter. Twenty-one thousand of us, to be exact. That horse loves stirring up mischief by taking people’s statements out of context. It happened to me a few times and almost got me in trouble.

I wonder how many people hate CSS because their experience with it

— Horse JS (@horse_js) September 23, 2018

I wonder how many people hate CSS because their experience with it is overriding bootstrap.

In completely unrelated news, guess what I’m doing today.

— Sarah Drasner (@sarah_edo) September 21, 2018

There’s even a @horsplain_js account that follows along and explains the origin of the tweets.

Burke Holland and Jasmine Greenaway created a data science project to uncover the true identity of the notorious JavaScript parody account. This single page site goes through time series analysis, most quoted people, location and phrases to get to the bottom of the riddle. We won’t spoil it… you’ll just have to visit and see.

Direct Link to Article — Permalink

The post Who is @horse_js? appeared first on CSS-Tricks.

The Smashing Survey: Join In!

Rachel Andrew

2019-01-22T13:00:09+01:002019-01-22T12:02:48+00:00

Our entire aim here at Smashing Magazine — and my focus as Editor-in-Chief — is to provide the most helpful and interesting content and resources for web professionals. We aim not only to introduce new tools, technologies, and best practices, but also to give you handy resources to refer back to and put on interesting live events such as our conferences and webinars.

To be able to do that well, we need to understand the people who read Smashing Magazine, come to our conferences, and sign up as members. Given that we don’t ever get to meet or interact with the majority of folks who visit the site, this can make it quite difficult for us to better understand our readers and subscribers. Many of our Smashing Members join us in Slack, and we get to chat with conference attendees. However, these two groups are small in comparison to our worldwide audience.

So today, we’ve decided to launch a Smashing Survey which will help us create even more relevant content and shape the future of Smashing. The information will be used only here at Smashing to guide our content and our work, to ensure that we are doing the best we can for those who you who give us your time and attention.

We look forward to learning more about your experience with Smashing Magazine, and the things that matter to you. We promise to use that information to provide the resources that you need.

(ra, vf, il)

One of the must-have technologies for sites in 2019 will be geolocation. Not only does geolocation help with security, and legal compliance, but it also improves customer experience—one of the key metrics in turning a profit online.

Geolocation has a number of core benefits for businesses but the real benefit is in personalized content. Transforming an anonymous visit into a lasting customer relationship is the aim of all good sites, and that’s arrived at with user experiences crafted around the user’s real world situation. Geolocation is the best way of determining a user’s preferred currency, their language, even their legal status.

ipapi is one of the simplest geolocation services to use, and as a bonus, it’s one of the cheapest too because for many businesses, it’s free to use.

Why Use Geolocation?

Geolocation isn’t just about tracking data, it’s about improving customer experience and delivering the most personalized UX possible. Almost all Progressive Web Apps (PWAs) and websites benefit from accurately matching user sessions to real world locations. Whether you want to run an ad campaign, offer variable shipping rates, or just make folks feel at home, it all starts with recognizing where they’re from.

Compare customers in Alaska and Florida. It’s highly unlikely that an Alaskan would be shopping for an electric fan in December, and it’s equally unlikely that a Floridian would be shopping for an electric heater in July. By customizing a product page for different locations, we can respond to user’s intentions. Tailoring a shopping experience based on geographic location has been proven time and again to increase customer engagement, boost your conversion rate and keep customers coming back for more.

One of the best uses of geolocation is to give users correct office hours. Lots of customers still like to speak to a human being on the end of a phone line, especially if something goes wrong with an order. Geolocation allows you to adjust the office hours you display so that East coast customers don’t call before your office opens, and West coast customers don’t call after it closes.

Being able to accurately identify the location of your users is increasingly a must have requirement for PWAs and websites. It’s never safe to rely on any geolocation service entirely, there are all kinds of reasons it could return false data, such as people vacationing overseas, or traveling to a different territory for business. Geolocation should only be used as a default, and users should have the option to change their location manually, but it’s a great place to start. Take GDPR for example, lots of businesses have fallen foul of the EU’s privacy laws, but ipapi lets you identify if people are residing in the EU, ensuring you stay on the right side of the regulations.

Why Use ipapi?

There are lots of geolocation lookup services available on the web, and many offer competitive pricing and simple setup. Where ipapi beats the field is with the quality of the data it returns. Any geolocation lookup service is only as good as the data it supplies, and ipapi maintains partnerships with some of the world’s largest ISPs, giving it data accuracy that other IP lookup services can only dream of.

Trusted by over 30,000 businesses globally, ipapi delivers the best data available, helping web teams design the best possible user experience for customers, by tailoring content to each user’s expectations.

ipapi is built on a scaleable infrastructure, which means that no matter if you’re handling a few requests each month, or millions of requests every day, the service will promptly return the data you need. Because of this, it’s the perfect geolocation service for developers and startups, who need to make a few calls at first, but hope to be handling millions very soon. The cloud infrastructure can rapidly handle any volume of requests, so whether you’re catering to 12 people or 1.2 million, your codebase will keep working as intended.

Getting Started with ipapi

Integrating your PWA or website with ipapi is a cinch. You can connect to the API with a number of popular coding languages from PHP to JS. The data is fed back as XML or JSON as you prefer.

It’s insanely simple to get started with ipapi, here’s how:

Step 1. Sign up for a free account with ipapi and grab your API Access Key (it’s a long string of numbers and letters that tells ipapi who’s accessing the API).

Step 2. Build a URL starting with the API address:

http://api.ipapi.com/

Next, add the IP address you want to query:

http://api.ipapi.com/167.75.23.18

Then, add your access key:

http://api.ipapi.com/167.75.23.18?access_key=YOUR_ACCESS_KEY

(Make sure you replace YOUR_ACCESS_KEY, with your actual access key.)

Open up that URL in your browser and you’ll get back these details:

It couldn’t be simpler!

Now you’re ready to integrate however you choose. The simplest way is via Ajax using a library like jQuery.

In addition to this simple setup, ipapi provides a ton of optional parameters for customizing your request, such as whether to receive the response in JSON or XML formats.

It’s a simple system that will have you up and running in minutes.

Choosing ipapi

ipapi is free for the first 10,000 requests each and every month. If you need more requests than that, premium plans start from just $10. But think about how many requests 10,000 actually is. How many of your stable of sites bust that ceiling? It’s unlikely that most small businesses will ever need more than 10,000 requests, which means you could be using one of the best geolocation services on the web, for absolutely nothing.

The only thing to be wary of is that only the premium plans enable https. Something to keep in mind if you’re delivering a secure site, or relying on SSL for an SEO boost.

The free forever account is also limited, not just to the number of lookups, and http, but to the amount of support you can request, and the variety of data you can retrieve. Once you move into the premium options unlimited support is included, and as well as location data you can identify currency, timezones, and connection data.

Get started with geolocation for free, by signing up for a free forever trial account with ipapi, and get your first 10,000 requests each month free of charge.

[– This is a sponsored post on behalf of ipapi –]

Source

When companies post job openings for “Front-End Developer,” what are they really asking for? Assuming they actually know (lolz), the title front-end developer alone isn’t doing enough. It’s likely more helpful to know which side of the divide they need the most.

My hope is that the solution is writing more descriptive job postings. If clearly defined and agreed upon job titles are too much of an ask for the industry at large (and I fear that it is), we can still use our words. Corey Ginnivan put it well:

I’d love more job descriptions to be more vulnerable and open — let people know what you want to achieve, specify what they’ll be working on, but open it as a growth opportunity for both parties.

“Front-end developer” is still a useful term. Like Mina Markham described to us recently, it’s who people that primarily work with browsers and people using those browsers are. But it’s a generic shorthand, says Miriam Suzanne:

Front-end developer is shorthand for when the details don’t matter. Like being in an indie-rock band — who knows what that is, but I say it all the time. Shorthand is great until you’re posting a job description. When the details matter, we already have more detailed language — we just have to use it.

So big:

• It’s everywhere on the front end of websites. The major JavaScript front-end frameworks are seeing explosive growth and dominating job postings. These frameworks are used by loads of teams to power loads of websites. Native JavaScript is evolving quickly as well, which has lots of people excited.
• It powers backends, too. Your site might be powered by or involve a Node.js server. Your build process is likely to be powered by JavaScript.
• Third-party JavaScript powers so many front-end features, from a site’s ad network and analytics to full-blown features like reviews, comments, and related content.
• Concepts like Node-powered cloud functions, storage, and authentication, combined with low-cost and low-effort scalable hosting, have empowered the crap out of JavaScript-focused front-end developers. They can use their skills exclusively to ship entire functional products.

A front-end developer with a strong JavaScript skill set is wildly empowered these days. I’ve been calling it the all-powerful front-end developer, and I did a whole talk on it:

Through all the possibilities that swirl around the idea of serverless combined with prepackaged UI frameworks, a front-end developer can build just about anything without needing much, if any, help from other disciplines. I find that exciting and enticing, but also worthy of pause. It’s certainly possible that you become so framework-driven going down this path that your wider problem-solving skills suffer. I heard that sentiment from Estelle Weyl who goes so far as to say she thinks of developers more as “framework implementers,” reserving the title of engineer for tool-agnostic problem solvers.

This front-end empowerment is very real. Particularly in the last few years, front-end developers have gotten especially powerful. So powerful that Michael Scharnagl says he’s seen companies shift their hiring in that direction:

What I am seeing is that many developers focus entirely on JavaScript nowadays and I see companies where they replace back-end developers with JavaScript developers.

What some don’t understand is that a JavaScript developer is not per se a front-end developer. A JavaScript developer may not like to write CSS or care about semantics. That’s the same way I prefer not to work directly with databases or configure a server. That’s okay. What is not okay is if you don’t want to use something and at the same time tell others what they do is easy or useless. Even worse is if you try to tell experts in their field that they are doing it all wrong and that they should do it your way.

And Jay Freestone takes a stab at why:

Over the last few years, we’ve started to see a significant shift in the role of the front-end developer. As applications have become increasingly JavaScript-heavy there has been a necessity for front-end engineers to understand and practice architectural principles that were traditionally in the domain of back-end developers, such as API design and data modeling.

It’s happened even with my own small scale work. We were looking for a back-end Go developer to help evolve our web services at CodePen. When we didn’t have a lot of luck finding the perfect person, we decided to go another direction. We saw that our stack was evolving into something that’s extremely welcoming to JavaScript-focused front-end developers to the point where we could easily put more of them to work right away. So that’s what we did.

There may be a cyclical nature to some of this as well. We’re seeing coding schools absolutely explode and produce fairly talented developers in less than a year. These code school graduates are filling labor gaps, but more importantly, as Brad Westfall tells me, starting to lead industry discussions rather than be passive followers of them. And make no mistake: these schools are producing developers on the JavaScript side of the divide. Every single code school web development curriculum I’ve ever seen treats HTML/CSS/UI/UX/A11Y topics as early fundamentals that students breeze through or they are sprinkled in as asides while JavaScript dominates the later curriculum. Can you come in and teach our students all the layout concepts in three hours?

When JavaScript dominates the conversations around the front end, it leads to some developers feeling inadequate. In a comment on Robin Rendle’s “Front-end development is not a problem to be solved,” Nils writes:

Maybe the term front-end developer needs some rethinking. When I started working, front-end was mostly HTML, CSS, and some JavaScript. A good front-end developer needed to be able to translate a Photoshop layout to a pixel perfect website. Front end today is much much more. If you want to learn front-end development, people seem to start learning git, npm, angular, react, vue and all of this is called front-end development.

I am a designer and I think I’m pretty good at HTML and CSS, but that’s not enough anymore to be a front-end developer.

Robin himself gave himself the job title, Adult Boy That Cares Too Much About Accessibility and CSS and Component Design but Doesn’t Care One Bit About GraphQL or Rails or Redux but I Feel Really Bad About Not Caring About This Other Stuff Though.

It’s also frustrating to people in other ways. Remember Lara Schenk’s story of going in for a job interview? She met 90% of the listed qualifications, only to have the interview involve JavaScript algorithms. She ultimately didn’t get the job because of that. Not everybody needs to get every job they interview for, but the issue here is that front-end developer isn’t communicating what it needs to as an effective job title.

It feels like an alternate universe some days.

Two “front-end web developers” can be standing right next to each other and have little, if any, skill sets in common. That’s downright bizarre to me for a job title so specific and ubiquitous. I’m sure that’s already the case with a job title like designer, but front-end web developer is a niche within a niche already.

Jina Bolton is a front-end developer and designer I admire. Yet, in a panel discussion I was on with her a few years ago, she admits she doesn’t think of herself with that title:

When I was at Apple, my job title when I first started out there was front-end developer. Would I call myself that now? No, because it’s become such a different thing. Like, I learned HTML/CSS, I never learned JavaScript but I knew enough to work around it. Now—we’re talking about job titles—when I hear “front-end developer,” I’m going to assume you know a lot more than me.

It seems like, at the time, that lack of a JavaScript focus made Jina feel like she’s less skilled than someone who has the official title of front-end developer. I think people would be lucky to have the skills that Jina has in her left pinky finger, but hey that’s me. Speaking to Jina recently, she says she still avoids the title specifically because it leads to incorrect assumptions about her skill set.

Mandy Michael put a point on this better than anyone in her article, “Is there any value in people who cannot write JavaScript?”:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

Mandy uses her post for peacemaking. She’s telling us, yes, there is a divide, but no, neither side is any more valuable than the other.

The post The Great Divide appeared first on CSS-Tricks.