We use ad-blockers as well, you know. 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. upcoming SmashingConf Oxford, UK, dedicated to smart front-end techniques and design patterns.
Responsive websites, even the most modern ones, often struggle with selecting image resolutions that best match the various user devices. They compromise on either the image dimensions or the number of images. We can solve these issues and start calculating image breakpoints more mathematically, rather than haphazardly.
The lives of web developers aren’t getting any simpler as the number of different devices and potential screen resolutions increase. The high-resolution arms race seems to be never-ending as vendors try to top one another with innovations in laptop and mobile device screens. New devices such as TVs and smartwatches are entering the market, making the race even more complex.
Have you ever wondered why your users do not interact with your product the way you hope? Persuading people to perform a particular action, like signing up or buying a product, is a challenge in most industries, especially when you want that action to be performed repeatedly.
As UX practitioners, we try to create the best conditions for users to complete their tasks, and yet even the most usable interface is sometimes not enough to engage users. Why is that? To understand the reasons behind what drives users to certain behaviors, we need to look at the psychology that underlies the process of initiating and performing a behavior.
Over the last two weeks, I had the chance to review about eighty job applications for a front-end position. The position requires strong JavaScript knowledge, but it also requires HTML and CSS. And here’s a thing: nearly no one could show off substantial markup skills, not to talk about accessibility.
Although I only had the chance to review their personal websites or GitHub profiles and this might of course not be a full show-off of their knowledge, it assured my lately developed opinion on web developers. Many are not able to choose the right HTML elements, to explain why and how a clearfix works, or what ARIA roles are for, but they can use React and Angular. If you got some spare time over the next weeks, learn semantics and re-read the basics (or specs if you like the challenge) of HTML and CSS from time to time.
The WordPress platform is a magnet for those who want to take matters into their own hands, who want complete control over their websites and want to be independent in running them. WordPress does make it really easily to completely customize a website. If you have a bit of knowledge of HTMl, CSS and/or PHP, there is nothing you can’t change.
I mean, just compare the default themes, Twenty Fifteen and Twenty Fourteen. Hard to believe they are running on the same platform, isn’t it? Therefore, it is only natural for you to want to adapt the look of your website to fit your vision. I doubt there are many WordPress users out there who don’t constantly think about what to implement next. However, a problem arises.
Chances are you’ve seen it: a child glued to a tablet or smartphone, swiping fearlessly with small, sticky fingers. From airports and restaurants, to homes and even schools, mobile devices are a ubiquitous part of childhood today. Apple launched a curated ‘Kids’ category in the App Store last year that already has more than 80,000 apps.
With so many apps for kids out there, you may have considered designing one yourself. “How hard could designing for kids be?” you might think. Well, don’t let appearances deceive you. Despite their simple storylines and silly soundtracks, designing for kids is serious business. It’s not just taking grown-up content and dumbing it down. In fact, there are many reasons why designing for kids is actually more difficult than designing for adults.
Node.js brought about a great revolution for JavaScript developers by allowing us to write code that runs directly on our machines; our skills were no longer limited to browsers alone. At first, many of us simply saw this as a way to write our application servers without needing to learn another language, but we all quickly caught on to the fact that we could also write tools for the command line that automate a lot of things in our development cycles.
npm, which is bundled with Node.js, made this even easier by giving us quick and easy access to tools that others have created, which we install on our machines to access from wherever we are in our system. JavaScript was finally a “real” programming language. But with these new capabilities came a lot of best practices that needed to be discovered, because there were many new scenarios that wouldn’t be found in the browser. In particular, I’d like to discuss a practice that has been on my mind a lot lately that I think much of the community needs to evaluate.
Responsive images have been around long enough for most of us to have taken them for a spin, or at least to have learned from the experiences of those who have. Beyond doubt, the responsive images specification is a great win for the web. However, quite a few reports from the front lines suggest that responsive images can become pretty ugly.
The good news is that there is a fix! No, not throwing JavaScript at the challenge, but by asking the web server for a helping hand. Enter Client Hints, an initiative spearheaded by Google that is already available in browsers (Chrome and Opera) and that is super-simple to use. Let’s see how Client Hints can reduce both image size and verbosity of the responsive images markup.
One thing we should learn to embrace more this year is to enjoy the good things and focus more on the positive news than on the negative. I started to learn more ES6 this year and have scheduled 1 to 2 small learning modules of ES6 and 1 to 2 accessibility features I don’t know yet to study each week.
This week, Apple announced the pre-release of Safari 9.1 which will introduce the <picture>-element, Fast Tap on iOS, changes to modal dialogs, CSS Variable support, all, unset, font-variant-* and will-change property support as well as unprefixed CSS filter. Let’s hope that shorter release-cycles are Apple’s new strategy for a more open, more responsive browser culture.
Every morning, designers wake up to happily work on their products, be they digital or physical, with an inner belief that people will want to use their products and will have a blast doing so. Perhaps that is a slight generalization; however, as designers, we tend to have a natural desire for each project we work on to be the best it can be, to be innovative and, most importantly, to make a difference.
Here is a little revelation. People are not really into using products. Any time spent by a user operating an interface, twisting knobs, pulling levers or tapping buttons is time wasted. Rather, people are more interested in the end result and in obtaining that result in the quickest, least intrusive and most efficient manner possible. And these are two fundamentally different concepts — usage versus results — which, at the very least, differentiate good product design from poor product design or, on a smaller scale, a good feature from a bad one.
The way we consume open source software (OSS) dramatically changed over the past decade or two. Flash back to the early 2000s, we mostly used large OSS projects from a small number of providers, such as Apache, MySQL, Linux and OpenSSL. These projects came from well-known software shops that maintained good development and quality practices. It wasn’t our code, but it felt trustworthy, and it was safe to assume it didn’t hold more bugs than our own code.
Fast-forward to today and OSS has turned into crowd-sourced marketplaces. Node’s npm carries over 210,000 packages from over 60,000 contributors; RubyGems holds over 110,000 gems, and Maven’s central repository indexes nearly 130,000 artifacts. Packages can be written by anybody, and range from small utilities that convert milliseconds to full-blown web servers. Packages often use other packages in turn, ending with a typical application holding hundreds if not thousands of OSS packages.
