You know, we use ad-blockers as well.
We gotta keep those servers running though. Did you know that we publish
useful books and run
friendly conferences — crafted for pros like yourself?
E.g. our upcoming SmashingConf New York, dedicated to smart front-end
techniques and design patterns.
Imagine that it's a hot day. The sun is out, and the temperature is rising. Perhaps, every now and then, there's a cool breeze. A good song is playing on the radio. At some point, you get up to get a glass of water, but the exact reason why you did that at that particular time isn't easy to explain. It was "too hot" and you were "somewhat thirsty," but also maybe "a little bored." Each of these qualities isn't either/or, but instead fall on a spectrum of values.
In contrast, our software is usually built on Boolean values. We set isHot to true and if isHot && isThirsty && isBored, then we call getWater(). If we use code like this to control our game characters, then they will appear jerky and less natural. In this article, we'll learn how to add intelligent behavior to the non-player characters of a game using an alternative to conventional Boolean logic.
In 2008, I worked on Boots.com. They wanted a single-page checkout with the trendiest of techniques from that era, including accordions, AJAX and client-side validation.
Each step (delivery address, delivery options and credit-card details) had an accordion panel. Each panel was submitted via AJAX. Upon successful submission, the panel collapsed and the next one opened, with a sliding transition.
When was the last time you took some time to reflect? Constantly surrounded by news and notifications to keep up with and in a rush to get things done more efficiently, it’s important that we take a step back from time to time to reflect our actions and opinions.
Reflect if you are working the way you want to work, reflect if you live your life as you want it to be, but also everyday matters. Do you really need that one particular app or service, for example, or could you live without it? Sometimes less is more and efficiency isn’t everything. What counts is how you use your time.
As a front-end developer, for each and every application I work on, I need to decide how to manage the data. The problem can be broken down into the following three subproblems: Fetch data from the back end, store it somewhere locally in the front-end application, retrieve the data from the local store and format it as required by the particular view or screen.
This article sums up my experience with consuming data from JSON, the JSON API and GraphQL back ends, and it gives practical recommendations on how to manage a front-end application data.
Good UX is what separates successful apps from unsuccessful ones. Customers are won and lost every day because of good or bad user experience design. The most important thing to keep in mind when designing a mobile app is to make sure it is both useful and intuitive.
Obviously, if an app is not useful, it will have no practical value for the user, and no one will have any reason to use it. And even if the app is useful but requires a lot of effort, people won’t bother learning how to use it.
Using this approach, we were able to create an incredibly fast and light web application that is also less work to maintain over time. The average page load on MeetSpace has just 1 uncached request and is 2 KB to download, and the page is ready within 200 milliseconds. Let's take a look at what went into this decision and how we achieved these results.
Have you ever wanted to make a website that non-technical folks can edit right in the browser? Or have you ever wanted to make a website that presents an editable collection of items (e.g. your portfolio)? Or simply upload images to a website you made, right from the browser?
Well, what if I told you, that you can do these things (and more!), just with HTML and CSS? No programming code to write, no servers to manage. You can make any element editable and saveable just by adding one HTML attribute to it. In fact, you can store your data locally in the browser, on Github, on Dropbox, or any other service just by changing an HTML attribute.
To get better at your craft, there’s nothing more valuable as learning first-hand from the experience of others. What little tricks have helped fellow designers, design leaders, and developers become more efficient? And how do they overcome hurdles in their projects? Conferences are a brilliant opportunity to get up close with the pros and exchange tips and ideas. But they aren’t the only one.
To spread expert knowledge between people who are hundreds, even thousands of miles apart, our friends at the full-stack UX design platform UXPin brought the first free virtual summit to life a few months ago. Now the second edition is on its way, and we are very happy to help make it happen: the Agile UX Virtual Summit, focusing on all things Agile UX. Because, well, we all know that building a UX team with agile organization can be quite a challenge.
Fluid layouts have been a normal part of front-end development for years. The idea of fluid typography, however, is relatively new and has yet to be fully explored. Up until now, most developers' idea of fluid typography is simply using Viewport units maybe with some minimum and maximum sizes.
In this article, we are going to take it to another level. We are going to examine how to create scalable, fluid typography across multiple breakpoints and predefined font sizes using well-supported browser features and some basic algebra. The best part is that you can automate it all by using Sass.