Richtlinien für Kacheln und Signale

Applies to Windows and Windows Phone

Beschreibung

In diesem Thema werden bewährte Methoden 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 besonderen Kachel-bezogenen Anforderungen, die Ihre App erfüllen muss, um im Windows Store akzeptiert zu werden.

Sehen Sie dieses Feature in unserer Reihe App-Features von A bis Z in Aktion.:  Windows Store-App-Benutzeroberfläche von A bis Z

Empfohlene und nicht empfohlene Vorgehensweisen

Allgemeine Richtlinien

  • Verwenden Sie nur eine kleine und mittlere Kachel, wenn Ihre App keine Updates per Kachelbenachrichtigungen an den Benutzer sendet. Der Inhalt breiter und großer Kacheln sollte immer aktuell sein und regelmäßig aktualisiert werden. Wenn Sie keine Live-Kachel verwenden, stellen Sie kein breites oder großes Logo im Manifest bereit.
  • Verwenden Sie nur eine kleine oder mittlere Kachel mit einem Signal, wenn die App nur Szenarien mit kurzen Zusammenfassungsbenachrichtigungen unterstützt, d. h. Benachrichtigungen, die nur durch ein badge image oder eine einzelne Zahl ausgedrückt werden können. Ein Beispiel hierfür wäre eine SMS-App, bei der nur die Anzahl empfangener neuer Textnachrichten in Benachrichtigungen angezeigt werden soll. Stellen Sie im Manifest kein breites Logo bereit.
  • Verwenden Sie nur die kleine und mittlere 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 anzeigen, dass eine neue Gehaltsabrechnung verfügbar ist, anstatt Details wie den Betrag anzugeben. Stellen Sie im Manifest kein breites oder großes Logo bereit.
  • Verwenden Sie breite oder große 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.
  • Verwenden Sie die große Kachel, um mehrere Artikel aus einer einzelnen Benachrichtigung gleichzeitig auf einer einzelnen Kachel anzuzeigen. Mithilfe von großen Kacheln können Sie jedoch auch längere Elementlisten oder Bilder anzeigen, die der Benutzer auf der Startseite gern in größerem Format sehen würde.
  • Verwenden Sie das Standardkachelbild, um die Marke Ihrer App zu verdeutlichen. Im Prinzip dient dieses Bild als Hintergrund für das App-Logo.
  • 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 Windows Store zur Folge.
  • 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.

Standardkacheln

  • Wenn Sie ein breites Logo oder sowohl breite als auch große Logos einschließen, müssen Sie die Designbeziehung zwischen Ihren mittleren, breiten und großen Kachelbildern berücksichtigen. Denken Sie immer daran, dass der Benutzer Ihre Kachel in allen unterstützten Größen anzeigen und die Größe jederzeit ändern kann. Befolgen Sie die folgenden allgemeinen Regeln:
    • 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. Behalten Sie die gleiche vertikale Platzierung (proportional) des Logos auf der großen Kachel bei.
    • Setzen Sie den Namen der App an den unteren Rand der Kachel, wenn er nicht in Ihrem Logobild enthalten ist. Bedenken Sie, dass der App-Name auf der kleinen Kachel nicht angezeigt werden kann. In den folgenden Beispielen sind beide Situationen dargestellt.

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

      Eine mittlere Kachel und eine breite Kachel, beide mit dem App-Namen.

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

      Eine mittlere Kachel und eine breite Kachel, beide mit einem Bild, das den App-Namen enthält.

    • 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 umgebrochen werden können. Um sicherzugehen, können Sie Ihr Logo für die mittlere und breite Kachelgröße z. B. auf eine Größe von ca. 80 x 80 Pixel bei 100 % 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, z. B. der weiter oben gezeigten Kachel einer E-Mail-App, angewendet.
  • 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:

    Eine mittlere Kachel mit einem Namensfeld und eine breite Kachel mit dem Namen der App im Logo.

Vorschauvorlagen

  • Verwenden Sie Vorschauvorlagen, wenn Ihr Szenario unabhängig voneinander verwendbare Bild- und Textinhalte beinhaltet. Sie können z. B. ein Foto eines Reiseziels oben in der Vorlage und den Namen des Orts im unteren Teil anzeigen.
  • 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.
  • 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. Eine Vorschauvorlage sollte z. B. nicht verwendet werden, wenn das Foto nichts mit dem Text zu tun hat.
  • 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.
  • Verwenden Sie keine Vorschauvorlagen, wenn Text erforderlich ist, um Kontext für das Bild bereitzustellen (z. B. bei einem Nachrichtenbericht).

Signale

  • Unterstützen Sie nur die mittlere Kachelgröße mit einem Signal, wenn Ihre App nur Szenarien mit kurzen Zusammenfassungsbenachrichtigungen unterstützt. Dies könnte z. B. eine SMS-App sein, die nur die Anzahl empfangener neuer Textnachrichten anzeigen soll. Bedenken Sie, dass Signale auch dann zu sehen sind, wenn der Benutzer zur kleinen Kachelgröße wechselt.
  • Zeigen Sie im Signal eine Zahl an, wenn eine kleine Zahl in Ihrem Szenario aussagekräftig ist. 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 z. B. darin, anstelle der absoluten Anzahl die Anzahl seit dem letzten Start der App anzuzeigen. So ist es z. B. sinnvoller, anstelle der Gesamtanzahl entgangener Anrufe seit der Installation der App die Anzahl von Anrufen anzuzeigen, die entgangen sind, seitdem der Benutzer die App zuletzt gestartet hat.
  • 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.
  • 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.

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 mittlere 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.

Weitere Hinweise zur Verwendung

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. Für Kacheln gibt es drei quadratische Größen (klein, mittel und groß) und eine breite Größe. Für die Größen "mittel", "breit" und "groß" sind mehrere Vorlagen mit Text, Bildern oder einer Kombination aus Text und Bildern verfügbar. Einige Vorlagen (bezeichnet als Vorschauvorlagen) bestehen aus zwei gestapelten Frames, für die innerhalb des Kachelbereichs ein Bildlauf vorwärts und rückwärts durchgeführt wird. Vorschauvorlagen sind für die Kachelgrößen "mittel" und "breit" verfügbar.

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. Auf einer Kachel kann auch ein Statussignal – eine Zahl oder eine Glyphe – angezeigt werden.

Auf einer mittleren, breiten oder großen Kachel kann optional Brandingmaterial in einer der unteren Ecken angezeigt werden. Dabei kann es sich um den Namen der App (auf einer Standard- oder Live-Kachel) oder ein kleines Symbol (nur auf Live-Kacheln) handeln.

Die beiden folgenden Gesichtspunkte sollten Sie immer berücksichtigen:

  • Der Benutzer kann die Kachelgröße in jede von der Kachel unterstützte Größe ändern. Sie können nicht feststellen, welche Größe gerade auf der Startseite eines Benutzers angezeigt wird. Alle Kacheln müssen die Kachelgrößen "klein" und "mittel" unterstützen. Die Unterstützung der breiten und großen Kacheln ist dagegen optional. Die Unterstützung einer großen Kachel setzt voraus, dass auch die breite Kachel unterstützt wird. Wenn Sie also große Kacheln unterstützen möchten, müssen Sie Unterstützung für alle vier Kachelgrößen bereitstellen. Große und breite Kacheln sollten nur dann verwendet werden, wenn Ihre Kachel Live-Updates unterstützt.
  • Falls Ihre Kachel Live-Kacheln unterstützt, kann der Benutzer Kachelbenachrichtigungen jederzeit deaktivieren und aktivieren. Bei deaktivierten Kachelbenachrichtigungen ist die Kachel statisch.

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 App-Inhalten durch die Kachel macht Benutzer glücklich.
  • Durch die Verwendung einer Live-Kachel erhöhen Sie die Wahrscheinlichkeit, dass der Benutzer Ihre App aus der Ansicht "Apps" an die Startseite anheftet, damit er die Liveupdates sehen kann.
  • 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 der Anzahl neuer 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 verschiedenen Kachelgrößen

Ihre App hat immer eine kleine und eine mittlere Kachel. Sie müssen im Manifest Ihrer App mindestens eine Bildressource für die mittlere Kachel bereitstellen. Sie können auch eine Ressource für die kleine Kachel bereitstellen, andernfalls wird aber eine verkleinerte Version der Ressource der mittleren Kachel verwendet.

Sie müssen entscheiden, ob Sie auch eine breite oder große Kachel unterstützen möchten.

  • Um eine breite Kachel zu unterstützen, fügen Sie im App-Manifest ein breites Logobild (wide310x150) als Teil der Standardkachel hinzu. Wenn Sie dieses standardmäßige breite Logobild nicht bereitstellen, unterstützt Ihre Kachel nur die kleine (square70x70) und mittlere (square150x150) Größe. Ihre Größe kann in diesem Fall nicht vom Benutzer in das breite Format geändert werden, und es können keine breiten Benachrichtigungen auf ihr angezeigt werden.
  • Um eine große Kachel (square 310x310) zu unterstützen, fügen Sie im App-Manifest sowohl ein breites als auch ein großes Logobild als Teil der Standardkachel hinzu. Wenn Sie dieses standardmäßige große Logobild nicht bereitstellen, kann die Kachelgröße nicht vom Benutzer in das große Format geändert werden, und es können keine Benachrichtigungen mit den großen Vorlagen auf ihr angezeigt werden. Da die Unterstützung einer großen Kachel die Unterstützung der breiten Kachel voraussetzt, hat das Hinzufügen eines großen Logobilds nur dann einen Sinn, wenn Sie auch ein breites Logobild bereitstellen.

Wenn Sie mehr Kachelgrößen unterstützen möchten, als Ihre App gegenwärtig unterstützt, müssen Sie eine neue Version der App mit einem aktualisierten Manifest bereitstellen, das die zusätzlichen Standardlogobilder enthält.

  • Auf mittleren Kacheln kann weniger Inhalt als auf breiten und großen 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 mittlere Kacheln zu übernehmen. Die einzigen von der kleinen Kachel unterstützten Liveinhalte sind Signalbenachrichtigungen.

    Eine breite Kachel mit einem Bild und einer Textnachricht neben einer mittleren Kachel mit nur einem Teil der Textnachricht

    Den Inhalt einer breiten Kachel, der aus einem Bild plus Text besteht, können Sie mit einer quadratischen Vorschauvorlage in zwei Frames aufteilen. Verwenden Sie jedoch keine Vorschauvorlage, wenn das Bild selbst nicht ausreicht, um den Hauptinhalt zu übermitteln.

Da die aktuelle Kachelgröße nicht bekannt ist, sollten Benachrichtigungen Vorlageninhalte für alle unterstützten Kachelgrößen bereitstellen (mit Ausnahme der kleinen Kachel). Wenn für eine Benachrichtigung die Verwendung einer breiten Vorlage festgelegt und die Kachel mit mittlerer Größe dargestellt wird oder für die Benachrichtigung die ausschließliche Verwendung einer mittleren 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 und haben im Allgemeinen ein einfaches Design. Für manche Apps benötigen Sie nur die Standardkachel. Heftet der Benutzer nach dem Installieren der App eine Kachel aus der Ansicht "Apps" an "Start" an, wird die Standardkachel auf der Startseite angezeigt, bis sie eine Benachrichtigung empfängt. Wenn Sie ein breites Logobild bereitgestellt haben, können Sie angeben, ob die Kachel anfangs als mittlere oder breite Kachel an "Start" angeheftet wird. Standardmäßig wird die Kachel einer App als breite Kachel angeheftet, sofern die breite Kachelgröße von der App über ein breites Logobild unterstützt wird, das im Manifest angegeben ist. Andernfalls wird die Kachel in mittlerer Größe angeheftet. Nach dem Anheften kann der Benutzer die Größe der Kachel in ein beliebiges unterstütztes Format ändern. Sofern für eine Live-Kachel keine aktuellen, nicht abgelaufenen Benachrichtigungen für die Anzeige vorhanden sind, kann sie auf ihre Standardeinstellung zurückgesetzt werden.

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.

Weitere Überlegungen bei der Entwicklung

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

    Kachel mit einem App-Namen

    Oder mit dem Symbol der App darstellen:

    Kachel mit einem App-Logo

    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. Beachten Sie, dass Sie für einige Vorlagen aufgrund von Platzbeschränkungen nicht den Namen anzeigen können — Sie haben lediglich die Möglichkeit, das Logo ein- oder auszublenden.

  • 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.

    Eine Kachel, die das Branding in einem Textelement anzeigt und eine Kachel, die das Branding in einem Bildelement anzeigt

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

  • 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 "Apps" und in der QuickInfo, aber 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".
  • Da die App mithilfe ihrer Kachel nur auf der Startseite gestartet werden kann, sollten Kachelupdates die Elemente der App betreffen, die über die jeweilige Startseite leicht zugänglich sind. Eine Nachrichten-App sollte beispielsweise nur die Artikel anzeigen, die der Benutzer nach dem Klicken auf die Kachel auf der Startseite der App leicht finden kann.

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.

Ablauf von Kachel- und Signalbenachrichtigungen

Der Inhalt der Kachel sollte nur solange angezeigt werden, wie er relevant ist. Legen Sie für alle Kachel- und Signalbenachrichtigungen eine für Ihre App sinnvolle Ablaufzeit fest. Standardmäßig laufen lokale und geplante Kachel- und Signalinhalte nie ab, und per Push oder über eine regelmäßige Benachrichtigung gesendete Kachel- und Signalinhalte laufen drei Tage nach dem Senden ab. Wenn eine Benachrichtigung abläuft, wird der Inhalt von der Kachel oder aus der Warteschlange entfernt und nicht mehr angezeigt.

Sie können ein bestimmtes Datum und eine Uhrzeit für den Ablauf des Benachrichtigungsinhalts festlegen. Eine explizite Ablaufzeit eignet sich besonders für Inhalte mit definierter Lebensdauer. Wenn Ihr Cloud-Dienst keine Benachrichtigungen mehr sendet, die App lange nicht ausgeführt wird oder der Benutzer die Netzwerkverbindung über einen längeren Zeitraum trennt, können Sie durch eine explizite Ablaufzeit außerdem sicherstellen, dass veraltete Inhalte trotz des Verbindungsstatus des Systems entfernt werden.

Während eines Börsenhandelstags können Sie z. B. die Ablaufzeit für eine Aktienpreisaktualisierung gegenüber dem Sendeintervall verdoppeln (z. B. eine Stunde nach dem Senden der Benachrichtigung, wenn Sie zu jeder halben Stunde Benachrichtigungen senden). Ein weiteres Beispiel wäre eine News-App, bei der festgestellt wird, dass ein Intervall von einem Tag für eine tägliche Kachelaktualisierung angemessen ist.

Wie Sie die Ablaufzeit festlegen, hängt von der Übermittlungsmethode ab. Bei Pushbenachrichtigungen und regelmäßigen Benachrichtigungen wird sie in den HTTP-Headern festgelegt, über die mit dem Cloud-Dienst kommuniziert wird, der die Benachrichtigungen liefert. Bei lokalen und geplanten Benachrichtigungen kann die Ablaufzeit im Rahmen des API-Aufrufs festgelegt werden.

Weitere Informationen finden Sie unter Anforderungs- und Antwortheader des Pushbenachrichtigungsdiensts, BadgeNotification.ExpirationTime, ScheduledTileNotification.ExpirationTime und TileNotification.ExpirationTime.

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 über die Einstellungen vornehmen. Durch seine Zustimmung erklärt der Benutzer, dass die von der App gelieferten Informationen wichtig für ihn sind. Ihre App muss auf diese Informationen ausgerichtet sein. Daher müssen Sie zunächst ü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

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. Anhand der Informationen in diesen Benachrichtigungen kann der Benutzer entscheiden, ob er die App startet, um z. B. eine neue E-Mail zu lesen oder einen Beitrag in einem sozialen Netzwerk zu kommentieren. Beim Sperrbildschirm bedeutet dies, 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.

Eine leere Anzeige ist besser als eine Statusanzeige, die sich nie ändert.

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.

Prüfliste zu den Anforderungen für den Windows Store

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

Für Designer
Kachelvorlagenkatalog
Übersicht über Kacheln und Kachelbenachrichtigungen
Übersicht über Signale
Übersicht über den Sperrbildschirm
Die Benachrichtigungswarteschlange
Auswählen einer Methode für die Übermittlung von Benachrichtigungen
Richtlinien für Sekundärkacheln
Für Entwickler (Windows-Runtime-Apps mit JavaScript und HTML)
Schnellstart: Senden eines Kachelupdates
Schnellstart: Senden eines Signalupdates
Schnellstart: Anzeigen von Benachrichtigungen auf dem Sperrbildschirm
Schnellstart: Erstellen einer Standardkachel im Manifest-Editor von Visual Studio
Planen einer Kachelbenachrichtigung
Einrichten regelmäßiger Benachrichtigungen für Kacheln
Verwendung der Benachrichtigungswarteschlange mit lokalen Benachrichtigungen
XML-Schema für Kacheln
Für Entwickler (Windows-Runtime-Apps mit C#/VB/C++ und XAML)
Schnellstart: Senden eines Kachelupdates
Schnellstart: Senden eines Signalupdates
Schnellstart: Anzeigen von Kachel- und Signalupdates auf dem Sperrbildschirm
Verwendung der Benachrichtigungswarteschlange mit lokalen Benachrichtigungen
Schnellstart: Erstellen einer Standardkachel im Manifest-Editor von Visual Studio
BackgroundExecutionManager.RequestAccessAsync
Beispiele
Beispiel für App-Kacheln und Signale
Beispiel für eine App auf dem Sperrbildschirm

 

 

Anzeigen:
© 2014 Microsoft