Monday, February 3, 2014

Magnolia app design guidelines are go!

Today, we're launching the Magnolia app design guidelines.

This is an important moment for everybody involved in designing and crafting the new UI, as it represents the first time that we're releasing official documentation that gives best practice advice on how to build good UIs for your Magnolia apps and also exposes some of the underlying principles of Magnolia's new user interface.

We've thought about a good format for our guidelines for a long time. I typically lean towards explaining everything in great detail, as I have to in the UX wiki space, in the hope that someone would actually go and read and understand it all and, from then on, apply and use all those ideas and UI elements as originally intended.

But that's not how it works: it's next to impossible to precisely capture every aspect of an interface and still come up with a document worth reading. And it's quick, simple, easy-to-read, easy-to-apply advice that makes a difference in the heat of a coding or design battle, not long texts.

So we're trying a different approach. Do you remember those print magazines in the 80s, 90s, which came with collectible recipe cards, maybe three or five cards per issue? 

Every card was explaining how to cook a particular dish and was properly laminated so you could use it in the kitchen with wet hands without ruining it. And you could order a handy (and horrendously pricey) plastic box to store them in. We've not copied the dark side of that business model, no, but we've applied the card model to our guidelines: the concise writing style and to-the-point character of every card; the consistent layout across all cards; and a layout that supports browsing for new recipes by just flipping through the set of cards.

We're launching with eight cards covering the most burning, most asked for UI topics that surfaced during reviews. Each card starts with a short summary of the issue, followed by one, two images of good and bad examples. The card is completed by some additional details in the bottom area. All text is typically linked to more comprehensive pages in the documentation wiki.

We've taken great care to pick titles that tell you enough about the topic of a card to help you in quickly finding what you're looking for by just glancing at the stack of cards. This should also give you additional ideas of what to look out for when designing an app. And you might actually want to consider using the entire card deck as a series of smoke tests for your new UI.

Obviously, eight cards are not enough to cover it all. Additional cards will be added over time. We've already written some cards to cover future, still unreleased UI features. This is an ongoing effort, and it greatly depends on your feedback - so tell us what you want and need to know. And let us know if our guidelines actually helped you in cooking better tasting, better looking dishes by leaving a comment on the corresponding card.

Monday, March 18, 2013

Magnolia 5's Editing Flow

One of the essential things of our new user experience and something that has been on Andreas’ mind a lot these weeks is the editing flow. We want to ensure that an editor can edit and preview content and assets swiftly, with minimal rupture in the editing process. That's why designing a flawless editing flow is of utmost importance.

Editing view and preview

In Magnolia 5, every item has an editing view and a preview, which open in the same tab. Below, you can see the example of a contact. Note that this is but a mock-up of the design. You can compare it to the (work-in-progress) of Magnolia 5's user interface in our image gallery.

On the left, the preview displays every detail of the contact, all the address and contact information it contains and where it’s currently being used. This is also where we’ll show a history of changes in a later release. By contrast, the editing view on the right focuses on all aspects of the item that you can actually edit.

To switch from preview to editing view, click on "edit item" in the action bar. To return to the preview, either save your changes by pressing the “save” button or hit "cancel" to discard them. Additionally, both views can be toggled between tabbed and full-screen view.

Same same, but different

While different, both views also share some facets of their visual appearance to avoid disorientating the user during the switch. We do this by defining visual landmarks or cues you immediately recognize. They can be found in similar positions in both views - in the example above, they are marked with orange rectangles. A good example for such a visual cue is the thumbnail image prominently located just below the title bar.

Example: previewing and editing assets

Let’s have a closer look at another example. Here’s the editing view of an image asset managed by the new DAM coming with Magnolia 5:

The title of the header looks like a dialog header. As a matter of fact, the entire form resembles our new dialogs. That makes it easier for users to identify key elements of forms placed in dialogs and on tabs, such as the “cancel” and “save” buttons. Below the header is the thumbnail of the image that you’re editing, one of the visual cues we’ve mentioned. By the way, the “edit image” button next to the thumbnail will open our cool new image editor - we’ll tell you more about this at another point in time.

Now here’s the preview of the same image asset:

You notice the similarities immediately. While there’s an additional tab named “Uses” listing all instances where this asset is being used, the rest of the view is structured similarly to the editing view. One major difference is the action bar on the right-hand side, which contains all actions you execute on the asset.

Multiple edit sessions at once

You might have noticed that one key feature of our new editing flow is that it allows you to have multiple edit sessions open at the same time. The pen and eye icons in the tab instantly visualize what view or state a tab is in. This makes seamless switching and copy-pasting between tabs significantly easier. No longer will you have to keep several windows open when editing a multitude of content - the tabs and their icons will keep it all in one place.

What you can expect later on...

This is just the first take at our realigned editing flow. With the changes we’ll deliver for the Magnolia 5 GA release, we’ll make sure that all aspects of a content item can be viewed and edited. But there’s more to this than might be apparent at the moment. Obviously, a switch between views is still a somewhat heavy operation, so that’s something we’re going to tackle in the future. Direct in-line editing is on our roadmap as well. Our goal is to make editing ever more seamless, faster and enjoyable in Magnolia. The new editing flow is a first, solid base we can continue to build on.

If you’re curious about what awaits you in the next six months, check out the Magnolia 5 roadmap. Additionally, in the months leading up to Magnolia 5, we’d like to continue sharing what we’re currently working on UX-wise. There is an enormous amount of things to consider, discuss and build for the UX team right now, since our new user experience is what will shape Magnolia 5 most substantially. Want to follow us on the journey there? Subscribe to the RSS feed of this blog and follow us on Twitter.

Thursday, December 6, 2012

Favorites: your personal space in Magnolia 5

Magnolia 5, our next and biggest release so far, is made up of three key areas: Apps, Pulse and Favorites. Apps and Pulse have been featured on here already. There’s only one piece missing from our trinity coverage: Favorites!

The most straightforward way to think about Favorites is to look at it as a user’s personal workspace. While Apps is a toolbox that will help a company customise the CMS according to their business processes, Favorites is all about what is relevant to a single user.

There are two different kinds of Favorites that a user can create.

The first way to use Favorites works a lot like the bookmark feature of your browser: you add a page to your Favorites that you will want to edit again and again - the landing page, for example. Instead of navigating to it within Magnolia, just access it through Favorites within seconds - by clicking “Edit main landing page”.

Let’s use the case of a product page as an example for the second kind of Favorite, which we plan to deliver in a next step. You might have to publish product pages again and again. All you have to do now is create a Favorite for that type of page, which in turn will give you a template for a product page. Drafting such a page will require two clicks only: “Favorites” and “Add new product page”. Without Favorites, the process to get started would be a lot longer: you’d have to go to the Apps screen, open the Pages app, add a new page, pick a page template and then edit it. Favorites will thus eventually be able to also trigger important actions.

Why did we make this customisation our third shell app and thus a focal point of Magnolia 5?
Being able to get to work fast and efficiently is one of the essential principles of Magnolia CMS, so it was clear that this ground rule would be present throughout Magnolia 5. Favorites contributes to this in decisive and dynamic ways.

First of all, Favorites will help you shorten the way from signing into Magnolia to actually getting to work. Most Magnolia editors have a few actions that they use again and again - Favorites will lead them there within two clicks. Customising your workspace is incredibly rewarding: you know exactly where to go to deal with pressing matters. Further, it is another means to help you keep focus: Favorites will represent your most common and thus most important tasks within Magnolia.

One last point to consider is the fact that new editors or occasional users, who might be responsible for one or two pages only, will find it a lot easier to work with Magnolia: they won’t have to know every app or details of areas that don’t concern them - instead they can just customise their user interface with Favorites to use efficient shortcuts from the start.