Blog

Feature Preview: The New Page Component

We’re actively working on the next release of WP-AppKit. As it is a rainy sunday (in France), it was a good time for a quick screencast about the new page component which will allow to browse page trees in apps. (Vous êtes francophone, pensez à activer les sous-titres.)

The Case Of Content Based Apps

We already saw the marketing and technical issues to be addressed for a mobile app project. Also, there is one particular issue we have to raise as it can greatly affect your mobile project: content. Whether you run a news site, an online shop, a blog or a job board, you push content online. It can be highly structured (e.g. classifieds) or mostly freeform (e.g. blog post). These pieces of content have probably been carefully crafted and optimized for web reading, navigation and marketing. There is also a good chance you use a CMS (WordPress, Drupal…). So you took a lot of care to produce content online to meet whatever objectives you have. And now, you’d like to bring this content to mobile users.

Same Content New Environment

Mobile is a totally new content consumption experience. Screens are obviously smaller. However, it’s not the only (or even the most important) difference. Yes screens are smaller but higher densities and font handling increase readibility. Reading conditions are different. You are no longer stuck at your desk to consume digital content. You can read on your sofa as you do with good old fashion books. You may also be in a coffee shop or standing in a subway. You can interact with it through the tactile interface. So it retains the interactivity you had on the desktop but in a lot more natural way. All that combined means that the same piece of content should fit both the now classic web usage and the new mobile usage. It’s not that the content is entirely different but the navigation to access it and the way it is presented and consumed differ.

The Right Content Structure

The keypoint is to be able to structure your content in a way that it can be presented in at least two different forms. It’s an old developer mantra: content/form separation. It has been a nice advantage when going through content migration. The stylesheet of the site is going to change? It shouldn’t be a problem as content is structured to offer anchor points for CSS. Reusable content structure and CSS styling have allowed to migrate smoothly from a CMS to another or even reuse content across different products. The very same advantage can be leveraged to bring content to the mobile. Structure should allow to clearly identify content pieces such as titles, quotes, paragraphs… in order to be able to entirely re-style content for the mobiles. Styling a title is simple but what about footnotes or comments ? You will have to think about mobile adapted forms for them. A quick word about content structure. When talking about structuring content, you may envision a CMS contribution interface as super complex forms where every piece of content is a field but then you will totally lose the required content creation flexibility. Often good, plain and well-structured HTML, where all visual attributes are handled with CSS, is good enough to support mobile styles. Don’t give in to a content structuration obsession or you’ll probably end up with a functional nightmare where creating content is a constant battle.

 Consider Also Media and Navigation

When working on mobile content, you will be quickly confronted with the problem of how to handle embeds. The most common embeds are video players (such as YouTube, Vimeo…). They’re relatively easy to use on mobile (providing you correctly handle screen sizes and orientations). But there is many other types of embedded content, and a lot more complex, which for technical reasons doesn’t adapt to mobile at all (often done with Adobe Flash) or simply because their format doesn’t fit (that’s often the case of data vizualizations). You’ll have to decide whether you can provide embeds for all platforms or simply strip content for some platforms. Even for media so simple as images, you’ll have to be careful. Let’s say an image is an infographic you’ll have to ensure that it can still be read on mobile (providing a zoom for example).

Fitvids.js is a Javascript library you can use to create responsive video embeds.

Navigation. Unless your content has a very simple structure, it’s likely that app navigation will differ from its web counterpart. So whatever content management tool you use, it has to be able to handle several types of content classification and navigation.

Content, even simple, will have to be adapted for the mobile to offer the smoothest possible experience. It has to be taken into account in content conception, creation and delivery. And it is likely that both your CMS and API will have to be upgraded to achieve that. Again, it is an often neglected part of mobile project budgets and it results in otherwise nice applications providing crappy content.

This article has been carefully edited by our friend Jenny Beaumont. A thousand thanks Jenny! All mistakes are ours.

Don’t Neglect Backend For Your App

When designing apps, along with technical issues,  we focus a lot on UI, content and interactions. It’s easy to forget that your app relies on a backend just as websites do. Some apps are fairly autonomous, let’s say calculators for example, but most of them retrieve content from backends (think of news apps).

Apps Are Not Standalone Products

When creating an app, you will encounter one of two scenarios that you’re already familiar with from building websites:

• Content and services are already in place
• You’re beginning from scratch

In both cases, you’ll have to ensure that the backend is “open” to app consumption. Basically it means that content and services needed by the app have to be available through an API.

Premium content is a good example of that.

• First your app will have to retrieve content from your content repository with the access rights correctly associated to each piece of content.
• Then, your app will have to trigger a connection when a user tries to access premium content.
• Finally, user login and password will have to be checked against the authentication system in order to let the user access (or not) the requested content.

Another good example: personalization. The Prismatic App uses the same backend as its corresponding website to agregate the contents you like (or you might like).

All of these functionalities rely on dedicated APIs, whether you add them to an existing infrastructure or you build this infrastructure from scratch along with the app itself.

It seems rather obvious, but believe me, it can be quite a challenge for a lot of app projects. Let me explain.

Your App Is Nothing Without A Very Well Adapted Backend

Backend as a service (BaaS) are services dedicated to provide backends dedicated to mobile apps (here the open source solution BAASBox)

A fairly common situation in an app project is to have a website already running with all the content and services needed.

If the content and services are available as web services, you’re in a good place to start your app project. (However, remember that all web services are not suitable for apps. Those based on REST and JSON are favored.)

If this is not the case, and from my experience it’s the most common situation, you will have to add this new access layer and that could be tricky on systems that have not been designed for that. Some companies even have to import feeds in a new backend that will coexist with the old one.

If you are in the situation where you create simultaneously your app and its backend, I would recommend not to build a backend only dedicated to mobile unless you have a very specific use case to back up this strategy. In the modern world, backends have to support both web and mobile.

Yes your app project will modify, sometimes deeply, your existing web products and this is often neglected in budgets. That should not be a hidden cost as it can be almost half of the budget.

The good news is that when your backend is ready for the mobile world, it will be used for all your mobile apps (or anything else needing an API by the way). So, it is a very good investment.

This article has been carefully edited by our friend Jenny Beaumont. A thousand thanks Jenny! All mistakes are ours.

How Can I Build My App?

We already saw why you may want to have an app. Now let’s see what your options are for building one. It won’t be an in-depth, technical article, but it should give you a good overview of the solutions currently (2014) available.

The Many Worlds Of Native Technologies

In order to be able to distribute your app in current main app stores (Apple App Store and Google Play), you have to use so-called native technologies. This means that you don’t use classic web technologies such as HTML, CSS and Javascript. Instead you use languages and frameworks provided by Apple and Google. Objective-C for iOS apps and Java for Android.

Once development is complete, you compile your app and submit it to the app stores. After that, when it gets validated, your app has its place in the app store catalog and users can download it. When updating your app, the process is the same. That’s right, there are no instant or automatic updates as you can have for websites.

It’s very important to understand that apps are installed on smartphones (like classic software on our good old fashioned desktop computers) as opposed to web apps which behave as websites being accessed on a distant server through a browser.

Being a permanent resident of user phones has its advantages. Mainly, it allows us to access phone features such as the camera, and to be less dependent on network availability. At the moment, native frameworks are also the most optimized and integrated way to provide a smooth and efficient app user experience.

Facebook Paper app is a very good of the kind of UI you may achieve with native technology.

https://www.youtube.com/watch?v=IhrbT9O6kW8

The downside of native technologies is that you have to invest in several different technologies, known to have quite steep learning curves. It leads to (really) high development costs to ensure your presence on your users’ mobiles. If your economic model doesn’t have room for this kind of investment, then building an app can be a problem.

Web Technologies

Web apps have existed since the beginning of the mobile era. In fact, they have been pushed even before apps became the favored solution.

In 2007, Apple Computer launched the iPhone, the company’s first ever smartphone. When the device launched, the device did not provide any support for third-party software: Apple’s CEO Steve Jobs believed that web apps served over the internet could provide adequate functionality required for most users. Soon after its release, however, developers had managed to “jailbreak” the iPhone and begin coding third-party apps for the device, distributed through package managers such as Installer.app (which itself was based on APT) and Cydia. (Extract from the Wikipedia article about app stores.)

You can see web apps as a cousin of web sites. They use the same technologies and technical architecture (HTML, CSS, JavaScript, Ajax, web servers…) but they emphasize an application UI rather than the classic web page model.

Web apps often co-exist with apps. Famous examples of that are the Facebook and GMail apps. You can download apps for these two services and you can also access them as mobile-optimized web apps. Sometimes, it’s even the only mobile offer for big brands such as the Financial Times. Since August 2013, Amazon App Store welcomes HTML5 apps.

In the beginnings of the mobile phone, web apps could not match the native experience. They lacked many features related to hardware access (eg. Camera access). But HTML5 is progressively closing the gap, and you can now build very good mobile UI with web technologies.

But even with an almost technical parity, web apps are still web sites. Yes, you can create a shortcut on the mobile desktops but users must have a connection to launch and use them, and you won’t be in the app stores. Finally, some technologies are still only available for apps such as notifications.

Bridging The Gap

Along the path to finding the right technical mobile strategy where you can use web technologies and benefit from mobile features such as notifications, many solutions have emerged under the name of hybrid apps.

The concept behind hybrid apps is fairly simple: mixing web and native technologies. Native technology provides a standard encapsulation of an app written with web technologies. The native shell adds a JavaScript API to access the phone’s hardware and renders the HTML app using the phone’s browser. It means that you can build your UI with HTML, CSS and Javascript, then embed it into a pre-defined, native shell (one per OS) and release your apps in app stores.

LinkedIn and Facebook have been early adopters of this method for building apps. But at the time, it was hacky at best. Clumsy UI, performance and cost issues brought them back on the track to native technologies (around 2012 for Facebook and 2013 for LinkedIn).

These changes have been largely discussed and some people saw them as a proof that web technologies are no match for native technologies regarding apps. Here, we have to focus on the fact that mobile is at the heart of the growth of these big brands, and that they can afford to invest in it.

So what’s left? Is there an efficient solution for building apps with web technologies for the rest of us?

Hopefully yes. Many solutions to industrialize hybrid apps creation have emerged and matured over the last few years. Among them PhoneGap (an open source project fully supported by Adobe) is probably the most well-known. It offers a standard way to encapsulate HTML apps into native shells and thousands of apps are currently made with it.

This video gives a quick intro of what is PhoneGap.

At the same time, HTML5 is making progress, mobile browsers are becoming increasingly efficient and many developers around the world are building HTML app frameworks to help ease the work needed to create your app.

So, we’re not yet to the point where going native or hybrid is the same, but in many situations hybrid is a very good solution for lowering the cost of production, notably when apps are content-oriented.

But mind the gap! You have to remember that native technologies are fairly mature technical worlds. Don’t assume that what you see in native apps can be done out the box in hybrid or web apps. Currently, you still have to benchmark different solutions (hybrid, HTML, JavaScript… frameworks) and then glue them together to create your app, opposed to the consistency found in integrated native solutions.

This article has been carefully edited by our friend Jenny Beaumont. A thousand thanks Jenny! All mistakes are ours.

Do You Need An App?

If you search for “Do You Need An App?“, results will show you that it’s a popular question with complicated (and often contradictory) answers. Of course, for a few businesses, like games for example, not having an app is nonsense. But it’s not so easy for the rest of the world. Small businesses and big corporations alike face the app dilemma.

Marketing Is Telling Me That I Need An App

As more and more people own smartphones (58% of American adults , 83% under 30), more and more people discover and use app stores (in the US, 62% of smartphone owners use at least one app per month ).

See all numbers on the Pew Research Internet Project website.

This means that your brand can be discovered on the web through search, social networks, directories… and now through app stores. If you’re not in the app stores, maybe you’re giving the opportunity to your competitors.

Having your icon (logo) on customers’ mobile desktops is a big advantage for brand awareness.

You can also engage them more through notifications. Apps are a powerful way to control the user experience you want for your brand. When using an app, you don’t use anything else. An application is a more direct medium between you and your customer. It’s better than mobile web where you have to launch a browser, then search for a website and eventually access it in a mobile-friendly version.

Apps Are About Situations And Services

Now that you have a motivation to get an app for your brand, you have to answer the question: what can I bring to my customers with this app?

The question is the same for the web but it’s probably harder to answer it in the app world. For example, searching the web is now the primary way to find a restaurant and it’s a good strategy for restaurants to have a web site well-optimized for search engines. The continuation of this strategy is probably to have a mobile-optimized version of the site. But why have an app if it’s likely to be a replica of the mobile website?

It’s certain that apps (and mobile websites) are not only about making things fit a small screen. As web designers, marketers and developers, we might think that mobile is about screen sizes. But mobile is in fact about mobility, i.e. the ability to have this small device available anywhere, in different situations, with various lighting and network conditions. Good apps take that into account. We often have only one hand available to use our phones or a short and chaotic 10 minutes to read in the subway.

Apps are tools just like our good old desktop software. Except that these are tools in our pockets, and they can interact with reality through a camera, geolocation, voice recognition, barcode scanners… the most used apps provide useful services such as restaurant finders, interactive subway maps, job alerts, chats, learning programs…

Releasing an app is providing useful services adapted to mobility situations, not replicating your website. Your app and your website have to coexist and be a consistent ecosystem.

La Fourchette app is based on content and uses geolocation to find a restaurant near you.

Is Content Enough?

In the US, at least 62% of smartphone owners get news on their handheld device. Mobile phones give us the ability to access news without particular effort, whenever we want. But content is more than news. Think of books, dictionaries, instructions, guides, classifieds, recipes… Your handheld device becomes a portable and interactive library. As on the web, content can be a service and apps become tools to deliver it in a totally new and more convenient way. Provided that content has been correctly setup for mobile consumption, it is often more readable and always available even offline.

Having good and useful content is definitely a strong point to provide an app. But to succeed, you should carefully craft the content to the mobile experience.

The Medium app pledge: read the stories that matter to you. Anywhere, anytime.

Building An App Is An Expensive Trip To The Past

Building an app brings you back 10 years when you had to setup your first website. Almost all apps are built with so-called native technologies. That means that iOS, Android, Windows Phone… all have their own language to build apps. (They also have their own ergonomics and ways to deliver apps.) iOS uses Objective-C, Android uses Java… These are not web technologies and can have steep learning curves. You won’t be able to capitalize a lot on what you’ve done before.

This is why hiring app developers is often hard and expensive. There’s no standard pricing for app projects, but you’ll see that it’s not rare to begin around 10K € (around 14K USD). This is why we’re seeing a lot of online app builders cropping up, which aim to simplify and industrialize the creation process for basic needs and to lower cost.

The other crux of the matter is that if you already have an online presence, you’ll probably want to reuse data you’re using for the web. If you have setup a CMS, you will have it to provide content for your app.

Building and maintaining an app can be a big technical investment and a rather radical change in your habits.

So, you still want to go with an app? In the following articles, we will provide you with insights on how we think we can tackle the problems it raises.

This article has been carefully edited by our friend Jenny Beaumont. A thousand thanks Jenny! All mistakes are ours.