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.
To my readers in or near Germany: Some of you might be aware that I organize a small event, and this week I have one ticket to give away for the NightlyBuild conference 20161 in Cologne, Germany on September, 2nd. If you want to attend, just send me an email2, and I’ll raffle the ticket on Tuesday.
While researching a bit on user tracking, I found out about header enrichment, a technique used by mobile network providers to set unique identifiers. But more interestingly, while it’s advised by the IETF to not expose any of these headers to public servers, many ISPs do it anyway and leak the private IP addresses of devices, the IMEI/IMSI or even the phone number, to any server. This research paper4 by the ICSI analyzed the worldwide spread and impact on users’ privacy.
Many of you might be aware that we can’t style :visited states and similar browser-history-based features in CSS very well. With CSS’ new mix-blend-mode-feature there seems to be a leak again that lets rogue sites inspect your browsing history. Michał Zalweski explains how it works5.
Harry Roberts now shares the slides to his talk “Refactoring CSS Without Losing Your Mind12”. Having experienced many of the mentioned problems already in the past, I think there are a lot of great tricks in there that can be really helpful.
13 Clipping and masking allows for interesting ways to show or hide pieces of your graphics. Abbey Fitzgerald explains how to do it with CSS and SVG14.
Today I read an interesting statement about constant learning15 (see the blockquote below) with which I fundamentally disagree. So instead of following this advice, I want to encourage you to take a break from constant learning every few days. There are reasons why you should rest on a weekend and recover from learning new things during the week: By taking a break, you’ll eagerly await learning something new afterwards.
“In today’s highly competitive business environment, we all need to be in constant learning mode. No one can afford to take a vacation from developing new skills, especially as economic and political uncertainty threaten businesses and job stability and make future career prospects unclear.”
Rose Marcario, CEO of Patagonia, has published an essay on why it’s important that employers support families16. It’s not just about saying this but about taking meaningful, real action to make employees feel comfortable, have a good life, and enjoy working for their employer.
The NASA started a new blog called “Science WOW!17” which shares educational articles on science each week. If you’re interested in learning how hurricanes form or about space exploration stuff, this might be for you.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
Progressive web apps could be the next big thing for the mobile web. Originally proposed by Google in 2015, they have already attracted a lot of attention because of the relative ease of development and the almost instant wins for the application’s user experience.
A progressive web application takes advantage of the latest technologies to combine the best of web and mobile apps. Think of it as a website built using web technologies but that acts and feels like an app. Recent advancements in the browser and in the availability of service workers and in the Cache and Push APIs have enabled web developers to allow users to install web apps to their home screen, receive push notifications and even work offline.
Progressive web apps take advantage of the much larger web ecosystem, plugins and community and the relative ease of deploying and maintaining a website when compared to a native application in the respective app stores. For those of you who develop on both mobile and web, you’ll appreciate that a website can be built in less time, that an API does not need to be maintained with backwards-compatibility (all users will run the same version of your website’s code, unlike the version fragmentation of native apps) and that the app will generally be easier to deploy and maintain.
A study has shown that, on average, an app loses 20%1 of its users for every step between the user’s first contact with the app and the user starting to use the app. A user must first find the app in an app store, download it, install it and then, finally, open it. When a user finds your progressive web app, they will be able to immediately start using it, eliminating the unnecessary downloading and installation stages. And when the user returns to the app, they will be prompted to install the app and upgrade to a full-screen experience.
However, a native app is definitely not all bad. Mobile applications with push notifications achieve up to three times more retention2 than their counterparts without push, and a user is three times more likely to reopen a mobile application than a website. In addition, a well-designed mobile application consumes less data and is much faster because some resources reside on the device.
A progressive web application takes advantage of a mobile app’s characteristics, resulting in improved user retention and performance, without the complications involved in maintaining a mobile application.
When should you build a progressive web app? Native is usually recommended for applications that you expect users to return to frequently, and a progressive web app is not any different. Flipkart3 uses a progressive web app for its popular e-commerce platform, Flipkart Lite, and Air Berlin4 uses a progressive web app for its online check-in process, allowing users to access their tickets without an Internet connection.
When assessing whether your next application should be a progressive web app, a website or a native mobile application, first identify your users and the most important user actions. Being “progressive,” a progressive web app works in all browsers, and the experience is enhanced whenever the user’s browser is updated with new and improved features and APIs.
Thus, there is no compromise in the user experience with a progressive web app compared to a traditional website; however, you may have to decide what functionality to support offline, and you will have to facilitate navigation (remember that in standalone mode, the user does not have access to the back button). If your website already has an application-like interface, applying the concepts of progressive web apps will only make it better.
If certain features are required for critical user actions but are not yet available due to a lack of cross-browser support5, then a native mobile application might be the better option, guaranteeing the same experience for all users.
Before we jump into the code, it is important to understand that progressive web apps have the following characteristics6:
Progressive
By definition, a progressive web app must work on any device and enhance progressively, taking advantage of any features available on the user’s device and browser.
Discoverable
Because a progressive web app is a website, it should be discoverable in search engines. This is a major advantage over native applications, which still lag behind websites in searchability.
Linkable
As another characteristic inherited from websites, a well-designed website should use the URI to indicate the current state of the application. This will enable the web app to retain or reload its state when the user bookmarks or shares the app’s URL.
Responsive
A progressive web app’s UI must fit the device’s form factor and screen size.
App-like
A progressive web app should look like a native app and be built on the application shell model, with minimal page refreshes.
Connectivity-independent
It should work in areas of low connectivity or offline (our favorite characteristic).
Re-engageable
Mobile app users are more likely to reuse their apps, and progressive web apps are intended to achieve the same goals through features such as push notifications.
Installable
A progressive web app can be installed on the device’s home screen, making it readily available.
Fresh
When new content is published and the user is connected to the Internet, that content should be made available in the app.
Safe
Because a progressive web app has a more intimate user experience and because all network requests can be intercepted through service workers, it is imperative that the app be hosted over HTTPS to prevent man-in-the-middle attacks.
Our first progressive web app, Sky High, will simulate an airport’s arrivals schedule. The first time the user accesses our web app, we want to show them a list of upcoming flights, retrieved from an API. If the user does not have an Internet connection and they reload the web app, we want to show them the flight schedule as it was when they last downloaded it with a connection.
7 Sky High, our fictitious progressive web app (Large preview8)
The first characteristic of a progressive web app is that it must work on all devices and must enhance on devices and browsers that allow it. Therefore, we’ve built our website using traditional HTML5 and with JavaScript that simulates the retrieval of data from a mock API. Throughout the application, we are using small bits of Knockout9 to handle our Model-View-ViewModel (MVVM) bindings — a lightweight JavaScript framework that allows us to bind our JavaScript models to our HTML views. We chose to use Knockout because it is relatively simple to understand and does not clutter the code; however you may replace this with any other framework, such as React or AngularJS.
Our website follows Google’s material design10 guidelines, a set of principles that guide design and interaction. Material design not only serves as a unified standard across applications and devices, but also gives design meaning. We’ve used material design for Sky High’s arrivals view to give our progressive web app that native-app look and feel.
Finally, we tested our app to make sure it is jank-free11 and that scrolling is silky-smooth. Jank-free rendering has been shown to improve user engagement. Aim for a rendering of 60 frames per second.
For this demo, we will retrieve a static JSON file, instead of a real API. This is merely to keep things simple. In the real world, you would query an API or use WebSockets.
The index.html file is relatively standard. We’ve created an HTML list and bound our View Model property arrivals to it using Knockout12, through the attribute data-bind="foreach: arrivals". The View Model arrivals is declared in the page.js file below and exposed in the Page module. On our HTML page, for each item in the arrivals array, we’ve bound the title, status and time properties to the HTML view.
(var Page = (function() { // declare the view model used within the page function ViewModel() { var self = this; self.arrivals = ko.observableArray([]); } // expose the view model through the Page module return { vm: new ViewModel(), hideOfflineWarning: function() { // enable the live data document.querySelector(".arrivals-list").classList.remove('loading') // remove the offline message document.getElementById("offline").remove(); // load the live data }, showOfflineWarning: function() { // disable the live data document.querySelector(".arrivals-list").classList.add('loading') // load html template informing the user they are offline var request = new XMLHttpRequest(); request.open('GET', './offline.html', true); request.onload = function() { if (request.status === 200) { // success // create offline element with HTML loaded from offline.html template var offlineMessageElement = document.createElement("div"); offlineMessageElement.setAttribute("id", "offline"); offlineMessageElement.innerHTML = request.responseText; document.getElementById("main").appendChild(offlineMessageElement); } else { // error retrieving file console.warn('Error retrieving offline.html'); } }; request.onerror = function() { // network errors console.error('Connection error'); }; request.send(); } } })();
This page.js file exposes the Page module, which contains our ViewModel vm and two functions, hideOfflineWarning and showOfflineWarning. The View Model ViewModel is a simple JavaScript literal that will be used throughout the application. The property arrivals on the ViewModel is Knockout’s observableArray, which automatically binds our HTML to a JavaScript array, allowing us to push and pop items onto our array in JavaScript and automatically update the page’s HTML.
The functions hideOfflineWarning and showOfflineWarning enable the rest of our application to call these functions to update the page’s UI that displays whether we are connected online. The showOfflineWarning adds a class of loading to our arrivals-list HTML element to fade the list, and then it retrieves the HTML file offline.html through XHR. Assuming that the file has been retrieved successfully (response.status === 200), we append this to our HTML. Of course, if we aren’t using service workers13 and the user is not connected to the Internet, then it would not be possible to retrieve offline.html, and so the user would see the browser’s offline page.
The business logic from where we retrieve the data from our API and bind it to our View Models and Views is found in arrivals.js14 and is standard MVVM functionality using Knockout. In the arrivals.js file, we simply initialize the services and View Models that we will be using throughout the application, and we expose a function — Arrivals.loadData() — that retrieves the data and binds it to the view model.
Let’s make our web app more app-like. A web app manifest file is a simple JSON file that follows the W3C’s specification15. With it, it is possible to run the web app in full-screen mode as a standalone application, to assign an icon that will get displayed when the application is installed on the device, and to assign a theme and background color to the app. In addition, Chrome on Android will proactively suggest that the user install the web app, via a web app install banner16. To display the installation prompt, your web app needs to:
have a valid web app manifest file,
be served over HTTPS,
have a valid service worker registered,
have been visited twice, with at least five minutes between each visit.
short_name is a human-readable name for the application. In Chrome for Android, this is also the name accompanying the icon on the home screen.
name is also a human-readable name for the application and defines how the application will be listed.
description provides a general description of the web application.
icons defines an array of images of varying sizes that will serve as the application’s icon set. In Chrome for Android, the icon will be used on the splash screen, on the home screen and in the task switcher.
start_url is the starting URL of the application.
display defines the default display mode for the web application: fullscreen, standalone, minimal-ui or browser.
orientation defines the default orientation for the web application: portrait or landscape.
theme_color is the default theme color for the application. On Android, this is also used to color the status bar.
background_color defines the background color of the web application. In Chrome, it also defines the background color of the splash screen.
related_applications is not implemented in our example but is used to specify native application alternatives in the various app stores.
Add the manifest.json reference to the index.html file’s head tag:
<link rel="manifest" href="./manifest.json">
Once a user has added the web app to their home screen, they will be able to re-engage with your application immediately from their device, without having to directly open the browser. You can see how this is much more than a web bookmark.
Add to home screen in Chrome for Android
Service Workers
One of the more exciting aspects of progressive web apps is that they can work offline. Using service workers, it is possible to show data that was retrieved in previous sessions of the app (using IndexedDB19) or, alternatively, to show the application shell and inform the user that they are not connected to the Internet (the approach we’ve taken in this demo). Once the user reconnects, we can then retrieve the latest data from the server.
All of this is possible through service workers, which are event-driven scripts (written in JavaScript) that have access to domain-wide events, including network fetches. With them, we can cache all static resources, which could drastically reduce network requests and improve performance considerably, too.
The application shell is the minimum HTML, CSS and JavaScript required to power a user interface. A native mobile application includes the application shell as part of its distributable, whereas websites ordinarily request this over the network. Progressive web applications bridge this gap by placing the application shell’s resources and assets in the browser’s cache. In our Sky High application, we can see that our application shell consists of the top header bar, the fonts and any CSS required to render these elegantly.
To get started with service workers, we first need to create our service worker’s JavaScript file, sw.js, placed in the root directory.
// Use a cacheName for cache versioning var cacheName = 'v1:static'; // During the installation phase, you'll usually want to cache static assets. self.addEventListener('install', function(e) { // Once the service worker is installed, go ahead and fetch the resources to make this work offline. e.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([ './', './css/style.css', './js/build/script.min.js', './js/build/vendor.min.js', './css/fonts/roboto.woff', './offline.html' ]).then(function() { self.skipWaiting(); }); }) ); }); // when the browser fetches a URL… self.addEventListener('fetch', function(event) { // … either respond with the cached object or go ahead and fetch the actual URL event.respondWith( caches.match(event.request).then(function(response) { if (response) { // retrieve from cache return response; } // fetch as normal return fetch(event.request); }) ); });
Let’s look more closely at our service worker. First, we are setting a cacheName variable. This is used to determine whether any changes have been made to our cached assets. For this example, we will be using a static name, meaning that our assets will not change or require updating.
self.addEventListener('install', function(e) { // declare which assets to cache }
The install event fires during the installation phase of the service worker and will fire only once if the service worker is already installed. Therefore, refreshing the page will not trigger the installation phase again. During the installation phase, we are able to declare which assets will be cached. In our example above, we are caching one CSS file, two JavaScript files, our fonts file, our offline HTML template and, of course, the application root. self.skipWaiting() forces the waiting service worker to become active.
So far, we have declared our service worker, but before we see it kick into effect, we need to reference it in our JavaScript. In our application, we register it in main.js
// Register the service worker if available. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js').then(function(reg) { console.log('Successfully registered service worker', reg); }).catch(function(err) { console.warn('Error whilst registering service worker', err); }); } window.addEventListener('online', function(e) { // Resync data with server. console.log("You are online"); Page.hideOfflineWarning(); Arrivals.loadData(); }, false); window.addEventListener('offline', function(e) { // Queue up events for server. console.log("You are offline"); Page.showOfflineWarning(); }, false); // Check if the user is connected. if (navigator.onLine) { Arrivals.loadData(); } else { // Show offline message Page.showOfflineWarning(); } // Set Knockout view model bindings. ko.applyBindings(Page.vm);
We’ve also included two event listeners to check whether the session’s state has changed from online to offline or vice versa. The event handlers then call the different functions to retrieve the data through Arrivals.loadData() and to enable or disable the offline message through Page.showOfflineWarning and Page.hideOfflineWarning, respectively. Our application also checks whether the user is currently online, using navigator.onLine20, and either retrieves the data or shows the offline warning accordingly. And in the last line of main.js, we apply the Knockout bindings to our View Model Page.vm.
If we load our application for the first time (with Chrome Developer Tools), we will see nothing new. However, upon reloading, we will see that a number of network resource have been retrieved from the service worker. This is our application shell.
21 Application shell network resources, in Chrome Developer Tools (View large version22)
A user running the application without an Internet connection (assuming that they have already been on the page) will simply result in the application shell and the offline warning being displayed — an improvement over Chrome’s prowling t-rex. Once the user has established a network connection, we disable the warning and retrieve the latest data.
Push notifications allow users to opt in to timely updates from applications they trust, helping them to re-engage with the apps. Push notifications on the web27 allow you to engage with your audience even when the browser is closed.
The Push API is supported in Chrome, Opera and Samsung’s browser and is under development in Firefox and Microsoft Edge. Unfortunately, there is no indication that the feature will be implemented in Safari.
One of the easiest wins with service workers is that we can improve performance with little to no effort. Comparing our website to itself before service workers were implemented, before we were retrieving over 200 KB upon page load; that is now reduced to 13 KB. On a regular 3G network, the page would have taken 3.5 seconds to load; now it takes 500 milliseconds.
These performance improvements are drastic because the application itself is very small and has limited functionality. Nevertheless, through the correct use of caching, it is possible to significantly improve performance and perceived performance, especially for users in places with low-connectivity.
Google’s Chrome team has put together a tool for testing progressive web apps. Lighthouse31 runs in Node.js or as a Chrome plugin32 and can be found on GitHub, too.
To run a Lighthouse test, your website needs to be available online, meaning that you cannot test on localhost.
To start, download the npm package:
npm install -g GoogleChrome/lighthouse
Once that’s installed, run Chrome (version 52 onwards):
npm explore -g lighthouse -- npm run chrome lighthouse https://incredibleweb.github.io/pwa-tutorial/
The output of the Lighthouse run will be visible in the command line and will grade your website according to the progressive web app features and properties you have implemented — for example, whether you are using a manifest.json file or whether your page is available offline.
This article is merely an appetizer for progressive web apps. We could do a lot more to create that app-like experience users are looking for, whether by supporting push notifications with the Push API33, making the app re-engageable, or using IndexedDB and background syncing34 to improve the offline experience.
Cross-Browser Support
These are still early days for progressive web apps, and cross-browser support is still limited, especially in Safari and Edge. However, Microsoft openly supports progressive web apps and should be implementing more features by the end of the year.
Service workers and Cache API
Supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge, expected to be available by the end of 2016. Under consideration for Safari.
Add to home screen
Supported in Chrome, Firefox, Opera, Android Browser and Samsung’s browser. Microsoft seems to indicate that progressive web apps will be available as store listings. No plans for Safari as of yet.
Push API
Mostly supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge. No plans for Safari as of yet.
If more developers take advantage of the features offered by progressive web apps — which are relatively easy to implement and provide immediate rewards — then users will prefer consuming these web apps in supported browsers, hopefully convincing the other browser vendors to adapt.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
Dariel Fitzkee, the famous magician, once said, “Magic is both in the details and in the performance.” Interaction design is just like that. Designers love to get the big picture right, but if the details aren’t handled properly, the solution will fail. The magic is all in the details. That’s why well-designed microinteractions make experiences feel crafted.
To get a better understanding of how your design benefits from microinteractions, it will help to sketch out your app ideas. Adobe introduced a new design and wireframing app called Experience Design (or Adobe XD) which lets you design wireframes and make them interactive. You can download and test Adobe XD1for free.
Jakob Nielsen’s first heuristic for UI design states, “The system should always keep users informed about what is going on, through appropriate feedback in a reasonable time.” This means that the user interface should keep the user abreast of what is happening by providing feedback. The app shouldn’t keep the user guessing — it should tell the user what’s happening, and microinteractions can help you make that known via appropriate visual feedback.
Data uploading and downloading processes are great opportunities for creative animated microinteractions.
Another well-known animation for this group is “pull down to refresh,” which initiates a process of content updates on mobile devices. A cheerful refresh animation can make users chuckle.
User interface elements such as buttons and controls should appear tangible, even though they are behind a layer of glass. Visual and motion cues can bridge this gap by acknowledging input immediately and animating in ways that look and feel like direct manipulation. UI buttons can mimic interaction with common physical objects. Simply put, you can add clarity through visual responses to the user’s input.
Takeaway: Visual feedback works because it appeals to the user’s natural desire for acknowledgement. It just feels good to click through an app and always feel like you know what’s happening.
You can use animation to smoothly transport users between navigational contexts, to explain changes in the arrangement of elements on a screen or to reinforce an element’s hierarchy.
Icons can morph from one shape to another, serving dual functions at different times.
Motion design can effectively guide the user’s attention in ways that both inform and delight. This is especially good for mobile devices and smartwatches because it’s impossible to fit a lot of information on those screens.
Apple’s iOS UI is a good example of meaningful transitions. In the example below, the user selects a folder or app and is zoomed into its detailed view (or directly to the app’s main screen).
Another good example is animation that creates visual connections between two states through color and persistent elements. This makes transitions smooth and effortless.
Microinteractions are very helpful during onboarding. Flawless UX and animations in the onboarding flow can have a tremendous impact on how first-time users engage with the app. They guide and educate users after the launch of an app by highlighting the most important features and controls.
Microinteractions can direct the user’s attention. In many cases, animation is used to attract their attention to an important detail (such as a notification). However, be sure that the animation serves a functional purpose and is appropriate to your users.
The most basic use of a microinteraction animation is in transitions. However, an app can truly delight users when animation is used in ways beyond the standard scope of actions. The button below seamlessly changes states and serves dual functions: to inform the user and to create a moment of wonder.
Takeaway: Focus on user emotions, which play a huge role in UI interactions.
What To Consider When Designing Microinteractions Link
When you create a visual design containing the elements discussed above, keep a few things in mind:
Make microinteractions almost invisible and completely functional.
Make sure the animations fit a functional purpose and do not feel awkward or annoying. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
Keep longevity in mind.
Microinteractions must survive long-term use. What seems fun the first time might become annoying after the hundredth use.
Over-designing a microinteraction can be lethal. Microinteractions shouldn’t overload the screen and cause a long process of loading. Rather, they should save time by instantly communicating valuable information.
Don’t start from zero.
You will almost always know something about your target audience and their context. Use that knowledge to make your microinteractions more precise and effective.
Create visual harmony with the other UI elements.
Microinteractions should match the general style of the application, supporting a harmonious perception of the product.
Microinteractions show that attention to small details can deliver big and powerful results. As Charles Eames once said, “The details are not the details. They make the design.” Every element of the design matters. Details make your app stand out from the competition because they can be either practical and forgettable or impressive, useful and unforgettable.
Always design with care, and don’t forget that a great design has to happen full-stack, from the functional parts down to the microinteractions.
This article is part of the UX design series sponsored by Adobe. The newly introduced Experience Design app23 is made for a fast and fluid UX design process, as it lets you sketch out ideas, create interactive prototypes, test and share them all in one place.
You can check out more inspiring projects created with Adobe XD on Behance24, and also visit the Adobe XD blog25 to stay updated and informed. Adobe XD is being updated with new features frequently, and since it’s in public Beta, you can download and test it for free26.
We’ve all been there. You spent months gathering business requirements, working out complex user journeys, crafting precision interface elements and testing them on a representative sample of users, only to see a final product that bears little resemblance to the desired experience.
Maybe you should have been more forceful and insisted on an agile approach, despite your belief that the organization wasn’t ready? Perhaps you should have done a better job with your pattern portfolios, ensuring that the developers used your modular code library rather than creating five different variations of a carousel. Or, maybe you even should’ve sat next to the development team every day, making sure what you designed actually came to pass.
Instead you’re left with a jumble of UI elements, with all the subtlety stripped out. Couldn’t they see that you worked for days getting the transitions just right, only for them to drop in a default animation library? And where on earth did that extra check-out step come from. I bet marketing threw that in at the last minute. You knew integration was going to be hard and compromises would need to be made, but we’re supposed to be making the users lives easier here, not the tech team.
1 When many people are involved in a project, it is very important to make sure that they have a common understanding of the problem and its solution. (Image credit: The Next Web2)
Of course, there are loads of good reasons why the site is this way. Different teams with varying levels of skill working on different parts of the project, a bunch of last-minute changes shortening the development cycle, and a whole host of technical challenges. Still, why couldn’t the development team come and ask for your advice on their UI changes? You don’t mess with their code, so why do they have to change your designs around? Especially when the business impact could be huge! You’re only round the corner and would have been happy to help if they had just asked.
While the above story may be fictional, it’s a sentiment I hear from all corners of the design world, whether in-house or agency side. A carefully crafted experienced ruined by a heavy-handed development team.
This experience reminds me of a news story I saw on a US local news channel several years ago. A county fair was running an endurance competition where the last person remaining with their hand on a pickup truck won the prize. I often think that design is like a massive game of “touch the truck”, with the development team always walking away with the keys at the end of the contest. Like the last word in an argument, the final person to come in contact with the site holds all the power and can dictate how it works or what it looks like. Especially if they claim that the particular target experience isn’t “technically possible”, which is often shorthand for “really difficult”, “I can’t be bothered doing it that way” or “I think there’s a better way of doing it so am going to pull the dev card”.
Now I know I’m being unfairly harsh about developers here and I don’t mean to be. There are some amazingly talented technologists out there who really care about usability and want to do the best for the user. However, it often feels as though there’s an asymmetric level of respect between disciplines due to a belief that design is easy and therefore something everybody can have an opinion on, while development is hard and only for the specially initiated. So while designers are encouraged (sometimes expected) to involve everybody in the design process, they often aren’t afforded the same luxury.
To be honest, I don’t blame them. After all, I know just enough development to be dangerous, so you’d be an idiot if you wanted my opinion on database structure and code performance (other than I largely think performance is a good thing). Then again I do know enough to tell when the developers are fudging things and it’s always fun to come back to them with a working prototype of something they said was impossible or take months to implement — but I digress.
The problem is, I think a lot of developers are in the same position about design — they just don’t realize it. So when they make a change to an interface element based on something they had heard at a conference a few years back, they may be lacking important context. Maybe this was something you’ve already tested and discounted because it performed poorly. Perhaps you chose this element over another for a specific reason, like accessibility? Or perhaps the developers opinions were just wrong, based on how they experience the web as superusers rather than an average Jo.
Now let’s get something straight here. I’m not saying that developers shouldn’t show an interest in design or input into the design process. I’m a firm believer in cross-functional pairing and think that some of the best usability solutions emanate from the tech team. There are also a lot of talented people out there who span a multitude of disciplines. However, at some point the experience needs to be owned, and I don’t think it should be owned by the last person to open the HTML file and “touch the truck”.
So, if good designers respect the skill and experience great developers bring to the table, how about a little parity? If designers are happy for developers to “own the code”, why not show a similar amount of respect and let designers “own the experience”?
3 Everybody has an opinion. However, it’s not a good enough reason to just dive in and start making changes. Image credit: Open Source Way4
Doing this is fairly simple. If you ever find yourself in a situation where you’re not sure why something was designed in a particular way, and think it could be done better, don’t just dive in and start making changes. Similarly, if you hit a technical roadblock and think it would make your lives easier to design something a different way, go talk to your designer. They may be absolutely fine with your suggested changes, or they may want to go away and think about some other ways of solving the same problem.
After all, collaboration goes both ways. So if you don’t want designers to start “optimizing” your code on the live server, outside your version control processes, please stop doing the same to their design.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
One of the hardest decisions to make when starting a new app is which platforms to target. A mobile app gives you more control and better performance but isn’t as universal as the web. If you’re making a mobile app, can you afford to support both iOS and Android? What about trying to build a mobile app and a responsive web app? Ultimately, the best experience for your customers is for your app to work everywhere, but the development and maintenance costs of that can be prohibitive.
We have already seen how1 React Native can help you make iOS and Android apps with a shared code base, without sacrifices in quality. But what about the web? This is exactly the problem the React Native for Web312 project is trying to solve. Instead of forcing you to maintain two separate code bases for your mobile and web apps, or making a hybrid app, with all its compromises3, React Native for Web is intended to let you write a single app that runs in a browser using standard web technologies, or on iOS and Android as a real native mobile app. While I don’t think the project is ready for production use yet, its potential success could mark a massive change in how large multi-platform applications are built. Let’s jump in!
You might be thinking, “Wait! doesn’t React already work on the web?” You wouldn’t be wrong. Unfortunately, traditional React and React Native build on a different set of primitives. React uses <div>, <p> and <input>, whereas React Native uses <View>, <Text> and <TextInput>. There are good historical reasons for this, since the building blocks of a web page and of a mobile app are quite different. Nonetheless, it would be great if we could use a single set of shared components.
React Native for Web’s solution is to provide browser-compatible implementations of React Native’s components — meaning, for example, that the <View> of React Native has a DOM-based version that knows how to render to a <div>. While not every React Native component is supported, enough of them are that you could (hopefully) share the majority of your code base.
In addition to the components themselves, styles for React and React Native are written differently. With React, most people use plain CSS or a preprocessor such as Sass4. But in React Native, all styles are written in JavaScript, because there is no DOM and no selectors. With React Native for Web, styles are written just like they would be for React Native, rather than with CSS. This has the benefit of allowing you to write a single set of styles, which will work on both native mobile and the web.
We’ll take a deeper look later at how these ideas work in practice and at how much code is actually reusable. First, let’s get a sample app going.
To get started, we will need to set up our project. At first, this will just be a regular React Native app, and then we’ll add React Native for Web. If you are following along, you’ll need to complete React Native’s “Getting Started325” guide before heading into the next section.
Once you’ve got React Native installed, you can run the following command from your terminal:
react-native init ReactNativeWeb
This will make a new React Native project named ReactNativeWeb. After it has finished installing, you can cd ReactNativeWeb, and then react-native run-ios or react-native run-android. If everything has gone correctly, you should see a friendly welcome message on your iOS or Android simulator or device.
Notice that React Native has created two JavaScript files in our project’s directory: index.android.js and index.ios.js. You can edit any of the styles or logic in these files and see those changes update in the running app. As you can probably guess, the .android.js file is for Android, and the .ios.js file is for iOS. Fortunately, separate files are only needed when you want multiple versions of a given file per platform. Most of the time, you’ll have a single file per component.
Before we can get our app running in a web browser, we’ll need to get a bit of package installation out of the way. First, run the following to install both the react-native-web package and the official React web packages.
npm i react react-dom react-native-web --save
(You might see some errors about peer dependencies from this command. You should be safe to ignore them, because they didn’t cause me any problems. If newer versions of any of these packages are out when you run the commands, though, you might need to adjust the installed versions.)
At this point, your package.json file should look something like this:
While we have what seems to be everything required for our React Native app to run in a web browser, we must take a brief detour to consider the realities of web development. React Native’s packager compiles your ECMAScript 6 code to something that a phone’s JavaScript engine can understand, but it won’t help us in the browser. If we tried to run our app in a web browser right now, it would quickly fail due to syntax errors.
To solve this problem, we will use Babel10 and webpack11. Babel will compile our ECMAScript 6 code into browser-compatible ECMAScript 5, and webpack will bundle the compiled JavaScript, as well as just generally make development faster. (There are other options for this. If you prefer another compiler or bundler, feel free to use it instead.)
Here are the installation commands to run:
npm i webpack babel-loader babel-preset-react babel-preset-es2015 --save
npm i webpack-dev-server --save-dev
Here, babel-loader and webpack-dev-server will be used to bundle and serve our JavaScript, while babel-preset-react and babel-preset-es2015 tell Babel which plugins we need to compile our code.
Here is what your package.json file should look like now:
First, we’ll make a webpack config file. This file tells webpack how to build, bundle and serve our compiled code. In addition, we are going to use the alias property to automatically replace imports on react-native with react-native-web. This file should be placed in your project’s root.
Finally, we must make an index JavaScript file for the web. The contents of this file can be the same as index.ios.js or index.android.js, but with one additional line to attach to the DOM. The div with the ID react-app from our HTML file must be selected and then used in the call to AppRegister.runApplication.
Now, just run ./node_modules/.bin/webpack-dev-server --inline to start webpack, and open your browser to http://localhost:8080/12. Fingers crossed, you will see a familiar welcome message but in the browser!
Let’s start by making a friends list. This will be a good simple stress test of React Native for Web, because we need to use a few different components for it: <Image>, <Text>, <View> and <ListView>.
We can work around this lack of support for now. Let’s make a Friend component for the individual rows, but have a FriendsList component per platform. This will separate out the shared code that works everywhere but allow us to customize each platform where we need to.
On iOS, our ListView usage code is unchanged. (I’m leaving out the Android code example here and for the rest of the article, for brevity. The Android and iOS code can be the same for the rest of the code samples.)
Much better. At this point, hearing that ListView requires workarounds might be enough to make you think that React Native for Web isn’t ready for production use. I am inclined to agree, particularly since lists constitute a large percentage of many applications. How much it matters will vary depending on the project, though. On the bright side, all of our other React Native code so far has been completely reusable. In any case, I am still interested in exploring it further, because there is still much potential in the ideas on display here. Let’s continue with our sample app.
Instead of hardcoding a handful of list items, we can use JSON Generator21 to create a long list for us to work with. If you haven’t used it before, JSON Generator is a great tool for creating dummy and development data. Here is the structure I have defined, which adds a few fields on top of what we already have.
To use it, just take your generated JSON and replace our friends array declaration from before. Of course, you can move that data into its own file if you’d like, so that your code files aren’t cluttered with data. In a real application, we would get that data from an API server.
Next, we can add an animation with a transformation to see how well those work. Let’s make it so that when you tap a row, it animates left and right before returning to its initial position. We will need to add imports for Animated and TouchableOpacity, and wire up the animation and press handler.
No luck. Our TouchableOpacity throws an error when pressed. Apparently, this will be fixed30 in the next release and is only present for our particular combination of versions. Attempting to run the animation without using TouchableOpacity causes the same error, too.
I am going to stop here, but if you want to continue on your own, here is a list of topics you could research next:
How well do the remaining React Native components and APIs work? We’ve seen that some definitely don’t work, but we don’t yet have a comprehensive list of support.
You could explore more extensive styling work, including media queries.
React Native for Web supports server rendering. This could be particularly cool because, if it works, it would mean that you could have a single code base driving native mobile applications and a responsive web app that is SEO-optimized.
As you can tell, React Native for Web is definitely not ready for production. There are too many unsupported components, even in our small demo app, for me to feel confident about using it in a real project. The most encouraging thing to me, though, is that the pieces that do work seem to completely work, and the parts that don’t, fail entirely. I find that much preferable to the entire thing just kind of working. At the moment, it seems like the project just needs more time to build support. If everything was only 50% functional, I would view that as a sign that the approach is fundamentally broken.
Despite the problems, I still think this is a very exciting project and worth keeping an eye on.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
I shut down my browser on Wednesday, accidentally having a setting switched on that clears history and all sessions. First, I was sad to have lost many tabs with articles I stored “for later”. At the same time, it felt refreshing, liberating to have a clean browser window with zero tabs open. So my new goal is to start work in the morning with a completely clean browser window at least once a week.
In other news: I spent several hours fixing broken links this week, and as a result I can’t say how happy I am that archive.is1 and archive.org2 exist to prevent content from disappearing forever. Still, some of the resources I found broken have left forever. So remind yourself about redirecting content.
There’s a big change coming up for how we write colors in CSS. Tab Atkins recently changed the color functions syntax3 in the CSS specification. So in future, we will write rgb(0 255 0 / 50%) instead of rgba(0, 255, 0, 50%). This might sound awkward after years of doing it differently, but the reason for it are the new color functions available in CSS Colors Level 4, including color(). You can read more about this in Tab’s blog post, but for now be assured that the old syntax is likely to be supported forever in our browsers thanks to legacy support.
Opera 39 and Chromium 52 hit the streets this week and with them a couple of new features4: The Fetch API now supports a custom referrer policy, Performance Observer5 is supported, just like alpha channel for RGB colors in hex notation (#ffffff50), and CSP 3’s strict-dynamic directive is now available as well.
The new Docker for Mac and Windows is finally production-ready6 after several months in beta. Great news for all users who eagerly awaited it but always had issues with the previous version (i.e. disk and permission management problems).
Big news from Mozilla this week: With Firefox 487, the multi-process engine e10s is now enabled for many users, making Firefox much more robust, faster and more reliable. Also, protection against harmful downloads has been improved8 and unsigned/unverified add-ons won’t load anymore. Web Extensions support9 including CSP enforcements for web extensions is also new, just like the about:debugging developer page. For developers, the DevTools come with an improved font inspector, calc() is now supported for line-height and can be nested, and, last but not least, support for the CSP directive upgrade-insecure-requests has been added, too.
Microsoft pushed Edge 14 this week10 and with it a lot of great new things11. Notably, the new version got a lot of accessibility improvements and now competes as one of the best browsers in the HTML5 Accessibility test1412. New features also include extensions and pinned tabs and performance got better to improve battery life, too. Fellow developers will be happy to hear about web notifications, the Fetch API, Beacon Interface, JavaScript’s asyncawait, and support for <time> and WOFF2.
Dave Rupert reflected on hidden expectations15 and why the hardest parts of the web are the ones the client doesn’t see. Accessibility, security, and performance serve very well as main examples for such hidden expectations.
In our industry, it’s important to have a connected workflow between design and development16 to make sure we’re aligned and to make real collaboration possible. Subjects like “avoiding assumptions, team up with our peers or sharing knowledge” will help us work together in a better way, says Simon Colijn.
We take GitHub for granted. We pay for it and we use it as the primary end point for our git-repositories. Now Fabio Akita shares why it’s the more expensive option and how you can use the open-source alternative gitlab19 on a pre-configured VPS that is cheaper and more flexible. At least worth reading.
Proofpoint published a very interesting in-depth analysis of a big malvertising network20 that they found in the wild and that hid itself from plain sight by using steganography and file whitelisting. There’s evidence that they targeted a daily traffic of 1-5 million high-quality client hits.
Mathy Vanhoef and Tom Van Goethem presented a new HEIST-attack on HTTPS pages to steal SSNs, email addresses, and more. You can view the slides21 (PDF) or read the write-up22 (PDF) to understand the attack and what you can do to prevent it.
Mike West, one of the main persons pushing security web standards at the moment, proposes to introduce an origin-wide policy manifest23 to reduce the risk that security policies aren’t applied to specific resources. The proposal suggests to use a file in the /.well-known/origin-policy/[name-goes-here] directory on the origin server, adapting an already used folder name and path.
The well-known security researcher Jonathan Zdziarski found an issue in Whatsapp’s iOS app that seems wide-spread in iOS apps in general: Deleted chats aren’t deleted24, which means that forensic experts could reconstruct them. Any app that uses SQLite on iOS has the same issue since deleted entries are only set “free” to be overwritten instead of actually deleted. In fact, Apple’s Messages app faces the same issues, and cloud sync makes this even worse as it spreads the deleted information to other devices. Jonathan finally shows how to implement an SQLite database in an iOS app to prevent this issue.
The Battery Status API in general sounds like a great addition to our web platform. Initially built by Mozilla to complete the API-set on the web, we can use it on websites to reduce the amount of interactivity and animation or serve videos in low resolutions when the battery is nearly empty, for example. Lukasz Olejnik, however, found out that this API is actually already used28 as a user tracking identifier by ad networks and others. And last but not least, it can also be used to charge more for a service when a user’s battery is low — as reportedly done by Uber29.
Mattias Geniar had a look at Google’s new QUIC protocol30 that uses UDP instead of TCP and manages to be more reliable and faster — an ideal candidate as a successor to the TCP protocol. While it’s still at an early stage, the IETF is considering to make it a standard, Google uses it for some of their services already, and several server and browser vendors have plans to implement it, too.
For very big websites, we often tend to use a CMS, as this seems to be the best option at first glance. But what about choosing a static site generator for better performance and less security risks? Stefan Baumgartner shares his experience with using static site generators at scale31 and how they even built something like a content management system around it.
React is a bit different when it comes to technical design decisions. Chris James Hycner looks into SVG icon systems for React.js32 and how to build a well-working module for it.
Ben Frain explains the native JavaScript array methods34 and how they differ from each other. A great introduction (or reminder) of what we can use today to get data out of arrays.
For long articles, a scroll indicator can be very useful to indicate the reading progress. Most people use some sort of JavaScript code to do this (which is calculation-expensive); some people, however, find clever tricks to do it with CSS. The CSS-only scroll indicator35 by Mike Riethmuller is an awesome show-off of using gradients, viewport units and a pseudo-element.
Tom Bartel shares some great thoughts on recalibrating your productivity sensors as a developer40. Reframe your work, whether it’s managing people, talking to others, or actual coding work whenever you think you’re not productive. Most of the time it’s simply untrue.
Simon St. Laurent on decentralizing the web41. Some useful thoughts about our current lock-in on technology, service providers, and centralized solutions, and how we might be able to break that up again to unlock the real power of the web.
Katharine Viner writes about how social media swallowed the news42 and how the consequences of this go far beyond journalism. Does the truth even matter any more? An interesting essay on how well-done social marketing has an enormous influence on the decisions people make — no matter if it’s about buying a product or making a political decision.
Since the financial crisis, the private equity industry has become hugely influential. The New York Times curated a lovely, interactive story about how private equity plays out in your daily life43.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
When I first learned about the Meteor JavaScript framework, I saw someone write, “Meteor is to Node.js as Rails is to Ruby,” and I think that’s a good comparison. A few years ago, Rails was the hot new thingon the web, sprinkling some useful “magic” through the development process to make programming on the web more approachable and pleasant. Out of the countless new frameworks that have spawned as of late though, none have made me feel the way Rails did as much as Meteor — a framework that you should seriously consider using for your coming projects. Here’s a few reasons why.
1. Your applications are real-time by default.
Lately, companies like Twitter and Facebook have been moving toward a real-time web. It’s inevitable that, sooner than you probably expect, users will expect web applications to work near-instantaneously. I imagine there’s already users who wince whenever a separate page load is required for simple tasks like changing settings and logging out.
The problem is, creating real-time web applications is tricky. Or at least, it was. Meteor has real-time built into its core though. When the database is updated, the data in your templates is updated. When a user clicks a button or submits a form, the action occurs immediately. In the vast majority of cases, this doesn’t even require any extra effort. You build a web application as you normally would and, out of the box, it just happens to be real-time.
A while back, the folks at Meteor released a screencast to demonstrate these real-time features, and it’s very much worth a watch, but there’s a range of production applications that do an even better job of showing off the Meteor difference:
One of the frustrating parts of being a web developer is the need to wear a variety of hats. You need to think about the front-end, the back-end, and the database, and then there’s another million details that squeeze out the last inch of your mental capacity. Meteor simplifies this process by shrinking the scope of what you need to consider, allowing you to build and manage the front-end, the back-end, and the database with nothing but JavaScript.
This, for instance, is how we create a “collection” — the equivalent of an SQL table – in Meteor:
BlogPosts =newMeteor.collection('posts');
So, we can create a collection with a familiar syntax, but also manipulate a collection with a familiar syntax. Here’s how we insert data:
BlogPosts.insert({
title:'Hello World',
content:'This is the content.',
published:true});
There’s another benefit to writing an entire application with one language. One line of code can run on both the client and the sever and do different things in either environment. Here’s why this matters:
When the statement to create a collection runs on the server it, predictably enough, creates a collection. But when that same statement runs on the client (which it will do by default), it creates a purely local collection within the user’s browser. The user then interfacts with the local collection directly, which is why the data on their screen can change instantaneously, while the local and server-side collections are seamlessly synced in the background.
This doesn’t require any special treatment. You write one line of code and are provided with a boat-load of functionality in addition to being able to use a familiar syntax throughout the development cycle.
3. You can save a lot of time with smart packages.
Let’s say you want to create a user accounts system within a Meteor project. How might you approach it? If your first thought was, “Well, I’d create a collection for the user’s data,” then you’re already thinking too hard.
In Meteor, this is how we create an accounts system:
meteor add accounts-password
We run this command in a terminal, and Meteor adds one of its built-in “smart packages” to the project. This particular package creates an accounts system that expects an email (or username) and password. But what if we wanted to let users sign up with their Twitter account? Then we could write:
meteor add accounts-twitter
Or, with their Google account:
meteor add accounts-google
Or, Facebook:
meteor add accounts-facebook
We could even run all of these commands so our users could choose how they want to sign up.
Meteor also provides an accounts-ui package that creates the front-end of this accounts system, and that only requires one other command:
meteor add accounts-ui
With our account system in place, we can do everything we would reasonably need to do when working on a web application, like checking if the current user is logged in via one of our templates:
Or navigating through and manipulating the Meteor.users collection, which is the collection that Meteor creates to store the data of our users.
Smart packages are not just for accounts though. There’s a range of them already available, with more presumably on the way, and they all allow you to do something cool, including:
Writing your applications in CoffeeScript.
Automatically compiling LESS files into CSS.
Integrating extras like D3.js and Bootstrap.
But if smart packages don’t have what you need, then the increasingly large library of third-party packages will probably have you covered.
4. The community is extremely supportive.
Nothing attracts me more to a new framework or technology than an active and vibrant community. I figure that, if the community’s active, then:
There’ll be a lot of detailed documentation.
I’ll waste less time getting up to speed with the basics.
The technology won’t hit the deadpool in the near future.
Luckily, Meteor’s community is already one of its greatest assets. There’s a ton of helpful resources that have spawned from people’s love of the framework, including:
Crater, a Reddit-like site for keeping track of what’s happening in the world of Meteor.
Evented Mind, a video training site for intermediate developers wanting deeper insight into how Meteor works.
Kadira, a performance tracking application that is both easy to use and has a reasonable free plan for getting started.
The official YouTube channel for Meteor has a range of talks from Meteor meetups and there’s plenty of blogs to follow for tips and tutorials:
But if you’re still not satisfied with what’s available, Stephan Hochhaus maintains a huge list of Meteor resources that has a little something for everyone.
5. It’s optimized for developer happiness.
Just about every framework markets itself as a better and more enjoyable way to work. What I appreciate though is Meteor’s attention to detail in holding true to its promise of optimizing for developer happiness.
This is a basic interface for a Meteor application with a template included between the body tags. (For templating, Meteor uses Spacebars — a Handlebars-inspired syntax.)
But notice that:
We haven’t included the html tags.
We haven’t included any CSS files.
We haven’t included any JavaScript files.
…and that’s because we don’t need to do these things since Meteor takes care of them for us. Is this the most significant feature in the world? Nope. But it’s indicative of Meteor’s interest in making every developer’s life that little bit easier at every turn.
Other pleasant details include:
A built-in LiveReload feature so you won’t have to manually refresh your browser.
The freedom to structure your projects however you want. There are standards you can follow but no strict rules or conventions.
The sheer modularity of Meteor that allows you to mix-and-match different components in case one part of Meteor isn’t to your liking.
So while Meteor has its fair share of “magic” and conventions designed to make your life easier, you can still make choices based on your personal preferences. It’s the best of both worlds.
6. It’s friendly to beginner developers.
What surprised me about Meteor was how quickly I was able to start building things that were actually kind of cool. I’d heard people refer to the framework as “easy” but, usually, other people’s definition of that word differs from my own. In this case though, they were right:
Meteor is one of the easiest frameworks for beginners to learn.
It’s still programming, and you’ll want to be familiar with the syntax of JavaScript — variables, loops, conditionals, JSON, etc. — but you don’t need to be a JavaScript ninja to make a start. You don’t even need prior experience with making web applications (it’s a great choice for front-end developers looking to bolster their skillset). You might not grasp all of the concepts right away but that won’t stop you from enjoying the practical side of things.
As for why Meteor is such a great fit for beginning developers, it’s mostly for the same reasons that I recommend Meteor in general:
You only need to know a single language.
There’s a ton of community-made resources.
It’s optimised for developer happiness.
So even if you stumble across a slight hump when learning Meteor, just push a little further and I think you’ll find that those humps are few and far between.
7. It’s ahead of the tech curve.
Like I said earlier, the web is becoming a real-time environment, but the shift won’t happen purely based on the actions of the big companies with the big budgets. The shift will happen as tools become available that allow small teams and individual developers to make real-time applications quickly and easily. Meteor is amongst the first wave of this tools and its “all in one” approach is surely going to make it a big player in the coming years.
The folks at Meteor have stated their long-term mission, and to put it plainly, their mission is huge:
…to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.
Can they pull this off? No one can say with absolute certainty, of course, but they have the funding, the community, and the ever-important balance of being great for developers and great for end-users. So at the very least, they’re on the right track (and it’s a track where I’m glad to be tagging along for the ride).
Conclusion
As of writing these words, Meteor is still young at version 0.8.2, but the releases are coming big and quick, and a range of impressive Meteor-built apps are live and being used on the web. Your particular situation will determine whether or not a particular framework is the right fit for you and your creations, but every developer owes it to themselves to at least play with Meteor for a day or two. I haven’t had this much fun with programming on the web in a long while and there’s a good chance you’ll feel the same way.
David Turnbull is the author of the Meteor Tips blog, a regular source of tips, tricks, and tutorials for the Meteor JavaScript framework. He’s currently hard at work on a screencast series for beginning developers to get started with Meteor.
When working in a team, it’s important to stick to rules. A common challenge is to build all your projects with a similar or the same toolset and coding guidelines. Only yesterday I discussed how we could port over a project that outgrew its initial codebase over the years to a fresh, React.js-based source code.
The decision for this wasn’t easy, since we had invested quite a lot of work and money into this project already, and a move to React would require quite some time, too. But since the switch makes sense from a technical perspective and the team is already using React for three other projects, we concluded that this would be a good step to do. It will enable more developers of the team to contribute to the project, to review code and to reduce the shift of technologies in the company. Occasionally, it’s time to re-evaluate your projects and move on.
Bootstrap 4 Alpha 31 has been released this week. It comes with an overhauled grid, updated form controls, a system font stack, and more.
Microsoft announced that their JavaScript engine ChakraCore2 now supports Mac OS and Linux. This means, you can now test and run your Node.js applications not only in Google’s V8 engine. Christian Heilmann wrote up why this is an important step3.
If you work on small projects, an (S)FTP-client can still be very useful. But on the other hand, it means you need to manually copy files from your git workflow to the server. To solve this issue, the indie developer Jan Östlund built GitFTP-Deploy8, a handy (S)FTP tool for a small fee that does automatic deployments based on your git workflow.
The privacy/tracking issue is bigger than we think. Have you ever monitored which apps connect to which service? You suddenly realize that an ad blocker/privacy add-on in your browser is only a drop in the bucket. Apps often connect to Google services, Google Analytics, sometimes to various ad networks, and very often to New Relic’s user tracking service. Fortunately, there’s a solution to nearly every problem: Add tracker hostnames to your /etc/hosts file. There’s even a public sample hosts file that you can use9 that includes most ad networks and trackers. Use it at your own risk though and be aware that some apps might not work anymore. But maybe your privacy is worth it?
FallibleInc’s “A practical security guide for web developers10” tries to help developers build more secure, less vulnerable solutions. While they claim that it’s by no means a comprehensive guide, it covers stuff based on the most common issues they’ve discovered in the past.
We know that HTTPS is not super-secure. That’s why lately a lot of bugs were fixed in the software implementations and a lot of techniques like HSTS and HPKP were added. But sometimes all of this won’t help. Recently, an attack was discovered that can be carried out by operators11 of just about any type of network, including public Wi-Fi networks, which arguably are the places where people need HTTPS the most. There are also hints that this type of attack is already in use by at least the NSA and therefore likely by a lot of other people, too. Please never trust TLS only for your own security but use a VPN for public networks.
I don’t want to be the scapegoat here, but Pokémon Go is very popular, and I read some interesting things about the privacy of the game. For example, not only Alphabet (aka Google) is one of the main investors, but there’s also a financial relationship between the game-maker Niantic and the CIA angel investment company In-Q-Tel15. While there’s no evidence on what this could mean for the privacy of users, it definitely means that those companies are highly interested in the data that is provided by the gamers — understandable, as it’d be very hard to get geo information and pictures of private ground in a normal way. I’ve heard that several companies such as BMW already advised their employees that it’s forbidden to play the game at their factory sites and the German army published a similar order to their soldiers. ExpressVPN also published a short summary list with nine privacy issues to consider when playing Pokémon Go16.
Erik Duindam writes about how a good architecture can save you a lot of money when building a product. He shares how he built a Pokémon Go app with 500k users in just five days17 and reduced the costs of it to a $100/month server infrastructure, compared to many MVP products that burn money by choosing bad technical designs.
Jake Archibald shares an interesting little fact about the benefits of using rel=noopener: it’s faster18.
Addy Osmani explains how to build accessible UI components for the web19, taking into consideration visual, hearing, mobility and cognition as accessibility factors. A pretty great entry-level guide to better, accessible products.
We have some evidence already that multitasking isn’t beneficial for productivity. Lydia Dishman now wrote up what changed when she moved to monotasking for a week. The reason why I found this article particularly interesting, is realizing how much multitasking we do during a normal day without taking note of it26.
We still might not know if it’s our fault that the climate is changing29. But what we now know is that Greenland’s ice-shield lost twice as much ice in the past four years30 as in the 20 years before that. And this means much faster-rising sea levels, the loss of drinking water, and the loss of an important weather control on Earth (the Arctic has much influence on how storms and weather develop). In the end, it’s us who suffer from it, so we need to act and do our best to stop this trend.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
If your business has seen successful growth in the US, it most likely will see success in other countries as well. And, you may want to lock up those markets, before some other company does.
I recently met a startup that had successfully tripled its revenues – largely from the results of a successful international expansion effort and wanted to share those learnings with all of you.
Pick your markets
All Killer, No Filler
We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.
There are 195 countries in the world. How do you even know where to start?
Many US companies go after the path of least resistance: In other English speaking countries, like Canada, the United Kingdom, Australia and New Zealand, typically in that order of closest to home.
While that is certainly a good strategy, a better strategy is figuring out which countries have the highest demand for your products. For example, if you’re selling into the auto industry, perhaps big auto markets like Japan and Germany may be the best place to start.
Like anything, there will be an 80/20 logic here, where 80 percent of your international sales will come from 20 percent of your international markets. So, carefully prioritize your efforts.
Pick your structure
There are many ways to take your business global, with various levels of complexity and investment. You’re going to need to decide between opening our own office overseas, leveraging key in-country distributors or striking channel partnerships with key companies that have access to your target customers, based on your goals and budgets.
And, the solutions you use in one country, may not be the same solution you use in others, depending on the challenge in those markets. For example, in China, you’ll need a local company to partner with, to help you navigate the local market.
Where you can, setting up your own efforts, either as a startup or via an acquisition of a local player, will typically exceed the results of piggy backing on the efforts of others.
Learn the local rules
Every country has different “rules of engagement”. And, when you’re getting started, it’s often helpful to engage an international expansion consulting firm, that can help you quickly learn all the local laws, regulations, accounting rules, business taxes, government taxes, employment vs contractor rules, compensation rules, privacy rules, etc.
And, don’t underestimate the downside risks from things like bribery payments, organized crime and other corruption in various countries, which you never want to partake in, or risk going to jail.
These varying rules can make the difference in deciding whether or not those markets make sense for you.
Localize your fulfillment
Make sure you have a plan for communicating in foreign markets.
You’ll have to think through all the back office tasks for your business and how it will be different overseas.
Who will be answering the phones (in the local language and during local business hours), how will products be warehoused and shipped, how will you collect payments from customers, how will you process payroll payments, into which bank accounts, who is going to train your local customers, who is going to service local customers post sale, etc.
Often times, it’s like building a whole new fulfillment process from scratch.
Localize your marketing efforts
Every country has a unique culture of its own. And, you need to tailor your marketing creatives into the messaging that will most resonate with the local market and stand out against local competitors (who are most likely different companies than the ones you’re competing with in the US).
If you’re already successfully selling into global companies today, be sure to ask your US contacts at those companies for introductions to their counterparts in the countries you desire to enter.
Anyway, hope you found this high level introduction to the topic helpful. Global expansion is a really tricky topic to cover is a short post, given all its complexities by country, so be sure to surround yourself with expert consultants, lawyers and other global entrepreneurs that can help you here.
Fusion reports that police officers contacted Michigan State University professor Anil Jain recently to recreate a dead man’s fingers using a 3D printer, so they could unlock his phone and sift through its content for clues.
Details are scare because the investigation is still underway. But Jain said that the deceased person in question was the victim in a murder case, not the attacker. Law enforcement officials had his fingerprints on file as he was arrested in a previous incident, and handed those over to Jain for replication.
All Killer, No Filler
We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.
The victim’s phone hasn’t yet been unlocked – Jain has created replicas of all ten digits, but is still working to refine them so the plastic fingers coated with metallic particles can be read by a fingerprint scanner as easily as human fingers, which are more conductive.
In October 2014, a Virginia court ruled that suspects can be asked to unlock their phones using their fingerprints. In contrast, PINs are more secure because the Fifth Amendment prevents government agencies from compelling people to turn over things in their minds, like memorized passcodes.
It’s also worth keeping in mind that phones locked with a fingerprint usually require a PIN to be entered if it hasn’t been used in 48 hours, or if it’s been powered off and back on again. In both instances, fingerprints are of no help, regardless of how they’re obtained.
This case could also set a precedent for law enforcement gaining access to people’s phones more easily. If a person has been arrested and their mobile device has been confiscated, they could be asked to merely submit to a fingerprint scan that would give police everything they need to create replicas for unlocking a phone.
The extent to which fingerprints and PINs can help protect our privacy seems to be rather limited; ultimately, what we really need is transparency and oversight when it comes to how our digital data is handled by law enforcement and government agencies.
A new vulnerability discovered by a Cisco researcher could allow hackers to gain access to the internal storage and stored passwords on your iOS or Mac device – and all they’d have to do is send you a malicious image file.
Tyler Bohan of Cisco Talos found that a TIFF format file – sent via MMS, email or placed on a webpage that a victim is guided to visit – can hide malware which can run automatically, without being detected.
All Killer, No Filler
We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.
In addition to beaming across your authentication credentials on iOS, Mac OS X, tvOS and watchOS, the vulnerability can also allow attackers to remotely control Macs which don’t support sandboxing.
Thankfully, these issues have been patched by Apple; you’ll need to update to the latest versions of their operating systems – iOS 9.3.3, El Capitan 10.11.6, tvOS 9.2.2 and watchOS 2.2.2 – to stay safe.
That’s why he’s collaborating with famed hardware hacker Andrew “Bunnie” Huang to create an iPhone 6 case that can detect whether your phone is transmitting data when it’s not supposed to. The idea is to protect journalists, rights workers and the like from being tracked by governments and to expose their agencies’ efforts to spy on such people.
All Killer, No Filler
We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.
The case is still just a concept at this point, but the duo have published a paper describing its design. Essentially, it will feature probe wires that access the phone’s antennae through the SIM slot to monitor them signal transmission. A display on the outside of the case, along with audible alarms, informs users of the phone’s status.
It certainly might be overkill for ordinary civilians who harbor only minor distrust in their governments, but it might be just the thing for journalists who cover sensitive issues in areas of conflict.
In their paper, Snowden and Huang cited the case of American reporter Marie Colvin of The Sunday Times, whose family claims she was tracked by the Assad regime in Syria and killed for covering stories about civilian casualties.
WordPress comes with so many awesome features and is continuously changing. Some of these features may not get the attention they deserve and remain a little hidden. In this article, we will show you 10 awesome WordPress features that you probably didn’t know existed.
1. Show/Hide Things Using Screen Options
You may have noticed the Screen Options button on some pages of your WordPress admin area. This Screen Options button allows you to show and hide items on the WordPress admin screen you are currently viewing.
Many beginner WordPress users are unaware of this feature. It allows you to simplify your admin pages like post edit screen to meet your workflow.
2. Move, Add, or Delete Dashboard Widgets
By default, users are redirected to the dashboard page in WordPress admin area when they login. The dashboard page has several handy shortcuts pointing to different sections of your website.
These sections are divided into different boxes called dashboard widgets. You can click on the Screen Options button to show or hide these boxes. You can also drag and drop them to rearrange items on your WordPress dashboard.
3. Paste URL to Make Links in Visual Editor
WordPress 4.5 introduced inline link editing in the visual editor.
Many users didn’t realize that instead of using a popup to paste a link, they can just select a text and press CTRL+V (Command+V on mac) to paste the URL. The visual editor automatically converts it into a link.
4. Accessibility Mode for Widgets
We all like how easy it is to just drag and drop widgets into sidebars. However, for many users it is not easy to drag and drop things using a mouse or trackpad.
WordPress also comes with a hidden accessibility mode for widgets. This accessibility mode makes it easier to add widgets without draging and dropping the items.
Accessibility mode for WordPress widgets can be activated by clicking on Screen Options button on the Appearance » Widgets page.
5. Preview Themes Without Activating Them
Many users worry that changing their WordPress theme will have unwanted consequences for their website. Their concern is genuine, that’s why we prepared a checklist of things you must do before changing your WordPress theme.
One of the things you can do is to test the new theme without activating it. Simply install your new WordPress theme and then go to Appearance » Themes page.
Take the mouse to the newly installed theme’s thumbnail and then click on Live Preview button. WordPress will launch the theme customizer showing preview of your website using the new theme.
6. Edit Images in WordPress
WordPress makes it easy to add images to your posts and pages. What many beginners don’t know is that WordPress also comes with some basic image editing features.
Simply visit Media » Library page and then click on any image. From the image details popup you can click on the Edit Image button.
In the image editing mode, you can crop, rotate, and resize an image. You can also flip an image in horizontal or vertical directions. These image editing features come in handy when you need to quickly crop or resize a large image file directly from WordPress.
Want to split a lengthy post into multiple pages? Simply add <!–nextpage–> tag in your post and WordPress will split it into two pages. Add the tag again if you want to split it into more pages.
This feature is particularly helpful if you are writing an unusually lengthy article and don’t want users to scroll to much.
WordPress automatically embeds content from some of the most popular websites like YouTube, Twitter, Instagram, etc. All you need to do is paste a URL from one of the supported sites and WordPress will automatically embed it for you.
Since WordPress 4.4, all WordPress sites have become oEmbed service providers themselves. This means you can paste URL from another WordPress site into your post and WordPress will embed the post for you.
9. Hidden Secret Options Page in WordPress
WordPress comes with a hidden master page for all your blog options. This page is hidden because users can easily mess things up here, so we don’t want you to use it. But you should definitely check it out. You can access it by visiting this URL:
http://example.com/wp-admin/options.php
Replace example.com with your own domain name. You will see a page with a long list of options. For more details see our guide on the hidden secret options page in WordPress.
10. Markdown and Keyboard Shortcuts Help you Write Faster
Most WordPress users spend more time writing content than anything else on their site. This is is why WordPress developers are always trying to improve the writing experience in WordPress.
WordPress comes with a whole range of keyboard shortcuts that you can use to write faster. Apart from these shortcuts, you can also use Markdown like formatting shortcuts. Just enter the formatting shortcuts and WordPress will convert them into HTML.
Using * or – will start an unordered list.
Using 1. or 1) will start an ordered list.
Using # will transform into h1. ## for h2, ### for h3 and so on.
