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 Barcelona, dedicated to smart front-end techniques and design patterns.
The bar is set high for today’s mobile apps. First, apps must meet the standard of quality that app markets expect. Secondly, mobile app users are very demanding. Plenty of alternatives are available to download, so users will not tolerate a buggy app.
Because mobile apps have become such a crucial part of people’s lives, users won’t be shy about sharing their love or hate for an app — and that feedback gets in front of millions of users in seconds.
Lately, I’ve gotten spoiled from using an editor that does intelligent autocompletion for me, something that in the past only massive complex IDEs offered. Opening my editor of choice, I created an input element and added an autocomplete attribute, only to find that the code completion offered me the state of on or off. Disappointing.
I recently sat down with Rock Zhang, a Chinese mobile entrepreneur. Rock is my classmate from business school, and we have both worked in the mobile industry for a while. In an age when the best marketing is good product management, Rock knows how to make millions of Chinese users fall in love with an app. I asked him to share his thoughts on app localization.
For me, China has always been a hard market to crack. I’ve marketed several mobile apps in European and US markets, and my apps have been featured many times in the App Stores in Russia, Israel, Spain, Germany and the US. But in China, our growth was stalling, and I don’t think we ever got a request for promotional artwork to be featured in the App Store. Truth be told, my “Asian expansion strategy” usually boiled down to hiring freelance translators through Elance to help me localize App Store pages in Chinese, Korean and Japanese.
There is a lot to learn this week. It starts with non-technical things like going for a walk to refresh your mind and finishes with how to prevent reverse XSS attacks in forms.
But it doesn’t matter whether you learn how to build self-contained web components using the new specification or to maximize the efficiency of your Angular 2 app or just how you can write less code. What matters is that you keep asking questions and that you try to get better and smarter at your craft.
First, I’ll recap what async functions are and how they work. Then, I’ll highlight the differences between Koa 1 and Koa 2. After that, I will describe my demo app for Koa 2, covering all aspects of development, including testing (using Mocha, Chai and Supertest) and deployment (using PM2).
It’s been almost five years since Photoshop Etiquette launched, which officially makes it a relic on the web. A lot can happen on the web in a few years, and these past five have illustrated that better than most.
In 2011, everyone was just getting their feet wet with responsive web design. The traditional comp-to-HTML workflow was only beginning to be critiqued, and since then, we’ve seen a myriad of alternatives. With a shift from page-based design to building a design system, it’s truly an exciting time.
For some time now, I’ve wanted the ability to route paths for a GitHub Pages website to its index.html for handling as a single-page app (SPA). This is table-stakes because such apps require all requests to be routed to one HTML file, unless you want to copy the same file across all of your routes every time you make a change to the project. Currently, GitHub Pages doesn’t offer a route-handling solution; the Pages system is intended to be a flat, simple mechanism for serving basic project content.
In case you weren’t aware, GitHub does provide one morsel of customization for your project website: the ability to add a 404.html file and have it served as your custom error page. I took a first stab at an SPA hack simply by duplicating my index.html file and renaming the copy to 404.html.
Criticism is easy. It seems like everybody has an opinion, but, as the author Harlan Ellison points out, "You are not entitled to your opinion. You are entitled to your informed opinion." To become informed, though, requires exploration. Design critiques are an important part of any product exploration.
A design critique — where the creator discusses and explains the creation with the rest of the team and/or client — is not about badgering the designer or pushing them to justify every decision they made. That’s just criticism. A good design critique is meant to explore the design, find where it is working and where it could be improved. If done well, design critiques allow everyone on the team to feel as if they have been heard and allow clients to give valuable feedback.
Even though we think everything happens in real-time nowadays, we need patience. While technology has been capable of real-time for long now, the “bottleneck” are human beings. Whether it’s a pull request that’s waiting for review since days or weeks or an email response, we need to keep in mind that delays might happen for a good reason.
Different people have different priorities, they might be focusing on something else at the moment, or they just take a break. Training patience is an important aspect of mental health, and, in the end, a well-thought-out, not instantly written feedback is better, too. Take your time and let others do the same.