Tag Archives: mobile

What Does Mobile First Index Actually Mean?


There are many things that a SEO analyst should master when it comes to SEO services. One of the examples is mobile first index, but first, let’s understands what indexing means. Indexing is described as the process of turning your webpage into something more useable and storing it in their database. You can find a lot of cool stuff that happens here. For instance, word vectors, and all kinds of other awesome computer science stuff. For our purposes though, Indexing is when they make a copy of your page in a format that’s useful to the ranking algorithm.

So What Is Mobile First Indexing?

Now, by creating signals based on Googlebot, you can figure out whether a site is mobile friendly or not. Therefore, a user searches Google the retrieval part of the algorithm looks at the desktop index created by the Googlebot desktop crawler. It finds relevant results based on the desktop index, then ranks them and even shows the searcher a snippet based on the desktop index. The ranker then looks at the mobile signals collected by mobile crawler and adjusts the rankings accordingly.

However, sometimes it can cause some problems. For example, in many cases where a user gets redirected and they realize that the content they saw in the search snippet isn’t available on the stripped down mobile version of the site.

Moreover, it is important to be remembered that “mobile index” and “mobile friendly” is a different thing. Mobile friendly is how you design your sites. So that it will be convenient enough to be displayed on your mobile. On the other hand, the categorization of mobile index includes three scenarios:

Responsive Site

Issues include things like changing the weights for tabbed content or drop-down menus which are probably less valued on desktop but shouldn’t (in theory) be devalued in mobile.

Separate Mobile and Desktop Sites

Here’s where things get tricky. If a site has device type redirects OR rel=alternate and canonical tags setup, then the mobile crawler will see the mobile site only, and not the desktop site. That means if some content is ONLY on the desktop site, the mobile Googlebot won’t see it and it won’t end up in the mobile first index. This is the issue Google is trying to solve, but it’s also an issue for many publishers.

No mobile site

The mobile Googlebot will still see these pages! The mobile crawler doesn’t just crawl “mobile friendly” pages. It crawls everything. These pages will still be seen – they just won’t get the “mobile friendly” designation – but that’s completely OK because it has absolutely nothing to do with mobile first indexing. Sure they won’t rank as well as mobile friendly sites – but they’re already not ranking as well as mobile friendly sites. That won’t change after mobile first indexing.

How to Design for Short Attention Spans


The number of mobile internet users has exceeded the number of desktop-only users, no wonder many businesses want to make their business becomes more mobile. If you are an apps developer or a web designer, you should understand that mobile users characteristic are likely short attention spans. Therefore, it is important to create business app that meets this characteristic. In this article, we present several tricks that can be used to make your apps fit the short attention spans, such as follow:


Nowadays, having a lightning fast app is a must thing to have, since a research of the Jampp study reveals that people spend less than an average of 60 seconds on mobile apps. In fact, a three seconds delay in website load time will result in 40 percent of users abandoning your website. The very first step is to make your website and app lightning fast. Make it easy for people to take the most basic action in your app, or on your website, in less than 60 seconds.

The most common mistake that many app developers do is to create app with lots of unnecessary features in the hopes that users will find it interesting while the fact is every web developers should avoid making complicated apps and focusing on performing the most basic tasks in your apps in seconds.

If waiting is avoidable, you can use bar of indication of progress to give your users sense of certainty. This trick has been successfully proven and it is used by many major sites. This is how you change everything. In fact, this method is so effective that 75% of people prefer to have one.


Opposite from completeness meters, loading spinners will provide you with bad user experience instead of bringing good impact. No matter how fast your app or website is, it won’t make much of a difference if people perceive it to be slow. Loading spinners doesn’t give users an exact indication of how much progress they’ve made and how long they have to wait, therefore it is not preferable to be used as a time indicator.


Instagram is the best example of making actions appear seamless to users. When a user attempts to upload an image that should generally take 30 seconds to load, Instagram makes it appears as if the image loads instantly. This is because while a user is still captioning the image, adding title and tags, Instagram is slowly uploading the image in the background which causes the image is posted automatically, by the time the user actually clicks “share”. This process has made Instagram populary known as a very fast app.


It goes without saying that mostly people will only use half of the functions; therefore, loading each and every function will cause slower user experience. But don’t worry, as you can use lazy loading to help you delay the loading of certain objects until they are needed; for example, on a website that heavily uses images, it is expected that the images will contribute to a delay in site load times.

Moreover, with lazy loading, you can postpone the loading until users scroll to where the images are which actually save users a lot of initial load time that result in creating a perception that your site is much faster than it really is.

PICASSO VS GLIDE (Advantage and disadvantage)


Currently, mobile developers keep looking for a new method to make image loading run faster. Today, we are going to see the difference between the two most popular image loader library, Picasso and Glide. Both of them may have their own advantage and disadvantage, even though they may look 90% similar. In fact, some resources said that Glide is Picasso-clone. Anyway in details, it is quite different. Especially in several ways below:

Import to Project

dependencies {
 compile ‘com.squareup.picasso:picasso:2.5.1’



dependencies {   
compile ‘com.github.bumptech.glide:glide:3.5.2’   
compile ‘com.android.support:support-v4:22.0.0’


Glide also requires Android Support Library v4, so bear in mind to import support-v4 to your project like above as well. Frankly, you basically need Android Support Library v4 in every single new-age Android project, so it should not be kind of problem for you.

Image’s Quality in Details

The image’s quality between the two may not be too different, but Picasso is better known that is has better image quality. As you can see on the images below, Glide has some hard pixels and is not as smooth as the Picasso one and it is difficult to find the straight way to change image resizing algorithm.


Disk Caching

In terms of default disk caching concept, Picasso and Glide are quite different. In the experiment below, the same Full HD image is loaded into ImageView with Picasso and Glide. When I checked the cache folder, it appears that Glide cached the ImageView-size (768×432 pixels) while Picasso cached the full size one (1920×1080 pixels).


If you see closer on the picture above, you will see the hard pixels described above is also there. In addition, if image is loaded in RGB565 mode, the cached image will be also in RGB565.

Moreover, other difference occurs when you try to adjust ImageView to the different sizes. Picasso will cache only single size of image, the full-size one while Glide acts differently, it caches separate file for each size of ImageView. You also need to download an image that has already been loaded if you need to load another size the same image before be resized to the right resolution and then be cached.

Anyway you could use this command to adjust its behavior by let Glide cache both the full-size image and the resized one.

.load(“http://nuuneoi.com/uploads/source/playstore/cover.jpg”)             .diskCacheStrategy(DiskCacheStrategy.ALL)            


The full-size image would be loaded from cache, resized and then cached, the next time image is requested to show on any ImageView. Due to this, Glide can load and show image faster than Picasso, while Picasso may take longer time to load images since it needs to be resized first before it is set to an ImageView.


Compared to Picasso,  Glide also has an ability to load GIP animation to a simple ImageView which makes it more interesting. However, if you would like to use GIF, you should use it wisely, since it consumes quite a lot of memory. Glide is also able to decode any local video file to a still image.

Furthermore, you can configure the way image appears with an animator (R.animator) while Picasso could do only one animation, fading in.