This post discusses the differences between responsive and web friendly websites, types of app development methodologies, and everything you need to know about sub-domains and whether you should publish your mobile website on one.
What you need to know about domains
A domain name is the string displayed before the last period in a web address, which then is followed by the so-called TLD (top-level domain) which can be distinguished in six groups as illustrated below:
- Country code top-level domains (ccTLD)
- Generic top-level domains (gTLD)
- Infrastructure top-level domain (ARPA)
- Restricted generic top-level domains (grTLD)
- Sponsored top-level domains (sTLD)
- Test top-level domains (tTLD)
For most web users, the two TLDs of interests are Generic TLDs (gTLD) which include .com, .edu and .gov; and Country TLDs (ccTLD) such as .fr for France and .se for Sweden.
#Sub-domains
A sub-domain is a prefix that can be used to differentiate segments of web content; example:
- Different language versions of a website:
- french.thewebsite.com
- english.thewebsite.com
- Country-specific webshops:
- sweden.webshop.com
- uk.webshop.com
- Mobile adapted versions of primary content:
- mob.newspaper.com
While the decision to use a sub-domain as a method to differentiate language- and country-specific versions of web content are self-explanatory, sub-domains sometimes also are used to distinguish mobile- and desktop versions of a website as illustrated in the list above.
One typical instance when such a strategy often is implemented is content-rich websites where you want to create an optimized experience on mobile devices by preventing secondary content to be downloaded. This strategy is justifiable if web analytics indicate that mobile users rarely consume explicit parts of the web content and where a technical audit attests that preventing parts of the content to be downloaded will increase loading speed and contribute to a more user-friendly UX. In such a strategy the mobile version can be published on sub-domain to clearly indicate for users what version of the site they are visiting.
In all instances where web content visible for users on desktop are hidden for mobile users, there is, however, important to always include a link to the desktop counterpart as users who first have visited the site using a desktop computer might be confused if they later re-visit it from a mobile device looking for the same content.
Content published on a sub-domain is by most search engines recognised as separate websites to avoid duplicate content in the search results. As such, the search result will include only one reference to either the primary domain or the sub-domain (Support.google.com, 2017a). To keep control of which domain that should be displayed in the SERP (usually the primary domain), it is, therefore, important to indicate pages that should not be indexed either in the htaccess file, a robot.txt, or by using a ‘no-index meta tag’ on duplicate pages.
It should also be noted that many CMS’s lacks multi-domain support and that using sub-domains might result in the need for two separate databases with two non-synced back-ends as a result. While this usually isn’t a major problem for smaller websites, larger websites where the content is frequently updated, however, such strategy can lead to substantially more work in keeping the two databases in sync.
Responsive versus a separate mobile website
As discussed above, creating a separate mobile version can be a good option for content rich websites to prevent content rarely visited to be downloaded to mobile users. In most cases, however, developing a responsive website where secondary content simply is hidden but still downloaded is more cost efficient. Responsive websites also have the benefit of a single domain for both the desktop- and mobile.
Apps
Mobile Apps are stand-alone applications created to solve a particular task in a more efficient manner than what can be achieved by a typical mobile-friendly/responsive website.
Apps can be the sole reason why a company exist as with Snapchat (2017) but they also can be created as a method to generate an additional source of income or to offer a better user experience for mobile visitors. Apps also have become an important alternative for organisations having problems with ‘ad-blockers’ which, according to Harvard Business Review (2017) has led to a net loss of advertising income as high as 50% for some organisations. To bring back some of this lost revenue, creating apps is one method to ensure that adverts are not getting blocked.
The decision to develop an app needs to be carefully assessed as this requires both monetary recourses and staff—not only for development—but also for content production and ongoing management. From a marketing perspective, apps also are no different from any commercial product and will need a separate marketing plan and funds for advertising. Companies with no experience of running apps also need to set-aside resources for educating their staff in the specifics of app marketing, which include building a thorough understanding of App Store Optimization (Kissmetrics, 2017).
The four principal methodologies of app development
The following section discusses the four principal methodologies of app development. Technical and practical differences of each method also are presented together with potential advantages and disadvantages from a digital marketing perspective.
#Web apps
Web apps are, in essence, web pages built with a mobile-first perspective and are designed to look and feel like a native app. They are developed using HTML5, CSS and JavaScript, and runs in the web browser accessible through a normal URL. While HTML5 gives access to many hardware features, such as GPS, accelerometer, camera and offline access (HTML5 Rocks, 2017; Technologies, 2017); the main difference between native and web-apps from a technical standpoint is that native apps are written in device-specific languages and, thereby, have a much better performance.
From a production and marketing perspective, web-apps have both advantages and disadvantages.
The fact that web apps technically are websites, they are cheap to develop and also need no special back-end services, allowing for the use of any CMS including WordPress or Joomla. On the negative side, web apps offer less performance compared to native apps and have less access to device hardware features than a native counterpart.
From a sales- and marketing perspective, web apps do not differ from regular websites and a marketing team can use the same traditional marketing tactics (on- and off-site) as in traditional web marketing; including SEO, link building and optimisation of content and code. It should be noted, though, that web-apps are not installed on user devices—nor can not be sold or marketed through the app stores. Whether this is an issue or not depends on the organisation’s underlying business goals.
#Web app example
In 2011 Financial Times (2017) after previously offering their readers a native app, withdrew it from Apple’s app store and instead published a web app. Difficult to distinguish from a native app with no visible browser buttons, horizontal swipe functionality, and the utilisation of the web worker API making content also available offline; the app is built using HTML5 and, in essence, is a normal web page. (Nngroup.com, 2015)
#Native Apps
Native apps are written in the language of the hardware platform of the device that runs it. They utilise data processing capacity more efficiently than web-apps and offer a faster and more “smooth” experience, in addition to also having access to almost all hardware features of the running device. Contrary to the beliefs of many marketers, though, “going native” is not necessary to gain access to basic device functionality like the camera, speedometer or the GPS—nor to create apps that function in the same manner as a native app in offline mode without an internet connection which can be achieved through the ServerWorker API (mobiForge, 2017). Native apps, however, handle offline behaviour and hardware access much more efficient than web apps, and for many data-intensive applications including graphic intensive games, native apps are the only viable alternative.
From a technical standpoint and the fact that native apps are written—not in a universal language like HTML5—but in a device specific language, native apps need to be developed in two different versions: one in Swift for IOS (Developer.apple.com, 2017) and one in Java for Android (not to be confused with JavaScript). Computationally intensive applications such as physics simulations and games, sometimes also are developed in C or C++ (Cprogramming.com, 2017) to maximise processor performance and many C-developers use the Android NDK library (NDK, 2017) to simplify app development in this programming language.
#Native app example
You might also like
