praegnanz.de büro für intervernetzte medien

Unser Weblog

Tablet First – der kesse Kniff für Leute von heute!

Gerrit, 30.11.2015

Wie wohl die meisten Webdesigner haben wir irgendwann 2013 gemerkt, dass der Spaß, den man beim nachträglichen Responsivieren von komplexen Website-Layouts hat, begrenzt ist. Das sogenannte „Responsive Retrofitting“ wird natürlich bis heute häufig praktiziert, wenn das Kundenbudget nicht für einen echten Relaunch ausreicht, oder die Zeit schlichtweg knapp ist. Selbstverständlich kann man sich hier aber auch ganz trefflich im Aufwand verschätzen, denn vierstufige Navigationen und ellenlange Seitenspalten, die unabhängig von der Haupttextspalte agieren, sind im linearisierten Layout echte Störenfriede.

Besser ist es, das Layout gleich als responsives Gesamtkonstrukt zu konzipieren, und die wichtigsten gewünschten Bildschirmbreiten gleichzeitig und gleichberechtigt zu betrachten und zu bauen. Dieser „Everything First“-Ansatz funktioniert auch in der Screendesign-Phase ganz passabel. Egal, ob ihr eure ersten Anmutungen und Wireframes in Photoshop, Sketch oder auf Prototyping-Papier entwerft – es fällt gar nicht sonderlich schwer, parallele Versionen für Desktop (> 900px), Hochkant-Tablet (500–900px) und Smartphones (< 500px) zu bauen, wenn man genügend Routine und ein paar gute Einfälle hat.

(Diese drei klassischen Entwurfsgrößen sind dabei nur grobe Anhaltspunkte und dienen als statische Aufhänger, welche später im browserfähigen Prototypen möglichst stufenlos ineinander übergehen können sollten. Meist braucht man deutlich mehr Breakpoints, und auch die Bildschirmhöhe spielt eine wichtige Rolle, schon klar.)

Sobald wir nun aber die Phase des initialen Entwurf verlassen und in den responsiven Workflow übergehen, wo wir im ständigen kleinteiligen Wechsel Screendesign und Frontend-Entwicklung ineinander greifen lassen, muss es naturgemäß eine Ursprungsgröße geben, sowie eine Richtung, in die man sich vorarbeitet. Klassischerweise ist das in früheren Jahren nach dem Desktop-First-Paradigma verhandelt worden. Die Breiten ab 900px bekommen das reguläre CSS, während die kleineren Bildschirme die CSS-Sonderregeln innerhalb von Media-Query-Klammern zugewiesen bekommen:

/* Normales CSS für alle Geräte: */
nav li { display: inline-block; }

/* Davon abweichende Regeln für Tablets und kleiner: */
@media (max-width: 900px) {
  nav li { font-size: .9em; }
}

/* Weitere Abweichungen für Smartphones: */
@media (max-width: 500px) {
  nav li { display: block; }
}

Diese Taktik ist allerdings größtenteils Schnee von gestern. Seit einiger Zeit wird allenthalben dem Mobile First gepriesen. Abgesehen davon, dass diese Catchphrase auf allen möglichen Ebenen verwendet wird (bis hin zum Business-Mantra disruptiver Enterprise-Unternehmen), bedeutet es für Frontend-Entwickler schlicht die Umkehrung des oben beschriebenen Prinzips. Wir betrachten das Smartphone-CSS als den „Normalfall“, und alles größere ist die Abweichung:

/* Normales CSS für alle Geräte: */
nav li { display: block; }

/* Davon abweichende Regeln für Tablets und größer: */
@media (min-width: 500px) {
   nav li { display: inline-block; }
}

/* Weitere Abweichungen für Desktop-Größen: */
@media (min-width: 900px) {
   nav li { display: block; font-size: 1.1em; }
}

Im Grunde machen beide Codebeispiele das Gleiche, und bei solch einfachen Dingen vermag man kaum einen praktischen Vorteil der einen oder der anderen Methode erkennen. Der reine CSS-Code ist aber nur das eine. Der Workflow ist etwas anderes! Wenn ich davon ausgehe, dass ein nicht unwesentlicher Teil der Gestaltung on-the-fly während des CSS-Aufbaus entsteht, macht es schon einen Unterschied, ob ich mich zuerst mit den „gewohnten“ Bildschirmgrößen beschäftige, und das Browserfenster solange kleiner ziehen, bis man scrollen muss oder nichts mehr erkennen kann, um dann einen Breakpoint zu setzen. Oder ob ich umgekehrt das Browserfenster langsam immer größer ziehen, bis es irgendwann scheiße auszusehen beginnt.

Sowohl Desktop First als auch Mobile First haben dabei gewisse Schwächen, die zunächst nicht auf der Hand liegen, aber deren Auswirkungen man ziemlich gut im derzeitigen Web beobachten kann.

Das Problem von Desktop First ist das Zusammenquetschen von Elementen auf zu engem Raum. Oder – manchmal noch schlimmer – das Weglassen von eventuell nützlichen Elementen. Und natürlich exzessive Ausklapp- und Off-Canvas-Orgien.

Mobile-First-Designs hingegen leiden oft unter akuter Blutleere. Alles wirkt übersimplifiziert und mit zuviel langweiligem Weißraum aufgeblasen, der nur als Füllmaterial dient. Und natürlich schwer lesbare, ellenlange Textzeilen aufgrund der notorischen Einspaltigkeit.

Was liegt also näher als zu versuchen, einen faulen Kompromiss zu machen das Beste aus beiden Welten zusammenzubringen, und von der Mitte auszugehen? Ende letzten Jahres hatten wir genau diesen Gedanken, und Tablet First war geboren! Es funktioniert ganz genauso, wie man es sich vorstellt: Die Originalversion des CSS ist auf Hochkant-Tablets optimiert, und es gibt Anpassungen für breitere sowie, unabhängig davon, schmalere Bildschirme. In der Praxis sieht das dann so aus:

/* Normales CSS für alle Geräte: */
nav li { display: inline-block; }

/* Davon abweichende Regeln für Desktop-Größen: */
@media (min-width: 900px) {
   nav li { font-size: 1.1em; }
}

/* Weitere Abweichungen für Smartphone-Größen: */
@media (max-width: 500px) {
   nav li { display: block; }
}

Hammer, nicht wahr? Mit diesem Paradigma konzentrieren wir uns auf mittelgroße Bildschirme und geraten nicht in Versuchung, allzu komplexe oder allzu reduzierte Layout-Bausteine zu gestalten. Es bleibt irgendwie sane und handlebar. Was denkt ihr?

Bonus: Einbettung in Sass

Dieser Artikel könnte jetzt vorbei sein, doch ich lege noch einen drauf! Da wir, wie wohl die meisten von euch, inzwischen mit dem CSS-Präprozessor Sass arbeiten, haben wir uns angewöhnt, unsere Tablet-First-Media-Queries direkt in die CSS-Eigenschaften hineinzuschreiben, weil man so alle Regeln, die zu einem Element gehören, beisammen hat und nicht ständig zwischen verschiedenen Abschnitten einer CSS-Datei oder gar in verschiedenen CSS-Dateien umherspringen muss. Darüber hinaus verzichten ich gerne auf feste Breakpoints, die für alle Layout-Elemente gleichermaßen als die großen Parameter dieses Webprojekts gelten. Vielmehr setzen wir immer häufiger auf „Mikrobreakpoints“ – noch so ein Wort, was wir uns ausgedacht haben. Soll heißen: Bei der Gestaltung eines ganz bestimmten Elements mag es sinnvoll sein, bei genau 866px auf die Vierspaltigkeit zu wechseln, während bei einem anderen Element 910px der richtige Moment ist, das Floating umzudrehen. One Breakpoint fits all gibt’s ja irgendwie doch nicht wirklich.

Wenn wir alle drei Konzepte (Tablet First, Nested Media Queries, Mikrobreakpoints) zusammenfassen, könnte das in Sass etwa so aussehen:

nav li { 
   display: inline-block; 
   @include greater(900) {
      font-size: em(17);
   }
   @include smaller(500) {
      display: block;
   }
}

Um die Übersichtlichkeit noch ein kleines bisschen zu verbessern, habe ich im obigen Beispiel zwei Sass-Mixins und eine Funktion verwendet, die die Handhabung im Code vereinfacht, und ein paar good practises für die Media-Query-Syntax einsetzt:

@function em($px, $context: 16) {
   @return ($px / $context) * 1em;
}

@mixin smaller($px) {
   @media only screen and (max-width: em($px)) {
      @content;
   }
}

@mixin greater($px) {
   @media only screen and (min-width: em($px)) {
      @content;
   }
}

Jetzt ist aber wirklich Schluss. Über Anregungen und Kritik in den Kommentaren freuen wir uns!

Kommentare [10]

Die Blasenwelten von Print und Web

Gerrit, 05.11.2015

Filterblasen nennt man abgeschlossene soziale Räume, in denen Gleichgesinnte über ihnen wohlbekannte Themen reden und dabei eigene Werte und Sichtweisen immer weiter kultivieren und sich gegenseitig bestätigen. Der Blick über den Tellerrand wird dabei oftmals aus Bequemlichkeit vermieden.

Heute war ich in meiner alten Hochschule in Mainz zu Gast und konnte mich mit zwei meiner damaligen Typografie-Professoren, sowie einer Reihe von Masterstudent/innen aus dem Studiengang Deep Typography über Webtypografie austauschen.

Meine Beobachtung ist, dass sowohl die klassischen Printdesigner als auch wir Webdesigner nicht genügend voneinander lernen, und jede Gruppe ein wenig in ihrer eigenen Blase lebt. Ich stellte unter anderem fest, dass

  • visuelle Trends im Grafikdesign sich kaum im Webdesign widerspiegeln, und umgekehrt. Jede Disziplin hat unabhängige Trendzyklen und eigene herausragende Benchmarks und Protagonisten.
  • mutige und neuartige typografische Entscheidungen im Webdesign fast ausschließlich auf Websites „von Designern für Designer“ stattfinden, nicht bei echten Kundenprojekten.
  • Grafikdesigner immer noch Schwierigkeiten haben, den extrem hohen Stellenwert eines mediengerechten, flexiblen Webdesign-Systems zu würdigen. Das krass durchgestaltete, aber starre Design ohne responsive Komponenten gilt immer noch als akzeptabel.
  • Webdesigner (mich eingeschlossen) oftmals ziemlich einfältig sind, was die Möglichkeiten angeht, die ein mutiger und radikaler Einsatz von Typografie eröffnet. „Gutes“ Webdesign erschöpft sich bei diesen Leuten oftmals in einem Aneinanderreihen von Best Practices, die man von Bootstrap, Divi und den anderen Baukästen kennt. Detailtypografische Parameter spielen kaum eine Rolle.

Was fehlt

Um es kurz zu machen: Es gibt zu wenig Beispiele von typografischer Gestaltung im Webdesign, die

  • frisch und neuartig, mutig und radikal, verblüffend und detailverliebt daherkommt.
  • dabei mediengerecht bleibt und auch im responsiven und barrierearmen Kontext funktioniert.
  • ein Mindestmaß an Usability und Lesbarkeit (falls nötig) offeriert.
  • ein reales Produkt oder eine normale Dienstleistung darstellt und nicht im Kontext einer Agentur-Selbstdarstellung stattfindet, oder explizit an Designer gerichtet ist.
  • technisch sauber und performant umgesetzt ist.

Bereits beim Verfassen meines #webtypobuch fiel es mir extrem schwer, solche kreativen Beispiele zu finden. Meine These zur Begründung: Die eingefleischten Webdesigner sind sehr vorsichtig und zu stark von der Usability-Polizei eingeschüchtert. Gleichzeitig sind die wilden und experimentellen Grafikdesigner zu weit von den Realitäten des Mainstream-Webs entfernt, so dass sich hier keine gegenseitige Befruchtung einstellen mag.

Man könnte fast zu der Vermutung gelangen, dass es faktisch unmöglich sei, beide Welten unter einen Hut zu bringen – was ganz schön schade wäre.

Was müssen wir tun?

Erster Schritt: Lasst uns den Gegenbeweis antreten! Sammeln wir alle zusammen einmal inspirierende Websites, die einige oder gar alle der obigen Aspekte in sich vereinen. Eine weitere Designgalerie nach dem Muster von DMIG? Ja, aber schmeißen wir doch mal alle Agenturportfolios und alle nichtresponsiven Projekte raus! Dann bleibt nichts mehr übrig? Eben! (Ich stelle mich gerne als strenger Kurator zur Verfügung und brenne darauf, die Liste zu veröffentlichen und schick aufzubereiten.)

Zweiter Schritt: Machen wir unseren Kunden einen mutigeren Umgang mit Schrift, Fotos, Illustration, Animation und Farbe schmackhaft. Kämpfen wir für mehr individuellen Look, wenn wir schon alle die gleichen responsiven Layout-Strukturen verwenden müssen. Kurz gesagt: Macht Werbung für mehr krassen Style, jetzt wo das Grundgerüst der responsiven Technologie so stabil verankert ist!

Was meint ihr, kriegen wir da was zustande? Ihr kennt die Kommentarfunktion, ihr kennt Twitter! Dankeschön.

Update 9.11.2015: Owen Williams hat auf TNW News ähnliche Gedanken wie ich.

Kommentare [9]

Mobile First First Contact

Gerrit, 23.10.2015

Gerade habe ich meinen jüngsten HTML/CSS-Einführungskurs an der Zürcher Hochschule der Künste beendet. Teilnehmer waren elf ausgesprochen freundliche Erstsemestler, die die Grundlagen der Webgestaltung erlernen sollten. Es gab keine nennenswerten Vorkenntnisse in der Materie, also konnte ich – wie immer – relativ frei agieren. Und anders als in den letzten Jahren wollte ich diesmal etwas Neues ausprobieren.

Was, wenn man jeglichen historischen Ballast ignoriert, und nur die neuesten und tollsten Praktiken lehrt? Ein bisschen Zen in den Unterricht (und meinen eigenen Kopf) bringen, auch wenn es nicht 100% praxisnah ist?

Ich habe das mal gemacht:

  • nur die neuesten Browserversionen
  • keine Float-Layouts, nur Flexbox-basierte Konstruktionen
  • Mobile First in Entwurf und Umsetzung
  • vollfluides CSS (möglichst alle Breitenangaben in Prozent)
  • Responsive Breakpoints für den zweiten Kursabschnitt aufheben

Ich kann sagen, dass das soweit ganz gut geklappt hat! Das Konzept, dass die mobile Nutzung einer Website heute viel wichtiger ist als die Desktop-Nutzung, musste kaum erklärt werden – das erschließt sich Menschen mit Anfang 20 von alleine.

Wenn man HTML und CSS komplett neu lernt, so ist eine anfängliche Beschränkung auf eher lineare Mobile-First-Layouts eine hilfreiche Sache, denn besonders komplexe Gestaltung ist hier kaum möglich – von daher konnten die Kursteilnehmer ihre Scribbles meist erfolgreich und ohne größere Schwierigkeiten umsetzen. Für viel Freude sorgte dann am letzten Tag der finale Check des Layouts auf dem eigenen Smartphone – umgesetzt über MAMP und Zugriff per lokaler IP-Adresse im ZHdK-WLAN.

In nur 3 Tagen konnte ich die Grundlagen von modernem HTML/CSS rüberbringen. In meinen früheren Kursen ging recht viel Zeit für komplizierte Erläuterungen von schwer verständlichem Layoutverhalten drauf, u.a. bei Floats, Clearing, Selfclearing. Klar, manche Dinge wie absolute Positionierung in Kontextelementen oder Prozentangaben im vertikalen Padding, sind nach wie vor starker Tobak für Anfänger, aber man muss natürlich auch realistisch sein – CSS ist nicht einfach!

Insgesamt bin ich sehr zufrieden, wie selbstverständlich das Konzept einer unbekannten Viewportgröße aufgenommen wurde, und wie nett die Entwürfe teilweise geworden sind. Das mache ich jetzt immer so.

Wen es interessiert: Die Studierenden bekamen drei verschiedene Briefings mit ein paar vorbereiteten Assets zur Auswahl: Die Webpräsenz einer Glamrock-Band, das Tagebuch einer Weltreise und die Produktwebsite eines neuartigen Sneaker-Modells. Alle drei Aufgaben wurden etwa gleich oft gewählt :-)

Kommentare [4]

Typografie zur Markenbildung: Blendle zeigt, wie’s geht!

Gerrit, 24.09.2015

Die derzeit gehypte Meta-Nachrichtenwebsite Blendle wartet nicht nur mit inhaltlichen Überraschungen auf („Ach, so interessante Lesestücke gibt es also auf Papier gedruckt?“), sondern durchaus auch mit einer spannenden Entscheidung, was die Typografie angeht.

Blendle

Die eigentlichen Artikel der verschiedenen Tageszeitungen sind nämlich an die jeweilige Typografie der Print-Publikation angelehnt, jedoch in einem webgerechten und einheitlichen gestalterischen Rahmen. Dies ist natürlich ein Kompromiss zwischen dem Blendle-Branding und dem Branding der jeweiligen Original-Publikation, doch es ist ein guter und cleverer Kompromiss: Die Webprofis von Blendle kümmern sich um das gesamte Drumherum, die unkomplizierte Bedienung, den Mobile-First-Ansatz, alles Dinge, die so ein deutsches Printmedienhaus kaum alleine hinbekommen würde. Sobald man jedoch in den eigentlichen Inhalt hineinspitzt, sieht man die vertrauten Schrifttypen der Süddeutschen Zeitung, der Zeit und des gedruckten Spiegels.

Somit versprüht Blendle mehr typografisches Banding als die meisten offiziellen Zeitungs-Websites, die ja doch manchmal noch recht zögerlich mit Webfonts umgehen – von Ausnahmen einmal abgesehen. Und ich finde es hochgradig erstaunlich, mit welch kleinen Stilmitteln man bereits den Duft einer bestimmten Zeitung simulieren, und dabei trotzdem gut lesbar und mobiloptimiert unterwegs sein kann.

Mit Schaudern denkt man da zurück an die Zeiten von gruseligen ePaper-Ausgaben zu Wucherpreisen. Diese Kulturtechnik wird nun hoffentlich für immer verschwinden. Und mal sehen, ob mehr und mehr Verlage auf den Zug aufspringen und Blendle typografisch noch interessanter wird. Vom Inhalt einmal großzügig abgesehen, aber darüber schreiben ja andere schon eifrig ins Internet.

Kommentare [1]

Meine zerstörte iCloud-Mediathek

Gerrit, 05.07.2015

Meine iTunes-Bibliothek ist ganz schön alt. Ich stamme ja noch aus einer Generation, die mit dem Mantra „Rip. Mix. Burn.“ etwas anfangen konnte. Meine iTunes-Musiksammmlung besteht seit 2001 und hat seitdem alle Versionen von iTunes mitgemacht, wurde also schon ca. ein Dutzend Mal beim ersten Start einer neuen iTunes-Version „aktualisiert“, wie es so schön heißt.

Sie enthält allerlei digitale Kuriositäten aus den unterschiedlichsten Quellen. Die unorthodoxeste Form, wie ich an eine Handvoll digitaler Privatkopien gekommen bin, dürfte Megaradio gewesen sein. Wer kennt es noch? Eine Zeitlang wurde der Videotext-Datenstrom von NBC GIGA für das Streamen von MP3-Daten missbraucht. Mit einer TV-Karte am PC und einer entsprechenden Software konnte man mitschneiden und die mies komprimierten Musikstücke bei sich abspeichern.

Genug der Nostalgie. Mit der Software iTunes war ich, wie viele andere auch, in den letzten Jahren immer unglücklicher. Das lag vor allem daran, dass Apple nicht mutig genug war, die drölfzig Bestandteile, die iTunes auf dem Mac in sich vereint, aufzutrennen und separat weiterzuentwickeln. Im Grunde hätte man schon vor einigen Jahren getrennte Apps für den Store, die Videos und so weiter bauen müssen, wie das unter iOS ja geschehen ist. iTunes auf dem Mac ist überladener Schrott. Doch das Gegenteil ist passiert: Auch das neue Apple Music ist noch in iTunes 12 reingeflascht worden und verrichtet dort als eine von zwanzig weiteren Funktionalitäten seinen Dienst.

Ich mach das ja immer alles mit, ich bin so. Ich habe vor vier Jahren bei der Einführung von iTunes Match die Gelegenheit genutzt, meine Musiksammlung komplett in die Cloud zu laden, um sie ohne umständliches Kabelgesynce auch auf anderen Macs und meinem iPhone hören zu können. Nebenbei wurde die Klangqualität meiner abenteuerlicheren MP3s aufgewertet – auch nicht schlecht. Und iTunes Match funktionierte so gut, dass ich nach kurzer Zeit die Originaldateien von meinen iTunes-Bibliotheken gelöscht hatte, um Platz zu sparen. Das war risikoreich, aber es hat funktioniert. (Hinweis: Man soll Clouddienste nicht als Backup verstehen! Warnung! In diesem Falle hat es aber geklappt.)

Irgendwann letztes Jahr wurde mir iTunes Match zu teuer, und ich habe zwei Dinge gemacht: Alle Stücke von der iCloud wieder lokal in iTunes zurückgespielt, und dann alles zu Google Musik geschoben, weil dies kostenlos ist. Hat auch gut funktioniert!

Und zu meinem Glück habe ich dann vergessen, die Musik wieder aus iTunes heraus zu löschen! Zu. meinem. Glück. Nun hatte ich meine alte Musiksammlung wieder offline in iTunes, mit allen Kuriositäten, einmal durch iTunes Match gespült, und halbwegs intakten Playcounts, obwohl mir diese gar nicht so wichtig sind wie manchen anderen Nutzern.

Wir spulen in die Gegenwart vor: Ich melde mich vor einigen Tagen bei Apple Music an, um einerseits den Streamingdienst und beats1 auszuprobieren, andererseits natürlich die iTunes-Match-ähnliche Funktion wieder zu bekommen und meine gute alte Musiksammlung abermals in eine Cloud zustecken. Diesmal unter dem Namen „iCloud-Mediathek“. Mit dieser hatte ich im Rahmen der neuen Fotos-App insgesamt gute Erfahrungen gemacht, auch was das Syncing angeht. Allerdings habe ich bei „Fotos“ große Vorsicht walten lassen, was die Übertragung und die Umstellung meiner alten iPhoto-Bibliothek angeht.

Was soll ich sagen? Die Umstellung auf iCloud-Mediathek für Musik war eine absolute Katastrophe. Während viele Nutzer von vereinzelten falschen Coverfotos berichten, hat es mir fast die gesamte Struktur meiner Songs, Künstler, Alben, Cover und Verfügbarkeiten zerhäckselt:

So stelle ich es mir vor, wenn einer die Datenbank-Einträge einer Musiksammlung einmal mit einem Zufallsgenerator durchwürfelt. “The Truth is in the Cloud”, sagte Steve Jobs einmal über das Konzept des neuen iCloud. Lächerlich. “The Truth is in the Time Machine Backup” trifft es hier eher! Deshalb habe ich jetzt die Musik-iCloud komplett leergemacht, auf allen Geräten ausgeschaltet, die ganzen lokalen Bibliotheken gelöscht, und werde am Montag die alte iTunes-Bibliothek aus dem Backup wieder importieren. Allerdings vorsichtshalber nicht mit der offiziellen XML-Library-Datei, sondern wirklich die nackten Musikdaten manuell in iTunes lokal reinziehen. Mal sehen. (Wie gesagt: Playcounts interessieren mich kaum)

Was habe ich falsch gemacht?

Diese Frage sollte nicht nötig sein, denn natürlich ist Apple schuld, die Idioten! It just works, richtig? Dennoch trifft mich eine gewisse Mitschuld, denn ich habe mich durch die positiven Erfahrungen mit iTunes Match und der Fotos-Mediathek blenden lassen. Ich habe in kurzen zeitlichen Abständen drei Macs und drei iOS-Geräte auf die neue Musik-Cloud losgelassen, ohne jeweils abzuwarten, dass die Übertragung der Titel komplett und integer verlaufen ist. Kaum schien es komplett zu sein, habe ich die lokalen Dateien gelöscht. Aber da war es schon zu spät, und die “Wahrheit”-Version aus der Cloud war verhunzt und hat alle ans Ökosystem angeschlossenen Geräte infiziert. Die Bibliotheken von 6 Geräten haben sich gegenseitig kaputt gesynct.

Deshalb meine empfohlene Sicherheitsmethode beim Umstellen:

  1. iCloud-Mediathek noch nicht aktivieren, auf keinem Gerät.
  2. Eine sichere Offline-Version der Mediathek auf einem Mac erstellen oder sicherstellen, dass sie existiert.
  3. iTunes Match abschalten, falls vorhanden, auf jedem Gerät.
  4. Die in 2) erstellte Offline-Mediathek auf einem externen Datenträger backuppen.
  5. iCloud-Mediathek auf dem Mac von 2) aktivieren und alle Titel hochladen/erkennen lassen. Das kann dauern.
  6. Überprüfen, ob die gesamte Mediathek in der Cloud vorhanden ist, aber zunächst noch nicht lokal die Dateien löchen.
  7. Die Sache ein bis zwei Tage ruhen lassen. (Nur zur Sicherheit, eher Voodoo.)
  8. Auf allen anderen Geräten (am besten nacheinander!) die jeweiligen lokalen Mediatheken komplett löschen und im Anschluss die iCloud-Mediathek aktivieren und warten, bis alle Titel erscheinen und streambar sind. Anzahl der Titel vergleichen!
  9. Erst jetzt, wenn der initiale Sync abgeschlossen ist und alle Apps zur Ruhe gekommen sind, kann man wohl gefahrlos Titel zur Mediathek hinzufügen – entweder von Apple Music aus, oder als manueller Import von Dateien.

Weiterlesen

Seriöse und klare Informationen zu den iCloud-Mediathek/iTunes-Match-Grundlagen liefern dieser beiden Artikel bei iMore:

Kommentare [5]