Do you run or help promote a local business? Interested in taking advantage of the latest gaming craze? Pokémon Go is close to topping the number of daily users on Twitter and average time spent on the Facebook app. That’s why it’s time for your business to capitalize on it. In this article, you’ll discover [...]
This post 8 Ways to Use Pokémon Go for Business first appeared on .
- Your Guide to the Social Media Jungle
Continue reading %Versioning Show, Episode 1, with Craig Buckler%
Earlier this year saw the release of Google’s mobile search ranking algorithm, dubbed by many as “Mobilegeddon,” which included “mobile friendliness” as a mobile ranking signal. In case it wasn’t clear that you need to approach your mobile SEO differently from your normal SEO, it should be now!
If you fail to take the differences for mobile SEO into account you’ll lose out on a significant source of traffic: in the US, Google processes more queries from mobile devices than it does from desktop.
One important thing to keep in mind while devising your mobile SEO strategy is that mobile SEO is all about context - people searching on a mobile device have very different intentions and expectations for what they find.
They’ll also use your mobile version differently to desktop and this should change how you design and promote it in order to move visitors through the conversion funnel. Use Google’s Mobile-Friendliness Test to get an idea of how the current mobile version of your site is performing and what you need to change in order to improve the mobile user experience.
In this piece, we’ll cover how you should approach mobile SEO from the ground up so you won’t block your own digital marketing efforts from reaching as many people as you’d like.
While there are obviously many signals for Google’s mobile search rankings, page speed is one of the most important. Mobile searchers have notoriously short attention spans and even fractions of a second in load time can make a difference. The time it takes to load a page is a major factor when it comes to user abandonment rate: nearly half of users expect a mobile page to load in two seconds or less. 40% will abandon a website that takes 3 or more seconds to load. Google expects you to render above the fold (ATF) content in one second or less. So each millisecond could be making a difference to your positions in search results, and money.
When designing for mobile, remember that most devices have less powerful CPUs than desktop computers and a short battery life, making it a challenge to meet the one-second ATF requirement. On top of that, you have to take into account the time it takes to complete the DNS lookup, TCP handshake and HTTP request and response. In the end you’ve only got about 400 milliseconds that you can do anything about. Take every step you can to reduce the strain you put on the user’s network.
Optimize your image size: don’t rely on HTML to downsize your image; it just changes the appearance, not the actual size. Use a photo editor like Photoshop to change the size of your images.
Rely on browser caching: reduce the number of HTTP requests by leveraging browser caching. Use Expires headers (if you’re using Apache) and Cache-Control headers to tell users’ browsers that images, stylesheets and CSS are cacheable.
Reduce/eliminate browser redirects: some redirects are unavoidable. Remember, every redirect is another HTTP request, which slows down load time.
Minify code: Use tools such as YUI Compressor or JSMin to remove unnecessary characters from JavaScript and stylesheets on your mobile site. This can improve caching and reduce bandwidth consumption.
Avoid external blocking JavaScript and CSS above the fold: Every time a browser encounters an external script while parsing a page it has to stop and download that resource. This adds a network roundtrip, delaying the ATF rendering. Use inline JavaScript and CSS to render ATF content and load any additional functionality after the ATF content has been delivered.
TCP Slow Start: A new TCP connection is unable to utilize the full bandwidth of a connection between the browser and the server, so the server is limited to 10 packets or less in the first round trip. This means it’s important to render in the connection, so your ATF content needs to be 14KB or less. Make sure your server is updated to the latest version or else you might be limited to 3 or 4 packets in the first connection!
Accelerated Mobile Pages: Accelerated Mobile Pages (AMP) are mobile optimized web pages that have been created using an open source specification, which allows them to be served instantly. Google stores validated AMPs in a dedicated cache and serves them from there. Using structured markup, these pages are then eligible to appear in a carousel that includes AMP-ready pages.
If you need to improve your speed, start with Google’s PageSpeed Insights tool. PageSpeed measures the performance of your page as both mobile and desktop user-agents and scores them on a 0–100 point scale. Scores of 85 or higher indicate high performance. It judges on time to render ATF content and time to load the full page. You can also use browser tools like the Developer Console in Chrome, Web Console in Firefox or Tools Console in Internet Explorer to find errors and bottlenecks.
As mentioned before, users don’t interact with mobile in the same way they do on desktop. They are usually looking for specific information to answer a question or complete a task. It’s your site’s job to make sure they can find information or complete an objective as quickly and efficiently as possible. This should be reflected in the user experience.
After speed, user experience is one of the most important factors that dictates whether visitors stay on your site to convert or leave after minimal interaction. The way mobile visitors use your site is fundamentally different from desktop. This is not only due to screen sizes — mobile users expect to be able to complete their goal almost immediately. 70% of mobile search traffic results in an action within an hour. Since we already know that mobile users are an impatient lot, you must optimize your mobile user experience to give visitors an even more direct route to conversions.
Don’t use Flash, Silverlight, Java or other plugins. They might make your page look great but they aren’t supported by mobile browsers. It doesn’t matter how good it looks - your visitors will leave your site if they can’t see parts of it. If you want special effects, use HTML5 instead.
Content needs to be readable without zooming in on the page. If you’ve set your mobile viewport, make your base font size 16 pixels — this is the default size for most fonts. You can then define other text sizes relative to the base. You should also stick with mobile-friendly fonts like Arial, Helvetica, Courier/Courier New, Times/Times New Roman or Verdana. Limiting the text on your page will also allow you to use a larger font size.
Keep touchscreen readiness in mind. A user’s ability to quickly and easily navigate using their finger is a critical part of mobile friendliness. Your tap targets need to be at least 48 pixels in height and width with an extra 32 pixels on all sides. Accidental clicks lead to major frustration for users and severely impact your site’s usability.
Structure your content so that it’s easy and intuitive to find information or complete an action. You can use content to guide your users to an intended goal such as email sign up or account creation by prioritizing this content above the fold and using clear calls to action. Don’t distract them by putting unnecessary detail on your landing page. If a user really needs more information, they can always click through to a secondary page.
Make navigation on your mobile site obvious. If users can’t easily get around your mobile site 40% will move on to a more mobile-friendly site. To make sure you don’t lose out on this traffic, format your site vertically and make your back and home buttons prominent on each page. Use navigation bars, tab bars or a navigation hub to optimize page real estate dedicated to navigation.
When building your mobile site you have three options in how to tell search engines that you’ve got a mobile site: responsive design, dynamic design and a mobile subdomain.
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
Dynamic website design: this method requires a bit more development time investment. Sites that use dynamic design deliver different HTML code to mobile and desktop users by detecting the user-agent. You need to use the Vary HTTP header to tell Google that the mobile googlebot should crawl the page.
Mobile subdomain: this method requires more developer time and resources than the other two. It involves building an entirely separate mobile site and hosting it on a subdomain, usually mobile.domain.com or m.domain.com. Like with dynamic design, googlebot won’t be able to detect that your mobile subdomain is for mobile users. You’ll need to use the rel="canonical” tag to signal the relationship between the different versions of your pages. This method can be complicated and expensive, particularly for businesses with large websites, and is generally falling out of favor.
Continue reading %Your Guide to Getting Started with Mobile SEO%
h2>Headlines
Michael Mifsud shares his team’s experience during a recent switch to HTTP/2 for serving image assets. Don’t be fooled that HTTP/2 equals free perfomance. Awesome read. (99designs.com.au)
Bushel is a device management solution for the iPads, iPhones, and Macs in your workplace. It’s cloud based, so you can manage and protect your devices anytime from anywhere. No IT? No problem. It’s easy to manage your Apple devices with Bushel. Manage your first 3 devices for free. Add more for just $2/device/month. Create your free account today! (bushel.com)
Overflow menus seem like the perfect solution. Designers can “take away” complexity and leave just the really important bits. You can quickly and easily create a clean looking user interface. The trouble with overflow menus is that you didn’t actually take anything away, you just obnoxiously obfuscated it. (freecodecamp.com)
Combining React and Redux is a pretty hot topic at the moment. With a large amount of resources looking into getting up and running within a basic application, this post takes a different angle and looks at the lessons learnt pushing an app to production. (medium.com)
Allison McMillan has done a lot of thinking and discussing about what an effective interview process might be, especially for developers with 2-3 years of experience. Some great takeaways if you are in anyway part of the hiring process. (allisonsherenmcmillan.blogspot.com)
WordPress comes loaded with a series of hooks and filters that let you hook into specific parts of when WordPress operates. Simon Codrington digs in and gives us the low down. (sitepoint.com)
In this article Victor Savkin talks about why the Angular team decided to use TypeScript. He also shares his experience on how it affects the way he writes and refactors code. (vsavkin.com)
The WebKit team announced that iOS 10 will support silent <video> elements with the autoplay attribute. Great to see them thinking about users bandwidth and batteries. (webkit.org)
A new way to create single-page React applications. It offers a modern build setup with no configuration. (facebook.github.io)
An open sourced guide that covers a lot of common issues the web developers face on a day-to-day basis. (github.com)
This article introduces some well thought out styleguides and branding guidelines. It also details some of the most important elements every styleguide should have. (medium.freecodecamp.com)
Jon Moore shares some recommendations to help keep your Sketch designs organised so you stay efficient at all times. (medium.com)
We’re looking for a passionate Digital Product Designer in Sydney to lead and shape the future for some very exciting products from Australia’s top brands. (bilue.com.au)
We’re looking for a Senior Graphic Designer that can lead design within Typeform’s Creative Team. You’ll be in charge of creating all advertising, feature, and promotional content for our websites, social media channels and emails. (typeform.com)
The post Web Design Weekly #246 appeared first on Web Design Weekly.
So you’ve decided to cut costs by hiring a remote team, or you’re a boss that quite literally likes to live like a boss in a beautiful remote getaway in the Maldives — either are applaudable choices and I salute you.
[author_more]
Managing a remote team is not as difficult as it sounds; in fact it’s been noted that remote teams are 35% more productive and 11% happier because of the lifestyle they lead, and under your management this could be your team. All you need to do is hire the right people!
Information sources: Hubstaff and Zenefits.
It’s not unheard of for job-hunters to send out their resumé to absolutely everybody that is hiring without really reading the job requirements. Posting your offer on job sites aimed at remote workers ensures that you’re targeting the right crowd.
Here are the best and most well-known job boards for remote workers (feel free to suggest some more in the comments!):
It’s important to understand this first: a remote worker isn’t necessarily a freelancer, and a freelancer isn’t necessarily a remote worker. A remote worker lives far away from the rest of the team but can be hired as either a full-time employee or as a contractor, whereas a freelancer can only be a contractor but may live relatively local. It’s important for your hire to understand the unique challenges of working remotely.
Ideally, you should be a remote worker yourself so that you can understand and correctly explain these challenges; this ensures that you can effectively manage an employee that’s new to remote working, helping him/her gain experience with the concept.
Here are the questions you should be asking:
If you’ve discovered a remote worker from the right crowd, and you’ve asked them the critical questions, and you’re satisfied with the answers that they gave, you’ve probably found yourself a remote worker who could be a smashing asset to your team — but not without careful onboarding. New hires have a natural desire to prove themselves, which they can’t do without the support of a manager or team leader. Without this support, your team is left in confusion, which leads to isolation and a lack of confidence.
Your team needs to know:
With this level of support your team will remain happy, connected and confident in their abilities to collaborate when required and reach out for help when they’re feeling uneasy (as long as the support is maintained of course). For that to happen, your remote team needs to be using communication apps that facilitate openness and expression, and collaboration apps that inspire communication and team-wide problem-solving.
Since remote teams don’t converse face-to-face, they’re pretty much left to communicate and collaborate through app interfaces — and this is a good thing. Remote teams report that the inconvenience of timezones and lack of face-to-face communication results in fewer unnecessary/impromptu meetings and higher productivity. They found that instant messaging was faster, easier, more engaging and less time-consuming.
Continue reading %How to Hire Your First Remote Team%
So, you're a developer working on the next big thing. Your customers love your product and it's getting rave reviews on all the social networks. Even better, the CEO of the company has just secured $10,000,000 in funding to expand into new markets. But before you can go global, the product must be updated to support different languages, currencies, date formats, and much more. And guess what? You and your team are the ones in charge of making this happen. In technical terms, your software must be internationalized and then localized.
Internationalization (also known as i18n) is the process of creating or transforming products and services so that they can easily be adapted to specific local languages and cultures. Localization (also known as L10n) is the process of adapting internationalized software for a specific region or language. In other words, internationalization is the process of adapting your software to support multiple cultures (currency format, date format, and so on), while localization is the process of implementing one or more culture.
These two processes are usually adopted by companies that have interests in different countries, however they might also come in handy for a single developer working on their own site. For example, as you might know, I'm Italian and I own a website. My website is currently in English but I might decide to internationalize it and then localize it into Italian. This is beneficial for those that are native Italian speakers and aren't well accustomed to the English language.
In this article I'll introduce you to Globalize, a JavaScript library for internationalization and localization developed by some members of the jQuery team. All the snippets demonstrated in this article can be found on our GitHub repository.
But before delving into Globalize, I'd like to conclude this brief introduction on i18n with the words of Rafael Xavier de Souza, the lead of the project:
Developers think i18n is about translations to non-English languages. That i18n is only needed for expanding the current application to multiple countries or markets. I always try to explain that i18n is about "talking" in general. Every application, at some point, has to "talk" to its users. To talk with the users, the application may require pluralization support, gender inflection, date formatting, number formatting, and currency formatting. Even in English, it might be tricky to get this done properly.
Globalize is a JavaScript library for internationalization and localization that leverages the official Unicode CLDR JSON data.
The library is open source and it's developed by Rafael Xavier de Souza along with some of the members of the jQuery team.
Globalize is based on the Unicode Consortium's Common Locale Data Repository (CLDR), the largest and most extensive standard repository of locale data available. So, unlike libraries that embed locale data, if you use Globalize it's really easy to always be up-to-date with the latest CLDR data.
The library works both for the browser and as a Node.js module. Globalize 1.0 supports all major browsers including IE9+, Chrome, Firefox, Safari 5.1+, and Opera 12.1+.
The main features of the library are:
One of the things I like the most about Globalize is that it has a module for each of its features. A developer may not need the whole library and can thus cherry-pick the module(s) needed. Another interesting feature is that, unlike other libraries, it keeps the code separated from the content by not hosting or embedding any locale data in the library.
But Globalize isn't the only show in town. If you're interested in some alternatives, Rafael has a dedicated page. The most notable alternative is i18next.
To some of you this may come to a surprise, but JavaScript has native support for internationalization in the form of the Internationalization API (also known as ECMA-402). The Intl object is an object available on the window object which acts as a namespace for the Internationalization API. This API currently provides methods to format numbers and dates, and to compare strings in a specific language.
Now that you know of the existence of the Internationalization API, you could be led into thinking that Globalize uses it behind the scenes. This approach would surely lead to better date and number formatting performance. However, because the support is low and very inconsistent among browsers, the library doesn't use it.
Before we move on and start the discussion on Globalize, I want to give you a taste of the Internationalization API.
The first example I'm going to show uses the Internationalization API to format a date in several locales: IT, US, and GB.
Continue reading %How to Implement Internationalization (i18n) in JavaScript%
