Oracle’s ATG was born in a different time, a time when sites were only accessed from a desktop computer and a time before the concept of “mobile”. To put things into context, the first iPhone didn’t debut until 8 years after the IPO of ATG! As a result, it was inherently unprepared for the web we live in now. You can’t write software that will work far into the future if you don’t know what the future is going to hold.
Well, fast forward to today, and realize that the web has changed more than anyone would have predicted. Having a Commerce site that works in some fashion across every device is a primary goal for the leaders of the industry. In ATG/Oracle Commerce, this is no different, and we’ve come up with many ways over the last few years to make ATG/Oracle Commerce work for non-desktop devices.
In a perfect world, you’d be able to accommodate for every device. In this world however, the site is often divided into two distinct parts, a mobile component and a desktop component. Each component does its best to display correctly across all devices within its range. In general, this is how it is with ATG/Oracle Commerce sites, and this is what I’m going to discuss here. I’m going to attempt to outline the largest/most-promising mobile ATG architectures. Keep in mind that there are many ways to do mobile in ATG/Oracle Commerce, and also that mobile technologies change like the wind. What I discuss here might not be valid two years from now.
Writing a Separate Mobile Web Application Archive (WAR)
In a normal ATG project, you create a web application Archive (WAR) for the web application. It contains the entire “view” for your web application, or basically the entire frontend. One way to add the functionality for a mobile site is to simply add another WAR for the mobile view. The steps are simply:
- Write a complete new frontend to your application into a different WAR.
- Add some logic somewhere to redirect to the mobile site if they are on what you define to be a mobile device. This could be done in a servlet at the application level, but now days is best done at the CDN or webserver/load balancer level.
Writing a new WAR is really time consuming because it doubles your frontend development effort. You now have two user interfaces that will have bugs, you have to write two specification documents for each functional page on the site, and you have to write another complete frontend!
| + | – |
|
Having a distinct set of files for mobile (see next approach), Nothing is “hacky” except for the mobile redirect, which is a very standard procedure these days. |
2x the development effort,
Harder to maintain two versions of the same site. |
All in all, this is a solid, middle-of-the-road approach. With this, you’re using time-tested technologies to deliver a mobile site to users. While the mobile site might not be the fastest and sleekest, it is hard to go wrong.
Responsive Design
What constitutes “responsive web design” is hotly-debated by UX-gurus all around. For our high-level purposes, responsive web design means writing one site that will adapt, resize and reform itself to work on any device. A simple test I do to check for any responsiveness is to open a site in my desktop browser and resize the browser as thin as it will go. If the site adapts to the window being resized, it’s likely to have some degree of responsiveness built in. Here’s an example of responsiveness in the ecommerce site sunnysports.com:
Adding responsiveness into an ATG/Oracle Commerce application is really no different than any other type of application. You just mesh the mobile (and tablet) and desktop code into a single page. There are no mobile redirects, because the logic to decide how to display the site is determined based upon the width of your browser (typically).
The one caveat to this approach is that it doesn’t work well with existing applications. A full-on responsive web design can’t be simply thrown onto an existing frontend. The frontend is designed around responsive web design principles, and will probably have to be ripped out and rewritten.
| + | – |
| Very good open source frameworks available (such as twitter bootstrap),
One set of JSPs, one frontend to serve all devices. |
Requires serious UX talent to write and maintain,
Slower pages for mobile devices, because most* of the page has to be loaded, even if the mobile design isn’t displaying that content. |
*Some resources like images can be conditionally loaded based on the assumed device, however all of the HTML still has to be loaded, which can be a lot extra.
Responsive web design seems like a no-brainer for eCommerce. You’re adapting to mobile devices without writing a single line of backend code. All that has to be changed is the frontend HTML, CSS and JavaScript. I want to emphasize the complexity this can have. Imagine the effort and expertise required to build and maintain a single page ajax checkout that looks completely different based on the width of the window. This is why I mentioned above it takes a very knowledgeable UX resource to make responsive design work in eCommerce. This is also why all eCommerce sites today aren’t fully utilizing this relatively mature design pattern.
Responsive Delivery
Responsive delivery is a new take on what ISPs and such have been doing for ages: intercepting and rewriting web pages before they reach you. When you request a webpage on your smartphone, your ISP may alter its contents so that it requires less requests to fully render, thus saving them resources.
In responsive delivery, the concept is very similar. For mobile users, they get the desktop site, but it’s just been rewritten down into a mobile format by a 3rd party before it reaches them.
Using responsive delivery is a good way to retrofit an existing site to work with mobile devices. It’s not the cleanest, but it works for some ATG/Oracle Commerce sites.
| + | – |
| The mobile side of the site is handled by a completely different party,
Gives a fast site for mobile users, No code changes on the ATG/Oracle Commerce side. |
The mobile side of the site is handled by a completely different party,
Adds unnecessary complexity to all levels of the picture (the business, the team working on the existing site and the hosting team). |
The fact that the mobile site is maintained exclusively by another company can be a pro to some people and a con to others. ATG/Oracle Commerce sites are complicated enough, so it might make sense to sign away the mobile problem to a 3rd party. Doing that may actually complicate things more, so it’s a tradeoff. Responsive delivery is a relatively new phenomenon in the eCommerce world, and is a unique solution to delivering a mobile eCommerce site. It bears a mention.
Writing a Native Application
In the early days of smartphones, having an app on the app store for an eCommerce business was reserved for only the biggest companies. For a midsize eCommerce business, it just wasn’t worth it to write a fully native application. Well, today things have changed. More people shop on their mobile devices, and native application development has come a long way.
ATG/Oracle Commerce as we know it hasn’t shown itself to be easily wrapped up into a native application. Design patterns have changed since the core of ATG/Oracle Commerce and today. ATG/Oracle Commerce works on the premise that each “page” the user needs requires a trip to the application server. Mobile applications today work on the premise that “pages” are really just a few core “pages” or templates that use a RESTful API (commonly JSON) to communicate with the backend logic and only update the page as required.
Since ATG 9, they’ve shipped with a REST (json or xml) API that allows you to invoke most of ATG’s functionality via an API (an HTTP call essentially) instead of through a JSP. This opened the door for the native Commerce Reference Store mobile app that released in version 10.
The Commerce Reference Store basically writes in a layer between the Objective-C that the native app is written in, and the REST API (and ATG at the other end). It’s important to note that the app code is only included in the Commerce Reference Store release, so it’s merely a suggestion of how it could be done. If you’re planning to deploy an ATG app across android and iOS, you will have to look further, and probably dive into some uncharted territories. Someday I’ll write a piece dedicated solely to that problem.
As you can see, writing a fully native ATG application is a huge undertaking. There’s a large talent gap that you’ll have to fill when making the jump In addition, you have to break away from traditional ATG/Oracle Commerce design patterns, which will be hard for many. Although, the benefits to having a fully native application may just outweigh the troubles.
| + | – |
| Native apps are only increasing in popularity,
Optimal user experience. |
Requires more hard-to-find talent,
Charting into the unknown, Increased development time (versus other mobile solutions discussed). |
Closing Thoughts
There are many ways to write a mobile application in ATG, each with its own advantages and disadvantages. You can write a separate web application (WAR) to cater to mobile users or you can go all way to writing a fully native application. There are tradeoffs to consider in each technique.
As more people come online, the rise of mobility is not going to stop. I’d expect the demand to fully native mobile ATG applications to follow suit. While ATG began without any of this in mind, they’ve adapted sufficiently so far.
Leave A Comment
You must be logged in to post a comment.