But how do you get it on your website and into your apps at the same time?
We are building apps since the iPad was introduced. The only things certain ever since: we have to change the ways we build and think about apps.
When we started building the first apps, we tried the Adobe DPS and Woodwing. Both promised (and DPS still does today) to get content on tablets without a major effort.
For us, that way never worked. We tried it because it sounded so good. But we were unhappy with the results.
So, we decided to build our first apps for BMW as native iPad apps.
The world was easy back then. 1024 x 768 pixels on a fixed screen. No one knew anything about retina displays, smaller tablets, or bigger phones. All this was beyond imagination.
The usual way we built apps was to do designs in Photoshop.
Then we exported all the layers, handed it over to the developers, and they put it all back together so it became “interactive”. We added videos, 360s, sound, etc. to use what the iPad was able to do.
But what we basically did was to pull a lot of .jpgs and .pngs together. It was not possible to have text shown in a way that the print designer was happy with. Therefore, the text was also exported as images.
Imagine building a website where text is displayed with jpgs.
Insane?—?but that delivered the best result.
Can you imagine what happened when a client had a text change? We went back to Photoshop, changed the text, exported the layer, changed it in the code, compiled a new app, uploaded it to the app store, and waited a week until the text change finally showed up with an update of the app.
Insane?—?but that´s how it was.
A year after the original iPad, Apple launched the iPad2. Things went better for us at that point because the iPad2 had more processing power and apps felt even better. Also, more and more clients wanted to have apps.
However, another year later, things went from good to really bad. Apple launched the retina iPad. The iPad3 had four times the resolution of the original iPad. But processing power did not really increase.
Apple did not allow developers to use different apps for the iPad 1 & 2 (non retina) and the iPad 3 (retina). All iPads needed to be served with one app.
Suddenly, we had to add every image to the app twice. One is for the non-Retina version and the other for the Retina version. Because the Retina display has four times more pixels than the non-Retina one, the size of an image file in the former has also quadrupled, although it can be reduced using good file compression.
So an image with a size of 1 MB in a non-Retina app is 4 MB in the Retina version, for a combined size of 5 MB. If a non-Retina app has assets that are 100 MB in size, the asset size becomes 500 MB when combined with the Retina version.
Now, users suddenly need to download files five times their original size!
A lot of apps still do that. And there are apps that are still being built this way, which is OK for certain cases.
But, in general, a better way to build apps must be found.
The market has changed since the launch of the iPad, with competitors offering their own tablets. Newer tablets come in a variety of sizes and resolutions, with aspect ratios of 4:3 to as high as 16:9. Phones have also gotten bigger (no idea who likes phablets, but they are reality).
People use their devices to be entertained or to get the information they want. Fast, good looking, easy to access. Anytime, anywhere.
So, we wondered: what does all this change mean for us? What does it mean for building apps and websites?
What do we tell clients, if they want a native Android app, a native iOS app, and a responsive website?
Do we tell them that we have to see each one as a separate project? Do we tell them that we build a backend for the website, but build apps in Photoshop or with the DPS?
How do you get content into each of these devices? How do you handle images that should look good on a phone in portrait mode, on a tablet in landscape mode, and on a website on a 27” display?
What you want is to have all your content in one place: text, images, and videos.
You want to let the magic happen in the background.
That´s exactly what we have perfected over the last years.
But how do you achieve a process that is automated as much as possible but allows you maximum flexibility regarding design and user experience?
First, we needed to store all assets in one place.
Then, we developed a certain number of templates that worked and were responsive on any screen size. These templates can be chosen to display certain types of content.
This was too limiting. Just 10 templates? How can you squeeze great design into just a few templates?
So we went further. For each client or project we define the types of content that we need. Then we create modules. Each module can be combined giving you a lot of possibilities for great layouts that always look different.
These modules are all responsive, no matter on what screen size you are.
What can you do now with the asset management system and these modules?
You can deliver content to any medium or device you want. Android? iOS? Smartphone? Tablet? Web? We don´t care. Could be even devices that we don´t know today.
How does the app or site display the content? Nothing special in the web: frontend and backend development are not new.
But we do the same with native apps. The apps get content out of the System and display it. Those apps are not just web wrappers, which means they basically show a website within a native app (some call that hybrid apps).
No, we build fully native apps. They get the content delivered they need. Are you on a 7-inch Android tablet? You get the content you need in the exact size you need. The Asset Management System does all the magic in resizing images, compressing videos, etc. We don´t want files delivered to any app that are too big and could slow down or limit the experience.
Today we are also able to use native text on Android and iOS. What does that mean? In native apps, you can do less with text than you can do in the web. Google and Apple still have some work to do here. So, in the meantime, a lot of apps use “web views”. These are basically little “websites” within an app that display text. This is far from ideal.
What you want to do is to handle text natively. That speeds up performance, and it looks better. That´s exactly what we do.
As those apps store the content locally, they also work without any internet connection, and you can access the content anytime. We can program apps that are so smart that they download content in the background, so the user doesn´t even realize it.
Sharing was a huge issue in the past, as well. Usually, people want to share one piece out of an app. This could be an image, an article, or a video. In the old days, people needed to share the whole app. If you wanted to read an article a friend recommended, you needed to download the full app.
Today, we do it differently: every piece of content is available in the web as well, which allows people to look at the content you share, even if they don´t have the app installed.
We also put a lot of thought into responsive images. You always want to have images displayed in the ideal resolution for each device. Are you on a 2560 x 1440 px Samsung tablet or a 640 x 960 px iPhone 4? In that case, why download the huge image to the small phone?
You upload an image to the asset management system once, and the backend creates all the image sizes needed. But what happens to an image that is viewed in both landscape and portrait formats?
Imagine you have a portrait image with a person on the right, and the person is the focus of this image. What happens when this image is viewed in portrait mode on a phone?
It can be resized automatically, but you might lose the focus. The person you want people to look could be cut off.
To prevent this, we came up with the idea to set focus points. Within the system, you can set focus points on the image. In this case, you would set it on the person on the right, defining the focus point as “middle right”. When the image gets cropped, it takes this into consideration and cuts the image in a way that the person on the right is visible on any device, even in extreme formats.
What does this lead to?
In the end you have the following:
A system that stores all the information.
Responsive websites that use this content and are optimized for any screen.
Native apps for Android and iOS for smartphone and tablets.
What is the benefit to our clients?
They can reach anyone who is able to access content digitally. No matter via the web, through a mobile device or on a desktop. No matter if they want to access their content with an app or the web.
They can add content anytime they want. Without any programming skills. Immediately.
And only once! If they publish something, it is automatically published in the right way and format across all devices.
They have the most modern web experience and native apps at the same time. With an easy system in the background that is future proof!
Insane? No! Reality.
The project where we pushed the limits of this idea the furthest will be out soon …