Skip to content

Creating a great front end experience for your webshop with CoreMedia

Exciting shopping experiences are a lot of fun! But how do you get there? This post will cover the front end side of things from the idea to the design to the user experience to the implementation of a fully featured web shop frontend with augmented shop pages and custom content managed by CoreMedia.

Part of CoreMedia’s product portfolio is the Blueprint; a collection of example websites and webstores combined with useful customizations for the Studio, our CMS front end. The example websites come with a set of templates, stylings and JavaScript to get our customers going quickly with a versatile yet feature-rich foundation.

Every now and then, we create new example websites to better showcase new features and development methods. This time has come for our 3.1710.1 release of LiveContext 3 which includes the Calista webstore, our brand new example webstore that demonstrates how CoreMedia integrates with leading e-commerce solutions like IBM Watson Commerce, SAP Hybris, and Salesforce Commerce Cloud to sell luxurious brands on a global scale.

The Design

Calista (from the Greek “most beautiful”) is a small island in the Falklands, but it is also our fictional brand of exclusive haute-couture fashion that is active in many languages and countries around the world. It rivals internationally known brands such as Dolce & Gabbana, Armani, and Dior. As you may see from these sites, modern design for an international fashion brand is heavy on images and intentionally used whitespace. The typography is simple and elegant. These were qualities that we strived to achieve with Calista.

At the same time we wanted to put our new webstore on a new technical fundament based on the most modern web technologies so that our blueprint can continue to be used as starting point for large scale projects. We chose to go with Bootstrap and the CoreMedia front end brick system which allows for modern front end development with state-of-the-art tools and workflows. Our explicit goal was to go with Bootstrap as a standard as much as possible and avoid any special code that is unlikely to be reused by our customers.

Another indispensable trait of a CoreMedia Blueprint demo site is responsiveness and adaptive image delivery. All of our pages work well and look nice on all devices and save bandwidth on mobile. Of course, all devices can be previewed immediately and directly in CoreMedia Studio, making this feature even more crucial.

Our UX team was hard at work on the whiteboard, later in Sketch to come up with a design that is both functional and sleek. Sketch was enormously helpful for implementing atomic design principles. The Sketch ecosystem is rapidly evolving, though, and our workflows have changed during the project. For instance, collaboration and versioning has always been difficult with Sketch. When we started out, we were working on one Sketch file for each component (or organism) and one for each type of page (or template), synchronized via Dropbox. This allowed for several team members to work simultaneously but made it difficult to keep everything in sync.

In July, we took part in the public beta of Abstract which was an instant eye opener. It solved all of our synchronization problems and made collaboration easy and fun. It also makes real atomic design work possible. We had to change our workflows, though, to accommodate for the more “git-style” setup of Abstract. In the future, Abstract might also change the way we hand over UX deliverables (more on that in a minute) as they have announced new features in that area.


A bunch of commits on our Calista project in Abstract.

The Implementation

Creating a website with CoreMedia begins with the setup of your site and theme. Since the site is created as content in CoreMedia Studio, this part is usually just editorial work without development effort. Anyways, even the creation of a new site can be a bit tricky and if you’re not familiar with CoreMedia and don’t know what’s essential for a new site, you will end up being confused in just a second. A closer look into the documentation or existing sites can really save you a lot of time.

While the site is really just the foundation, the look and feel is created in the theme. This is the part where CoreMedia knowledge and a healthy dose of  front end experience come in handy. The fact that the CoreMedia front end workspace has really improved since its 3.1710.1 release has made our work way easier in comparison to previous blueprints we built. Different features could simply be activated in Calista by adding a dependency to the corresponding Bricks. Since Bricks are basically a set of templates, stylesheets and JavaScript which provide certain functionalities, it’s really simple to use these features by just adding a dependency to the theme. The only thing left to do is to add some includes in the theme’s templates and apply your own styles.

To facilitate the work of front end developers even more, we introduced the front-end-developer-workflow in a previous release. Now we were able to benefit from that ourselves and use the workflow to change templates and styles in the IDE and get an instant visual feedback in the browser. Simply connect to a remote system and let NPM work for you. Every edited file gets uploaded in seconds. It’s that simple and a real timesaver. The development of new websites and themes has not always been straightforward in CoreMedia, but with Calista – our first new demo site since all the improvements in the front end workspace – we can now proudly say that a lot of possible pitfalls have vanished.

And that’s not even where our scope ended. Whenever we felt that things didn’t go as smooth as planned, we changed them. Not just in Calista, but also in the front-end-developer-workflow, in the Bricks and in our front end developer manual as well. The work on Calista was not only the implementation of a new Blueprint demo site, but also a stress test and phase of improvements for all the new features we added to our front end workspace.

The Collaboration

Projects like Calista are somewhat large in scale compared to features that we usually collaborate on. Both the development and UX teams have experience in different kinds of project setups, be it building a whole new team for the project or completing it as part of the normal Scrum process. For Calista, we opted to extend our Scrum routine a bit.

We are not the first ones who have made the experience that just handing off a design document and specifications does not work. There will always be a tremendous amount of ambiguous screens, unspecified states, and complicated behavior. We have therefore decided to embrace the fluidness of the process. Our UX team has taken the time to sit in the same office as the front end developers and be ready to discuss—and often adapt—our design. They would sometimes work on unrelated things but were always ready to answer questions. In some instances—especially later in the project—we would throw in some very productive dev-design pairing.

Our workhorse for sharing the UX deliverables among the team members was Zeplin. Zeplin allows us to share Sketch artboards in a way that also communicates margins, text styles and other styling related figures. It can also deliver assets, like logos and icons. In the past, the UX team would work on their designs, export screenshots, mark spacings and dimensions manually and hand them over to the development team as mail attachments or attached to JIRA tickets. For front end developers, searching for these designs was daily business. Zeplin makes such tasks easier because it has all screens and specs in one place. It is less suitable for complete guidelines, though. We’re still on the lookout for a tool that combines Zeplin’s functionality with something like Pattern Lab and good, hand-written documentation.


Zeplin doing its thing.

The Conclusion

Calista is aptly named; it came together beautifully both in a visual and engineering sense. The design could be very well implemented, and the process was made easy by the new front-end-developer-workflow and our modular Bricks concept. Zeplin has proven indispensable for our project and reduced the number of feedback loops significantly. Calista will soon be extended to include even more great CoreMedia front end features like 360 degree product images.

Calista in Studio

The finished site within CoreMedia Studio.

We’re eagerly awaiting feedback from our customers and partners on how this new Blueprint demo site supports them in realizing their own great front end experience for webshops with CoreMedia.


Content as a Service


CoreMedia is a Content Management System (CMS) which can manage your content from creation straight through to rendering. Our Content Application Engine (CAE) provides tools and a framework with which you can easily design a beautiful, consistent and fully-functional user experience.

The components of the CoreMedia system work gracefully together as an isolated system, but it is also flexible enough to be a small but crucial component in a larger ecosystem. Perhaps you have data from many different sources to include into your website. These sources could include  commerce systems, brick-and-mortar backend systems, marketing data, user management systems. Perhaps you have already committed to a certain technology in your website that you need to include. Or perhaps you would like to inject content into native mobile apps.

You need the flexibility to incorporate all that data from many different sources into your website, or reuse that content on multiple channels, while still taking advantage of the powerful content management features that CoreMedia provides: versatile Studio for creating, editing and managing  your content; extensive collaboration features; configurable publication and translation workflows and a wide spectrum of other features.

Our answer to achieve this flexibility is to deliver content from CoreMedia in a standardized, structured way (JSON), making it available for another system, leaving you full freedom to design and render your content using the framework of your choice. We  affectionately call this service the “Headless API”.  And this service is available for you now in CoreMedia Labs (see Resources below).

Using the Headless API you can generate ready-to-go HTML content fragments or dynamic Javascript modules. You can then easily insert these fragments into any webpage or single-page application. Use these fragments to seamlessly integrate, reuse, syndicate or publish your content from your CoreMedia CMS anywhere.

How does it work?

The Headless API defines a simple REST API to access content from the CoreMedia repository. On the server side the content is transformed via GraphQL queries before being returned to the client as JSON reponse. On the client side, simply parse the JSON response and process it as you please.

You can customize the GraphQL queries to tailor the returned JSON to your application’s needs.

The first step is to define a schema, which maps the content properties in the repository scheme to the attributes that you would like to extract. This can be done manually or with the help of a schema generator.

Then you define a set of GraphQL queries which will be matched against the schema.

The schema and query set are either deployed alongside the headless server or installed in the CoreMedia repository. The headless server can be started either by Spring Boot or as a Tomcat webapp. This is a separate component that can be deployed and maintained decoupled from the central CoreMedia system.

On the client side, just request the service’s URLs. The URLs determine which GraphQL query will be used, which content should be extracted and optional parameters for more fine-grained responses. Then you may process the JSON response with whatever technology you prefer.



Interested in a deeper understanding of CaaS in CoreMedia? See what we’ve cooked up for you in our CoreMedia Labs.

Github project: Headless Server as source code, plus a React client as an example

Technical wiki: Documentation on installing and customising the Headless Server, plus documentation on the example React client

Integration of commerce systems into CoreMedia

Auslesen und verarbeiten von MBeans

Es gibt viele Möglichkeiten, die Leistung und den Status eines Java Applikations Clusters zu überwachen.
Aus historischen Gründen ist dabei JMX (Java Management Extensions) weit verbreitet.

Um diese Daten auslesen zu können, gibt es verschiedene Tools, die ich einmal kurz vorstellen möchte:

jmx4perl ist ein Befehlszeilenprogramm für einen einfachen Zugriff auf einen Anwendungsserver.
check_jmx4perl ist ein NRPE Plugin für die Überwachung von Java Anwendungen.
jmxdump ist ein Bestandteil der CoreMedia Toolsuite
jolokia ist ein REST Service, der einen erweiterten Zugriff auf die JMX Daten bietet.
jconsole / jmc sind grafische Frontends, welche direkt mit einem oder mehreren JMX Endpunkten verbunden sein können.
j4psh ist ein Frontend zu JMX::Jmx4Perl. Es bietet eine interaktive Shell für den Zugriff auf die JMX MBeans.
Read more…

The “Maven Box”: an Arduino Controller for Software Developers


As a software developer, you sometimes want to grep some tools and build some “real” hardware. If you can implement the software for this hardware on your own – even better!

I’m a big fan of JavaFX and Arduinos, so I thought I would combine these two interests by building the “Maven Box”. It’s an Arduino board connected with switches, push buttons, LEDs and a rotary encoder that allows you to control a JavaFX based UI. The idea of the UI is to select a CoreMedia workspace (e.g. a workspace of CoreMedia 7 or CoreMedia 8), select a branch and trigger a Git update and a Maven build. Once the build is finished, a notification is shown that you are now able to use this workspace in IDEA.

In addition to this “project control”, six LEDs indicate which pipelines are currently available. This is very helpful, because it’s annoying to start your local Studio instance just to realize the connected repository is not available.

The whole project is not hard to build and I’ve written complete instructions which are available on


Sketch and Principle: UX Prototyping on Scale

The CoreMedia UX team has been busy working on a new vision for our UI. We wanted to explore new interaction concepts and interface design using an example story that leads through the major parts of our product. However, our product is huge so the story became quite long.

We ended up with a Sketch prototype of more than a hundred artboards that we painstakingly animated in Principle. Now, creating clickable prototypes with beautiful animations is super fast and easy with Sketch an Principle. But at that scale, we pushed them to the limit. Here are some lessons we’ve learned and pitfalls to avoid.

But first, we would like to express our sincere gratitude to the Sketch-people at Bohemian Coding and Daniel Hooper of Principle. We ❤️ both! They’ve helped us create an amazing prototype.

Design Phases

A project like this goes through several phases. Here is what you’re looking at when you plan a large prototype.

1. Create a Storyboard

We started out drafting our story on a dozen whiteboards. First, we drafted the key points of our protagonists through the story, then we began creating a storyboard that depicted each step. We came up with 27 steps, or waypoints, through the story. This was a group effort and we gathered feedback during and after this phase.


Here is one of our storyboards. We had several of those.

The storyboard already included the structure and key interactions of the app but was still very rough in terms of micro interactions and design. The whole storyboard was saved in our wiki. We gave each step a number and a little explanation so we wouldn’t be confused as the project went on.

2. Design in Sketch

Then we began converting the whiteboard drawings to a high fidelity prototype. Let’s call this the design phase, which was also a group effort. We already had in mind that the artboards we created would eventually be imported into Principle so we created artboards for each and every interaction. Those were the sub-steps of our storyboard steps. For example, if the user would open a menu, we would create another artboard for this sub-step. We gave each artboard a number comprising the storyboard-step-number plus a number for the sub-step, e. g. “step_4_2”.

Screen Shot 2016-12-09 at 11.39.46.png

This is our symbols page. As you can see, you can see nothing. It’s really cluttered.

This took a while in the beginning because we had to design things like buttons, panels, or content elements as we went through the story. Once these were all in place, adding new steps became much quicker. Most time, however, was spent on discussions about how things should work, not how they should look.

3. Consolidate your Design

Then we entered what I would call a consolidation phase. We imported our design into Principle and found a million little things that didn’t work right. We had to make our Sketch file Principle-ready (see next section). This phase includes most of the tedious work and is a job for one person. At this stage, we didn’t do any complex motion design. In fact, we only animated the transition from artboard to artboard (not from any layers) on tap so we could go through the whole story step by step.

Importing from Sketch took more than 2 minutes every time, by the way, so make sure your coffee kitchen is well stocked.

4. Design Transitions

At last we entered the motion design phase where we created nice looking transitions between certain steps. This is the part where Principle really shines though you have to understand the way Principle animates pretty well. Especially Drivers can become pretty complex.

In our prototype, the story can only be told in one specific way from the beginning to the end. This is typical for Principle prototypes but with more than a hundred steps it is sometimes hard to remember which step comes next. It is critical to really practice the story before presenting it so the click path comes off as natural.

How to Make Your Sketch File Principle-Ready

Remove Masks

Limitation: Principle likes to flatten certain layers to bitmaps (see documentation for more info). That’s often OK but if you have to interact with individual elements of your design they can’t be flattened. In our experience, masks were most often the culprit. Solution: sift through all of your symbols and remove all the masks in your design. Try to be clever with the order of your layers instead. It is OK for layers to stick out of the artboard, those parts won’t be visible in the Principle viewer. This is all of course a bit frustrating, especially considering that Principle does support its own flavor of masks (clipping sublayers).

Detach Nested Symbols

Limitation: Principle can import symbols completely with overrides but only one level deep. So if you’re using overrides on nested symbols you’re out of luck. Solution: at the end of your design phase in Sketch, detach all nested symbols. Of course, this makes changes after this phase difficult so you really have to make sure that your design is solid at this point.

Principle’s Components (same as symbols in Sketch) are not helpful here yet but maybe they’ll get there eventually. We didn’t use Components at all.

Detach Resized Symbols

Limitation: Sketch has this amazing ability to resize symbols and groups. However, this feature does not work reliably for text and images. We’ve experienced some glitches on resized layers where margins were just all over the place. Solution: at the end of your design phase in Sketch, detach all resized symbols that give you trouble. This is also what Principle does internally when importing your Sketch file. You will notice that Sketch is to blame here, not Principle.

Avoid Unexpected Renaming

Limitation: In the consolidation phase, a normal workflow is importing something from Sketch into Principle (☕️), finding a mistake, going back to Sketch to fix it, and then re-importing(☕️☕️) everything in Principle. However, that can sometimes lead to unintended results as Principle sometimes renames layers in an unexpected way. Solution: In the consolidation phase in Principle, before re-importing from Sketch, just select all layers of all artboards with the mouse (not ⌘-R) and delete them. All your artboards and the transitions between them will remain. This way, Principle can start with a clean slate when doing a re-import. You’ll lose all other interactions though so make sure you’ve consolidated your design thoroughly before moving on to detailed animations.

Also, make sure to follow the tips in the next section to avoid unexpected renaming.

How to Work with Large Sketch Files

Name Your Layers and Keep them in Order

The first keyboard shortcut you should learn in Sketch is ⌘-R for renaming your layers. It is very important to name every layer and to keep everything in aptly named groups that correspondent to the hierarchy of your design.

Pro tips:

  1. When you use overrides, make sure that the layers within your symbols are redundantly named. For instance, if you have a symbol for a primary button, name the text layer “Label primary button”. This redundancy is not needed for Sketch but when you import your design into Principle this pattern lowers the risk of layers that are identically named and potentially confusing to Principle.
  2. Keep the layers and groups in the same order from artboard to artboard. This helps Principle identify identically named layers.
  3. Use Rename It for Sketch. It is a great plugin that helps with bulk renaming of layers. Also, did you know about Sketch’s ⌘-F? It’s the fastest way to find all layers named “Rectangle”, for example.

Use Symbols for Everything

Use symbols for everything. Also, nest your symbols. Your artboards should pretty much only contain symbols and the few things that are specific to that very artboard. In programming, this mantra is called “DRY” (don’t repeat yourself.) We’ve learned the hard way when we had to go through all the artboards and replace tons of layers with one big symbol that we had neglected to create.

Here are some more tips on organizing your symbols.

Use a Staging Page for Animation Tests

Every Sketch prototype will have at least two pages; one for the prototype and one for symbols. When trying out animations between artboards, it can help to create another page, e. g. “Staging” in which you copy and paste only the artboards that you are currently working on. This makes importing them into Principle much faster. Principle will only import the page that is currently open in Sketch.

Be Prepared for Some Inconveniences

Here are some things that made our life harder:

  1. Work can’t be parallelized very well. Given the scope of our undertaking we did most of the work as a group anyway, but the consolidating phase could have been sped up immensely if it was possible to work on a Sketch file in collaboratively. There are already tools out there that can do this. We will definitely evaluate other tools when we do something similar again. Leave a comment if you can recommend another toolset.
  2. Navigating artboards both in Sketch and in Principle. If you want to navigate from the beginning to the end you’ll have to scroll for a long time or zoom out to a point where you can’t distinguish artboards anymore. And on the symbols page you can’t find anything anyways.
  3. Text overrides in Sketch are cool and we used them all the time but for long strings the input field is just too small and cumbersome.
  4. Overriding images in symbols is awful if images don’t have the same aspect ratio. This cost us so much time.
  5. Importing into principle takes a looooong time even if only one tiny bit has been changed in the Sketch file. It should offer importing specific artboards.
  6. It’s hard to find out if symbols are ever used or not. This makes it impossible to clean up our cluttered symbols page.


We hope these tips were helpful to anyone who is considering Sketch and Principle for a large project. If you would like to add something, please feel invited to comment.

Happy Sketching!

What if Google and Facebook got it all wrong?


Google and Facebook are without any doubt two of the greatest entrepreneurial success stories of the digital age. Both companies serve billions of users. They provide various services directly and are critical enablers of countless third party services. Both companies have unimaginable technical and financial capabilities. They are the winners of our era. The caught an enormous wave and surfed it well. But what if they got the core of their business wrong?

What if Google and Facebook focused on the wrong monetization strategy from a long term perspective? What if ads are inferior to transactions? And what if we can watch our future unfolding in China today?

There are a growing number of signs that this might be true. One of the most revealing is the rapid evolution of China’s e-commerce market and Tencent’s rise to the top as China’s most valuable tech company.

Tencent’s success point to a business model that goes beyond ads: direct transactions. Instead of mainly selling ad impressions to advertisers while – more often than not – annoying users, Tencent decided to sell virtual goods – and now physical goods – by delivering these commercial transactions directly to consumers on any channel or device. Give people the chance to immediate buy what they want, when they want it. If you can see it, you can buy it: right here, right now on your mobile device.

Tencent’s WeChat application is revolutionizing e-commerce. It integrates orders, payments and customer care right into your chat app with tremendous success. 9 out of 10 people in urban areas in China use WeChat already.

And by all measures Tencent’s approach has beena huge success, enabling them to reach more than $10B in revenue in the first half of 2016. That’s 48% more than a year before. And all that growth happened while maintaining a net margin of 30%. Even very happy Amazon shareholders might feel jealous of these numbers.

Unlike Google and Facebook, who generate around 90% and 97% of their revenues through advertisements, Tencent generates the majority of their revenue through enabling direct transactions.

No doubt, digital ads are a growing business in China and will generate many billions in revenue. But advertising is not the dominant business model that it is in Silicon Valley. And it might never be that way.

Even in the U.S., Google is confronted with signs of trouble. Google is no longer the #1 search engine for product searches. That title now goes to Amazon. Google had lost the race and Amazon is pulling further ahead. In 2016, 55% (up from 44% in 2015) of consumers use Amazon to search for product while only 28% (down from 34%) use Google. This creates significant long term problems for Google because these are the best searches to monetize. Google knows this and started Google Shopping a while ago to compete with Amazon. It is a great service that I personally enjoyed using. However, the above numbers seem to suggest this was too little, too late.

Given the growing success of ad blockers on mobile devices, we can expect even more headwind for any forms of digital advertising–old and new–that disturb or annoy users. Nobody likes to be bombarded with ads, but most of us like to buy nice things. And that might be the winning monetisation strategy of the future: making it easier to buy the things we like.

Apple and Facebook seem to have taken the WeChat lesson to heart. Both companies have opened up their messaging platforms for external apps, enabling transactions right inside a chat and adding the ability to make payments or move money around. You can order your Uber ride, send money with Square Cash or share your favorite fashion items with the YOOX app inside Apple’s iMessage. Plus you can use Apple Pay on your Apple device to pay for stuff on the Internet. Not to be forgotten, Facebook turned their whole platform into a marketplace. Now, all companies can start selling products directly from their Facebook page.

In the future, shoppers can expect to have more and more options to spend their money in more social ways without leaving their favorite apps. The distance between a piece of content showing a product and the purchase of that product will further decrease. Amazon’s One Click Shopping will be the norm wherever you are. And since we spend most of our time in messaging apps, that is where we will discover and buy most new things.

Why didn’t Facebook try to enable transactions earlier?

They did. For many years, Facebook launched efforts to monetise through transactions and a digital wallet built into their platform. They haven’t been successful though. The main reason that ads ended up to be dominant in Silicon Valley might have been the starting point. When Google and Facebook started their monetisation efforts, the U.S. had already a sophisticated retail ecosystem with broadly accepted payment option and significant advertising budgets. The Internet penetration was significant and growing even though there was no mobile Internet yet. In this environment online advertising worked pretty well compared with all the other options. It was relatively easy to implement, scalable and efficient. It just worked.

Trying to monetise online transactions was a much harder thing to do. It also wasn’t a must have for American shoppers. They were pretty satisfied with their malls and super stores and could usually buy whatever they wanted.

Not so much in China. China lacked all this. They lacked a comparable retail infrastructure and the growing middle class didn’t have easy access to many retail options. They main problem to solve was enabling people to spend money and buy stuff. Fortunately, they had the mobile Internet from the start and no legacy system in their way. China’s Internet ecosystem leapfrogged the established patterns of the western world.

What does this all mean for brands?

Brands might be the biggest benefactors of this development. More platforms to reach more customers will enable successful brands to sell more. To thrive in such an environment, brands will need to provide compelling content and engaging experiences on various current and future platforms. Shoppable products will live on mobile apps, mobile sites, messaging platforms, social networks, online marketplaces and new platforms we haven’t even imagined yet. But before a product can be ordered, it needs to be seen and it needs to look convincing. Therefore, there will be increasing demand for great content that can be used in a wide range of commercial scenarios.

What does this mean for publishers?

Publishers might be on the losing end of this. They used to own a big piece of our attention and sold it for a nice profit to advertisers. The Internet shifted our attention to other things and to new players like Facebook and Google. Publishers saw a huge decline in revenue. Instead, Google and Facebook were able to capture our attention and sell it more efficiently and at a much bigger scale. In a world where enabling transactions replaces ads as the main monetization model, publishers might have to rethink their online and mobile strategies.

Photo Credit: David Goehring via Compfight cc

CoreMedia Soulbottles

CoreMedia is really special… and a great working place. The recent proof for this: the introduction of soulbottles at CoreMedia. Each employee got a bottle with:

  • CoreMedia Logo
  • Personal Name Tag
  • CoreMedia Values  as recipe of the “CoreMedia Cocktail”
  • and as developer of a Web Content Management System of course: a “reload” button at the bottom of the bottle

The soulbottles are a result of a discussion at a CoreMedia Open Space and four colleagues (thanks to them!) driving the idea until it got implemented.

And now? CoreMedia became even more special. Instead of boring bottles made of plastic now employees are running around with their soulbottles, easily carrying them around using the nice handle.


Configuring the MDM login screen with xrandr for mirrored multiple monitors

Setting up my new laptop with Linux Mint 18 Cinnamon I faced the challenge that on a multi-monitor set up the MDM login screen did not show up well: While it looks great on the laptop monitor the external monitor has the wrong resolution and shows only a part of the login box.

Searching for a solution I stumbled across a post at Segfault (News from the Linux Mint development team):

This post was really helpful to eventually evolve to my solution. I needed a somewhat different approach than in the fixed call to xrandr because I sometimes switch working places. So it needs to be more generic. And the result is this xrandr setup placed directly in front of the exit 0 call in /etc/mdm/Init/Default:

PRIMARY=`xrandr -q|awk '/connected primary/ { print $1 }'`
if [ "x$PRIMARY" = "x" ] ; then
  # take the first one
  PRIMARY=`xrandr -q|awk '/ connected/ { print $1 }'|head -n 1`

if [ "x$PRIMARY" != "x" ] ; then
  SECONDARY=`xrandr -q|awk '/ connected/ && $1 != $PRIMARY { printf "--same-as %s ", $1 }'`
  if [ "x$SECONDARY" != "x" ] ; then
    xrandr --output $PRIMARY --mode 1920x1080 $SECONDARY

What the script does:

  1. see if xrandr already knows some primary screen to take this as reference
  2. if there is no primary screen take the first connected screen as primary screen
  3. if a primary screen could be determined choose all secondary screens which are all connected screens, which are not equal to the primary screen
  4. add --same-as for all secondary screen
  5. only if primary and secondary screen are present: use xrandr to set up all screens as mirrored screens; use resolution 1920×1080 which fits best for all working spaces

5 x 5km = 2:12h

Der Muskel wird durch starken Gebrauch gestärkt, der Nerv hingegen dadurch geschwächt. Also übe man seine Muskeln durch jede angemessene Anstrengung, hüte hingegen die Nerven vor jeder.

Arthur Schopenhauer

Einige CoreMedia Mitarbeiter kräftigen ihre Muskeln regelmäßig bei gemeinsamen nervenberuhigenden Laufeinheiten in der Mittagspause oder nach Feierabend. Die Teilnahme am diesjährigen Mopo-Team-Staffellauf war damit willkommene Abwechslung und Herausforderung. Fünf CoreMedianer ließen auf der jeweils 5km langen Runde durch den Hamburger Stadtpark ihre Muskeln spielen. Unterstützt und nervlich gebändigt wurden die CoreRunners durch Rhea, die den Papierkram erledigte, für Verpflegung sorgte und am Streckenrand fleißig motivierte. Erfreuliche Einzelleistungen und exzellenter Teamgeist mündeten in einer Zeit von 2:12:23 und damit Platz 321 von 986 gestarteten Teams.

Mopo Staffellauf 2016

Die CoreRunners: Patrick, Kerstin, Eva, Rhea, Karo und Peter (v.l.)