I had just dropped my brand new iPhone 6. It smashed from my shirt’s pocket straight onto the paving. No case was protecting it. The screen cracked heavily in the upper right corner, the back shell got two dents. This was my first phone since 4 years. I appreciated how the new device felt and looked in my hand, actually more so than my wife’s 5S. Speed was great, no more waiting between app switches. And reading webpages and my Instapaper safes was a pleasure on the new, larger screen.

And now this accident. I would have to put up with the cracks, which fortunately weren’t extending over the visual area of the screen. But there were many, and they were deep. Some glass pieces had actually come off.

My first reaction was to check out repair prices. At least 350 Swiss francs for larger repairs, 120 francs for replacing the screen. Then I thought about cheating. Wasn’t there an AppleCare+ protection plan that would cover such cases? I could get one still. I even called their number, I figured I would somehow sneak around any kind of checks, then wait a week, then get a more-or-less cheap replacement device. But I eventually hang up – this was not my style.

So I decided to just visit the Apple Store and ask for options. What the heck was I expecting from this?

When I entered the store, I was friendly told I should have made a reservation, but there was a free slot in about 40 mins. I decided to wait in the store and work with my laptop. After just 5 minutes, two Apple technicians approached me. I showed them the broken phone and asked for my options. I decided not to beg for anything. Of course I showed my frustration, but I didn’t want to make any accusations to somehow get a guarantee replacement. That’s not me. I decided to just be honest. After all, it was all my fault.

What happened? They handed me a brand new iPhone 6 for the cost of replacing a broken screen. That’s a brand new device for 120 CHF.

I was partly lucky, because there weren’t any replacement parts available for this new phone series yet. So there was no way to only replace the screen now, else they’d done that.

But the stunning part of this is that I was actually treated with what is one of the best customer experiences on the planet. From the beginning, it was all about helping me, about fixing my new phone now. This didn’t feel staged, it was all just plain honest and straight-forward.

They could have asked me to come back in a week or so when they’d probably have replacement displays. They could have charged me the steeper repair price for the new phone – that would have been goodwill already. They could have just say, “sorry, but the warranty doesn’t cover this and we can’t fix that now”. But they didn’t hesitate for even one second to fix this in my best interest.

So, thank you, Apple, for this stunning lesson in customer experience. And for the new device, of course. It’s protected by your black silicone case now.

Gripes

Not much progress on my 5.1 pain points

In my gripes about 5.1, I’ve mentioned a couple of things I hoped we could address in 5.2, but we’ve finally decided to set the priorities differently. Unfortunately, that means that most usability issues with the configuration tree are still there. The same is true for some areas of the visual design, which leads to an overall inferior visual quality of our new UI than I’d like to see.

The property editor of Pixelmator

On a lighter side, Sasha has shown me a nice dialog configurator with integrated property editor he’s been working on. The editor could mean that we might get a safer, more comfortable input method for configuration values earlier than I expected. I’m not yet fully convinced that a generic property editor is indeed the preferred way to tackle this issue, so we have to do some more research still, but I must say I liked what I saw. However, you shouldn’t expect this to show up any time soon.

Lack of UI evolution starts to smell badly

Although Magnolia 5 is still new, some bad UX smells have already added up due to our focus on more technical topics in the last two releases. That focus is fine with me, of course, but things start to seriously and unnecessarily restrict me in authoring interfaces for some new features we’re working on. To give you an example, since we still lack support for multiple and closable sections in the Action bar, the list of actions gets messier with every additional group I add.

A messy edit form in Assets

We also need to work on forms. We lack grouping elements to properly structure them – that makes the “meta data” tab in Assets shown above just a mess of fields. I’d like to improve our forms with proper titles, field sets and sub tabs rather sooner than later. Also, forms need more flexibility in width. And, yes, the visual appearance of inline messages and of the recently added, more complex fields wait to be improved as well.

ACLs are not working well

When we set out to re-implement ACLs, we basically took over what we had. But ACLs don’t look and work so well currently; unsurprisingly, the feedback I get is trending towards the negative. I see three main problems with ACLs currently.

First, the current approach is powerful and flexible, but not very expressive and quite error-prone. On an admin level, I’d like to be able to just allow or deny access to features, not URIs, for example. Second, the URI approach feels inherently unsafe as it doesn’t provide a good overview of the current security settings. Can you instantly tell what is allowed or disallowed? I can’t, and that makes me feel unsure about what I’ve configured.

An improved visual design for our current ACLs.

While part of such a problem can always be solved by offering better tooling for auditing and verification, I actually would like to go a step further and re-think the UI itself and do away with all the worries that our current approach causes.

The last problem I see is that the current dialog layout with it’s fixed-width appearance does not leave enough space for an embedded ACL UI. We need more flexibility here, but I’ve mentioned this already when talking about forms above.

So all pain and no gain?

No. For once, we’ve decided to make the polishing and improvement of existing UI features a major goal for 5.3. We plan to assign a small group of developers to UX during the entire development cycle to tackle as many critical issues as possible. Second, we’re going to revive the UX team. Sometimes also dubbed the U-XMen, this team of experts on all UI matters will meet with me on a very regular basis and helps to tackle UI design and usability issues. We’ll do early reviews of proposals and try to further disseminate the knowledge about how to design and build proper UIs in Magnolia in the entire company.

So I’m looking forward to 2014. Happy New Year to all of you. Thanks for following this blog, thanks for all your feedback and support in the last year. And enjoy the holidays!

As I’ve done for the previous release already, I’d like to have a look at the new release from my UX perspective. I’ll start in this blog post with what I like.

Hypes

1. Migration brings more users

A Magnolia 4.5 installation waiting to get updated to the new 5 UI.

I love the fact that a solid, mostly automated migration is now available for 4.5 installations. This will bring many more users to the new 5 UI and will increase the pressure to further develop and evolve it.

Because new apps mean new ideas and additional demands. What additional views do we need? Could we standardize some of these and make them available to all apps through the basic framework? Do we need a property inspector? A view filter? Should dialogs be more dynamic?

I have my own thoughts on these topics, but I’m more interested in hearing from you. Let me know what questions you have, where you’d like us to change or improve things. Reveal the new ideas to me that have popped up in discussions with your colleagues.

2. REST brings native apps to the crowd

I’d also love to hear from you if you plan to leverage our new REST API to integrate an external service or to build a native app for a mobile device. What we’re shipping is already quite powerful for many applications I can think of, plus it can be easily extended with your own endpoints.

How about a simple app, that allows to quickly screen incoming work items and approve or reject them? Or an app for my NEX-6 to automatically upload images to the Magnolia DAM? I could finally start using Magnolia for photos I need to directly publish from my camera.

3. Fresh UIs for well-deserved apps

RSS Aggregator configuration tab in Magnolia 5.2

We’ve upgraded a great slew of apps to feature new UIs, apps which we’ve shipped with their legacy designs so far. For 5.2, we’ve invested some additional time in the more complex of these to also simplify and streamline their interfaces. Most apps look and work more now how we expect 5 apps to look and work.

Verifying your mail settings in the new release

The Mail tools app and the RSS Aggregator are good examples for using the Small app layout, which we’ve explicitly developed for apps offering tools or hosting settings. Although we’re still lacking some structural elements in forms to make these UIs really first class, I’m happy with the results: both apps demonstrate how existing interfaces can be simplified and beautified mostly by just employing the new framework.

Some more notables

Uploading an entire ZIP archive full of assets

At the last notice, we’ve also added support for uploading entire ZIP archives of assets. You may also directly insert assets in the rich-text fields again. Both features have been requested several times and add great value for users. And in case you haven’t noticed it yet: search in 5.2 is now case-insensitive.

So, all in all, Magnolia 5.2 demonstrates to me for how far you can go with the available means already. It may not add big UI improvements, but it finally opens the doors for existing projects. This will bring a many more users to the reworked Magnolia platform. I’m really looking forward to seeing increased dynamics in UI development in the time coming.

Meanwhile in Magnolia land, we’ve just released Magnolia 5.1, and some of you might want to change to the new release rather sooner than later. There’s indeed an impressive set of changes that will make the update worthwhile. I’d like to shed light on a couple of improvements I like and which have a significant impact on the product’s UX, knowing that you’ll be hearing about all the other changes from other sources.

But to make this a bit more exciting, I’m also going to name some of the issues, which sadly didn’t make it into 5.1, in a second post.

Hypes

1. Better search

What a view: a search for “admin” no longer returns 5000 matches.

Search is such a powerful tool in applications, if done well. In 5.0, search isn’t exactly brilliant, as it returns way too many results and only searches a single (the default) node type. In 5.1, that has changed significantly. We’re now filtering out many unnecessary matches (e.g. those because of “jcr:” properties) and will return folders and other node types as well. Search does still not provide a fully satisfying experience – you can’t search for properties, for example, and it really should work as a filter instead of a view -, but I’m happy we got these changes in.

2. Your own icons and widgets

If you’ve designed and built your own UI elements for your M5 app, you can now simply add a custom widget set to your module – there’s no need to extend our widget set any more. Similarly for adding your icons: just add and configure your  theme in your module. It’s still not all smooth sailing yet, but this step makes custom app development a lot easier. Which I find exciting as I’d like to see these apps coming!

3. Powerful new fields for forms

Forms can always be improved. In 5.1, newly added fields may accept multiple values or values which are made up from several fields. And switchable fields are capable of showing different sub forms based on what the user chooses as their main value. Why is this important? It paves the way for easier to understand forms. A gallery can now simply be configured as list of images.

But these magic fields will also allow me to improve and fix the in-page editing experience substantially. We’ll see easier to navigate component hierarchies and less bars in the future.

4. Working “move” in trees

We’ve added an actual “move” action to the Pages and Assets app (others should feature it, too, really) to complement drag and drop. It opens a dialog and lets you choose the target destination of where you want to move things to. It may feel a bit retro to open a dialog like that, but this offers a reliable, fully accessible solution on all devices while the underlying table code is seeing major reworks. And it fixes a major usability problem we had in 5.0.

5. Full-dialog editing for text areas

Switch any larger text area to go full-screen to support distraction free writing.

Every text area and rich text field in a form now sports a switch that will allow the field to take over the entire width and height of a dialog.

Not worth mentioning, you think?

For me, this little change represents an actually much improved editor experience I’m currently working on. Content editor pros need a better UI while content breaks out of the page. No more in-page editing. Better previews. It’s all planned for early next year.

Check out my next post for a list of my UX anti-favorites in 5.1.

Gripes

1. No light dialogs yet

The rename dialog shown as light dialog – it’s still modal, but looks lighter and doesn’t hide the context you’re working in.

Not all dialogs are alike. Our current dialogs feel too heavy and intrusive, when you just need to quickly pick a page to link to or rename a particular contact – they have been designed to help you focus on editing content. This is where light dialogs come in. These dialogs are lighter, and while still modal, they do not black out the background and thus connect with the context you’re coming from.

We’ll use light dialogs to show the item chooser UI, for the new move dialog and all existing rename dialogs. Unfortunately, they didn’t make it into 5.1. For me, that’s why the new “move” action feels incomplete, though it works fine.

2. Usability when working with trees

Working with the tree is fine for small to moderately sized trees of pages. When working with the configuration, the tree doesn’t shine. This is partly because the current UI is targeted towards editors more than developers, but we can still do a lot better for both. We do not support copy & paste of nodes – you can’t even select text to Ctrl/Cmd-C it -, white space characters are not visible, values are rendered as HTML, and the whole tree just takes up way too much space. I’d like to correct this rather sooner than later.

3. Visual appearance of alerts and notes

Alerts and notes are for showing modal messages and notifications. These highly visual elements just don’t look right yet. In fact, they don’t look as designed: both elements are supposed to feel like little sheets of papers, like post-its that quickly come and disappear. We’re not quite there yet and for me, this lowers the visual quality of the product.

How notes look now (at the top) and how they should actually look like.

How alerts currently look (at the top) and how they have been designed.

4. Form fields done, but not done

While we have an impressive set of fields for forms, we had to stop working on them, before they were actually completed. Re-ordering the elements in multi value fields is not possible yet; the trash icons are placed too close to regular, non-destructive actions; we have editable fields in the image upload field, which not only looks bad, but is plain wrong. And, again, the visual design is not yet fully implemented.

I consider this important as I’d like to leverage these cool fields types to simplify in-page (and enable in-line) editing. That’s going to be a significant step forward for a better editing experience, but I can’t take it just yet.

5. The sea of actions in the Action bar

The list of actions starts to get long

The list of actions available in the Action bar becomes large and will soon start to appear unorganized, despite our attempts to properly group and order them. I wanted to add separate, collapsible sections for less used actions, rework and unify others, and even get rid of one or two actions entirely for 5.1. Also, the tablet UI shows actions such as “export” that don’t make much sense on a tablet, particularly on an iPad. However, our technical and visual debt provided us to drain the sea of actions. Users thus have to travel it with no further guidance from us.

There’s happily no relief in sight

I’d love to address all my gripes in the next release, but that’s not very likely going to happen – and actually for good reasons. For Magnolia 5.2, due in only four weeks, we’ll focus all our resources on migration topics. A proper migration path is as important for our customers and users of Magnolia 4.5 than good-looking alerts. My modest goal for 5.2 is to get some of the bigger usability issues with trees and previews fixed and to guide developers when migrating the UIs of existing modules.