Month: February 2019

Due to the rapid increase in mobile internet traffic, recently one of the most frequently asked questions from project owners is if their website would be responsive. This is not a bad question; however, the question is incomplete, and also our responses are quite technical. At this point, we at SHERPA want to provide a solution without drowning everyone in terminology.

Go ahead. Read it, enjoy it, and even share your objections, but please do not ask if it should be responsive or adaptive.

As if he had heard us, Nick Davison, vice president of technology at Rhythm Agency, suggested a solution for this dilemma. (Yes, it’s possible to find an answer to almost every question on the internet.) The project Liquidapsive is just like the final answer to the discussion with four simple examples.

Let’s examine them one by one:

If you’d like a responsive website

Enter the liquidapsive.com and pick “responsive” from the drop-down on the top of the page. The user interface of the website will convert to responsive. Let’s continue for those who might be wondering what changed.

Responsive user interfaces have different layouts for different resolutions. As you drag your browser window narrower and wider, taller and shorter, you will understand how the interface responds to the changes in size. You can see that the transitions between different layouts are softer and fluid (liquid) during the change. The content and media elements within your page layout begin to vary depending on your browser’s display area. If you ask how it happened or are displeased by content not being as fluid as you would like, I can recommend a series of articles, however, be warned that if you are not a developer, they might give you a headache. In Hollywood-made horror films, remember what happens to the teenager who asks where that sound came from and still goes down to the basement all alone. Believe me, It’s better to trust the experts to design your product or service’s user experience.

If you’d like an adaptive website

Enter the liquidapsive.com and pick “adaptive” from the drop-down on the top of the page. The user interface of the website will become responsive. Let’s continue for those saying “So, what happened?”:

Adaptive user interfaces have different layouts for different resolutions. If you drag your browser window narrower and wider, taller and shorter, the page layout does not change. However, if the viewport reaches a resolution predefined by the development team, then the page layout adapts itself to the new resolution.

If you noticed, there are white columns on the right and left blocks of the screenshot above. It is because the viewport displayed on my browser is 1.440 pixels, and the upper limit for the adaptive option of liquidapsive.com is 1.366 pixels in width. In other words, the website does not adapt itself to viewports over 1.366. It is a decision which is made within the user experience design process. If your users prefer displaying your website on giant screens as much as next-generation TVs’, it would be a good idea to review your decision about 1.366 pixels for the upper limit and to consider adaptive solutions for wider resolutions such as 1.600, 1.920 and 2.500 pixels, and more.

If you’d like a fluid/liquid website getting into every form

Let’s first ask what the timing of the project is. Your answer to this question will set in motion a series of questions and answers from which there will be no turning back. Let’s assume that your answer is “Let’s first find out what is happening, then let’s see the budget, and timing is not an issue.” Enter the liquidapsive.com and pick “liquid” from the drop-down on the top of the page. The user interface of the website you are on is fluid/liquid now. So what? It’s actually almost the same as the responsive UI.

This is where our famous debate mentioned in the title (and also ego wars) begin. The comparison of responsive to fluid/liquid is not valid. Responsive is a type of development that performs responsive page layout decisions based on display areas. On the other hand, liquid is just one of the responsive page layout methods. And yes, an adaptive page layout can also be liquid. Therefore, the question if the best one is adaptive, responsive, or liquid is a futile discussion.

Content and media elements vary depending on the display areas of your browser when the page is designed as a liquid. If you try to display your website with resolutions other than the defined page layouts (that is smaller or larger than the defined metrics), you may see the page layout scattered. Here you can see an example of what happens when you display a page prepared as liquid, in 628 px as an undefined page layout. This interface is a dead-end of a project providing a user experience that ignores the widths below 1.024 px.

We know exactly what we want: Make it static

Then let’s ask: why static? Enter the liquidapsive.com and pick “static” from the drop-down on the top of the page. The user interface of the website you are on becomes static. Let’s keep for those who say “Is this all? Is it done?”:

The static page layouts, as can be seen from the name of the preference, are static, so they do not vary according to the condition. Whatever your screen resolution, they’re always static. Whether it is wanna-be-smart phones, laptops, tablets, it does not matter on which device you display your website, you always see the same page layout. Of course with a small difference: you see some different kinds of scroll bars to view the content outside the viewport. Here you can see an example and then decide how many times you have to scroll the bar to see the whole content.

If you read this blog post, I first want to thank you. From now on, you are one of us. Unless the speed of the development of mobile internet quite slows down, I am worried that this debate will be exacerbated and I considered to write this blog post as public debt. If you have any questions, please comment below.

Finally, I would like to emphasize that I avoid providing technical details in the article as I was trying to explain the matter in an understandable language. The necessity of the language of expression that I used to describe the issue plainly. My sole purpose in writing this article was not to make it easier for you to decide whether your site should be adaptive or responsive, but to help you get information first and so idea when conducting a discussion on the user experience.

But not finished yet…

Frequently asked questions

1. In the 2nd paragraph of your article, I got bored, and I jumped to the last section, and I did not understand anything. Well now, we have a mobile website. We would like to turn it into responsive. What do we need to do?

First of all, I assume that your mobile website runs on a subdomain such as m.yourfabulousdomain.com. If this is the case, I feel bad for saying this, but I cannot hide the truth. Google does not like you. If you wonder why that is the case, I recommend you check out this article. In case you don’t read the article, here is the summary: Google does not like URL redirection. If you would like to learn more, you can contact us via this form to get an SEO 101 education pack.

2. Do I have to know all this mumbo-jumbo? What does my agency do?

If your agency is free to make the user experience decisions which can affect the KPIs of your web assets, you don’t need to know all about this. If you’re not satisfied with your agency, we say “Oh! Look at the delegation discipline!” and we would be delighted to meet you. In other words, if you are the one who makes the user experience decisions of your web assets, you must know about it to answer the questions of your agency or other service providers. If not, you sometimes are tricked, generally, have wrong feelings and mostly make a false budget allocation, and you become pretty exasperated when you’re writing your year-end reports.

3. Nice. I got the point. But I am not sure about which resolutions should be responded by our website?

If you use any tool such as Google Analytics to measure the performance of your web assets, you can find out all the answers there. Analysis of these answers, more precisely the interpretation, will require technical knowledge. If your agency cannot support you in this case, you can contact us via this form to get a Web Analytics 101 education pack.

That’s all for now.

With smart devices, apps have become one of the most essential parts of our daily lives. Today, no service provider can claim there are no mobile device users in their target audience. However, the world of apps is confusing as well as it’s exciting. If you ask, “What type of app should we develop?” it’s quite possible you would get many more questions than a clear answer. In this article, we will talk about perhaps the most important of these confusing questions, “Native application, or hybrid application?”

As mobile devices continue to evolve rapidly, all recent advancements lead to significant changes in the users’ lives. Especially as the IoT devices became real and entered into our lives; usage of mobile devices introduced us a completely different world. It started with reading emails, taking notes and playing games; now the apps are a part of our lives in almost every environment from car controls to the food in the oven. From the safety and the cleanliness of your home to your health checks. Perhaps this is why there are no services and/or products left without the target audience of mobile device users. At the same time, various new technologies and options have emerged in the app development industry and are having a tremendous impact.

Native apps

We definitely loved the apps that came into our lives with the rapid rise of smartphones; and by the third quarter of 2018, the number of apps stood at 2.1 million on the Android platform, and at 2 million on the iOS platform. Native applications, which were the pioneering format, to this day continue to be the first format that comes to mind in the mobile application world.

The “App Store” standards, which emerged with the iPhone, brought specific rules that must be followed by both developers and software infrastructures. By instituting restrictions such as not allowing the installation of apps from external sources, Apple made it compulsory to comply with these standards. Developers have begun developing apps per these standards using only the necessary software development infrastructures.

Various operating systems — such as the later Android — have continued the concept of App Store created by Apple, even though they didn’t have any restrictions on external app installation. They also started developing their own standards for app development. However, the difference between these software infrastructures and the operating-system standards began causing various problems — especially higher costs — for the app service providers. There are many differences between the user experience and how the devices which are designed  The differences between the user experience, as well as the device usage brought about by variation in design and software, has made it necessary to consider devices both in respect to its design and the user experience from various angles.

These limitations in native applications, in fact, provide significant advantages in terms of user experience and performance. These standards, based on the hardware features of the device, allows you to offer the most satisfactory experience for your application.

Advantages of native apps:

• They provide users fast, reliable and consistent software.
• They may access all the hardware and software functions of the devices.
• Especially for continuously updated systems such as publishers; they allow using the device’s own notification system.
• Users generally spend more time in native apps.
• Native apps may be more easily adapted to newly developed technologies in devices.
• Designers can use the device’s own design kits with native apps.

The primary disadvantage of native applications is that they can only work on the platform they are created for. Because of the differences between operating systems, the app created for a platform needs to be re-created with a completely different infrastructure and hardware to be able to work on another platform. As mentioned above, it may even be necessary to redesign the usage habits of the devices. A native application that is supported on multiple platforms cannot be created. However, if your budget is sufficient, designing a native app is an ideal solution for better user experience.

Web apps

Web apps are displayed on browsers just like mobile-compatible websites. No installation is needed for these apps. They can also be added as shortcuts to your device’s screens. You can even run them like an application view, by editing the manifest.json file to force the browser to go full-screen.

Web applications can be indexed by search engines. They can be shared as URLs and can be given links, and on top of that, they do not require updating.

Web apps can be designed in a native app appearance. Their creation is remarkably fast and easy. However, this simplicity is also the most significant drawback of web apps. Web applications are limited in their ability to feature development, and they often need an internet connection. They cannot connect to the hardware of the device. They have limited hardware access, such as microphone access provided by HTML5. Therefore, they cannot access any hardware in mobile devices, and they cannot use the notification systems. They are unable to be used when there is no internet connection available; also problems may occur at slow connection speeds.

Hybrid apps

Hybrid apps can be positioned between native apps and web apps. They are usually faster than native apps, but they work better than browser-based web apps. Hybrid apps are also designed with HTML, CSS, and JS, like web apps. To gain access to some functions in the devices, they can use almost all of their software and hardware features. This allows them to take full advantage of the native apps above. Thanks to the improvements in the hybrid app development frameworks, the gap between hybrid apps and native apps are closing.

They do not need different development software and hardware for different operating systems. The app can be published in the market. It can be converted into an app to be downloaded and installed by users.

There are many frameworks in the hybrid app development world. These frameworks accelerate the hybrid app development process. They also enable the apps to be strengthened at their weaker points compared to their native counterparts.

How should we choose?

Native apps are preferred in projects for which high frequency of use is expected. In such cases, performance and device usage habits become more important.

In the whole process, from the creation to the launch of web apps, considerable savings in terms of cost and time are possible. Projects for which low frequency of usage is expected, web apps are the way to go.

Hybrid apps are widely preferred because they can benefit from the advantages of both web apps and native apps at the same time. With the advancements in hybrid application development frameworks like ionic, hybrid apps are getting closer to the experience of native apps. In many apps, you may find it difficult to recognize the differences between the two. There are two operating systems at the top of the mobile world: Android and iOS. When you think you might have to give up 2 million users when you choose only one of them, the world of hybrid apps become more attractive. The critical factors in this choice are, being familiar with your target audience, their needs, the mobile devices, and the operating systems well. Also, of course, your budget is critical.