Personal blog by MOC creative lead, Neos UX lead and TYPO3 brand manager. Winterbather, zazen-meditator, micro-managing 4 kids, photographing - and some 16 short years of experience doing concept development, user experience planning, interaction design, information architecture and brand management.

Localization is not about localization

A couple of weeks ago, the TYPO3 Neos core team met in Rosenheim, Germany for a code sprint leading up to the Inspiring Conference. A major feature we wanted to work on (again-again-again) was localization. 

The technical concept for how to build in localization for TYPO3 Neos has been underway—and basically done—for a really long time. We only started thinking about the UI concepts about a year ago. Turned out it was a much bigger UX challenge than I had imagined. Quite a lot of research also went into these efforts. A tiny bit of that was blogged about.

So why is localization not about localization in TYPO3 Neos? I’ll get back to that—yet let me first give you a bit of background info and tell some of the stories about why dealing with languages and regional variants in a CMS can make developer heads implode and turn an experienced UX’er into a whining monster baby.

Only care to see the end result? Scroll down!

Getting it right from the start

Localization is now finally getting into to the youngest of the two CMS’s that the TYPO3 community is developing. How could we wait so long with such a crucial feature for an enterprise-aimed CMS, you might ask. The first, simple reason is that we wanted to get it right from the outset.

Releasing a flawed localization UX concept would be entirely unacceptable as agencies and clients would have to struggle with its first iterations and adapt after we’d have gotten it on track. In this case, failure is just not an option when releasing it. Will it be perfect when we release it? No—but the fundamental concept has to be strong.

Many of the guys on the Neos team are from German-speaking countries. This fact gives us a huge advantage since so many of the devs are highly experienced in dealing with content management in places like Switzerland, Belgium and other countries in the region where multiple languages co-exist. What those solutions often have in common are the dreaded cases of fallback. 

When a website translated from Deutsch to Schweizerdeutsch is launched in Switzerland, the common approach is to copy the German content and then translate and/or correct stuff for regional differences. But if you have a huge collection of content, you would normally be okay with launching the Swiss version with some of the German content “shining through” to the Swiss audience.

That’s a simple fallback chain (that even I can understand.) But it goes even further. In some cases you can have a 3 or 4 step fallback chain. It’s quite simply a usability nightmare providing the content author an overview of what’s going on with their content. What’s translated and what’s not? How do you test the fallback versions? Many tricky questions turn up. 

In many localization scenarios, you would typically use an external translation agency to translate the content and feed that into the CMS. The localization UIs in Neos can then function as a staging environment where editors can tweek the translated content. The importing of translated content into Neos is done using the built-in XML format—or one of the standardized translation file formats using a 3rd party package.

The UX goal:
Make it all about content variants

This is the second reason why the localization project in Neos has taken it’s time. We wanted localization to introduce a user interface that handles all kinds of content variants—or dimensions as we call it internally on the team—in a similar, consistent way. Languages and regionalized content is essentially just that—content in multiple variants. This concept of content variants can be bridged “easily” to a lot of other variants of content. 

To name just a few examples of dimensions we regard as variants that can be handled by one, all-embracing user interface pattern:

  • Language-versioned content (everything from just Danish—to UK English, US English, Pirate Dutch and the mysterious non-existing language hidden in Neos)
  • Personalized content (any kind of personalized content you can think of—there are many variants—including persona-based content variants, allowing you to differentiate content based on personas)
  • Device-variants of content (one version for a faculty website, another for its on-campus screens etc)
  • Channel-variants (one version of a content chunk for your website, another for an iTunes abstract and another for an aggregated version on another website)
  • Regional variants
  • Location-based variants (responding to your exact location)
  • Time-zone variants (say you’re launching a product at 9:00 AM in all time zones with differentiated messages)

So, your obvious next question is OF COURSE:

Will Neos even be able to let you combine such dimensions? Naturally. And we’ve even designed an interface that makes it fairly easy for an author to see what’s going on in the more complex setups. It’s not going to be as easy as opening your fridge to find the champagne—but it sure as hell is going to be simpler than many other systems I’ve seen.

Why a generic concept?

When it comes down to planning user experiences and actual interaction design for localization—the first obvious choice is to go for a pretty specific interface solution that covers the most important use cases (the 80% basically - and let me assure you, the 20% edge cases of localization could make most interface designers cry and dream of simpler days of having to design a print brochure in high school). A specialized interaction design would let you tailor the interface for “just” localization. 

However, one of the most important design guidelines I adhere to in Neos is that I always choose generic solutions over the specialized. Whenever, I can apply framework thinking (all greatly inspired by the devs on the team), I do just that—instead of falling into the trap over doing one, specific UI at a time (think about the mess that would grow into over time!).

Enough talk, show me pictures!

Start building variants—in this case language variants—by clicking the corresponding edit mode (Translation):


Below the editing modes (in the formatting bar just above the view of the website), the user will be able to configure the source version view, enabling you to preview languages, device-versions etc. directly from the Neos interface. This interface provides editors with a way to configure what variant of the content is worked on. Whether you use In-Place editing or Raw Content, the editor can switch languages from here without thinking about translation.

Split-screen is enabled, using our Raw Content editor on both sides:


On the right hand side, you can have multiple variants all connected to one source on the left. The 2 arrows at the bottom will let you collapse the split-screen both left and right, enabling the author to focus on either the source or the variants. The split-screen view is based on our Raw Content editing mode to let editors easily compare content to keep it in sync. For quality assurance tasks (think legal), this will also provide an easy way to spot regional differences etc.

Configure the view—could be just language selection or a combination of device, language and persona-based personalization. This can be expanded in many ways, enabling you to do content variants for different time zones or whatever parameter you can dream up:


This shows the interface for starting the variant for a whole page. Might want to rework the help texts a bit:


Interface for showing the content author that there’s a fallback variant. This gray box on the right hand-side will then let the author decide whether to just edit the fallback (in the fallback language) or make a new variant that matches the current target language:



The plan is to release the localization / content variants UI in TYPO3 Neos version 1.2. A lot of it is already implemented and “just” needs tweeks, QA and finalization—but there are also things that can still be altered. Please do give us feedback on this. 


Technology needs art

I work with technology. But my background is in arts.

This blog post is about discovering how artistic processes can influence technology—and about just how much technology needs both processes and values coming from the arts.

I danced classical ballet, my parents are both musicians and in so many ways, I was brought up with values such as artistic excellence, endless questioning, intuition over rationale, about giving room to surprises and coincidence, quality over efficiency, depth over surface, subtle slow thinking over drastic fast change, length over the bite-sized, experience over flashes of the moment, embracing complexity, defying the strictly linear—and about how gut feelings are more important than arguments.

Me with my ballet teacher, Ralph Grant – dancer in Germany for Tanztheater Wuppertal with Pina Bausch

Without realizing it in the process, I carried values from arts into business and technology. Every time I talk to an engineer, a programmer, a project manager or a business developer—my thoughts are permeated by such thinking. They might come to me with a design problem hoping for a simple, implementable solution to a complex problem—and although I have trained myself to deliver that, too—most often what they get are just more questions—or answers based on intuition. Because that’s how I faciltate quality.

Luckily, most of the time those clashes of paradigmes turn out fruitful. So what is there to learn here? That’s what I want to dig deeper into in the next couple of years.

Technology OD’es on rationality

I recently met with author and communication consultant, Christian Have. We spoke about this topic and he urged me to pursue this further—he asked: “How do you think artistic processes will help technology?”

"But I let artistic processes influence technology choices all the time", I answered and looked at him curiously. "What’s new?"

The answer is clear: Looking at the entire sphere of technology—it is nearly always dreamt up, planned and executed within a rational paradigm. Technology suffers from an overdose of rationality.

I’d like to dig into how we can let art and technology influence each other—not on an experimental basis but in a mainstream business environment. 

With agile processes, we have found a way to make the most complex operations become streamlined. And that’s brought lots of value when it comes to efficiency in a chaotic digital landscape.

Yet, what I learned from my background was that only so much can be streamlined—and that true quality comes from the most unexpected places.

What art knows about quality

This line of thinking—that art knows something special about quality—is second nature to me. Artistic processes are all about achieving quality. Profit-based thinking, not so much. How many times have we seen inferior quality become a hit on the market? It happens all the time.

I’m not saying that’s never the case in arts—absolutely not. But art is intimately connected to achieving quality in a fundamentally different way than business. A business success is quality in it’s own right. Yet, it can be succesful without ever reaching a state of deeper quality—it basically just needs to be sellable.

Business uses technology—with and without strong values of quality. Art comes with another value set attached to it. One that I want to bring into business and the way we explore technology because it heightens quality.

I see that without art, I cannot produce the creative software solutions I work to achieve.

That has to be true for many designers of technology.

Artistic processes can greatly impact technological innovation and I can’t wait to explore this field even more.


Researching localization for TYPO3 Neos

On the quest to structure and design localization for TYPO3 Neos, I’m currently going through some of the varied use cases for translating and localizing in typical content management scenarios. Localization is a really tricky thing to get right because the use cases are so different—yet, I want the UI to be as generic as possible to handle as many types of scenarios as possible—within one design framework. 

Here’s a collection of randomly sorted use cases. Please include more in the comments. 

  • Translator translates an entire website to another language in the CMS: A translator goes through every single word of a website and translates it to another language using the CMS’s editing interface. Preferably, this is done in a split-screen UI to enable the translator to continuously see the base version alongside the one being translated.

  • Translator translates an entire website to another language using translation software: A translator goes through every single word of a website and translates it to another language in a translation software package. The original content and the translated version is imported and exported back and forth. The translated version then gets reviewed and QA’d in the CMS interface before publishing.

  • Web editor translates a limited part of a website: A web editor maintains and translates a limited subset of the content. Typically, a small portion of content on a non-english website is translated or versionized into english.

  • Web manager of a regional website “takes over”: Web manager of e.g. a brand site gets a full copy of a website, translates it 1-to-1 but then takes over control of the localized version and starts to alter the node structure and gradually changes the content, eventually seperating it completely from the original source website. When new material from source site is introduced, that content then has to be adapted to the localized structure. Also, the regional web manager should be notified of important changes or additions.

  • Multi-site manager pushes out changes to localized sites: A web manager of multiple, related websites introduces new or altered content that needs to flow out to every localized version—regardless of whether localized sites are 1-to-1 copies, slightly altered sites or entirely changed, localized versions.

  • Multi-site manager wants specific content elements to be adapted for cultural differences: A multi-site manager tasks regional site managers to differentiate content to enable culturally fitting end-user experiences. Typically, this could include applying new images that convey the same meaning but fit the culture of the localized version.

  • Marketing department introduces personalized content variants to be translated and adapted to all localized sites: (good luck with handling that!)

  • Site manager sets up fall-back rules

  • Web editor needs to QA different fall-back versions of a website

  • Multi-site manager changes legal text for immediate publishing on all localized sites

  • Web editor needs to correct simple typos and notify others of the changes

These are just a handful of use cases, that I can think of. There’s a gazillion others. Please do list your use cases in the comments. Later, I will group them together with other core team members and prioritize which are to be handled in the first version of Neos localization and which can be designed for later. 

In general, I would guess that 80-90% of all web producers that deal with localization are frustrated with their CMS capabilities when it comes to handling the complexity that localization introduces. While researching, I have looked into a number of other systems to see how they design UI’s for localization—and I have to say, it’s not pretty.

I don’t think that there’s a really strong reference we can use for inspiration. In other words: It’s okay for TYPO3 Neos to think outside the box and introduce entirely new ways of handling localization better. 


Using TYPO3 Neos’ preview framework for accessibility testing

This blog post is a guest post from Christian Herberger, a TYPO3 developer from punkt.de.


Clicking “Accessible” in the Preview Central would turn off all CSS to let you see how the page is basically displayed without all styling. 

After seeing a demonstration of the customizable preview modes which are available in Neos, I felt this would be a nice framework to use creatively. Testing how a website looks and feels on a smartphone is usually done with either a smartphone or an emulator – being able to do a preview directly from the backend sounds much more convenient.

Then I started asking myself - “which modes would I define?”. I first thought of mobile and maybe Full HD screens. But digging a bit deeper into how varied the possibilites of previewing actually are, I suddenly thought of a personal friend of mine. She is a web designer who specializes in building accessible websites for people with disabilities. Now wouldn’t it be awesome if she or the editors for her websites could use a preview mode that disables CSS and JS?

Editors and developers could check out if the page and the content is semantically correct and if all features work as designed for limited browsers. This would be a huge step towards a more accessible web.

Maybe you could even define preview modes for different, specific screen readers so the editor could get a precise simulation. The editor would see the experience of the visitor with a disability. We as developers or editors could better understand the needs of those website visitors if we saw visualization of pages like the disabled people see them. Disabled visitors should have the same quality web experiences and get the same value from online experiences as everyone else. But the editors and web developers will need be able to quickly see realistic previews – otherwise the trouble of developing accesible web is too great.

I don’t think that any CMS out there provides the possibility to test content experiences in this way. Surely, some developers and frontenders turn off CSS, JS, images in the browser’s developer tools but this happens far to rarely. A preview mode in TYPO3 Neos could be a step into the right direction towards a web that truly is for everybody. Sounds big and exaggerated but I believe that we as developers and editors should be more responsible in regard to accessibility.

Everyone wants the web to be accessible on smartphones and tablets - we should start thinking broader than that.

About the guest blogger

Christian Herberger is a developer/TYPO3 integrator for punkt.de in Karlsruhe. He has been developing since 2004 and using TYPO3 since 2008.

Website: http://www.kabarakh.de/
Facebook: http://www.kabarakh.de/fb
Twitter: http://www.kabarakh.de/@
Google+/Hangouts: http://www.kabarakh.de/+


UX Romandie: Designing a CMS for the future

UX Romandie: Designing a CMS for the future from Rasmus Skjoldan

TYPO3 Neos 1.0 launch: My thank you notes


So many people were involved in making yesterdays launch of Neos a reality.

And so many people from all over the world have helped me replan the UX framework and the interface designs for Neos.

I’d like to sincerely thank so many, I just had to write a list:

Robert Lemke
and Karsten Dambekalns
– for sticking to this goal for so many years and for delivering such a great framework to do Neos with

Everyone on the TYPO3 Neos team and everyone in the TYPO3 community that’s been supportive of Neos throughout the years

– for letting us spend a gazillion hours on TYPO3 Neos – and for believing in Neos being the future CMS for the agency

Leisa Reichelt
– for challenging us to commit to multi-channel 

Karen McGrane
– for teaching the world content strategy and for giving me such great advice leading up to WYSIFTW

Aske Ertmann
for kicking me into the Neos project again

American Express
and TechDivision for having the courage to build 2 websites on TYPO3 Neos while it was in Beta 

The CMS experts group at J.Boye – for letting me ramble on about template-less editing and previewing

Everyone who participated in the 2017 WCM Forecast 
Karen McGrane, Janus Boye, Alain Veuve, Perttu Tolvanen, Boris Kraft, Kian Gould, Martin Goldbach Olsen, Jacob Floyd, Mikkel Staunsholm, Olivier Dobberkau, Daniel Hinderink, Christian Badse, Robert Lemke, Jan-Erik Revsbech, Sebastian Kurfuerst, Anders Bendix Kiel, Christian Nilson)

Bret Viktor
– for his Inventing on Principle talk that has had massive influence on the Edit / Preview modes of Neos

for helping us with last-minute frontend development of Neos

Jeff Eaton
– for his great Inline Editing post and for sharing thoughts

Yat Hui
– for debating with me how to apply master planning principles from architecture in our UX planning of a CMS

Deane Barker
for taking the time to demo Neos and for making developers cry when they heard what he thought about it

Information Architects
– for the insights they gave Robert and me about how journalists curate content in CMSs today 

All those clients and agencies who participate in the follow-groups

And yeah, I have most certainly forgotten lots and lots of people who have also helped me during the last year of Neos UX/UI planning and development. Thanks to you, too :-)

I’m super excited about where Neos will go in 2014. I have some pretty serious plans about what I’m going to do myself during the first half year of ‘14 to get some serious translation and localization UI’s into Neos – and about how to interface with relationship planning in a CMS.


Hello World. TYPO3 Neos 1.0 is out.

Yesterday night we managed to deliver TYPO3 Neos 1.0 on the promised date, 10th of December. That was just huge! 

The new website was also launched: neos.typo3.org

And you can even try the CMS, too :-)



Interview from T3CON13. I’m rambling. Not the cleverest things I’ve said– but I do believe it’s sound to tone down presentation and up content work in general. 


World-wide labeling decision: Editor Experience or Author Experience?

I talk and write quite a bit about editor usage of CMS and how to improve the editor or author experiences using this type of software.

So do others and others and others and others and many more.

The world seems to agree on the labels “UX” and “User Experience”. But when we talk about “Editor Experiences” or “Author Experiences”–it seems we mean kinda the same, yet call it different things.

I haven’t found major differences between definitions of “Editor” and “Author” in the world of content management. Editors not only create content but can also manage it – but both editors and authors create and edit content, right? Or am I overlooking something? (JeffKaren?)

It’s a simple label–it would just make clients slightly less confused if we agreed on using the same terminology here. I personally prefer “Editor Experience” as it (to me) goes beyond content creation and into a bit more general usage of content software but I can definitely be persuaded to change to Author Experience and “AX”.

Wikipedia on Author:

An author is broadly defined as “the person who originated or gave existence to anything” and whose authorship determines responsibility for what was created.

Wikipedia on Editor

Editing is the process of selecting and preparing written, visual, audible and film media used to convey information

Is there actually another difference between these two terms in regard to CMS work that I’m overlooking or could we do a quick worldwide vote and settle on one of them?

Our clients will love us for using similar language!