AEM 6 TOUCH-OPT IMI ZED UI
P R E S E N T E D B Y
Gilles Knobloch - November 18th, 2014
A F EW WO R D S A B O U T M E…
Engineering Manager @ Adobe Basel, Switzerland
• 4+ years of AEM experience
• Launches, History API, Granite References API,
Sling Resource Merger
• Team focusing on CoralUI, Granite UI, WCM Sites
and Page Authoring
• Why a new UI?
• AEM 6 Touch-Optimized UI highlights
• Feedback & Improvements
• Q & A
SO WHAT CHANGED OVER T IME?
• Multiplication of devices
• Various screen sizes
• 4 major browsers for desktop and 2 major ones for touch devices
• New interfaces: touch screen, voice over, etc.
• Technology improvements
IS TOUCH-OPT IMI ZED UI FOR ME? NOW?
• Classic UI is still supported, even within Touch UI
• You can still decide to use it or not
• Upgrade won’t change the Authoring UI
• Get all other nice features from AEM 6
CUSTOMER TRANSI T ION
New sites and
Most sites are
Touch UI using Touch UI
Classic UI 100% of
5.6 6.0 2015 2016 2017
move all sites to
WH E R E ’ S M Y T R E E ?
• Classic UI had a nice tree view
• This pattern does not work in Touch UI
• How can I quickly navigate within the structure of my resource?
• Now introducing Miller Columns
I’m pleased to have you joining this session today. We’re going to talk about the new Touch-optimized UI in Adobe Experience Manager 6
Before we dive into this topic, let me quickly introduce myself.
I’m an engineer manager @ Adobe Basel, in Switzerland.Some examples of my contributions to the product over the last years are listed here, and I’m now in charge of a team focusing on CoralUI library, Granite UI framework as well as pure AEM features like are Sites administration and the new Page authoring.
Talking about a new UI, the first question you probably asked yourself was: why did now Adobe create a new UI, whereas ExtJS was working perfectly for me. And I’ll answer that question, before showing you some highlights of the new UI.
Of course, we already got a lot of comments, suggestions and critics on the new UI, and we are actively listening to that feedback to make sure it always gets better.
And finally, I’ll open the session for Q & A.
You might have wondered, and some customers even told us: why do I ever need a Touch UI. In this morning’s keynote, Cedric said, whenever you change the UI, it’s get emotional.
So, let’s go through the reasons who pushed us to create a new user experience.
Since the 80’s, you were using a keyboard and a mouse to interact with your computer, but new hardware like smartphones or tablets started to invade the market, and your fingers now replaced the mouse.
But that’s only one part of the new things companies invented to change the way people consume digital data: watches, glasses, eye recognition, etc. Who knows how this is going to evolve in the future?
As you can see, a revolution is currently happening. <CLICK>
And Adobe needed to be prepared for it!
When we realized that a revolution is ongoing, what did we do first ?
We tried to load the application as-is on iPad, and guess what? It was not fun to use it. Immediately we struggled to use it with the finger:
Buttons were too small
Web emulates native application, which is designed to be used with mouse & keyboards
Mouse was precise on those small buttons, so we could pack many of them into the screen
All of these started to create issues on Touch devices
So we needed to understand what changed over time in order to build a new user experience.
First of all, as we already talked about, new devices came in.
Available screen sizes vary a lot between phones, tablets, desktop computer or even big screens.
On the technical side, instead of one browser with 95% market share in enterprise world, we now have a lot of them, even different ones on mobile devices
Furthermore, the way we interact with devices diversified with new input sources
And finally, some technology improvements pushed this revolution. Computers got faster, internet speed increased, and the browsers give us new opportunities with regular feature updates
So for sure, as a product manufacturer, we needed to do something.
It is a bit like time traveling: we have to support the mouse from the 80s, all the new devices from now and what’s coming in the future.
It is a great challenge!
Let’s go back to our new user experience.
We had several options. One of them was to ask our customers to work like in the 80s, force you to keep using a mouse and a keyboard in front of your desk… which is not really optimal.
The option we choose was to drive the revolution and create our own User Experience framework, based on 3 key principles:
<CLICK> first one: it has to work across all the Marketing Cloud solutions - it sounds trivial, but you’ll see it was not so easy
<CLICK> second principle: it must be usable on all the devices
<CLICK> finally: it has to be ready for the future
Let’s start with our requirement to build a user experience for all Marketing Cloud solutions
Take a look at how Marketing Cloud UI looked like some time ago.
Due to history of various acquisitions in the past year, the user interface of those products was not standardized, although a huge work has been none in the backend to integrate the products.
As you can see from those screenshots, there was a lot of work to do.
But our goal was to have a unique user experience through all the solutions of the Marketing Cloud!
This is already pretty cool to have a seamless experience cross our solutions. But let’s think about the revolution again. The way how people interact with computers and software is changing.
Applications now have to run on multiple devices.
We imagined what would be the needs for a web application user in 2014.
We came up with the 4 major needs listed here.
Depending where you are, you’d like the be able to work on the same web application and the use the device that fits the more for you.
Moreover, when using a web app on a mobile, you want to get finger friendly hit areas and enhanced gestures.
Of course, the user experience should best fit the device you’re using, so that, as you can see on this picture, you have a different UX on a mobile device compared to desktop.
Desktop applications were also forcing people to go to their computer. Turn on the computer, wait 5 mins, sit down, grab the mouse, take the keyboard… This was a major barrier to do small changes or quick interactions.
Mobility comes with the opportunity to work on-demand: when I have 5 mins, I want to quickly do something… reactivity. Information exchange can happen much faster.
We need to get rid of long loading times, user should go to the essential, to the core of his business. Be fast and efficient.
Before, it was easy for developers: one screen, one mouse, one keyboard, one browser.
But there is no reason why the application should dictate to the user which device he has to use. It is not the users’ responsibility to adapt to an application.
Instead of targeting each single combination of device and browser, we put the user in a position where he can decide what to use and the application will adapt.
Last year, our designer colleagues sent us this image to wish us a merry Christmas. I am not really sure how we should take it but it fits perfectly in our slide.
This is how applications were designed not so long ago. Many buttons, lots of possible actions available. It gives the full power to the user, but it is really efficient ?… <CLICK>
Instead, you probably want to have less buttons, which cover 90% of your daily use cases.
And finally, let’s discuss the unknown - the future.
Of course we cannot predict the future, but we can be prepared for it.
And to do so, we are building our framework on 4 standpoints.
Our first one is web technologies.
Web technologies are an open standard, which, compared to native applications, have a long life time.
The web is evolving progressively! But browsers are still able to open a web page that was designed long time ago.
Therefore we rely on 2 concepts
The visual part. Responsive layouting, to support different device sizes. So even new devices with different screen sizes can be supported instantly
Second a Hypermedia driven API allows to create a library of reusable functionality. As long as HTML is used, this API can be maintained
Besides reusable actions the UX framework has reusable UI widgets, like the one you see on the right side, a simple Dropdown widget
Reusables widget are important for 2 reasons:
First we can guarantee that not every single developer builds his own buttons. Which are spreaded over the whole application. So we are able to be consistent in functionality and look feel
Second: fast changes in browser/devices -> fast react reaction. feature available in whole app, cross solutions, immediately
A User Interface is not a static.
With all the technology evolution and revolution it is a very dynamic piece of an application.
To be ready to adopt to new needs, our UX Framework provides a way to integrate Extensions and Plugins .
It seems obvious how people would use the shown devices - but it isn't when it comes to accessibility.
Long story short, we follow the ARIA (W3C) standard to support screen readers and allow keyboard shortcuts to interact with the page.
Time to do a quick wrap-up on the reasons that pushed us to build a new UI
No matter what’s behind, the Marketing Cloud and our solutions provides one seamless experience.
The users are free to use the devices they like and the experience is built efficiency and performance.
Our framework is designed for the future, whatever new devices or our input mechanism we’ll come in the future.
Now that you got why we created a new UI, I’d like to walk you through some of the new features we introduced in 6.0
As every major change like this, you get mixed feedback… and we’re open to listen to the people that are using or developing with this solution.
Even after understanding why we created a new UI, even after you saw some nice features that made it into 6.0, you might still wonder, if you have to switch to Touch-optimized UI, and when?
Actually, don’t be scared. We don’t expect all our customers to switch that fast to the new technology, therefore Classic UI is still supported in 6.0, and will be in 6.1
You can decide to use it or not, at admin level or for the page authoring.
Any upgrade from a previous version won’t switch you to Touch UI, so you can still benefit of all other improvements of AEM 6 without having to adjust to a new user experience.
Here is how we see the transition happening.
Until 5.6, all the sites were using Classic UI, and we introduced the Touch UI as a preview technology in 5.6
With 6.0, new sites will start to be built for the Touch UI, and we’ll continue to work with customers on improving it over the next couple of years until probably all the sites moved to Touch UI.
Moving from ExtJS to Touch UI of course takes time. Back in the days, think about how long you needed to get used to ExtJS.
So nothing’s set in stone, and we’ll still improve the user experience.
SP1 already fixed quite a lot of things to make it more usable.
After we listened to some partners and customers, we even provided an additional update package in october.
There will be more improvements in the future, in SP2 and 6.1
In order to help transition from Classic UI page authoring to Touch, we’re about to release a dialog conversion tool, which I’m going to demo in the next session on the technical track.
Let’s see some of those improvements.
In Classic UI, we had a nice tree view, which allowed you pretty easily to drill-down the structure of your website, and find the resources you’d like to work with.
But this pattern does not fit for a Touch UI. Remember, we wanted a lighter UI, bigger buttons to allow Touch devices to work nicely, etc.
But one of the most common question we got asked by customers was: how can I quickly navigate within the structure of my sites or assets?
That’s we designed the Miller Columns for.
Some other useful features made it or will soon be available for you in the next SP
Configure Cloud services
We also enhanced the user experience in page authoring.
One missing feature that was reported by customers was the ability to drag & drop directly into page dialogs. And we also made the activation of in-place editing triggers easier.
From a technical point of view, it’s also important for developers to customize the user experience, either by extending an existing console, or creating you own to manage the resources specific to your application, and integrate nicely in the product.
We also introduced various extension points into the page authoring.
If you want to know more about this topic, you’re kindly invited to join my next session in a couple of minutes, where Damien Antipa and myself will walk through those new capabilities.
Now that you got why we created a new UI, I’d like to walk you through some of the new features we introduced in 6.0