Richtlinien und Prüfliste für Kacheln und Signale (Windows Store-Apps)

In diesem Thema werden bewährte Methoden, Problembehandlungsmaßnahmen und Globalisierungs- bzw. Lokalisierungsempfehlungen für das Erstellen und Aktualisieren der Kachel Ihrer App auf der Startseite und dem Sperrbildschirm beschrieben. Außerdem finden Sie hier eine Liste der Anforderungen, die Ihre App erfüllen muss, um im Windows Store akzeptiert zu werden.

Mit einer Kachel wird die App auf der Startseite dargestellt. Eine Kachel erlaubt Ihnen die Präsentation von umfangreichem und ansprechendem Inhalt für Ihre Benutzer auf dem Startbildschirm, wenn Ihre App nicht ausgeführt wird. Durch Tippen oder Klicken auf die Kachel wird die App gestartet. Kacheln sind in zwei Größen vorhanden: quadratisch und breit. Für jede Größe sind mehrere Vorlagen verfügbar, mit Text, mit Bildern oder einer Kombination aus Text und Bildern. Vorlagen können aus einem Frame oder zwei gestapelten Frames, der sogenannten Vorschauvorlage, bestehen. Eine Kachel auf Basis einer Vorschauvorlage wird zwischen den beiden Frames im Kachelbereich animiert. Vorlagen aus einem Frame werden nicht animiert.

In einer Ecke der Kachel können Sie optional Branding wie den Namen der App oder ein Logo anzeigen.

Kacheln können live (über Benachrichtigungen aktualisiert) oder statisch sein. Anfänglich werden Kacheln als Standardkacheln, die im Manifest der App festgelegt sind, angezeigt. Eine statische Kachel zeigt immer den Standardinhalt, üblicherweise ein Logo über die gesamte Kachel, an. Eine Live-Kachel kann die Standardkachel mit neuem Inhalt aktualisieren, kann aber zum Standardinhalt zurückkehren, wenn die Aktualisierung abläuft oder entfernt wird. In der Ecke gegenüber dem Branding kann eine Kachel auch ein Statussignal in Form einer Zahl oder einer Glyphe anzeigen.

Die beiden folgenden Gesichtspunkte sollten Sie immer berücksichtigen:

• Wenn Sie eine breite Kachel verwenden, kann der Benutzer die Größe der Kachel jederzeit von breit in quadratisch oder von quadratisch in breit ändern. Sie wissen nicht, welche Größe aktuell angezeigt wird.
• Der Benutzer kann Kachelbenachrichtigungen jederzeit deaktivieren.

Richtlinien für die Benutzeroberfläche bei Verwendung von Kacheln

Dieser Abschnitt behandelt Richtlinien und Designüberlegungen, die Sie beachten sollten, wenn Sie das Aussehen und die Verwendung Ihrer Kacheln planen.

• Philosophie der Gestaltung von Kacheln
• Wählen zwischen quadratischen oder breiten Kacheln
• Verwenden von Standardkacheln
• Verwenden von Vorschauvorlagen
• Weitere Überlegungen bei der Entwicklung
• Verwenden von Kachelbenachrichtigungen

Philosophie der Gestaltung von Kacheln

Ihr Ziel ist, eine ansprechende Kachel für Ihre App zu gestalten. Wenn Sie eine Live-Kachel verwenden, ist es Ihr Ziel, einen neuen, ansprechenden Inhalt zu präsentieren, der für den Benutzer auf dessen Startbildschirm einen Nutzen hat und der dazu einlädt, die App zu starten. Vermeiden Sie für diesen Zweck den übermäßigen Gebrauch von schrillen Farben. Ein einfaches, klares und elegantes Design wirkt besser als eines, das wie ein bockiges Kind förmlich nach Aufmerksamkeit schreit.

Wenn Sie Ihre App gestalten, fragen Sie sich möglicherweise, warum Sie in eine Live-Kachel investieren sollten. Es gibt verschiedene Gründe:

• Kacheln sind die "Eingangstür" zu Ihrer App. Eine ansprechende Live-Kachel kann den Benutzer in Ihre App hineinziehen, wenn diese nicht ausgeführt wird. Benutzer schätzen in zunehmendem Maße solche Apps, die sie häufig benutzen.
• Eine Live-Kachel ist ein Verkaufsargument, durch das sich Ihre App sowohl von anderen Apps im Windows Store (Benutzer werden einer App mit einer tollen Live-Kachel in der Regel den Vorzug vor einer ähnlichen App mit statischer Kachel geben) als auch von Apps für Betriebssysteme, die auf ihrer Startseite nur statische Kacheln und Symbole unterstützen, abhebt.
• Wenn Benutzern Ihre Live-Kachel gefällt, fördert eine prominente Platzierung dieser Kachel auf dem Startbildschirm das Wiedereinschalten Ihrer App. Das zufällige Entdecken von coolen Inhalten in der App durch die Kachel macht die Benutzer glücklich.
• Wenn Benutzer Ihre Kachel nicht mögen, platzieren sie diese möglicherweise am Ende des Startbildschirms oder lösen sie ganz ab, schalten die Aktualisierung aus oder deinstallieren Ihre App sogar.

Einige Merkmale, die eine Live-Kachel ansprechend machen, sind:

• Frischer, häufig aktualisierter Inhalt, der den Benutzern das Gefühl gibt, dass Ihre App auch dann aktiv ist, wenn sie nicht ausgeführt wird.

  Beispiel: Anzeigen der aktuellen Schlagzeilen oder ein Zähler für neue E-Mails.

• Personalisierte oder maßgeschneiderte Updates, die Ihr Wissen über den Benutzer einsetzen, wie zum Beispiel Interessen, die der Benutzer über die App-Einstellungen angeben kann.

  Beispiel: Angebote des Tages passend zu den Hobbys des Benutzers.

• Inhalte, die zum aktuellen Kontext des Benutzers passen.

  Beispiel: Eine App mit Verkehrsmeldungen, die den aktuellen Standort des Benutzers verwendet, um eine aktuelle Verkehrskarte anzuzeigen.

Wählen zwischen quadratischen oder breiten Kacheln

Ihr App besitzt immer eine quadratische Kachel. Sie müssen entscheiden, ob Sie auch eine breite Kachel zulassen möchten. Die Auswahl erfolgt durch Bereitstellen des breiten Logos, wenn Sie die Standardkachel in Ihrem Manifest definieren. Wenn Sie kein breites Logobild bereitstellen, ist Ihre Kachel nur quadratisch. Ihre Größe kann nicht vom Benutzer angepasst werden, und es können keine breiten Benachrichtigungen auf ihr angezeigt werden. Wenn Sie dies ändern möchten, stellen Sie eine neue Version Ihrer App mit einem aktualisierten Manifest bereit, das ein breites Logobild enthält.

• Verwenden Sie eine quadratische Kachel nur, wenn die App keine Updates per Kachelbenachrichtigungen an den Benutzer sendet. Der Inhalt breiter Kacheln sollte immer aktuell sein und regelmäßig aktualisiert werden. Wenn Sie keine Live-Kachel verwenden, stellen Sie kein breites Logo im Manifest bereit.
• Verwenden Sie nur eine quadratische Kachel mit einem Signal, wenn die App nur Szenarien mit kurzen Zusammenfassungsbenachrichtigungen unterstützt, d. h., Benachrichtigungen, die nur durch ein Signalbild oder eine einzelne Zahl ausgedrückt werden können. Dies könnte beispielsweise eine SMS-App sein, die nur die Anzahl der empfangenen neuen Textnachrichten in Benachrichtigungen mitteilen soll. Geben Sie im Manifest kein breites Logo an.
• Verwenden Sie nur die quadratische Kachel, wenn die von der App gesendeten Updates nicht detailliert auf der Startseite angezeigt werden sollen. Beispielsweise könnte eine App für Gehaltsabrechnungen einfach mitteilen, dass eine neue Gehaltsabrechnung verfügbar ist, anstatt Details, wie z. B. den Betrag, anzugeben. Geben Sie im Manifest kein breites Logo an.
• Verwenden Sie breite Kacheln nur dann, wenn die App den Benutzern neue und interessante Inhalte anzeigt und die Benachrichtigungen häufig (d. h. mindestens einmal pro Woche) aktualisiert werden.

• Auf quadratischen Kacheln kann weniger Inhalt als auf breiten Kacheln angezeigt werden, legen Sie deshalb für Ihren Inhalt Prioritäten fest. Versuchen Sie nicht, alles, was auf einer breiten Kachel angezeigt werden kann, in eine quadratische Kacheln zu übernehmen.

  

  Den Inhalt einer breiten Kachel, der aus einem Bild plus Text besteht, können Sie mit einer quadratischen Vorschauvorlage in zwei Frames aufteilen.

Benachrichtigungen enthalten oft eine breite und quadratische Vorlage, da die aktuelle Größe der Kachel nicht bekannt ist. Wenn für eine Benachrichtigung die Verwendung einer breiten Vorlage festgelegt und die Kachel quadratisch dargestellt wird oder für die Benachrichtigung die ausschließliche Verwendung einer quadratischen Vorlage festgelegt und die Kachel breit dargestellt wird, wird die Benachrichtigung nicht angezeigt.

Verwenden von Standardkacheln

Die Standardkachel einer App wird in ihrem Manifest festgelegt. Standardkacheln sind statisch, quadratisch oder breit und haben im Allgemeinen ein einfaches Design. Für manche Apps benötigen Sie nur die Standardkachel. Wenn eine App installiert ist, wird die Standardkachel so lange auf der Startseite angezeigt, bis die Kachel eine Benachrichtigung empfängt. Wenn ein breites Logobild verfügbar ist, wird die breite Kachel verwendet. Ein Update kann ablaufen oder explizit entfernt werden. In diesem Fall wird die Kachel auf den Standardinhalt zurückgesetzt, bis die nächste Benachrichtigung eingeht.

Richtige Verwendung von Standardkacheln

• Verwenden Sie das Standardkachelbild, um die Marke Ihrer App zu verdeutlichen. Im Prinzip dient dieses Bild als Hintergrund für das App-Logo.
• Wenn Sie ein breites Logo einschließen, berücksichtigen Sie die Designbeziehung zwischen den breiten und den quadratischen Kachelbildern, die Sie bereitstellen. Denken Sie immer daran, dass der Benutzer Ihre Kachel quadratisch oder breit anzeigen kann und die Anzeige jederzeit ändern kann. Hier sind einige allgemeine Regeln aufgelistet:
  • Zentrieren Sie das Logo horizontal in der Kachel.
  • Behalten Sie die gleiche vertikale Platzierung des Logos in beiden Kacheln bei. Die quadratische und die breite Kachel haben die gleiche Höhe.

  • Setzen Sie den Namen der App an den unteren Rand der Kachel, wenn er nicht in Ihrem Logo enthalten ist. In den folgenden Beispielen sind beide Situationen dargestellt.

    Kacheln, die das im Manifest definierte App-Namenselement verwenden:

    

    Kacheln, die den App-Namen im Logo-Bild enthalten:

    

  • Achten Sie bei Apps mit längeren Namen darauf, dass sich das Logo und der Name nicht überlappen. Berücksichtigen Sie, dass längere Namen auch in zwei Zeilen umbrochen werden können. Ein sicheres Vorgehen ist die Größe des Logos in der 100 %-Bildressource auf ungefähr 80 x 80 Pixel zu beschränken.
  • Wenn Sie den Platz um das Logo in Ihrem Bild als transparent definieren, scheint die Markenfarbe Ihrer App (im Manifest deklariert) mit einem Farbverlauf durch, der vorab als Teil des Windows 8-Stils zugewiesen wurde. Diese Methode würde für Logos, wie z. B. der weiter oben gezeigten Kachel einer E-Mail-App, angewendet.

Falsche Verwendung von Standardkacheln

• Die Standardkachel ist nicht als ausdrückliche Aufforderung zum Starten der App gedacht. Beschriften Sie sie daher nicht mit Text wie "Klick mich an!".

• Wenn Ihr Logo den Namen der App enthält, wiederholen Sie diesen Namen nicht im Namensfeld. Verwenden Sie nur eine der beiden folgenden Möglichkeiten:

  

Verwenden von Vorschauvorlagen

Vorschauvorlagen stellen Kachelinhalt bereit, der nacheinander in zwei Informationsframes im Kachelbereich angezeigt wird. Der obere Frame enthält ein Bild oder eine Bildersammlung und der untere Frame Text oder Text mit einem Bild. Beispiele finden Sie im Katalog für Kachelvorlagen.

Richtige Verwendung von Vorschauvorlagen

• Verwenden Sie Vorschauvorlagen, wenn Ihr Szenario Haupt- und ergänzenden Inhalt sowie Bilder und Text enthält. Gute Beispiel dafür sind Benachrichtigungen für eine E-Mail, die ein Foto enthält, oder ein Nachrichtenbericht mit einem Bild-/Überschrift-/Textlayout.
• Eine Vorschauvorlage weckt durch ihre Animation das Interesse des Benutzers, stellen Sie deshalb wirklich lohnenden Inhalt bereit. Ansonsten verärgern Sie Ihre Benutzer nur.
• Wenn Sie eine Vorschauvorlage verwenden, kann die Anzeige an jedem der beiden Enden (Frames) des Zyklus beginnen — wobei der Text entweder ganz unten oder ganz oben steht — und dann nach oben bzw. unten zum anderen Frame animiert werden. Achten Sie aus diesem Grund darauf, dass Ihre Frames jeweils alleine stehen können.

Falsche Verwendung von Vorschauvorlagen

• Verwenden Sie keine Vorschauvorlagen, um Benutzern Informationen über bereits bekannte Sachverhalte anzuzeigen. Beispielsweise sollte für eine Benachrichtigung über ein angehaltenes Video, die auf einer Kachel angezeigt wird, keine Vorschauvorlage verwendet werden.
• Verwenden Sie keine Vorschauvorlagen für Benachrichtigungen, die inhaltlich nicht zusammengehören. Beispielsweise sollte nie mit einer Vorschauvorlage ein Nachrichtenbericht versendet werden, wenn das Foto oder die Fotos nicht Teil des Berichts sind.
• Verwenden Sie keine Vorschauvorlagen, wenn der wichtigste Teil der Benachrichtigung sich wegen der Vorschauanimation außerhalb des Bildschirms befinden könnte. Für eine Wetter-App, die die Temperatur und ein begleitendes Bild (eine lachende Sonne oder eine Wolke) anzeigt, würde die Verwendung einer Vorschauvorlage beispielsweise bedeuten, dass die Temperatur (der Kern der Benachrichtigung) nicht immer sichtbar ist. Eine statische Vorlage, die das Bild und die Temperatur gleichzeitig anzeigt, wäre für den Benutzer hilfreicher.

Weitere Überlegungen bei der Entwicklung

• Sie können die Marke der App auf der Kachel entweder mit dem App-Namen:

  

  Oder mit dem Symbol der App darstellen:

  

  Diese Elemente werden anfänglich im App-Manifest definiert. Welches der beiden Elemente in jeder folgenden Benachrichtigung angezeigt werden soll, entscheidet der Entwickler. Nachdem Sie sich für eine der beiden Möglichkeiten entschieden haben, sollten Sie diese aus Konsistenzgründen in Zukunft beibehalten.

• Verwenden Sie keine Bild- oder Textelemente, um App-Brandinginformationen in einer Kachelbenachrichtigung anzuzeigen. Um die Marke Ihrer App hervorzuheben und dem Benutzer eine einheitliche Oberfläche zu präsentieren, sollte das Branding über die dafür bereitgestellten Vorlagenelemente erfolgen: App-Name (Kurzname) oder Logo. Das Erscheinungsbild einer Live-Kachel kann von Benachrichtigung zu Benachrichtigung deutlich verändert werden, aber die Position des Namens/Logos ist einheitlich. Dadurch wird sichergestellt, dass Benutzer Ihre Lieblings-Apps auf einen Blick finden können und sich die Informationen auf jeder Kachel an derselben Stelle befinden. Wenn Ihre App die bereitgestellten Brandingelemente (Name und Logo) nicht nutzt, dann ist es für Benutzer u. U. schwerer, die Kachel Ihrer App schnell zu erkennen.

  Die folgenden Abbildungen zeigen Kacheln, die mit den Text- und Bildelementen der Vorlage das Branding ungeeignet vermitteln. Beachten Sie, dass in beiden Fällen die Kacheln den Namen und das Logo auch wie vorgesehen verwenden, daher ist das zusätzliche Branding eine redundante Information.

  

  Weitere Informationen zum Namen und Logobild finden Sie unter Schnellstart: Erstellen einer Standardkachel im Manifest-Editor von Visual Studio.

• Verwenden Sie das Branding nicht als ein Element in der Benachrichtigungswarteschlange oder als einen Frame in einer Vorschauvorlage. Beide Szenarien beinhalten animierte Änderungen der Kachel, die die Aufmerksamkeit des Benutzers erregen. Der Benutzer wird verärgert, wenn Sie seine Aufmerksamkeit durch eine Animation wecken, die dann nur Ihre Marke anstatt neuem interessantem Inhalt anzeigt.
• Wenn der Name Ihrer App nicht in den durch den optionalen "Kurznamen" bereitgestellten Platz passt, verwenden Sie eine kürzere Version des Namens oder eine aussagekräftige Abkürzung. Beispielsweise könnten Sie "Contoso Game" für das Spiel "Contoso Fun Game Version 3" verwenden. Namen, die länger sind als die maximal zulässige Pixelanzahl, werden abgeschnitten und mit Auslassungspunkten dargestellt. Für App-Namen stehen ungefähr 40 Zeichen in zwei Zeilen zur Verfügung, wobei die tatsächlich mögliche Zeichenanzahl von den verwendeten Buchstaben abhängt. Aus Design-Gesichtspunkten empfehlen wir kürzere App-Namen. Beachten Sie, dass Sie auch einen längeren Namen für Ihre App (den "Anzeigenamen") in Ihrem Manifest verwenden können. Dieser Name wird in der Ansicht "Alle Apps" und in der QuickInfo, jedoch nicht auf der Kachel verwendet.
• Verwenden Sie Kacheln nicht zum Anzeigen von Werbung.
• Vermeiden Sie auf Kacheln zu viele grelle Farben. Ein einfaches, klares und elegantes Design wirkt besser als eines, das wie ein bockiges Kind förmlich nach Aufmerksamkeit schreit.
• Verwenden Sie keine Bilder mit Text, sondern nutzen Sie für Text immer eine Vorlage mit Textfeldern. Text in einem Bild wird nicht so scharf wie gerenderter Kacheltext dargestellt. Wenn für das aktuelle Display keine geeignete Bildressource bereitgestellt ist, könnte das Bild skaliert werden, was die Lesbarkeit weiter beeinträchtigt.
• Verwenden Sie Kacheln nicht dazu, dringende Informationen in Echtzeit an Benutzer zu übermitteln. Eine Kachel ist beispielsweise nicht die richtige Oberfläche für eine Kommunikations-App, die Benutzer über einen eingehenden Anruf informiert. Für Echtzeitnachrichten sind Popupbenachrichtigungen besser geeignet.
• Verwenden Sie keine Bilder, die wie Links, Schaltflächen oder andere Steuerelemente aussehen. Kacheln unterstützen Elemente dieser Art nicht, und die gesamte Kachel ist ein einziges Klickziel.
• Da Kachelbenachrichtigungen statisch sind, sollten keine relativen Zeitstempel oder Datumsangaben (z. B. "vor zwei Stunden") verwendet werden. Andernfalls wird die Meldung mit dem Fortschreiten der Zeit ungenau. Geben Sie stattdessen ein absolutes Datum und eine absolute Uhrzeit an, z. B. "11:00 Uhr".

Verwenden von Kachelbenachrichtigungen

Auswählen der richtigen Benachrictigungsmethode zum Aktualisieren Ihrer Kachel

Zum Aktualisieren einer Live-Kachel stehen verschiedene Mechanismen zur Verfügung:

• Lokale API-Aufrufe
• Einmalig geplante Benachrichtigungen mit lokalem Inhalt
• Pushbenachrichtigungen, die von einem Cloudserver gesendet werden
• Regelmäßige Benachrichtigungen, die Informationen von einem Cloudserver in festgelegten Abständen abrufen

Die Wahl des geeigneten Mechanismus hängt weitgehend von dem Inhalt ab, den Sie anzeigen möchten, und davon, wie oft der Inhalt aktualisiert werden soll. Die meisten Apps werden wahrscheinlich die Kachel durch einen lokalen API-Aufruf aktualisieren, wenn die App gestartet wird oder sich der Zustand in der App ändert. Dadurch ist sichergestellt, dass die Kachel aktuell ist, wenn sie aufgerufen und ausgeführt wird. Ob lokale, Push-, geplante oder Abrufbenachrichtigungen, einzeln oder in Kombination verwendet werden, hängt völlig von der jeweiligen App ab. Beispielsweise kann ein Spiel lokale API-Aufrufe verwenden, um die Kachel zu aktualisieren, wenn von einem Spieler ein neuer Punkterekord erreicht wird. Gleichzeitig kann dasselbe Spiel mit Pushbenachrichtigungen diesem Benutzer neue von seinen Freunden erzielte Punkterekorde senden.

Weitere Informationen über die Auswahl des geeigneten Mechanismus zur Aktualisierung Ihrer Kachel finden Sie unter Auswählen einer Methode für die Übermittlung von Benachrichtigungen.

Wie oft sollte Ihre Kachel aktualisiert werden?

Wenn Sie eine Live-Kachel verwenden, müssen Sie überlegen, wie oft die Kachel aktualisiert werden soll.

• Bei personalisiertem Inhalt, wie Meldungszählern oder wer in einem Spiel an der Reihe ist, empfehlen wir die Aktualisierung der Kachel dann, wenn die Information verfügbar wird, besonders, wenn der Benutzer bemerken würde, dass der Kachelinhalt verzögert oder falsch ist oder fehlt.
• Bei nicht personalisiertem Inhalt, wie Wetterupdates, empfehlen wir, dass die Kachel nicht öfter als alle 30 Minuten aktualisiert wird. Dies bewirkt einen aktualisierten Eindruck der Kachel, ohne den Benutzer mit Informationen zu überschütten.

Richtige Verwendung von Kachelbenachrichtigungen

• Personalisieren Sie die Kachelbenachrichtigungen anhand der verfügbaren Informationen über den jeweiligen Benutzer. Kachelbenachrichtigungen sollten für den Benutzer relevant sein. Die betreffenden Informationen sind größtenteils interne Informationen für Ihre jeweilige App und können durch die Datenschutzeinstellungen des Benutzers eingeschränkt sein. Ein Dienst zum Streamen von Fernsehinhalten kann beispielsweise Updates zu den Sendungen anzeigen, die der Benutzer am häufigsten abruft. Eine App für Verkehrsinformationen kann anhand der aktuellen Position des Benutzers (sofern der Benutzer die Preisgabe dieser Information gestattet) die passende Karte anzeigen.

• Senden Sie häufige Updates an die Kachel, damit sich die Benutzer sicher sein können, dass die App aktiv ist und sie immer wieder neue, aktuelle Inhalte erhalten. In welchem Abstand die Kachelbenachrichtigungen gesendet werden sollten, richtet sich nach der jeweiligen App. Beispielsweise könnte eine sehr aktive App für soziale Medien alle 15 Minuten aktualisiert werden, eine Wetter-App alle zwei Stunden, eine Nachrichten-App mehrmals am Tag, eine App für Tagesangebote einmal am Tag und eine Zeitschriften-App einmal im Monat. Wenn bei Ihrer App seltener als einmal im Monat neue Updates zur Verfügung stehen, ist eine einfache quadratische Kachel mit Signal möglicherweise besser geeignet, um den Anschein von veraltetem Inhalt zu vermeiden.
• Stellen Sie ansprechende und informative Kachelbenachrichtigungen bereit, damit Benutzer eine fundierte Entscheidung treffen können, ob sie Ihre App starten sollen oder nicht. Im Allgemeinen ist eine Benachrichtigung eine Einladung an den Benutzer, die App zu starten, um weitere Details zu erfahren oder um eine Aktion durchzuführen. Eine Benachrichtigung kann den Benutzer beispielsweise dazu veranlassen, auf einen Beitrag in einem sozialen Medium zu reagieren, einen vollständigen Nachrichtenbericht zu lesen oder Einzelheiten zu einem Schlussverkauf abzurufen.
• Senden Sie Benachrichtigungen zu dem Inhalt, der sich auf der Homepage oder der Angebotsseite Ihrer App befindet. Auf diese Weise können Benutzer, wenn sie die App als Reaktion auf Ihre Benachrichtigung starten, den Inhalt einfach finden, auf den sich Ihre Benachrichtigung bezogen hat.

Falsche Verwendung von Kachelbenachrichtigungen

• Verwenden Sie keine Live-Kacheln, wenn Sie dem Benutzer keinen interessanten, neuen, personalisierten Inhalt bieten können. Eine Rechner-App zum Beispiel wird diese Art Informationen nicht bereitstellen.
• Verwenden Sie keine Live-Kacheln, wenn das einzig Interessante, was Sie dem Benutzer mitteilen können, der letzte Status des Benutzers ist. Hilfsprogramm-Apps, Entwicklertools wie Microsoft Visual Studio und Browser, die nur Miniaturansichten der letzten Sitzung des Benutzers anzeigen würden, sollten keine Live-Kacheln verwenden.
• Verwenden Sie keine Live-Kacheln, um dem Benutzer Spam zu senden oder Werbung anzuzeigen. Das hat Ihren Rausschmiss aus dem Store zur Folge.

Richtlinien für die Benutzeroberfläche bei Verwendung von Signalen

Richtige Verwendung von Signalen

• Verwenden Sie die quadratische Kachel mit einem Signal, wenn die App nur Szenarien mit kurzen Zusammenfassungsbenachrichtigungen unterstützt. Dies könnte beispielsweise eine SMS-App sein, die nur die Anzahl der empfangenen neuen Textnachrichten anzeigen soll.
• Zeigen Sie im Signal eine Zahl an, wenn die Zahl klein genug ist, um innerhalb des Szenario bedeutsam zu sein. Wenn im Signal wahrscheinlich immer die Zahl 50 oder eine höhere Zahl angezeigt wird, sollten Sie eine Systemglyphe verwenden. Eine Möglichkeit, im Signal kleinere Zahlen anzuzeigen, besteht beispielsweise darin, die Anzahl seit dem letzten Starten der App statt die absolute Anzahl anzuzeigen. So ist es z. B. hilfreicher, die Anzahl entgangener Anrufe seit dem letzten Starten der App durch den Benutzer statt die Gesamtzahl der entgangenen Anrufe seit dem Installieren der App anzuzeigen.
• Verwenden Sie in Fällen, in denen das Anzeigen einer Zahl nicht hilfreich oder die Zahl zu groß ist, eine der bereitgestellten Systemglyphen, um eine Änderung anzugeben. Beispielsweise kann die Anzahl von neuen ungelesenen Artikeln in einem RSS-Feed mit sehr vielen Nachrichten verwirrend sein. Verwenden Sie stattdessen die Systemglyphe newMessage.
• Verwenden Sie eine Glyphe, wenn eine Zahl ohne Bedeutung ist. Wenn z. B. in der Kachel die Benachrichtigung "Angehalten" für eine Wiedergabeliste angezeigt wird, sollte die Glyphe paused verwendet werden, da eine Zahl in diesem Szenario nicht sinnvoll ist.
• Verwenden Sie die Glyphe newMessage in Fällen, in denen eine Zahl mehrdeutig ist. Beispielsweise kann "10" in einem Signal einer Kachel für soziale Medien 10 neue Anfragen, 10 neue Nachrichten, 10 neue Benachrichtigungen oder eine Kombination dieser Elemente bedeuten.
• Verwenden Sie die Glyphe newMessage in Szenarien mit vielen Benachrichtigungen (z. B. in E-Mail-Apps oder Social-Media-Apps), bei denen das Signal der Kachel andernfalls ständig den Höchstwert 99 anzeigen könnte. Für den Benutzer kann es verwirrend sein, wenn immer der Höchstwert angezeigt wird, und da er konstant bleibt, ist er ohne Informationsgehalt.

Falsche Verwendung von Signalen

• Wiederholen Sie Zahlen von Signalen nicht an anderer Stelle im Textinhalt einer umfangreichen Kachel, da die zwei Instanzen möglicherweise nicht immer synchronisiert sind.
• Verwenden Sie keine Glyphe, wenn sich ihre Aussage für den Benutzer niemals ändert. Glyphen stellen Benachrichtigungen und Übergangsstatus dar, nicht eine dauerhafte Kennzeichnung oder einen dauerhaften Status.

Richtlinien für die Benutzeroberfläche für Kacheln und Signale auf dem Sperrbildschirm

Um festzustellen, ob sich Ihre App für die Anzeige auf dem Sperrbildschirm eignet, müssen Sie die Funktionsweise und die Einschränkungen des Sperrbildschirms kennen. Eine Zusammenfassung über den Sperrbildschirm finden Sie hier. Weitere Informationen finden Sie unter Übersicht über den Sperrbildschirm.

• Auf dem Sperrbildschirm können maximal sieben App-Signale angezeigt werden. Die Signalinformationen geben die Signalinformationen der Kachel der App-Startseite wieder. Das Signal (entweder eine Glyphe oder eine Zahl) wird zusammen mit einem einfarbigen Symbol (Logo) angezeigt, um die App, der das Signal zugeordnet ist, zu identifizieren.
• Nur eine dieser sieben Apps kann einen ausführlichen Statusplatz belegen, wodurch das Anzeigen des Textinhalts des letzten Kachelupdates der App ermöglicht wird.
• Auf der ausführlichen Statuskachel des Sperrbildschirms werden keine Bilder angezeigt, die in dem Kachelupdate enthalten sind.
• Der Benutzer ist dafür verantwortlich, welche Apps Informationen auf dem Sperrbildschirm anzeigen können und welche dieser Apps den ausführlichen Status anzeigen kann.
• Alle Apps, die auf dem Sperrbildschirm vorhanden sind, können auch Hintergrundaufgaben ausführen. Alle Apps, die Hintergrundaufgaben ausführen können, sind auf dem Sperrbildschirm vorhanden. Eine App kann keine Hintergrundaufgaben verwenden, ohne auch einen Platz auf dem Sperrbildschirm zu beanspruchen.
• Die Benachrichtigungswarteschlange wird nicht von der ausführlichen Statuskachel des Sperrbildschirms unterstützt. Es wird nur das letzte Update angezeigt.
• Eine auf dem Sperrbildschirm angezeigte App, für die die Option Toastfähig im Manifest auf "Ja" festgelegt ist, zeigt ihre empfangenen Popupbenachrichtigungen auf dem Sperrbildschirm an, wenn dieser aktiviert ist. Auf dem Sperrbildschirm angezeigte Popups sind identisch mit an anderen Stellen angezeigten Popups.
• Kachelupdates, Signalupdates und Popupbenachrichtigungen werden nicht speziell für den Sperrbildschirm entworfen oder an den Sperrbildschirm gesendet. Sie als Sender wissen nicht, ob das Gerät zurzeit gesperrt ist. Bei Apps, die auf dem Sperrbildschirm angezeigt werden, werden Benachrichtigungen auf dem Startbildschirm und auf dem Sperrbildschirm wiedergegeben.

Merkmale eines ansprechend gestalteten Sperrbildschirms

Die einzige Möglichkeit, dass Ihre App auf dem Sperrbildschirm angezeigt werden kann, ist eine ausdrückliche Genehmigung durch den Benutzer. Der Benutzer kann diese Genehmigung durch eine Antwort auf eine Anforderung in Ihrer App (Sie können nur einmal fragen) oder manuell auf der Seite Anpassen in PC-Einstellungen vornehmen. Durch seine Zustimmung erklärt der Benutzer, dass die von der App gelieferten Informationen wichtig für ihn sind. Ihre App muss dann diesem Anspruch genügen. Daher müssen Sie überlegen, ob sich Ihre App überhaupt für den Sperrbildschirm eignet.

Apps mit den folgenden Attributen eignen sich für den Sperrbildschirm:

• Die Information kann auf einen Blick verstanden werden
• Die Informationen sind immer aktuell
• Die Information kann ohne weiteren Kontext verstanden werden
• Die Informationen sollten persönlich und für den Benutzer nützlich sein
• Die Informationen sollten nur angezeigt werden, wenn eine Änderung stattgefunden hat
• Ein akustisches Signal sollte nur beim Eintreffen von Popupbenachrichtigungen wiedergegeben werden

Die Information kann auf einen Blick verstanden werden

Wenn der Sperrbildschirm angezeigt wird, besteht momentan keine Interaktion zwischen dem Benutzer und dem Gerät. Daher sollten alle Updateinformationen, die Ihre App auf dem Sperrbildschirm anzeigt, durch den Benutzer auf einen Blick verstanden werden können. Dies ist vergleichbar mit einem eingehenden Anruf auf einem Mobiltelefon. Sie werfen einen kurzen Blick auf das Telefon, um zu sehen, wer anruft, und antworten entweder oder lassen den Anruf von der Voicemail entgegennehmen. Die Information, die auf dem Sperrbildschirm angezeigt wird, sollte leicht verständlich und behandelbar sein, wie die Anzeige bei einem Mobiltelefon. Alle anderen Merkmale dienen der Unterstützung dieses Merkmals.

Die Informationen sind immer aktuell

Gute Signalupdates, Kachelupdates und Popupbenachrichtigungen, unabhängig davon, ob sie auf der Startseite oder dem Sperrbildschirm angezeigt werden, sind alle potenziell handlungsrelevant. Aufgrund der Informationen in diesen Benachrichtigungen kann der Benutzer entscheiden, ob er als Reaktion darauf die App startet, um z. B. eine neue E-Mail zu lesen oder einen Beitrag in einem sozialen Netzwerk zu kommentieren. Vom Sperrbildschirm aus bedeutet das, dass das Gerät auch entsperrt werden muss. Deshalb müssen die Informationen aktuell sein, damit der Benutzer eine fundierte Entscheidung treffen kann. Wenn Benutzer bemerken, dass die Informationen Ihrer App auf dem Sperrbildschirm nicht aktuell sind, dann haben Sie deren Vertrauen verloren, und die Benutzer werden wahrscheinlich eine verlässlichere App für diesen Sperrbildschirmplatz suchen.

Gute Beispiele: aktuelle Informationen

• Eine Nachrichten-App sendet eine Benachrichtigung, wenn eine Nachricht eintrifft. Wenn diese Benachrichtigung ignoriert wird, aktualisiert die App ihr Signal mit einem Zähler für verpasste Nachrichten. Wenn der Benutzer anwesend ist, kann er den Bildschirm anschalten, um die Wichtigkeit der Nachricht zu beurteilen und zu entscheiden, ob er sofort oder erst später reagiert. Wenn der Benutzer nicht anwesend ist, wird ihm bei seiner Rückkehr die genaue Anzahl der verpassten Nachrichten angezeigt.

• Eine E-Mail-App verwendet ihr Signal, um einen Zähler der ungelesenen E-Mails anzuzeigen. Sie aktualisiert das Signal umgehend, wenn eine neue E-Mail eintrifft. Der Benutzer kann schnell den Bildschirm einschalten, um zu überprüfen, wie viele ungelesene E-Mails vorhanden sind, und er kann sicher sein, dass die Anzahl korrekt ist. Anhand dieser Information kann der Benutzer entscheiden, ob er das Gerät entsperren und die E-Mails lesen möchte.

Schlechte Beispiele: Veraltete Informationen

• Eine Nachrichten-App aktualisiert ihr Signal mit der Anzahl der verpassten Nachrichten nur zweimal in der Stunde. Der Benutzer kann sich bei der Entscheidung, das Gerät zu entsperren, nicht auf den Signalzähler verlassen.
• Eine Wetter-App, die den ausführlichen Statusplatz verwendet, zeigt eine Schlechtwetterwarnung auch dann noch an, wenn die Warnung bereits abgelaufen ist. Dadurch erhält der Benutzer nicht nur falsche Informationen, sondern es ist auch besonders ärgerlich, wenn in dem Text angegeben ist, wann die Warnung abläuft. Für den Benutzer wird so offensichtlich, dass es sich um eine veraltete Information handelt. Der Benutzer verliert das Vertrauen, dass die App ihn richtig informieren kann. Die App hätte diese Information löschen müssen, als sie abgelaufen ist.
• Eine Kalender-App zeigt einen vergangenen Termin weiterhin an. Auch hier hätte die App diese Information löschen müssen, als sie abgelaufen ist.

Die Information kann ohne weiteren Kontext verstanden werden

Folgende Kontextinformationen sind auf dem Sperrbildschirm nicht vorhanden:

• Die mit dem Signal gelieferte Kachel, wenn die App den ausführlichen Status nicht anzeigen darf. Selbst wenn der ausführliche Status angezeigt wird, ist das Signal von der Kachel physisch getrennt. Das Logo neben dem Signal ist die einzige Identifikation der App, für die es steht.
• Bilder in Kachelupdates. Nur der Text des Updates wird am ausführlichen Statusplatz angezeigt.
• Die Benachrichtigungswarteschlange. Nur das neueste Update wird am ausführlichen Statusplatz angezeigt.

Deshalb müssen Ihre Updates für den Benutzer ohne den zusätzlichen Kontext verständlich sein, der auf der Startseite verfügbar ist. Beachten Sie erneut, dass Benachrichtigungen nicht spezifisch auf den Sperrbildschirm ausgerichtet sein können. Deswegen müssen sämtliche Updatemitteilungen Ihrer App unter die Regel "Ohne zusätzlichen Kontext verständlich" fallen.

Hinweis  Anders als ausführliche Kacheln enthalten Popupbenachrichtigungen Bilder (falls vorhanden) und Text. Auf dem Sperrbildschirm angezeigte Popupbenachrichtigungen unterscheiden sich nicht von Popupbenachrichtigungen an anderen Stellen. Der Kontext geht also nicht verloren.

Gute Beispiele: Ohne zusätzlichen Kontext verständlich

• Eine E-Mail-App verwendet ihr Signal, um den Zähler der ungelesenen E-Mails anzuzeigen. Obwohl die Kachel der Startseite mehr Informationen anzeigen könnte, wie z. B. Textausschnitte aus den letzten E-Mails oder Bilder der Absender, ist das, was das Signal mitteilt, ohne Zusatzinformationen verständlich.
• Eine App für ein soziales Netzwerk verwendet den ausführlichen Statusplatz, um den Benutzer über die letzten Aktivitäten seiner Freunde zu informieren. Wenn ein Freund ihm eine Nachricht sendet, wird der Name dieses Freunds in den Benachrichtigungstext aufgenommen (z. B. "Kyle hat Dir eine neue Nachricht geschickt!"). Auf der Startseite kann der Benutzer ein Bild seines Freunds in der Benachrichtigung sehen, und auf dem Sperrbildschirm wird auch ohne Bild durch den Text klar, wer diese Nachricht gesendet hat.

Schlechte Beispiele: Ohne zusätzlichen Kontext nicht verständlich

• Eine Nachrichten-App aktualisiert ihre Kachel mit der zuletzt empfangenen Nachricht und zeigt nur das Bild des Absenders und den Meldungstext an. Auf der Startseite ist dem Benutzer klar, von wem die Nachricht stammt. Auf dem Sperrbildschirm – ohne das Bild des Absenders – weiß der Benutzer nicht, wer die Nachricht gesendet hat.
• Eine App für ein soziales Netzwerk aktualisiert ihre Kachel mit einer Collage von Fotos ohne Text. auf der Startseite ist das eine ansprechende, lebendige Kachel. Auf dem Sperrbildschirm wird überhaupt nichts angezeigt, weil das Kachelupdate keinen Text enthält.

Die Informationen sollten persönlich und für den Benutzer nützlich sein

Zwei der Hauptzwecke des Sperrbildschirms sind die Bereitstellung einer personalisierten Oberfläche für den Benutzer und die Anzeige von App-Updates. Berücksichtigen Sie diese beiden Zwecke, wenn Sie beurteilen, ob Ihre App sich für die Darstellung auf dem Sperrbildschirm eignet.

Auf dem Sperrbildschirm angezeigte Apps sind etwas Besonderes, da jeweils nur sieben Apps auf dem Sperrbildschirm angezeigt werden können. Durch das Zuordnen einer App zu einem dieser wertvollen Sperrbildschirmplätze bringt der Benutzer zum Ausdruck, dass die Informationen von dieser App wichtig genug sind, um angezeigt zu werden, auch wenn der Benutzer das Gerät nicht aktiv verwendet. Deshalb sollte die App Informationen bereitstellen, die persönlich und für die Benutzer nützlich sind.

Hinweis  Definitionsgemäß wird der Sperrbildschirm angezeigt, wenn das Gerät gesperrt ist. Es ist keine Anmeldung oder andere Sicherheitshürde erforderlich, um den Inhalt des Sperrbildschirms anzusehen. Sie sollten deswegen beachten, dass die dort angezeigte Information, auch wenn sie idealerweise personalisiert ist, von jedem gesehen werden kann.

Gute Bespiele: Personalisierte Informationen

• Eine E-Mail-App zeigt die Anzahl der ungelesenen E-Mails im Konto des Benutzers an.
• Eine Nachrichten-App zeigt die Anzahl der verpassten Nachrichten an, die an den Benutzer gesendet wurden.
• Ein News-App zeigt die Anzahl der neuen Artikel in den Kategorien an, die der Benutzer als Favoriten gekennzeichnet hat.

Schlechte Beispiele: Unpersönliche Informationen

• Eine News-App zeigt die Gesamtanzahl aller neuen Artikel an, die von ihrem Dienst gesendet werden, ohne Berücksichtigung der vom Benutzer festgelegten Prioritäten.
• Eine Shopping-App sendet eine Benachrichtigung über einen Ausverkauf, aber nicht aufgrund einer Artikel- oder Kategoriepriorität, die der Benutzer angegeben hat.

Die Informationen sollten nur angezeigt werden, wenn eine Änderung stattgefunden hat

Wie weiter oben bereits erwähnt, sollten Informationen auf dem Sperrbildschirm mit einem kurzen Blick verstanden werden können. Wenn eine App aktuell kein Signal anzeigt, wird zu diesem Zweck auf dem Sperrbildschirm an der Position, an der sonst das Signal erscheinen würde, eine Lücke gelassen. Benutzer können so leichter sehen, dass etwas ihre Aufmerksamkeit erfordert – das Erscheinen eines Signals und Logos in Folge eines Ereignisses ist auffälliger als ein Signal, das immer angezeigt wird und nichts Neues mitteilt.

Zeigen Sie den Status nur an, wenn er sich ändert. Ein lange ausgeführter oder sich niemals ändernder Status überfrachtet den Sperrbildschirm nur und verdeckt dabei wichtigere Informationen. Ein Signal sollte nur angezeigt werden, wenn etwas eingetreten ist, über das der Benutzer Bescheid wissen sollte. Dasselbe gilt für Kachelupdates. Entfernen Sie alten Benachrichtigungsinhalt aus Ihrer Kachel, um die Kachel auf ihr Standardbild auf der Startseite zurückzusetzen und nichts auf dem Sperrbildschirm anzuzeigen.

Gute Beispiele: Nur nützliche Informationen anzeigen

• Eine E-Mail-App zeigt ein Signal nur dann an, wenn es ungelesene E-Mails gibt. Wenn neue E-Mails eingehen, wird das Signal aktualisiert und angezeigt.
• Eine Nachrichten-App zeigt ihren Verbindungsstatus nur an, wenn der Benutzer keine Nachrichten empfangen kann. Da der Status "verbunden" als Standardzustand der App angenommen wird, besteht keine Notwendigkeit, diese Information zu übermitteln. "Alles in Ordnung" ist keine handlungsrelevante Benachrichtigung. Eine Benachrichtigung darüber, dass keine Nachrichten empfangen werden können, ist dagegen eine nützliche, handlungsrelevante Information.

Schlechte Beispiele: Lange ausgeführter Status

• Eine E-Mail- oder Benachrichtigungs-App hat keinen Zähler für die Anzeige ungelesener E-Mails und zeigt daher den Verbindungsstatus an, bis neue E-Mails oder Nachrichten eingehen. Dadurch wird die Möglichkeit des Benutzers, mit einen Blick festzustellen, ob eine neue Nachricht vorliegt, beeinträchtigt, weil das Signal immer vorhanden ist.
• Eine Kalender-App zeigt die Meldung an, dass der Benutzer keine Termine hat. Wieder wird dadurch die Benutzerfreundlichkeit des ausführlichen Statusplatzes verringert, da hier immer irgendetwas angezeigt würde.

Ein akustisches Signal sollte nur beim Eintreffen von Popupbenachrichtigungen wiedergegeben werden

Fügen Sie Ihrer App keinen Code bei, der beim Aktualisieren eines Signals oder einer Kachel ein akustisches Signal wiedergibt. Eine eingehende Popupbenachrichtigung kann jedoch ein akustisches Signal wiedergeben, da diese dafür gestaltet wurde.

Wenn Sie die Ratschläge in diesem Artikel befolgen, können Sie Apps erstellen, die die richtigen Informationen auf die richtige Art und Weise auf dem Sperrbildschirm anzeigen und dadurch die Zufriedenheit und das Vertrauen der Benutzer erhöhen.

Wann die Sperrbildschirmanforderungs-API verwendet werden sollte

Rufen Sie die Sperrbildschirmanforderungs-API (RequestAccessAsync) nur auf, wenn Ihre App tatsächlich Hintergrundrechte erfordert, um korrekt zu funktionieren. Da nur sieben Hintergrundplätze zur Verfügung stehen, müssen Benutzer unterscheiden, welche Apps tatsächlich Hintergrundprivilegien benötigen, um korrekt zu funktionieren, und welche auch ohne diese funktionieren (selbst wenn sie mit diesen über zusätzliche Funktionalität verfügen würden).

Wenn eine App unbedingt Hintergrundprivilegien benötigt, um den Erwartungen des Benutzers zu entsprechen, empfehlen wir, dass diese die Anforderungs-API verwendet, um den Benutzer dazu aufzufordern, die App auf dem Sperrbildschirm zu platzieren.

Wenn eine App jedoch den Erwartungen des Benutzers auch ohne Hintergrundprivilegien entspricht, empfehlen wir, dass Sie den Benutzer nicht ausdrücklich dazu auffordern, die App auf dem Sperrbildschirm zu platzieren. Lassen Sie stattdessen den Benutzer die App über die Seite Anpassen in PC-Einstellungen auf dem Sperrbildschirm platzieren.

Beispiele für Apps, die die Anforderungs-API aufrufen sollten:

• Eine Nachrichten-App, die Hintergrundprivilegien erfordert, um Nachrichten zu erhalten, wenn die App nicht im Vordergrund ist
• Eine E-Mail-App, die Hintergrundprivilegien erfordert, um den Posteingang des Benutzers zu synchronisieren, wenn die App nicht im Vordergrund ist

Beispiele für Apps, die die Anforderungs-API nicht aufrufen sollten:

• Eine Wetter-App, die regelmäßige Benachrichtigungen anstelle von Hintergrundaktivitäten verwendet, um ihre Prognose zu aktualisieren
• Eine News-App, die ihren Signalzähler mit neuen Artikeln zu einer bestimmten Tageszeit aktualisiert

Hinweis  Die App sollte keine Implementierung eines eigenen Dialogfelds aufweisen, in dem die Benutzer zum Hinzufügen der App zum Sperrbildschirm aufgefordert werden. Wenn für die ordnungsgemäße Ausführung der App ein Zugriff auf den Sperrbildschirm erforderlich ist, sollten Sie auf das Dialogfeld zurückgreifen, das durch die Sperrbildschirmanforderungs-API dargestellt wird. Wenn ein Benutzer zuvor über dieses Dialogfeld die Rechte für den Sperrbildschirm für Ihre App verweigert hat, wird das Dialogfeld möglicherweise nicht mehr angezeigt. In diesem Fall können Sie Benutzer mithilfe von Inlinetext in der App auf die Seite Personalisieren der PC-Einstellungen weiterleiten, um die App dem Sperrbildschirm manuell hinzuzufügen.

Problembehandlung für Kachelbenachrichtigungen

In diesem Abschnitt werden gängige Fehler erläutert, die bei der Arbeit mit Kacheln und Kachelvorlagen auftreten können. Sofern nicht anders angegeben, gelten die Lösungen jeweils für alle Arten der Benachrichtigungsübermittlung (lokal, geplant, regelmäßig oder Pushbenachrichtigung).

Möglicherweise gibt es konkrete Problembehandlungsschritte für die Übermittlungsmethode der Benachrichtigung. Weitere Informationen finden Sie unter diesen Themen:

• Richtlinien und Prüfliste für periodische Benachrichtigungen
• Richtlinien und Prüfliste für geplante Benachrichtigungen
• Richtlinien und Prüfliste für Pushbenachrichtigungen

Keine Anzeige der lokalen Kachelbenachrichtigung

Am häufigsten ist dieses Problem darauf zurückzuführen, dass zum Definieren der Benachrichtigung fehlerhafter XML-Code verwendet wurde. Es kommen aber auch andere Ursachen infrage, die Sie folgendermaßen überprüfen können:

• Überprüfen der Benutzereinstellungen
• Angeben von Ressourcen für breite Logos im App-Manifest
• Überprüfen der Bildgrößen
• Überprüfen der URLs
• Untersuchen der Bildformate
• Überprüfen der XML-Syntax
• Überprüfen der Ablaufzeit der Benachrichtigung
• Sicherstellen, dass die Benachrichtigungswarteschlange aktiviert ist

Überprüfen der Benutzereinstellungen

Mögliche Ursache: Der Benutzer oder Administrator hat Benachrichtigungen über Einstellungen deaktiviert. Überprüfen Sie, ob in der App-Leiste der App eine Option wie Live-Kachel aktivieren/deaktivieren vorhanden ist und ob die Live-Kachel damit deaktiviert wurde. Der Administrator kann über verschiedene Gruppenrichtlinien Benachrichtigungen deaktivieren. Vergewissern Sie sich beim Administrator, dass Benachrichtigungen aktiviert sind.

Fix: Aktivieren Sie Benachrichtigungen über Einstellungen, oder bitten Sie einen Administrator, Benachrichtigungen über Gruppenrichtlinien zu aktivieren.

Weitere Informationen finden Sie unter TileUpdater.Setting.

Angeben von Ressourcen für breite Logos im App-Manifest

Mögliche Ursache: Im App-Manifest ist kein standardmäßiges Ressourcenbild für breite Kacheln angegeben. Wenn dieses Standardbild nicht festgelegt ist, werden auf der Kachel keine breiten Benachrichtigungsvorlagen angezeigt. In der Benachrichtigungsnutzlast sollten immer sowohl eine breite als auch eine quadratische Vorlage angegeben sein, da der Absender nicht weiß, ob die Kachel beim Eintreffen der Benachrichtigung breit oder quadratisch angezeigt wird (es sei denn, für die Kachel ist absichtlich kein breites Bild vorhanden). Diese Einstellung wird vom Benutzer festgelegt.

Fix: Geben Sie im App-Manifest eine Standard-Bildressource für breite Logos an.

Überprüfen der Bildgrößen

Mögliche Ursache: Bilder für alle Benachrichtigungen müssen kleiner als 1024 x 1024 Pixel und 200 KB sein. Wenn ein Bild in einer Benachrichtigung eine dieser Abmessungen überschreitet, wird die Benachrichtigung verworfen.

Fix: Verkleinern Sie die Bilder.

Weitere Informationen finden Sie unter Größe von Kachel- und Popupbildern.

Überprüfen der URLs

Mögliche Ursache: URL-Syntaxfehler.

Bilder in Benachrichtigungen werden als Ressourcenverweis oder Literalpfad angegeben. Wenn ein Pfad verwendet wird, muss dieser mit einem der drei folgenden Protokolle angegeben werden:

Hinweis  Das Zeichen "/" kann in allen Spezifikationstypen als Trennzeichen verwendet werden. Wir empfehlen, immer "/" anstelle von "\" zu verwenden, um unbeabsichtigte Verwechslungen mit Escapezeichen zu vermeiden.

Wohlgeformte Beispiele:

Falsch geformte Beispiele:

Untersuchen der Bildformate

Mögliche Ursache: Das Format der Bilder wird nicht unterstützt.

Für Benachrichtigungen können nur Bilder in den Formaten GIF, PNG oder JPG bzw. JPEG verwendet werden. Das Format des Bilds muss außerdem der Erweiterung entsprechen. Es reicht nicht aus, eine Datei mit einer unterstützten Erweiterung lediglich umzubenennen.

Die häufigste Ursache von Bildformatfehlern ist die Serialisierung von Bitmaps im Windows.Storage.ApplicationData.current.localFolder-Speicher. Achten Sie darauf, Ihr bevorzugtes Format aufzurufen. Anderenfalls wird das Bild als Windows-Bitmap gespeichert, und der Header enthält "BMP".

Überprüfung: Stellen Sie zunächst sicher, dass Sie eine nur aus Text bestehende Benachrichtigung erfolgreich senden können, um das Problem auf das Bild einzugrenzen. Eine Möglichkeit zur Überprüfung des Bildformats besteht darin, das Bild in einem Bildverarbeitungsprogramm zu laden und es als JPG-Datei zu speichern. Wenn Sie in der Benachrichtigung auf diese neue JPG-Datei verweisen und der Fehler nicht mehr auftritt, lag vermutlich ein Bildformatfehler vor. Sie können die Datei auch im Binär-Editor von Visual Studio öffnen und den Header untersuchen.

Fix: Ändern oder korrigieren Sie die Bildformate.

Überprüfen der XML-Syntax und des Inhalts

Mögliche Ursache: XML-Syntaxfehler oder Überprüfungsfehler.

Überprüfen Sie, ob die XML-Inhalte auch über die grundlegende Syntax hinaus vollständig und fehlerfrei sind. Folgende Punkte führen bei XML häufig zu Fehlern:

• Groß- und Kleinschreibung. Bei Tagnamen, Attributnamen und Attributwerten muss die Groß- und Kleinschreibung beachtet werden. Stellen Sie sicher, dass im XML-Code die richtige Groß-/Kleinschreibung verwendet wird.
• Für jede Kachelgröße muss ein binding-Element vorhanden sein. Wenn Sie breite Kacheln unterstützen, sollten Sie immer für jede gesendete Kachel eine breite und eine quadratische Vorlage für binding-Elemente angegeben.
• Textzeichenfolgen sollten keine reservierten XML-Zeichen enthalten. Sie können Zeichenfolgen auf der Kachel z. B. nicht durch Hinzufügen der Tags <i> und </i> kursiv formatieren. Wenn Sie die Literalzeichen "<i>" anzeigen möchten, müssen diese richtig zwischen Escapezeichen gesetzt werden. Weitere Informationen zu Ecapezeichen in XML finden Sie im Artikel zu XML-Zeichenentitäten und XAML.
• Die für die lang-Attribute angegebenen Werte müssen der ITEF BCP 47-Spezifikation entsprechen.
• Bei lokal erstellten XML-Zeichenfolgen (für lokale oder geplante Benachrichtigungen) muss UTF-8 als Codierung verwendet werden. Bei Textzeichenfolgen, die per Pushbenachrichtigung gesendet oder von einer URL abgefragt werden, ist UTF-16 erforderlich.
• Wenn Sie in der XML-Nutzlast ein image-Element mit einem nicht leeren src-Attribut verwenden, müssen Sie einen Verweis auf ein gültiges Bild hinzufügen, da die Benachrichtigung sonst nicht übermittelt werden kann.

Sie können auch das Ereignisprotokoll auf Fehler überprüfen, wenn die Kachelbenachrichtigung nicht angezeigt wird. Suchen Sie im Ereignisprotokoll (Anwendungs- und Dienstprotokolle > Microsoft > Windows > Immersive-Shell > Microsoft-Windows-TWinUI > Betriebsbereit) nach Ereignissen, die Ihre Kachelbenachrichtigung betreffen.

Überprüfung: Suchen Sie mit einer XML-Syntaxprüfung wie beispielsweise dem Visual Studio-Editor nach grundlegenden Syntaxfehlern. Überprüfen Sie im jeweiligen Vorlagenverweis (TileTemplateType), ob die richtige Anzahl von Bildern vorhanden ist und die Bilder dem richtigen Bildindex zugewiesen wurden.

Fix: Ändern Sie den XML-Code, oder verwenden Sie eine andere Vorlage, die dem Inhalt entspricht.

Sicherstellen, dass die Benachrichtigung nicht abgelaufen ist

Mögliche Ursache: Die Ablaufzeit ist auf einen zu kleinen Wert festgelegt.

Wenn Sie die Ablaufzeit in der Benachrichtigung über die ExpirationTime-Methode (bei einer lokalen Benachrichtigung) oder das X-WNS-TTL-Headerfeld (bei einer Pushbenachrichtigung) festlegen, beachten Sie, dass die Werte Millisekunden darstellen. Wenn eine Kachelbenachrichtigung beispielsweise genau eine Stunde lang gelten soll, lautet der Wert 60 * 60 * 1000 = 3600000.

Fix: Verwenden Sie einen größeren Wert.

Sicherstellen, dass die Benachrichtigungswarteschlange aktiviert ist, wenn der Benachrichtigungszyklus ausgewählt wurde

Mögliche Ursache: Die Benachrichtigungswarteschlange für Kacheln ist nicht aktiviert.

Standardmäßig zeigen Kacheln nur ein Update auf einmal an, sodass eine neu eintreffende Benachrichtigung die vorhandene ersetzt. Wenn die letzten fünf Benachrichtigungen abwechselnd angezeigt werden sollen, müssen Sie im Initialisierungscode der App TileUpdater.EnableNotificationQueue(true) aufrufen. Dies ist während der gesamten Lebensdauer der App nur einmal erforderlich. Weitere Informationen finden Sie unter Verwendung der Benachrichtigungswarteschlange mit lokalen Benachrichtigungen.

Fix: Rufen Sie im Initialisierungscode EnableNotificationQueue(true) auf. Achten Sie außerdem darauf, dass die Benachrichtigungstags eindeutig sind.

Prüfliste

Informationen zu allgemeinen Anforderungen für den Windows Store finden Sie unter Zertifizierungsanforderungen für Windows-Apps. Damit Ihre App im Windows Store akzeptiert wird, dürfen Sie Kacheln und Benachrichtigungen nicht zum Anzeigen von Werbung verwenden.

Verwandte Themen

Beispiel für App-Kacheln und Signale

Beispiel für eine App auf dem Sperrbildschirm

Schnellstart: Erstellen einer Standardkachel im Manifest-Editor von Visual Studio

Schnellstart: Senden eines Kachelupdates

Schnellstart: Senden eines Signalupdates

Schnellstart: Anzeigen von Benachrichtigungen auf dem Sperrbildschirm

Kachelvorlagenkatalog

Planen einer Kachelbenachrichtigung

Einrichten regelmäßiger Benachrichtigungen für Kacheln

Verwendung der Benachrichtigungswarteschlange mit lokalen Benachrichtigungen

XML-Schema für Kacheln

Übersicht über Kacheln und Kachelbenachrichtigungen

Übersicht über Signale

Übersicht über den Sperrbildschirm

Die Benachrichtigungswarteschlange

Auswählen einer Methode für die Übermittlung von Benachrichtigungen