@sapallie , könntest du die Design-Mockups öffentlich zugänglich machen? Es sei denn, sie sollen an dieser Stelle nicht geteilt werden.

Ich arbeite derzeit an der XAML-Entwicklung und würde gerne so etwas sehen. Oder so etwas wie eine nette Scrolling-Nachrichtensteuerung.

Aus Sicht des Microsoft-Branding scheint ein standardisiertes Fehlerbanner schrecklich schief gehen zu können. Ich befürchte, dass Endbenutzer jeden Anwendungsfehler mit der Marke Microsoft in Verbindung bringen. Ich habe gerade den Vorschlag gelesen, und als erstes fiel mir ein, dass Memelords über das auffällige Todesbanner twittern.

@sapallie , könntest du die Design-Mockups öffentlich zugänglich machen? Es sei denn, sie sollen an dieser Stelle nicht geteilt werden.

Tut mir leid @adrientetar , ich kann sie noch nicht teilen. Die Designs sind vorerst nur Microsoft.

@sapallie , danke für diese phänomenale Feature-Idee! Ich bin Programmmanager für WinUI und freue mich, dies dem Team vorzustellen!

Ich wollte ein wenig über unseren Prozess schreiben, damit Sie wissen, wie wir von hier aus fortfahren werden. Ab sofort werde ich daran arbeiten, den Umfang/die Anforderungen dieses Vorschlags auf hoher Ebene und die Begründung für die Entwicklung zu verfeinern. Dann werde ich es dem Rest des WinUI-Teams vorstellen und wir werden darüber beraten, ob es mit unserer Roadmap (Nr. 717) übereinstimmt und ob wir denken, dass wir relativ bald darauf reagieren können. Wenn ja, werde ich genehmigt, um die Details herauszufinden und mit dem Schreiben von Spezifikationen zu beginnen, damit die Funktion für einen Entwickler bereit ist.

Hier sind ein paar Dinge, von denen ich bereits weiß, dass ich mir ein bisschen mehr Gedanken machen muss ...

• Visuelles Verhalten

Ist Ihr Vorschlag für ein Edge-to-Banner? Oder eine Benachrichtigungskachel wie bei Windows-Benachrichtigungen, aber im App-Fenster, z. B. in der Mitte, am unteren Rand oder in einer Ecke?

Tut mir leid @adrientetar , ich kann sie noch nicht teilen. Die Designs sind vorerst nur Microsoft.

Ich glaube nicht, dass ich diesen Vorschlag genehmigen könnte, ohne ein öffentliches Bild der Anfrage einzufügen, da das Repo _is_ Open Source ist und ein Close-Sourcing der visuellen Seite der Konversation den Prozess und die Erfahrung für unsere Community verwirren würde . Basierend auf den Antworten auf das Obige unternehme ich gerne einen Versuch, ein Modell für den Vorschlag zu entwerfen. Würden Sie dies vorziehen oder haben Sie einen Zeitplan für die Erteilung Ihrer Erlaubnis zur Veröffentlichung Ihres Designs? Ich liebe Ihr Mockup und würde es gerne in unser Brainstorming hier einbeziehen, damit wir die Diskussion nicht unnötigerweise in eine von Ihrer Absicht abweichende Richtung lenken. Lass es mich wissen, bitte! :erröten:

Das Banner macht Benutzer auf Fehler aufmerksam, die sie daran hindern, eine App/ein Feature zu verwenden

Das Banner kann bei nicht kritischen Fehlern geschlossen werden

Sehe ich diese Aussagen richtig so, dass Sie auch die Möglichkeit haben müssen, ein nicht zu schließendes Banner für kritische Fehler zu verwenden? Wenn ja, könnten Sie mir mehr über Ihr spezifisches App-Szenario für den Erhalt eines Banners/das Fortschreiten von einem nicht zu schließenden Banner erzählen? Müssen die Benutzer die App schließen, bis das Problem gelöst ist? Oder würden die Schaltflächen hierher kommen, um sie beispielsweise zur Seite Netzwerk- und Interneteinstellungen zu navigieren?

Nochmals vielen Dank und ich freue mich darauf, diese Idee zu verfeinern!

Fühlen Sie sich bitte alle ermutigt, Ihre Bedürfnisse, Entwürfe und Perspektiven zu diesem Gespräch beizutragen! :erröten:

Ich möchte sagen, dass es einige Vorschläge gibt, die alle etwas Ähnliches verlangen. Anstatt dies speziell zu einem Fehlerbanner zu machen, warum bringen Sie nicht einfach die In-App-Benachrichtigung aus dem Community Toolkit ein. Es könnte eine Symbol-Eigenschaft hinzugefügt werden, die ein Fehlersymbol oder ein Bestätigungssymbol usw. anzeigen würde.

@SavoySchuler – schön von dir zu hören. Ich habe versucht, alle Ihre Fragen zu beantworten, aber lassen Sie es mich bitte wissen, wenn Sie noch etwas brauchen.

Sehverhalten:
Idealerweise ähnelt das Banner einer Windows-Benachrichtigungskachel und wird entweder oben oder unten im App-Fenster angeheftet. Wo es angeheftet wird, hängt von den anderen visuellen Elementen in der App ab und davon, wo der Fokus liegt. Diese Entscheidung sollte von einem Designer getroffen werden.
Ich denke, das von @mdtauk gepostete GIF wäre ein guter Ausgangspunkt.

Entlassung:
Ich denke, es wäre sinnvoll, näher darauf einzugehen, was ich mit kritischen vs. nicht kritischen Fehlern meine:

• Kritische Fehler = App-Funktionalität ist aufgrund eines systemweiten Problems beeinträchtigt (z. B. Internetverbindung unterbrochen) – diese sollten mit den Systemeinstellungen verknüpft sein, wo der Benutzer das Problem möglicherweise beheben kann
• Nicht kritische Fehler = Einige der Funktionen sind beeinträchtigt oder ein einzelnes Feature funktioniert nicht, aber Benutzer können immer noch andere Dinge in der App tun
• Es wäre auch cool, eine rein informative Iteration des Banners einzuführen, die verwendet werden kann, um Benutzer darüber zu informieren, dass App-Updates oder neue Funktionen verfügbar sind.

Und ich denke, all diese sollten verworfen werden (ich habe das auch in der Vorschlagsbeschreibung aktualisiert).

Beispielbilder
Ich habe ein paar Änderungen an der Grafik vorgenommen und kann sie so teilen:

Diese Beispiele sind eine Iteration, bei der das gesamte Banner im Grunde eine große Schaltfläche ist. Benutzer können es verwerfen oder darauf klicken, um zu den Systemeinstellungen zu gelangen (kritischer Fehler), eine Webseite mit Details zu Feature-Fixes zu öffnen (Warnung 1), die App-Seite neu zu laden (Warnung 2) oder zum Microsoft Store zu gehen, um die zu aktualisieren App (informativ).
Es wäre möglich, dieses Konzept zu erweitern, um mehrere Schaltflächen innerhalb des Banners hinzuzufügen.

Ich mag diese Grafiken für das Banner wirklich. Ich würde den Text und das Symbol um 4 Pixel nach oben verschieben, sodass sie im weißen Bereich und nicht im weißen und farbigen Balken zentriert sind.

Einverstanden. Die geposteten Visuals sehen ganz nett aus.

Ich mag diese Grafiken für das Banner wirklich. Ich würde den Text und das Symbol um 4 Pixel nach oben verschieben, sodass sie im weißen Bereich und nicht im weißen und farbigen Balken zentriert sind.

Ich habe die Pixel nicht gezählt, aber es sieht so aus, als ob diese zentriert sind, wenn der Platz für diakritische Zeichen über der X-Höhe berücksichtigt wird.

@sapallie Haben Sie darüber nachgedacht, diese Steuerelemente automatisch oder programmgesteuert zu schließen?

Wenn Sie aufgefordert werden, offline zu sein/zu gehen, wäre es sinnvoll, eine solche Aufforderung programmgesteuert zu entfernen, wenn Sie wieder online sind. (Ich habe gesehen, dass Apps dies nicht tun, und es kann zu einer verwirrenden Erfahrung führen.)

In ähnlicher Weise kann die Anzeige unwesentlicher Nachrichten, die nicht auf unbestimmte Zeit angezeigt werden, unnötige Unordnung in der Benutzeroberfläche vermeiden und verhindern, dass Hauptbenutzer aus dem Fluss geraten müssen, sobald sie eine Nachricht gelesen haben, indem sie nicht gezwungen werden, die Benachrichtigung manuell zu schließen.

Mir ist bewusst, dass es bei einem solchen Steuerelement und diesen Verhaltensweisen möglicherweise zusätzliche Überlegungen zur Barrierefreiheit gibt, aber ich glaube, dass diese Möglichkeiten, das Steuerelement abzulehnen, unerlässlich sind.

Ich denke, es ist wichtig, darauf hinzuweisen, dass ein solches Steuerelement nicht für allgemeine Nachrichten innerhalb einer App gedacht ist. Es sei denn, das ist wirklich ein gewünschter Anwendungsfall.

Soll eine App mehrere Banner gleichzeitig anzeigen dürfen?
Wenn ja, wie werden sie angeordnet? Und kann die App das steuern?

Dies würde diejenigen zufrieden stellen, die nach einem Android-Toast-Stil in der App-Benachrichtigungssteuerung gefragt haben, es könnte möglicherweise auch für Validierungsszenarien nützlich sein, um Fehlertext anzuzeigen, wenn der Platz im Formular knapp ist.

Ich würde es auch so etwas wie StatusTip oder StatusNotification nennen , damit es nicht nur mit negativen Verwendungen in Verbindung gebracht wird.

Ich nehme an, das Design würde sich anpassen, indem die Platzierung auf der einfarbigen Leiste geändert wird, wenn sie am unteren Rand des Fensters platziert wird?

Es sollte wahrscheinlich eine Zeitüberschreitungseigenschaft haben und könnte sogar die Möglichkeit haben, eine ausstehende Nachricht anzuzeigen, wie einen Fortschrittsring und einen Text wie "Jetzt anmelden", bevor zu einer Bestätigung der Fehlermeldung gewechselt wird.

Ich mag diese Grafiken für das Banner wirklich. Ich würde den Text und das Symbol um 4 Pixel nach oben verschieben, sodass sie im weißen Bereich und nicht im weißen und farbigen Balken zentriert sind.

Ich habe die Pixel nicht gezählt, aber es sieht so aus, als ob diese zentriert sind, wenn der Platz für diakritische Zeichen über der X-Höhe berücksichtigt wird.

Ich denke, es war wahrscheinlicher, dass der Text vertikal in der Box zentriert war, ohne den farbigen Balken zu berücksichtigen

So könnte sich die Platzierung der farbigen Balken mit der Platzierung des Steuerelements ändern

@mrlacey Ja, die programmatische/automatische Entlassung, wenn das Banner nicht mehr relevant ist, ist ziemlich wichtig – ich habe es der Angebotsbeschreibung hinzugefügt.

Statusänderungen und Fehler: Dafür sollten die Banner verwendet werden. Keine allgemeine Botschaft – dem stimme ich zu.

Und ich denke, mehrere Banner sollten funktionieren. Sie sollten nur gestapelt werden.

@mdtauk Ich habe es in „Statusbanner“ umbenannt – danke für deine Vorschläge.

Für den Ladezustand – ich glaube nicht, dass das im Banner passieren sollte. Ladende Inhalte sollten in der App dort angezeigt werden, wo die Inhalte tatsächlich erscheinen würden.

Und wenn es darum geht, die Platzierung des farbigen Balkens zu ändern, wäre es großartig, dort die Flexibilität zu haben, je nachdem, wo das Fehlerbanner im App-Fenster platziert wird. 👍

Die Ausgaben Nr. 622 und Nr. 792 könnten ebenfalls von diesem Steuerelement abgedeckt werden, wenn es gebaut würde.

@sapallie Dein Hinweis zu kritischen Fehlerumständen ist interessant im Hinblick auf die vorgeschlagene Anleitung, dass Statusbanner den Benutzer auf eine Lösung hinweisen. Meine Intuition sagt, dass Sie möglicherweise auch eine API zum Deaktivieren oder zumindest vorübergehenden Abweisen benötigen?

Mir ist bewusst, dass es bei einem solchen Steuerelement und diesen Verhaltensweisen möglicherweise zusätzliche Überlegungen zur Barrierefreiheit gibt, aber ich glaube, dass diese Möglichkeiten, das Steuerelement abzulehnen, unerlässlich sind.

@mrlacey , tolle Legende! Glücklicherweise habe ich einen erheblichen Teil davon während der Berücksichtigung des zeitgesteuerten automatischen Schließens von TeachingTip durchgearbeitet, und obwohl einige Partnerschaften mit Teams erforderlich wären, die eigene Barrierefreiheitseinstellungen haben, glaube ich nicht, dass diese Funktion aufgrund von Bedenken hinsichtlich der Barrierefreiheit blockiert würde. +1 auf alle Ihre anderen Punkte!

Könnte es die Möglichkeit geben, einen HyperlinkButton hinzuzufügen, der eine Verknüpfung zu einer Lösung oder zu einer Einstellungsverknüpfung wie Networking herstellt?

Könnte es die Möglichkeit geben, einen HyperlinkButton hinzuzufügen, der eine Verknüpfung zu einer Lösung oder zu einer Einstellungsverknüpfung wie Networking herstellt?

Ich stellte mir den Subtext vor, der einen Hyperlink zu einer In-App- oder Einstellungs-App enthält (siehe Galeriecode der XAML-Steuerung von TeachingTip). Hast du an etwas Standardisierteres gedacht @mdtauk?

@SavoySchuler Content-Eigenschaft statt MessageText?

Ihr Hinweis zu kritischen Fehlerumständen ist interessant im Hinblick auf die vorgeschlagene Anleitung, dass Statusbanner den Benutzer auf eine Lösung hinweisen. Meine Intuition sagt, dass Sie möglicherweise auch eine API zum Deaktivieren oder zumindest vorübergehenden Abweisen benötigen?

Ja, vielleicht denke ich… Es tut definitiv nicht weh, es hinzuzufügen. Es fügt immerhin Flexibilität hinzu und wird wahrscheinlich für einige Anwendungsfälle sehr nützlich sein.

@mdtauk - Ja, ich meine sicherlich Inhaltseigenschaft!

@sapallie

Ihr Hinweis zu kritischen Fehlerumständen ist interessant im Hinblick auf die vorgeschlagene Anleitung, dass Statusbanner den Benutzer auf eine Lösung hinweisen. Meine Intuition sagt, dass Sie möglicherweise auch eine API zum Deaktivieren oder zumindest vorübergehenden Abweisen benötigen?

Ja, vielleicht denke ich… Es tut definitiv nicht weh, es hinzuzufügen. Es fügt immerhin Flexibilität hinzu und wird wahrscheinlich für einige Anwendungsfälle sehr nützlich sein.

Auf der einen Seite haben Sie ein nicht zu schließendes Popup, das die Benutzeroberfläche abdeckt (und möglicherweise einen eigenen szenariobasierten Fehler verursacht), und auf der anderen Seite haben Sie eine App-Warnung/einen kritischen Fehler, der nicht dauerhaft ist, was ebenfalls auftritt Meine Spidey-Sinne kribbeln.

Vielleicht würde ein In-UI + Edge-to-Edge-Banner (wie es von der Office-Suite verwendet wird, um über Updates zu benachrichtigen – siehe unten) die Anforderungen erfüllen, anstatt ein Popup im Stil von Over-UI + Tip-Stil, und gleichzeitig die Anforderungen erfüllen dauerhaften Platz in Ihrer Benutzeroberfläche gewährt?

@SavoySchuler Es könnte ein Verhalten auf dem Steuerelement geben, bei dem Kopfzeile und Inhalt in einer einzigen Zeile platziert werden, wenn die Breite des Steuerelements breit genug ist.

Mein früherer Vorschlag mit den unterschiedlichen Positionierungslayouts würde auch funktionieren, wenn das Steuerelement aus dem Rand eines anderen Steuerelements herausgleitet - nicht nur innerhalb des Fensters oder Bedienfelds.

Vielleicht würde ein In-UI + Edge-to-Edge-Banner (wie es von der Office-Suite verwendet wird, um über Updates zu benachrichtigen – siehe unten) die Anforderungen erfüllen, anstatt ein Popup im Stil von Over-UI + Tip-Stil, und gleichzeitig die Anforderungen erfüllen dauerhaften Platz in Ihrer Benutzeroberfläche gewährt?

Ja, das geht auch. 👍

Es scheint ideal zu sein, sowohl Inline- als auch Overlay-Optionen zu haben, da sich die Office-Suite im Nachhinein darauf verlassen kann, dass alle ihre Apps eine Multifunktionsleiste haben. @mdtauk Ich mag deinen Vorschlag, der darauf hindeutet, wie wir über das Verhalten beim Erscheinen / Verschwinden denken.

@all , kann mir jemand bestimmte Szenarien in Ihren realen Apps mitteilen, in denen Sie sich vorstellen, dass dieses Steuerelement verwendet wird? Insbesondere interessiere ich mich für Gedanken zum visuellen Eingang und zur Benutzerinteraktion, die erforderlich ist, um die Entlassung zu veranlassen? Decken die Anforderungen hier die wichtigsten Verhaltensweisen ab, die Sie von dieser Kontrolle benötigen?

@SavoySchuler In Anbetracht von Eingang und Ausgang könnte es von einer Kante hineingleiten, aber auch als schwebende Überlagerung animiert werden, wenn der Entwickler dies wünscht. Vom rechten Rand des Bildschirms auf Betriebssystemebene nach innen schieben – vom rechten Rand eines App-Fensters oder vom Rand eines Steuerelements oder UI-Elements nach außen.

Es gibt eine Schließen-Schaltfläche zum Schließen, aber bei Touch-Displays könnte auch die Möglichkeit funktionieren, sie in die umgekehrte Richtung von der Stelle zu schieben, an der sie auftaucht. Um Konsistenz zu gewährleisten, muss dies in das Steuerelement eingebaut werden.

Das Antippen des Steuerelements sollte wahrscheinlich eine Aktion auslösen, die der Nachrichtentext angeben würde.
Die Ausnahme wäre die Anzeige des Fortschritts einer Aktion, die nicht verworfen werden kann, bis sie mit einem Fehler abläuft oder erfolgreich abgeschlossen wird.

Animierte Beispiele

Eingeben, aktualisieren, beenden – YouTube-Link

Animieren - YouTube-Link

TeachingTip existiert und ist eine gute Möglichkeit, auf ein bestimmtes Steuerelement oder UI-Element abzuzielen, und gut, um ein neues Feature in einer App hervorzuheben. Es könnte technisch gesehen für die gleichen Zwecke wie dieses StatusBanner verwendet werden, daher müssen einige Gedanken in die semantische Verwendung von jedem von ihnen gehen und identifizieren, was jedes einzigartig macht.

Nachfolgend meine persönlichen Gedanken zur Unterscheidung zwischen Statusbanner und Unterrichtstipp

• Das Statusbanner _glaube_ sollte für tatsächlich umsetzbare Status ermutigt werden und sollte daher eine einzelne Aktion auslösen, wenn es angetippt wird.

  • Der Unterrichtstipp würde Aktionen als Schaltflächen oder Hyperlinks darstellen, die normalerweise für Informationen verwendet werden, die leicht verworfen werden können.

• Wenn sich eine App- oder Betriebssystembedingung ändert, die für die App erforderlich ist, sollte dies die Anzeige eines Statusbanners auslösen.

  • Der Lehrtipp würde keine kritischen Informationen liefern und nach dem Abweisen nicht erneut angezeigt werden, es sei denn, es wird etwas Neues hinzugefügt, das aufgerufen werden soll.

• Das Statusbanner sollte entweder bei der Anzeige bestehen bleiben, es sei denn, es wird mit der Schaltfläche „Schließen“ geschlossen, oder vielleicht ein Wischen, wenn es berührt wird. Mit Ausnahme des Abschlusses eines fortlaufenden Fortschrittsszenarios oder der Auflösung des Betriebssystemstatus (Netzwerk wird wiederhergestellt).

  • Der Unterrichtstipp würde möglicherweise eine Timeout-Funktion enthalten, würde nicht zufällig angezeigt, während die App läuft, sondern hauptsächlich beim App-Start oder beim Navigieren zu einer Seite/einem Bildschirm angezeigt.

• Status-Banner sollten in der OS-Shell einheitlich verwendet werden – es könnte eine Reihe von lokalisierten Standard-Bannern mit Inhalten, Symbolen, Farben als Aufzählung geben.

• Es könnte eine Betriebssystemlogik geben, um Statusbanner an App-Fenster anzuhängen.
  Wenn beispielsweise eine App versucht, auf das Netzwerk zuzugreifen, und es nicht verfügbar ist, könnte das Betriebssystem ein Standard-Statusbanner innerhalb des App-Fensters statt im Bildschirmbereich anzeigen oder es den Entwicklern überlassen, es zu implementieren.

  • Der Unterrichtstipp wäre anwendungsspezifisch und ohne definierten Standardinhalt und nur für den Entwickler.

@mdtauk , fantastische Arbeit an den Videos! 🎉 Sie sind überaus hilfreich, um diese Ideen zum Leben zu erwecken.

Die Notwendigkeit der Persistenz ist ein ausgezeichneter Punkt, und ich denke, die Entlassungsfunktion könnte auch durch Richtlinien gemildert werden, die vorschlagen, die Statusbenachrichtigungen dauerhaft in einem Benachrichtigungsfenster verfügbar zu machen, wenn sie kritisch sind, oder sie _möglicherweise_ in nicht-invasiven Intervallen wieder aufzutauchen, wenn die Probleme bestehen bleiben. Dies sind keine definitiven Behauptungen, sondern lediglich Überlegungen, die angestellt werden müssen, um sicherzustellen, dass diese Lösung in ihrer Szenariolösung angemessen umfassend ist.

Die Notwendigkeit, TeachingTip von dieser Funktion zu unterscheiden, ist genau richtig, und ich stimme Ihren Punkten zu. Dieses Steuerelement würde einem bestimmten Bedarf dienen, für dessen Lösung TeachingTip nicht entwickelt wurde, obwohl möglicherweise Möglichkeiten für einige gemeinsame Funktionen oder Code vorhanden sind.

Gibt es Stakeholder, deren Bedürfnisse nicht durch etwas wie das, was @mdtauk oben mitgeteilt hat, erfüllt werden würden?

Es scheint Unterschiede zwischen den im OP nachgebildeten Statusbannern und der Benachrichtigung in voller Breite zu geben, wie sie in Office (Bilder oben in früheren Kommentaren) oder Visual Studio (wie unten) zu sehen ist.

Aufgrund der Unterschiede zwischen den beiden frage ich mich, ob es sich um die gleiche Steuerung oder um separate Steuerungen handeln sollte.

Hier ist eine kurze Liste der Eigenschaften, die jeder benötigt. (Namen zum Beispiel nicht festgelegt, sondern auf Bedeutung schließen sollen)

Statusbanner

• _Symbol_
• Nachrichtentext
• Zusatztext (zweite Zeile)
• Typ (Kritisch, Warnung oder Information)
• Farbe
• Standort
• Animationsrichtung
• Tippen Sie auf Ereignis/Befehl
• Auszeit

Benachrichtigungen in voller Breite

• _Symbol (möglicherweise)_
• Nachrichtentext
• Linkstil (Schaltfläche oder Hyperlink)
• Links (Text und Tap Event/Command - mehrere)
• Auszeit

Nur die fett gedruckten Eigenschaften existieren in beiden. _Icon_ ist möglicherweise verwirrend, da für jeden Typ unterschiedliche Arten von Symbolen (in einem Kreis oder Umriss) benötigt werden.
Es müsste auch eine Eigenschaft vorhanden sein, die angibt, welcher Stil verwendet werden soll.

Für mich fühlt es sich so an, als gäbe es zu viele Unterschiede für ein einzelnes Steuerelement, und das Zusammenfügen all dieser Funktionen wäre verwirrend und kompliziert.
Ich denke, diese beiden Konzepte:

• ein ausblendbares Banner in voller Breite mit null oder mehr umsetzbaren Unterelementen
• ein Banner, das Statusänderungen anzeigen soll und das als einzelne Schaltfläche fungiert

bieten als separate Steuerelemente den größten Nutzen und die geringste Verwirrung.

Wie würden animierte Statusbanner die gleichzeitige Anzeige mehrerer Benachrichtigungen unterstützen?
Oder ist das jetzt aus dem Rahmen?

• Status-Banner sollten in der OS-Shell einheitlich verwendet werden – es könnte eine Reihe von lokalisierten Standard-Bannern mit Inhalten, Symbolen, Farben als Aufzählung geben.
• Es könnte eine Betriebssystemlogik geben, um Statusbanner an App-Fenster anzuhängen.
  Wenn beispielsweise eine App versucht, auf das Netzwerk zuzugreifen, und es nicht verfügbar ist, könnte das Betriebssystem ein Standard-Statusbanner innerhalb des App-Fensters statt im Bildschirmbereich anzeigen oder es den Entwicklern überlassen, es zu implementieren.

Diese Ebene der OS-Integration zeigt Ambitionen, die über ein einzelnes Steuerelement und über WinUI hinausgehen.

Wären „standardisierte lokalisierte Banner“ alles, was verfügbar wäre, oder wären diese zusätzlich zu der Möglichkeit, etwas vollständig Anpassbares zu haben?
Wenn Sie einige standardmäßig bereitstellen, welche werden das sein?
Ich hätte Bedenken, dass die Bereitstellung einer begrenzten Anzahl von Optionen das Potenzial einer solchen Kontrolle unnötig einschränken würde.

Dass das Betriebssystem Banner in der offenen App für systemweite Szenarien wie den Verlust der Netzwerkverbindung anzeigt, wirft für mich eine Reihe von Bedenken auf.

• Das Aktionszentrum bietet bereits eine Möglichkeit, systemweite Benachrichtigungen bereitzustellen.
• Wenn mehrere Fenster geöffnet sind, erscheint das Anzeigen von Bannern in jedem Fenster unnötig aufdringlich.
• Dass das System Benachrichtigungen (Banner) in einer App anzeigt, ist etwas, von dem ich erwarten würde, dass Entwickler es kontrollieren oder deaktivieren möchten.
• Wenn eine App nur gelegentlich eine Netzwerkverbindung benötigt, kann es für den Benutzer verwirrend oder ablenkend sein, eine Meldung über einen Verbindungsverlust zu sehen, wenn dies für seine aktuelle Tätigkeit nicht relevant ist.
• Dies würde Apps an bestimmte Versionen des Betriebssystems binden, um Updates oder das gewünschte Verhalten zu erhalten. Eine zukünftige Änderung der Betriebssystemfunktion kann eine App beschädigen oder auf unerwünschte Weise ändern.
• Updates und Fehlerbehebungen wären nur nach Veröffentlichungszeitplänen auf Betriebssystemebene verfügbar. Ein Teil des Grundes für die Existenz von WinUI besteht darin, diese Kopplung mit dem Betriebssystem und der App-Funktionalität zu unterbrechen.

• Eines der Ziele eines solchen Steuerelements, wie es hier beschrieben wird, besteht darin, Entwicklern die Implementierung zu erleichtern. Das Entfernen ihrer Fähigkeit zur Steuerung würde Probleme für Apps verursachen, bei denen bestimmte Szenarien auf benutzerdefinierte Weise behandelt werden müssen.

Ich habe gerade diese Ausgabe aus dem Twitter-Post über die animierten Mock-ups gefunden. Es scheint sich mit einem Großteil der Arbeit zu überschneiden, die wir mit dem InAppNotification -Steuerelement im Toolkit durchgeführt haben. Dazu gehören Dinge wie der Umgang mit mehreren Nachrichten.

Wir haben gelernt, dass dies zwar wie eine einfache Steuerung erscheint, aber ziemlich komplex ist. Es wäre jedoch schön, eine ganzheitliche Lösung zu haben, die in WinUI integriert werden kann, um all diese Fälle abzudecken. Dann können wir das Toolkit-Steuerelement verwerfen.

Rücksprache mit @ryandemopoulos , und ich möchte dieses anfängliche Gespräch ein wenig umgestalten, um mich auf das Problem (Notwendigkeit einer Fehler-Benutzeroberfläche) vor der Lösung (jedes bestimmte Teil/Teile der Fehler-Benutzeroberfläche) zu konzentrieren.

Zu diesem Zweck besteht mein erstes Ziel darin, die Szenarien und Anforderungen für die Fehler-UI zu sperren ( @sapallie , Ihr Szenario „Kritisch: WLAN-Konnektivität verloren“ ist ein perfekter Anfang). Von dort aus können wir zusammenarbeiten, um zu entscheiden, ob die Lösung eine Fehlerbenachrichtigungs-UI oder eine Reihe von Fehler-UI-Komponenten enthält. Daraus erweitern wir @mrlacey 's Aufschlüsselung der API-Ähnlichkeit (danke, dass Sie damit begonnen haben), um zu entscheiden, ob es genügend Gemeinsamkeiten für einen Ableitungsansatz im Vergleich zu unterschiedlichen Steuerelementen gibt, wenn es mehrere Ausgaben dieser Konversation gibt. Ich möchte nicht vorgreifen, aber das Argument von @mrlacey für unterschiedliche Lösungen _ist_ bereits knackig und das ist in Ordnung. Mein Fokus liegt darauf, hier für jeden das richtige Set an Lösungsteilen zu erstellen.

Könnten Sie mir also für jeden ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk und @mrlacey ), für den dieses Steuerelement besonders relevant ist, Folgendes hier oder per dm @ [email protected] zukommen lassen :

• App-Titel
• Szenariobeschreibung (Fehler, kritisch/unkritisch und Beschreibung, wie Sie es darstellen möchten)
• Screenshot des App-Bildschirms, auf dem der Fehler auftreten würde (falls verfügbar)

Ich habe die Ausgabe aktualisiert, um diesen problemorientierten Ansatz widerzuspiegeln, und ich habe die bisher beschriebenen Anforderungen, Szenarien und Lösungsmöglichkeiten katalogisiert.

@sapallie Ich habe versucht, so höflich wie möglich zu sein, um Ihre ursprüngliche Arbeit zu bewahren. Der Versionsverlauf ist unter dem Drop-down-Menü "Bearbeitet von..." oben in der Ausgabe einsehbar. Bitte lassen Sie mich wissen, wenn ich etwas nicht richtig erfasst habe.

Ich habe dies dem WinUI-Team vorgestellt und wir glauben, dass die hier definierte Funktionalität in der Lage wäre, nicht nur Fehlermeldungen, sondern langlebige App-weite Statusmeldungen als Ganzes zu liefern. Dazu gehören neben fehlerspezifischen Szenarien auch Statusmeldungen der Art „Update verfügbar“ und „Sicherung abgeschlossen“.

Ich habe die Ausgabe aktualisiert, um diesen ganzheitlicheren Ansatz widerzuspiegeln. Ich hoffe, die Anforderungen und Szenarien in den kommenden Wochen fertigstellen zu können, damit wir die erforderlichen UI-Ausgabeelemente zum Anzeigen dieser Nachrichten untersuchen können.

Ich formuliere meine Anfrage oben noch einmal. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk und @mrlacey , für Status-/Fehlermeldungen, die Sie in Ihren Anwendungen anzeigen möchten, könnten Sie mir hier oder unter [email protected] Folgendes zur Verfügung stellen:

• App-Titel
• Szenariobeschreibung (Statusmeldung, kritisch/unkritisch und Beschreibung, wie Sie es darstellen möchten)
• Screenshot des App-Bildschirms, auf dem der Fehler auftreten würde (falls verfügbar)

Es ist erwähnenswert, dass Popup-Dialoge nach Möglichkeit vermieden werden sollten. Das Web ist überall voll von Popup-Eingabeaufforderungen, die den Fluss unterbrechen und versuchen, Ihre Aufmerksamkeit zu erregen. Zum Beispiel denke ich, dass ein leerer Status ( Beispiel ) bevorzugt werden sollte, zB wenn etwas nicht in ein Steuerelement geladen werden konnte.

In Bezug auf die von @mdtauk geposteten Visuals, brauchen wir wirklich Popups, die von allen vier Rändern des Bildschirms/der App angezeigt werden? Der Zweck von WinUI sollte darin bestehen, die Position und das Aussehen solcher Elemente zu standardisieren, damit alle Apps dasselbe verwenden, und in dieser Hinsicht ist Android Snackbar eine offensichtliche Referenz. Eine andere Sache, die bei Snackbar zu beachten ist, ist, dass Fehler nicht mit einer leuchtend roten Farbe oder ähnlichem angezeigt werden, sie hat ein nüchternes Erscheinungsbild, was meiner Meinung nach wiederum vorteilhaft ist, um den Benutzer nicht zu sehr von dem abzulenken, was er tut.

Wir benötigen auch eine Anleitung, wann dieses Popup beispielsweise anstelle eines Dialogfelds verwendet werden soll, da es sonst nur zu einer Fragmentierung kommt (verschiedene Apps verwenden die Messaging-Steuerelemente auf unterschiedliche Weise).

Flyouts haben ein Platzierungskonzept, dieses Steuerelement könnte dasselbe tun. Erscheint am inneren Rand eines Container-Controls, sei es ein Page- oder Tab-Content usw.

@adrientetar Nicht jede App ist gleich, also gibt es zwar einen Standardwert für dieses Steuerelement, aber es muss eine Möglichkeit für Entwickler geben, diesen Speicherort zu ändern, ohne das Steuerelement neu erstellen oder neu entwickeln zu müssen.

Office verwendet den Platz unterhalb der Multifunktionsleiste. Edge verwendet den unteren Bildschirmrand. Nur Windows selbst könnte es an die Ränder der Shell oder des Bildschirms anhängen, und es gibt wahrscheinlich einen guten Grund, Apps daran zu hindern, Warnungen auf Systemebene nachzuahmen.

Außerdem hat jeder Entwickler die Möglichkeit, seine eigenen Warnsteuerungen neu zu gestalten, daher muss es in dieser Phase so flexibel wie möglich sein, und dann wird das Shell-Team ein gewisses Mitspracherecht darüber haben, welche Einschränkungen in die Verwendung der Steuerung einfließen.

Das Your Phone-Team verfügt über eine dieser Arten von Steuerelementen, also könnten Sie sie vielleicht fragen, auf welche Probleme sie gestoßen sind, und sie davon überzeugen, zur Verwendung des WinUI-Steuerelements überzugehen, wenn es fertig und enthalten ist?

Dropbox verwendet auch Snackbar in seinem Designsystem (scrollen Sie nach unten, vorletzte Bildreihe).

Kürzlich habe ich ein paar weitere Beispiele für langlebige, App-weite Statusmeldungen entdeckt:

(Meldung „Aufzeichnung gestartet“ in Teams)

("versucht, sich mit dem Spielkoordinator zu verbinden" in Dota 2)

Tut mir leid, dass diese klein sind – das erste Bild wurde von meinem Desktop mit einem Ultrawide-Monitor aufgenommen. :)

Einige Dropbox-Snackbars enthalten unten einen Fortschrittsbalken. Soll das hier aufgenommen werden? Es kann zB für Dinge wie Upload, Download, Update, Sync-Fortschritt sinnvoll sein. Es ist imo kein Muss, aber könnte oder sollte es vielleicht?

Sollen diese gerundet werden? Oder Nein?

Ja, ich denke, der Hauptunterschied hier zum Unterrichtstipp besteht darin, dass Apps ihren Messaging-Bereich koordinieren möchten und möglicherweise mehrere Fehler-/Statusaktualisierungen gleichzeitig (oder nacheinander) anzeigen.

Ich denke, idealerweise ist dies ein Steuerelement, das der Entwickler konfiguriert und in seiner App platziert und dann auch Nachrichten weiterleitet (von denen ich mir vorstellen kann, dass sie eine Art Typ haben, um anzugeben, ob es sich um einen Fehler, Status, eine Warnung oder eine andere allgemeine Nachricht handelt).

Sowohl im Banner- als auch im Popup-Fall habe ich Apps gesehen, die möglicherweise mehrere Nachrichten enthalten. Manchmal stapeln sie die Banner, die dann die UI-Immobilien dominieren, also wäre es schön, wenn diese Lösung dies vermeiden würde (obwohl nichts einen Entwickler daran hindern würde, mehrere Instanzen des Steuerelements zu verwenden, um dieses Verhalten immer noch neu zu erstellen).

Ich bin überrascht, dass wir VS Code auch nicht aufgerufen haben, da sie unten rechts ihre stapelbaren Popup-Benachrichtigungsfelder haben, auf denen sich auch zusätzliche Aktionsschaltflächen befinden (um beispielsweise zu den Einstellungen zu springen).

VS-Code-Beispiel-Screenshot:

Sie haben verschiedene Arten von Symbolen, die oben links angezeigt werden, anpassbare Schaltflächenaktionen und die Möglichkeit, das „Zahnrad“-Symbol zu haben, um Einstellungen zu den Benachrichtigungen pro Erweiterung zu konfigurieren, in ihrem Fall.

Ich habe gerade diesen Screenshot von Cortana gesehen ...

Die MessageBar von Office UI Fabric sieht toll aus, IMO:

Mir ist aufgefallen, dass Samsung Notes für Windows 10 Benachrichtigungstoasts verwendet, um zu erklären, dass eine Notiz verworfen wurde, weil nichts darin war, was so ärgerlich war

Hallo allerseits! Ich bin Programmmanager für WinUI und nehme diesen Vorschlag von @SavoySchuler wieder auf. In diesem Thread gab es bereits viele großartige Diskussionen und den Austausch von Ideen. Vielen Dank für all Ihre Vorschläge!

Da hier seit einigen Monaten keine Aktivität mehr stattgefunden hat, wollte ich mich noch einmal bei allen melden und wiederholen, wo wir uns derzeit befinden.

Als Zusammenfassung unseres aktuellen Umfangs oben im Angebot:

• Die Benachrichtigung dient dazu , den Benutzer auf wesentliche Informationen bezüglich der Anwendung als Ganzes aufmerksam zu machen
• Unterstützt benutzerdefinierte Inhalte und Stile
• Kann automatisch und programmgesteuert verworfen werden
• Die Benachrichtigung sollte vom Benutzer verworfen werden können
• Sollte mehrere Benachrichtigungen unterstützen, die je nach Spezifikation der App gestapelt werden können
• Sollte auf App-Größenänderungen und UI-Änderungen reagieren
• Die Benachrichtigung dient nicht zum Anzeigen systemweiter Benachrichtigungen

Bitte zögern Sie nicht zu kommentieren und lassen Sie mich wissen, wenn ich etwas in meiner Scope-Zusammenfassung übersehen habe oder wenn Sie nicht einverstanden sind. Ich möchte sicher sein, dass wir alle auf derselben Seite sind, bevor wir weitermachen 😊

Nachdem wir nun den Umfang definiert haben, müssen noch einige spezifische Szenarien und Benutzererfahrungen definiert werden. Ich hoffe, dass die Definition dieser Erfahrungen dazu beitragen wird, die UI-Angebote für die Steuerung zu lenken. Was sind Ihre Gedanken für Ihre Szenarien?
CC: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

Die Erfahrungen sind:

• Wie die Benachrichtigung die Ansicht verlässt
  
  
  
  • Der Benutzer verwirft die Benachrichtigung manuell
  
  
  • Die Benachrichtigung läuft automatisch ab und schließt sich selbst
  
  
  • Die Benachrichtigung verschwindet erst, nachdem der Benutzer eine Aktion durchgeführt hat, die sich darauf bezieht, warum die Benachrichtigung überhaupt erschienen ist
    
    
    
    
    
    • Das heißt, nach Erhalt einer Benachrichtigung, dass die Internetverbindung getrennt wurde, verschwindet die Benachrichtigung nur, wenn die Internetverbindung getrennt wird
    
    
    
  
  
  • Andere?
  
  
• Wie der Benutzer auf die Benachrichtigung reagieren wird
  
  
  
  • Ergreifen Sie sofort Maßnahmen im Zusammenhang mit der Benachrichtigung
  
  
  • Verschieben Sie ihre Aktion im Zusammenhang mit der Benachrichtigung auf einen späteren Zeitpunkt
  
  
  • Ignorieren und/oder ignorieren Sie die Benachrichtigung vollständig
  
  
  • Andere?
  
  
• Wann die Benachrichtigung erscheint
  
  
  
  • Beim App-Start
  
  
  • Programmgesteuert aus dem App-Status
  
  
  • Nachdem ein Benutzer eine Aktion ausführt (z. B. die Entscheidung, seine Dokumente zu sichern)
  
  
  • Andere?
  
  
• Wenn es möglich ist, dass mehrere Benachrichtigungen gleichzeitig angezeigt werden, und warum

Nochmals vielen Dank für all Ihre Gedanken und ich freue mich darauf, dies ans Licht zu bringen!

Ich bin froh zu sehen, dass dieser Vorschlag nicht vergessen wurde @gabbybilka und danke, dass du ihn angenommen hast!

Wenn es überhaupt möglich ist, können Sie sich an diejenigen wenden, die an Erstanbieter-Apps arbeiten, die diese Art von Benachrichtigungs-UIs enthalten, um eine Liste der Anforderungen zu erstellen, damit sie von ihrer benutzerdefinierten Lösung zu einem nativen WinUI-Steuerelement wechseln können. Ihre Bedürfnisse, kombiniert mit den Wünschen und Bedürfnissen der Community, sollten genug für eine V1 dieser Kontrolle abdecken.

@chigy wäre jemand, mit dem man über endgültige Designspezifikationen sprechen könnte, da sie mit den Fluent Design-Teams zusammenarbeitet.

Microsoft sollte hier mit gutem Beispiel vorangehen, wenn andere dazu animiert werden sollen, ein konsistentes WinUI-Control zu verwenden.

• Cortana
• Groove-Musik
• Film und Fernsehen
• Dein Telefon

Das sind die Apps, die mir in den Sinn kommen.

@gabbybilka Wir haben auch die Kontrolle im Windows Community Toolkit , daher freuen wir uns, jederzeit mit Ihnen darüber zu sprechen. Es wäre wirklich großartig, hier einen Upgrade-Pfad für unsere Benutzer zu haben und ihn vom Toolkit zu WinUI zu migrieren.

Ich denke, nach Ihrer anfänglichen Zusammenfassung hat das die meisten Dinge abgedeckt, aber könnte es gut sein, etwas darüber zu sagen, dass es auch optionale, umsetzbare Schaltflächen gibt? Oder wären das immer nur benutzerdefinierte Inhalte?

Follow-up aus dem Toolkit mit etwas Geschichte der Steuerung aus dem Toolkit (es ist schon eine Weile her):

• Ursprüngliches Problem
• Erste PR-Rezension
• GitHub-Verlauf – nicht sicher, wie Sie die vollständige Liste auf einer Seite abrufen können, also scrollen Sie nach unten und klicken Sie weiter auf „Älter“.

Die Stile im Toolkit sind den ursprünglichen Benachrichtigungsstilen von Microsoft Edge und VS Code nachempfunden (die beide seitdem aktualisiert wurden). Aber wie gezeigt, ist es flexibel und kann mit neuen Vorlagen erstellt werden und würde sowohl für eine Statusleisten-Warnung im Office-Stil auf oberster Ebene als auch für eine allgemeine Benachrichtigung im Popup-Stil funktionieren.

Hallo wieder! Als Update dazu habe ich diesen Vorschlag kürzlich erneut an das Team weitergeleitet und grünes Licht erhalten, um diese Funktion weiter zu definieren.

Für die zuvor beschriebenen Szenarien möchten wir mit der Erstellung eines Steuerelements fortfahren, das derzeit den Titel „ InformationBar “ (kurz „InfoBar“) trägt, um langlebige, anwendungsweite, wichtige Statusmeldungen darzustellen. Das anfängliche visuelle Designdenken ist von der MessageBar von FluentUI und davon inspiriert, wie Teams ihre Nachrichten „Now Recording“ und „Internet Disconnected“ anzeigen.
Insbesondere einschließlich eines Symbols, eines Titels, eines flexiblen Nachrichtenbereichs und einer Schaltfläche zum Schließen als primäre, minimale visuelle Komponenten in einem Container, der standardmäßig auf die Breite des Inhaltsbereichs passt, in dem er sich befindet. Wie zuvor festgelegt, kann die Infoleiste über geschlossen werden der Benutzer oder programmgesteuert, wenn die App-Funktionalität, die den Status beeinflusst, behoben ist, dh die Internetverbindung wiederhergestellt ist, ohne Intro-/Exit-Animationen.

Teams (jetzt Aufzeichnung)

Office (Kompatibilitätsmodus)

Teams (kein Internet)

Wenn sich die API zu kristallisieren beginnt, werde ich beginnen, die Diskussion auf die Spezifikation zu lenken. In der Zwischenzeit können Sie gerne weiterhin Ihre Szenarien teilen, in denen Sie eine InfoBar verwenden würden und welche Funktionen Sie benötigen 😊

Zu Beginn der Diskussion haben @mrlacey und andere das Potenzial angesprochen, zwei separate Steuerelemente zu haben, die die erwähnten Szenarien abdecken könnten.

Ich denke, diese beiden Konzepte:

• ein ausblendbares Banner in voller Breite mit null oder mehr umsetzbaren Unterelementen
• ein Banner, das Statusänderungen anzeigen soll und das als einzelne Schaltfläche fungiert

bieten als separate Steuerelemente den größten Nutzen und die geringste Verwirrung.

Ich erkenne an, dass der visuelle Stil und die Komponenten von InfoBar möglicherweise nicht für einige der zuvor geteilten Anwendungsfälle geeignet sind. Wenn Ihre spezifischen App-Szenarien und Funktionen einen anderen visuellen Stil erfordern, können Sie diese Situationen gerne weiterhin in diesem Thread teilen.

Nochmals vielen Dank an alle!

Das Steuerelement sollte so gestaltet sein, dass es gut mit Vorlagen und Stilen funktioniert – damit es an die Anforderungen angepasst werden kann, während alle Verhaltensweisen Eigenschaften des Steuerelements sind.
Animieren oder nicht animieren.
Schließen-Schaltfläche anzeigen oder ausblenden.
Position.
Symbol anzeigen oder nicht.

etc

Ich erkenne an, dass der visuelle Stil und die Komponenten von InfoBar möglicherweise nicht für einige der zuvor geteilten Anwendungsfälle geeignet sind. Wenn Ihre spezifischen App-Szenarien und Funktionen einen anderen visuellen Stil erfordern, können Sie diese Situationen gerne weiterhin in diesem Thread teilen.

Nochmals vielen Dank an alle!

Toll, dass es voran geht. Dieser visuelle Stil, wie er gezeigt wird, lässt viele Wünsche offen, bis zu dem Punkt, an dem ich die App nicht mehr verwenden möchte.

Designs, die @mdtauk gepostet hat, oder die Cortana-Screenshots oben wären viel besser. Das Design von Apps muss vorankommen und darf nicht von Programmen zurückgehalten werden.

Würde/könnte dies auch als abschaltbare CommandBar fungieren, wie sie beim Präsentieren/Desktop-Sharing verwendet wird? Z.B

Ich weiß, dass es das Overlay nicht über alles unterstützen würde, aber in Bezug auf das Fixieren seiner Breite und das Einfügen in eine Overlay-Ebene einer App könnte ich sehen, dass die Überschneidung in Design / Funktionalität in dieser Richtung ähnlich ist.

@mdtauk

Das Steuerelement sollte so gestaltet sein, dass es gut mit Vorlagen und Stilen funktioniert – damit es an die Anforderungen angepasst werden kann, während alle Verhaltensweisen Eigenschaften des Steuerelements sind.
Animieren oder nicht animieren.
Schließen-Schaltfläche anzeigen oder ausblenden.
Position.
Symbol anzeigen oder nicht.

@shaheedmalik

Toll, dass es voran geht. Dieser visuelle Stil, wie er gezeigt wird, lässt viele Wünsche offen, bis zu dem Punkt, an dem ich die App nicht mehr verwenden möchte.

Designs, die @mdtauk gepostet hat, oder die Cortana-Screenshots oben wären viel besser. Das Design von Apps muss vorankommen und darf nicht von Programmen zurückgehalten werden.

Danke für dein Feedback dort! Ich stimme zu, dass das Steuerelement für dieses grundlegende Verhalten und die Anpassbarkeit im Fluent Design-System flexibel genug sein sollte. Die von mir geteilten Visuals waren hauptsächlich Referenzen von zuvor implementierten Beispielen.
Wir werden weiterhin versuchen, das Gleichgewicht zwischen dem Überladen eines einzelnen Steuerelements mit zu vielen Funktionen zu finden und gleichzeitig sicherzustellen, dass es anpassbar und nützlich genug für die verschiedenen langlebigen App-weiten Statusmeldungsszenarien ist.

Würde/könnte dies auch als abschaltbare CommandBar fungieren, wie sie beim Präsentieren/Desktop-Sharing verwendet wird? Z.B

@michael-hawker

Ich denke, dies ist ein interessantes Szenario, das noch nicht im Thread angesprochen wurde und möglicherweise von diesem Steuerelement unterstützt werden könnte. Danke, dass Sie uns darauf aufmerksam gemacht haben! In Bezug auf den Umfang scheint dies ein Szenario mit niedrigerer Priorität zu sein, aber ich stimme zu, dass das Design/die Funktionalität außerhalb der Overlay-Priorisierung ähnlich ist.

Gibt es ein Update zu diesem Thema? Wir planen derzeit eine Benutzeroberfläche, um den Status von Dateivorgängen in Files UWP anzuzeigen, das Design, zu dem wir tendieren, kann von einer solchen hier vorgeschlagenen Funktion profitieren.

Hallo @yaichenbaum , danke fürs Einchecken! Als Update zu diesem Vorschlag freue ich mich, das Spezifikationsdokument zu teilen, das wir zu entwerfen beginnen.

Als Zusammenfassung dessen, was bisher definiert wurde, haben wir uns dafür entschieden, ein einzelnes Steuerelement mit zwei visuellen Modi zu erstellen, "Bar" und "Toast" oder "Card". Unsere aktuellen Bemühungen liegen in der Definition und dem Prototyping des "Bar"-Modus. Die Komponenten dieser beiden Modi sind gleich und sollen sich nur im visuellen Layout unterscheiden. Da es mehrere visuelle Modi geben wird, halte ich dieses Steuerelement derzeit für StatusBanner anstelle von InformationBar, um nicht auf den einzelnen "Balken"-Stil beschränkt zu sein, aber fühlen Sie sich frei, Ihre Ideen für die Benennung zu teilen 😊

Die Hauptbestandteile des StatusBanners von links nach rechts im Layout sind:

• Statusfarbe
• Symbol
• Titel
• Nachricht
• Aktionsknopf
• Schließen-Schaltfläche

Diese Eigenschaften sind optional und benutzerdefinierter Inhalt über die Eigenschaft „Content“ ist weiterhin eine Option.

Darüber hinaus planen wir, verschiedene Bannertypen zu definieren, die ein Entwickler festlegen kann und die je nach Status voreingestellte Symbol- und Farbkombinationen haben. Dies kann die Auswahl des richtigen Symbols oder der richtigen Bannerfarbe basierend auf der Wichtigkeit der Benachrichtigung vereinfachen und für eine gewisse Konsistenz zwischen Anwendungen sorgen. Das Anpassen von Icon oder BannerColor wird ebenfalls unterstützt.

Papierprototyp des StatusBanners im "Bar"-Modus ohne Aktionsschaltfläche oder benutzerdefinierte Schließschaltfläche.

Das aktuelle Design der StatusBanner-Leistenlayouts wurde stark von @mdtauks Designs für die Statuskarte inspiriert, danke!

Wenn Sie Feedback zum aktuellen Stand der Spezifikation geben möchten, können Sie dies gerne in dieser Ausgabe kommentieren. Unsere nächsten Schritte bestehen darin, die Designs und Code-Snippets zu festigen (und zu erweitern, um mehr Anwendungsfälle abzudecken) und Funktionen wie Stapeln und Nachrichtenumbruch zu definieren. Vielen Dank an alle!

@yaichenbaum in der Zwischenzeit gibt es die InAppNotification -Steuerung des Toolkits.

@gabbybilka Danke für das Update, eine wichtige Funktion, die ich für meinen Anwendungsfall benötige, ist die Möglichkeit, mehrere Statusmeldungen gleichzeitig anzuzeigen, genau wie @hawkerm weiter oben in diesem Thread geteilt hat. Es ist ein Plus, dass die Steuerung die Platzierung mehrerer Statusmeldungen handhaben kann.

@yaichenbaum in der Zwischenzeit gibt es die InAppNotification -Steuerung des Toolkits.

@hawkerm Ich habe mir InAppNotification nicht viel angesehen, aber ich würde lieber auf die WinUI-Version warten, anstatt auf das neue Steuerelement umzuschalten, wenn es fertig ist.

Hallo, alle miteinander!
Entschuldigung für den Zeitmangel zwischen dem letzten Update und jetzt, wir haben hart daran gearbeitet, diese Steuerung zu definieren 😊
Vielleicht haben Sie vor ein paar Wochen gesehen, wie der Prototyp von @chenss3 im Repo zusammengeführt wurde, wir sind wirklich gespannt darauf, dass dies zum Leben erweckt wird! In diesem Stadium sind wir daran interessiert, mit allen Verbrauchern dieser Steuerung in Kontakt zu treten, die daran interessiert sind, Prototypen zu entwickeln und diese in ihren Anwendungen zu verwenden. Bitte wenden Sie sich an uns und teilen Sie uns mit, welche Anwendung Sie entwickeln, die Szenarien, in denen Sie dieses Steuerelement verwenden, ob Sie Hilfe beim Einstieg benötigen, und Ihr Feedback zur Verwendung des Prototyps.

Da wir begonnen haben, Implementierungsdetails für eine Popup-Version dieses Steuerelements mit Unterstützung für das Positionieren und Stapeln mehrerer Benachrichtigungen herauszufinden, haben wir uns entschieden, in naher Zukunft weiter an einer Inline-Version zu arbeiten . Wir hören Ihr Feedback dazu, dass für einige Ihrer Szenarien Popup-Funktionen erforderlich sind, und werden uns weiterhin in diese Richtung bewegen! In der Zwischenzeit entwickeln wir unsere nächste Version des Prototyps, die den untenstehenden Mockups mehr ähnelt.

Bitte sehen Sie sich die Spezifikation an, wenn Sie ein paar weitere Beispiele sehen möchten:

Vielen Dank an alle und ich freue mich darauf, von Ihnen zu hören!

Ist dies nur in WinUI 3 verfügbar oder geht es in eine Vorabversion von WinUI 2?

@kmgallahan WinUI 2 Pre-Release, noch nicht ganz sicher über die genaue Schiffsversion, da wir etwas mehr Feedback von der Community und den Kunden zu den Prototyp- und Vorschauversionen erhalten möchten.

Um das frühe Feedback zu maximieren, würde ich empfehlen, es so einfach wie möglich zu machen, solche Prototypen auszuprobieren. Schieben Sie sie vielleicht in Vorabversionen mit Haftungsausschlüssen oder stellen Sie Entwicklungs-/Betaversionen bereit.

Die Notwendigkeit, einen Dev-Zweig von WinUI zu erstellen, um Prototypen auszuprobieren, sorgt für ein gutes Stück Reibung, insbesondere wenn Sie hauptsächlich ein WinUI-Verbraucher und kein Mitwirkender sind (zumindest zur Codebasis).

Einverstanden, sobald sich der Prototyp in einem soliden Zustand befindet (ähnlich wie die gezeigten Mockups aussieht und verschiedene Eingabeoptionen unterstützt), möchten wir ihn in die 2.5-Vorschau stellen. Wären Sie in der Lage / interessiert, es zu diesem Zeitpunkt auszuprobieren?

Ich bin daran interessiert, es jetzt auszuprobieren, ich ziehe es einfach vor, von NuGet zu konsumieren, anstatt meinem Build ein riesiges Projekt wie WinUI hinzuzufügen.

Im Moment warte ich auf alles, was es in eine Vorschau schafft.

Hallo wieder! Ein paar Aktualisierungen:

• Die Spezifikation wurde weiterhin überprüft und iteriert. Bitte schauen Sie sich diese PR an und hinterlassen Sie Kommentare. Eine bemerkenswerte Änderung ist das Hinzufügen einer generischen ActionButton-Eigenschaft, die Ihren eigenen Inhalt aufnimmt, der von ButtonBase erbt.

  • Eine Inkonsistenz in den aktuellen Mockups, auf die ich hinweisen möchte, ist die Position dieses ActionButtons. In der Spezifikation wird die Aktionsschaltfläche derzeit rechtsbündig direkt links neben der Schließen-Schaltfläche angezeigt, die tatsächliche Position befindet sich jedoch direkt rechts neben der Nachricht. Das in meinem vorherigen Kommentar und unten gezeigte Bild ist der richtige Ort. Verbesserte Mockups werden im Laufe der Entwicklung weiterhin aktualisiert und der Spezifikation hinzugefügt 😊

• @teaP hat mit der Implementierung der nativen Version dieses Steuerelements begonnen, während es sich in Richtung einer Vorabversion von WinUI 2.5 bewegt. Danke!

Wenn Sie sich als potenzieller Benutzer dieses Steuerelements sehen, können Sie wie zuvor gerne Kommentare zu der von Ihnen entwickelten Anwendung und den Szenarien abgeben, in denen Sie die Infoleiste verwenden würden. Vielen Dank an alle!

Hallo wieder! Nur um hervorzuheben, @teaP hat kürzlich den Pull-Request Nr. 3325 für die InfoBar geöffnet, wenn Sie ihn sich ansehen möchten 😊

Warum heißt das InfoBar? Info ist nur eine kleine Klasse von Informationen, die es enthalten kann. Es unterstützt auch Fehler und Warnungen sowie darauf basierende Aktionen. Bar beschränkt auch künstlich die "Form" des Steuerelements. Neben einer Bar gibt es noch einige andere Anwendungsfälle dafür.

NotificationView oder MessageView usw. wären meiner Meinung nach bessere Namen.

Warum heißt das InfoBar? Info ist nur eine kleine Klasse von Informationen, die es enthalten kann. Es unterstützt auch Fehler und Warnungen sowie darauf basierende Aktionen. Bar beschränkt auch künstlich die "Form" des Steuerelements. Neben einer Bar gibt es noch einige andere Anwendungsfälle dafür.

NotificationView oder MessageView usw. wären meiner Meinung nach bessere Namen.

Es wurde ursprünglich als StatusBanner vorgeschlagen
Dann wurde es in InformationBar / InfoBar geändert

Die FluentUI-Version dieses Steuerelements heißt MessageBar

Danke für die Zusammenfassung. Der Name macht für mich immer noch nicht viel Sinn. Das aktuelle Steuerelement ist als Benachrichtigung ausgelegt. Allgemeiner sollte es eine „Nachricht“ sein, damit sie auch Hilfe-/Lehrszenarien unterstützen kann. Um die verschiedenen Konzepte zu verallgemeinern, hier ist ein besseres Design für die Steuerelemente:

1. ~ MessageView ~ oder Tip : Ein Steuerelement zum Anzeigen von Status-, Hinweis- oder Unterrichtsinformationen für den Benutzer mit einer optionalen Aktion, einem Titel, einer Glyphe, einem Bild und Schaltflächen. Dies kann überall platziert werden und ist kein Popup. Es würde auch verschiedene Layouts unterstützen.

2. TeachingTip : Ein Flyout/Popup, das eine MessageView hostet.

   • Gehosteter Tipp

3. NotificationBar oder StatusTip : App-weite Benachrichtigung in einem „Balken“-Format oben in der Anwendung oder Ansicht.

   • Gehosteter Tipp

4. ToolTip : Kann jetzt auch den Tipp hosten, der Unterstützung für Aktionen und Bilder usw. bietet.

   • Gehosteter Tipp

Wir müssen wirklich in allgemeinen Begriffen denken und hochrangige Konzepte in denselben Steuerelementen kombinieren. Andernfalls werden wir viele sehr spezialisierte Steuerelemente mit ähnlichen, aber unterschiedlichen Eigenschaften erstellen.

Dachte an einen perfekten Namen für ein allgemeines 'MessageView'-Steuerelement: Nennen Sie es einen 'Tipp'. ToolTip könnte es auch hosten. Entsprechend aktualisiert.

Hier ist ein weiteres reales Beispiel einer Benachrichtigungsleiste am oberen Rand einiger Eingabefelder. Die aktuelle Steuerung wäre für dieses Szenario nützlich:

Hier ist ein weiteres reales Beispiel einer Benachrichtigungsleiste am oberen Rand einiger Eingabefelder. Die aktuelle Steuerung wäre für dieses Szenario nützlich:

TextBoxen erhalten Validierungsstatus, die einiges davon abdecken könnten, aber hier ist, wie ich die verschiedenen Steuerelemente ansehe ...

• Tooltip für ein einzelnes Element, das der Benutzer aktiv identifizieren möchte;
• TeachingTip für ein einzelnes Element, das der Entwickler dem Benutzer mitteilen möchte (kann auch nicht an ein Element angehängt werden);
• InfoBar für den gesamten App-/Content-Bereich, in dem der Entwickler Informationen liefern möchte;
• Flyout/Dialog , wenn der Entwickler möchte, dass der Benutzer bestätigt, dass er etwas gelesen hat, bevor er es verwirft;
• Inhaltsdialog , wenn der Entwickler vor allem verlangt, dass der Benutzer eine Wahl trifft oder eine Aktion ausführt;

Ich würde auch vermeiden, das Wort Benachrichtigung zu verwenden, da es die Benachrichtigung auf Betriebssystemebene und das Benachrichtigungszentrum für diese gibt

Ich würde auch vermeiden, das Wort Benachrichtigung zu verwenden, da es die Benachrichtigung auf Betriebssystemebene und das Benachrichtigungszentrum für diese gibt

Nun, ich denke, Entwickler würden den Unterschied erkennen, aber es ist sicherlich ein fairer Punkt.

Es ist auch wahr, dass wir viele separate Steuerelemente erstellen können. Aber es gibt sicherlich einige übergeordnete Konzepte rund um Benachrichtigung/Status/Nachrichten/Hinweise/Unterricht, die miteinander kombiniert werden könnten. Aus all dem sollten wir zumindest eine Schnittstelle machen.

Flyouts/Content-Dialoge sind separate Konzepte, da es sich größtenteils um generische Inhaltssteuerelemente handelt.

Ich habe mir einen perfekten Namen für ein allgemeines Steuerelement vom Typ „Nachrichtenansicht“ ausgedacht, das in verschiedenen Szenarien gehostet werden kann: Nennen Sie es „Tipp“. Ich habe meinen Kommentar oben entsprechend aktualisiert: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

Ich habe mir einen perfekten Namen für ein allgemeines Steuerelement vom Typ „Nachrichtenansicht“ ausgedacht, das in verschiedenen Szenarien gehostet werden kann: Nennen Sie es „Tipp“. Ich habe meinen Kommentar oben entsprechend aktualisiert: #913 (Kommentar)

Ich würde mich nicht wohl dabei fühlen, eine wichtige Warnung oder Fehlermeldung in einen Tipp zu schreiben ...

Es ist auch wahr, dass wir viele separate Steuerelemente erstellen können. Aber es gibt sicherlich einige übergeordnete Konzepte rund um Benachrichtigung/Status/Nachrichten/Hinweise/Unterricht, die miteinander kombiniert werden könnten. Aus all dem sollten wir zumindest eine Schnittstelle machen.

Flyouts/Content-Dialoge sind separate Konzepte, da es sich größtenteils um generische Inhaltssteuerelemente handelt.

Ich mag diese Idee wirklich. Ich denke, es gibt Gemeinsamkeiten in den Symbol-, Titel-, Nachrichten- und Aktionsschaltflächen-APIs, die über diese Infosteuerelemente hinweg konsistent sein können. Bei InfoBar bin ich mir nicht sicher, ob es etwas ist, das wir in dieser aktuellen Version implementieren können, aber möglicherweise für unsere nächste Kontrolle dieser Art.

Ich habe mir einen perfekten Namen für ein allgemeines Steuerelement vom Typ „Nachrichtenansicht“ ausgedacht, das in verschiedenen Szenarien gehostet werden kann: Nennen Sie es „Tipp“. Ich habe meinen Kommentar oben entsprechend aktualisiert: #913 (Kommentar)

Ich würde mich nicht wohl dabei fühlen, eine wichtige Warnung oder Fehlermeldung in einen Tipp zu schreiben ...

Ich stimme dem auch zu ... weitere Erkundungen sind zu erledigen.

Ich habe mir einen perfekten Namen für ein allgemeines Steuerelement vom Typ „Nachrichtenansicht“ ausgedacht, das in verschiedenen Szenarien gehostet werden kann: Nennen Sie es „Tipp“. Ich habe meinen Kommentar oben entsprechend aktualisiert: #913 (Kommentar)

Ich würde mich nicht wohl dabei fühlen, eine wichtige Warnung oder Fehlermeldung in einen Tipp zu schreiben...

Ich stimme dem auch zu ... weitere Erkundungen sind zu erledigen.

Denken Sie daran, wie gut es zu allen vorhandenen Steuerelementen und Ideen passt – in dieser Hinsicht ist es perfekt. Aber ja, es scheint im Zusammenhang mit Fehlern/Warnungen fehl am Platz zu sein. Ich denke, die Leute würden es schnell verstehen, aber ich kann dieser Logik nicht widersprechen.

Warum heißt das InfoBar? Info ist nur eine kleine Klasse von Informationen, die es enthalten kann. Es unterstützt auch Fehler und Warnungen sowie darauf basierende Aktionen. Bar beschränkt auch künstlich die "Form" des Steuerelements. Neben einer Bar gibt es noch einige andere Anwendungsfälle dafür.

NotificationView oder MessageView usw. wären meiner Meinung nach bessere Namen.

Ich stimme Ihrem Standpunkt zu, dass die InfoBar möglicherweise nicht immer eine Leiste ist, aber ich denke, dass die Aufnahme von „Bar“ in den Namen impliziert, dass sie sowohl visuell als auch konzeptionell für App-weite Szenarien gedacht ist. Wenn Sie nach Bildern von "Informationsleiste" suchen, finden Sie Bilder ähnlicher Erfahrungen aus dem IE (nicht, dass wir unbedingt versuchen, mit dem IE übereinzustimmen), und ich denke, dies entspricht dem erwarteten visuellen und funktionalen Layout. Ich sehe das nicht als "Ansicht", aber ich mag den Fokus auf Nachricht oder Benachrichtigung.

@gabbybilka Ja, es ist der alten StatusBar oder der neueren AppBar ... CommandBar ... usw. ziemlich ähnlich. Das Problem ist, dass die Verwendung des Steuerelements ziemlich verallgemeinert werden sollte, um auch Hinweise und Nachrichten an beliebigen Stellen anzuzeigen. „View“ passt auch nicht zu 100%, aber es ist eher ein allgemeiner Name. Mein Anliegen ist es wirklich, die zugrunde liegenden Konzepte zu vereinheitlichen, damit wir nicht mit mehreren Steuerelementen enden, die Variationen derselben Sache ausführen.

Bearbeitet, weil ich mich mit mehreren Kommentaren an zwei Stellen verwirrt habe.

Wiederkehrende Gedanken, die ich in einer der anderen Ausgaben gepostet habe ...

_Reaktion darauf, dass für V2 kein Floating Mode für die Steuerung mehr in Betracht gezogen wird_
Ich kann verstehen, dass die Änderung des Verhaltens und der Form Sie dazu bringen würde, sich dem TeachingTip als Alternative zuzuwenden, aber ich würde vorschlagen, dass der Mangel an Strenge, Statusfarbe und das Design des Teaching Tip selbst nicht mit der gleichen Art von kompatibel wäre Nachrichten, die das InformationBar-Steuerelement verarbeitet.

Die Bildschirmbreite und Unterschiede in den UI-Layouts zwischen einer Vollbild-WinUI-App, einem schmalen Fenster und Dingen wie Hololens und Xbox – würden sich nicht für einen angedockten Bar-Formfaktor eignen.

In Anbetracht dessen sollte die Informationsleiste vielleicht zusammen mit einem InformationCard-Steuerelement in eine AppMessage-API eingebunden werden – damit die gleichen Eigenschaften von Schweregrad, Farbe, Titel, Nachricht, Aktionsschaltflächen usw. in XAML oder in platziert werden können App-Code - und die Art und Weise, wie sie auf dem Bildschirm dargestellt werden, ändert sich je nach Formfaktor/Gerätefamilie.

Ein nicht angehängter Unterrichtstipp könnte einspringen, aber er würde nicht die Anpassungen unterstützen, die für App-Statusmeldungen geeignet sind – was die ursprüngliche Absicht hinter diesem Steuerelement ist.

Was wäre also, wenn wir einen „Tipp“ hätten, der wirklich nur eine Nachricht ist? Es hat eine Glyphe, Bilder, Nachrichtentext, Titel.

Dann, abgeleitet von Tip, haben wir AppMessage, das Schweregrad, Aktionen und Dinge hinzufügt. Tip wäre dann weiterhin in TeachingTip und ToolTip nutzbar, wie sie heute existieren. Es wäre auch in meinem Szenario für Inline-Kontexthinweise nützlich.

Was wäre also, wenn wir einen „Tipp“ hätten, der wirklich nur eine Nachricht ist? Es hat eine Glyphe, Bilder, Nachrichtentext, Titel.

Dann, abgeleitet von Tip, haben wir AppMessage, das Schweregrad, Aktionen und Dinge hinzufügt. Tip wäre dann weiterhin in TeachingTip und ToolTip nutzbar, wie sie heute existieren. Es wäre auch in meinem Szenario für Inline-Kontexthinweise nützlich.

TeachingTip without a Tail scheint perfekt für Ihre Situation zu sein ...

TeachingTip without a Tail scheint perfekt für Ihre Situation zu sein ...

Wusste nicht, dass Sie das mit TeachingTip machen können. Außerdem gibt es meine Steuerung schon viel länger als TeachingTip, also habe ich bis jetzt nie wirklich nach einem Upgrade gesucht. So oder so, wenn Sie das tun können, ist es ein Versehen meinerseits.

Bearbeiten: Egal, auch ohne Schwanz ist es immer noch eine Überlagerung, die auf die eine oder andere Weise entlassen wird. Der 'Hinweis', den ich beschreibe, ist alles inline und bleibt bestehen, bis der Benutzer im Grunde das erste Element erstellt. Es ist einfach ein Steuerelement, das Informationen präsentiert – nicht in einem Popup, Flyout oder einer anderen nicht persistenten Ansicht.

Ich bin immer noch davon überzeugt, dass es eine Menge Gemeinsamkeiten gibt, um Schnittstellen/Steuerelemente aufzubrechen, die an mehreren Stellen verwendet werden. Alle diese Steuerelemente, die wir besprechen, haben weitaus mehr Ähnlichkeiten als Unterschiede. Es ändert sich nur, wo/wie die zugrunde liegenden Informationen dargestellt werden. Das alles ist reif für eine Vereinfachung.

TeachingTip without a Tail scheint perfekt für Ihre Situation zu sein ...

Wusste nicht, dass Sie das mit TeachingTip machen können. Außerdem gibt es meine Steuerung schon viel länger als TeachingTip, also habe ich bis jetzt nie wirklich nach einem Upgrade gesucht. So oder so, wenn Sie das tun können, ist es ein Versehen meinerseits.

Ich bin immer noch davon überzeugt, dass es eine Menge Gemeinsamkeiten gibt, um Schnittstellen/Steuerelemente aufzubrechen, die an mehreren Stellen verwendet werden. Alle diese Steuerelemente, die wir besprechen, haben weitaus mehr Ähnlichkeiten als Unterschiede. Es ändert sich nur, wo/wie die zugrunde liegenden Informationen dargestellt werden. Das alles ist reif für eine Vereinfachung.

Wenn Sie es aufschlüsseln, ist es nur ein Symbol und Text, und es ist kein "Kontext" damit verbunden. Aber mein Vorschlag, es in eine AppMessage zu verpacken, könnte Non Attached TeachingTips als eine andere Form der Benutzeroberfläche beinhalten, denke ich.

Wenn Sie es aufschlüsseln, ist es nur ein Symbol und Text, und es ist kein "Kontext" damit verbunden. Aber mein Vorschlag, es in eine AppMessage zu verpacken, könnte Non Attached TeachingTips als eine andere Form der Benutzeroberfläche beinhalten, denke ich.

Entschuldigung, siehe meine Bearbeitung oben. Der Unterrichtstipp ist immer noch nicht inline und schwebt einfach unten, bis er verworfen wird. Es gibt auch ein Bild und einen Titel, die ebenfalls berücksichtigt werden müssen.

Wenn Sie es aufschlüsseln, ist es nur ein Symbol und Text, und es ist kein "Kontext" damit verbunden. Aber mein Vorschlag, es in eine AppMessage zu verpacken, könnte Non Attached TeachingTips als eine andere Form der Benutzeroberfläche beinhalten, denke ich.

Entschuldigung, siehe meine Bearbeitung oben. Der Unterrichtstipp ist immer noch nicht inline und schwebt einfach unten, bis er verworfen wird.

Muss nicht ganz unten sein.

Inline ist vielleicht ein ungewöhnlicher Anwendungsfall für einen Hinweis, da er andere Inhalte um ihn herum verdrängen würde.

Sie könnten vorschlagen, dass ein V2 Unterstützung für einen Inline-/Non-Floating-Anzeigemodus hinzufügt

Um dem Kommentar von @mdtauk etwas mehr Kontext zu geben, hier war meine erste Antwort auf seine Frage zum Entfernen des Floating-Modus aus dem Abschnitt „Beabsichtigte Funktionen für InfoBar V2“ in der Spezifikation.
Von mir:

Hüpfen Sie hier für die Designdiskussion. Achten Sie darauf, dass sich die beabsichtigten Funktionen von V2 ändern 😉 Im Moment verpflichten wir uns aus mehreren Gründen nicht zum Floating-Modus für InfoBar in einer V2-Version. Ich würde gerne weiter untersuchen, ob der schwebende Modus in einer Infoleiste _sollte_ oder ob Toast-ähnliche Benachrichtigungen eine ganz andere Steuerung sein sollten. Während der Untersuchung stellten wir fest, dass eine grundlegende Implementierung des Floating-Modus dem Teaching Tip unglaublich ähnlich wäre und dass wahrscheinlich Funktionen wie Stapeln, Positionieren und Überlagerungsoptionen (siehe StackMode von WCT InAppNotification ) benötigt werden, um Toast-ähnliche Benachrichtigungsszenarien vollständig zu erkunden. Dies würde den Geltungsbereich und die Absicht der Infoleiste erweitern, sodass sie viel breiter als ihr ursprünglicher Fokus ist. Zu beachten ist, dass wir die Tür zum Hinzufügen von Floating-Funktionen zur InfoBar nicht vollständig geschlossen haben, sondern eher zu Nein tendieren.

Für den Vorschlag von InformationBar und InformationCard, der auf einer Basis-AppMessage-Klasse basiert, gefällt mir diese Idee. Sie haben erwähnt, dass sich "die Art und Weise, wie sie auf dem Bildschirm dargestellt werden, an den Formfaktor / die Gerätefamilie anpassen würde", was ich eingehender untersuchen möchte. Ich denke, es gibt Szenarien, die besser für Card UX geeignet sind (insbesondere transiente Meldungen, seitenspezifische Fehlermeldungen und Apps ohne andockbare Oberflächen) als Bar UX und umgekehrt.

Für mich gibt es sowohl Unterschiede im „Wann“ eine InfoBar/InfoCard/Lehrtipp zu verwenden (gebunden an visuelle und funktionale Anforderungen) als auch im „Warum“ zu verwenden (basierend auf der Wahrnehmung des Endbenutzers und der Erfahrungskonsistenz). Transiente Meldungen sind für mich ein klares Highlight als etwas, das von einer InfoCard unterstützt werden sollte und nicht von einer InfoBar. Nachrichten, die nicht vom Benutzer geschlossen werden können, sind ein Beispiel für das Gegenteil, da dauerhaft überlagerter Inhalt aus Sicht der Barrierefreiheit schwierig zu unterstützen ist.

Lassen Sie sich jedoch nicht ablenken :) Alle diese verschiedenen Steuerelemente präsentieren größtenteils die gleiche Art von Informationen – nur in unterschiedlichen Bereichen/Stilen. Dies muss verallgemeinert und vereinheitlicht werden. Ich denke, wir können uns um ein gemeinsames „AppMessage“-Steuerelement vereinheitlichen, wenn Sie es so nennen möchten. Dann haben Sie einfach verschiedene Container, um diese „AppMessage“ auf unterschiedliche Weise darzustellen. Es könnte in einem TeachingTIp, einem ToolTip, einer Benachrichtigungsleiste, irgendwo als Karte usw. dargestellt werden. Jeder Container kann den Stil an seinen Anwendungsfall anpassen. Die zugrunde liegenden Eigenschaften und Typen würden jedoch vereinheitlicht.

Ich habe nicht versucht, irgendeinen Zusammenhang mit der Antwort von @gabbybilka falsch zu interpretieren 😄

Für den Vorschlag von InformationBar und InformationCard, der auf einer Basis-AppMessage-Klasse basiert, gefällt mir diese Idee.

Hier kommt die Benennung ins Spiel. Ich mag „AppMessage“ („Tipp“ wäre allerdings großartig, da es den Anschein hat, als wäre es die ganze Zeit der Plan gewesen), aber wenn wir uns daran halten, sollten es „MessageBar“ und „MessageCard“ sein es.

Für mich gibt es sowohl Unterschiede im „Wann“ eine InfoBar/InfoCard/Lehrtipp zu verwenden (gebunden an visuelle und funktionale Anforderungen) als auch im „Warum“ zu verwenden (basierend auf der Wahrnehmung des Endbenutzers und der Erfahrungskonsistenz).

Ich stimme diesen unterschiedlichen Anwendungsfällen und Präsentationen definitiv zu. Sie präsentieren jedoch immer noch eine Botschaft, die verallgemeinert und standardisiert werden kann. Ich denke, wir sind uns jetzt alle einig über dieses Konzept :)

Beispiel für eine Kartennachricht/einen Tipp

Eines der Ziele sollte meines Erachtens darin bestehen, den Posteingang und Erstanbieter-Apps/Windows-Shell dazu zu ermutigen, von ihren benutzerdefinierten Lösungen wegzugehen und eine konsistente Posteingangssteuerung/API zu verwenden

Ich sollte wahrscheinlich hinzufügen, dass in einer UWP-App, an der ich arbeite, einige dieser Konzepte bereits vereinheitlicht wurden. Die für diese Diskussion relevante vereinfachte Version lautet:

Es gibt eine 'Message'-Klasse (es ist kein Steuerelement, nur eine Datenstruktur) mit den folgenden Eigenschaften:

        protected MessageDisplayMode _DisplayMode;
        protected List<Message>      _InnerMessages;
        protected MessagePriority    _Priority;
        protected string             _Text;
        protected DateTimeOffset?    _Timestamp;

Die Priorität ist im Grunde die gleiche wie die, die Sie bereits entschieden haben (sie ist heutzutage ziemlich standardisiert). DisplayMode unterstützt Benachrichtigung, Keine und Popup. Wenn eine Nachricht vom Back-End-Code generiert wird, wird sie an das Front-End weitergeleitet, das sie entsprechend entweder als schnelle Benachrichtigung in einer „Leiste“ oben in der zu schließenden App anzeigt. Oder als blockierendes Popup für schwerwiegendere Nachrichten.

Darüber hinaus gibt es ein 'MessageView'-Steuerelement, das eine Nachricht selbst nimmt, aber eine Glyphe und einen Titel hinzufügt und sie als den kontextbezogenen Inline-'Hinweis' darstellt, über den wir zuvor gesprochen haben.

Genau das würde ich vorschlagen: Führen Sie die Abstraktion auf der App-Schicht durch. Haben Sie eine einfache ViewModel-Klasse, die Sie an jede Ansicht anhängen können. Es ist einfacher und flexibler. Vielleicht möchten Sie auch mit Ihrem bevorzugten Protokollierungs-Framework protokollieren, Sie möchten benutzerdefinierte Prioritäten haben und Ihre eigenen Daten hinzufügen. Alles ganz einfach in Ihrem ViewModel.

Die Absicht der von Ihnen erwähnten Steuerelemente besteht darin, eine einheitliche Methode zum Durchführen bestimmter Szenarien für viele Apps und Betriebssystemanwendungsfälle bereitzustellen, anstatt dass jede App mit einer etwas anderen Benutzeroberfläche und einem etwas anderen Verhalten ausgestattet ist. ToolTips und InfoBar/MessageBar sind bekannte Konzepte, sowohl für Entwickler als auch für Endbenutzer. Obwohl beide Informationen darstellen, werden sie für sehr unterschiedliche Dinge verwendet. Ich sehe keinen großen Nutzen darin, eine gemeinsame Basisklasse oder ein gemeinsames Konzept für diese zu haben. Warum möchten Sie eine Nachricht in einen ToolTip einfügen, der bereits in der globalen App-Infoleiste angezeigt wird (und wo würden Sie diesen ToolTip anhängen)? Es ist nicht so, dass dies zu einer großen Wiederverwendung führen würde.

Es gibt andere Bereiche, in denen gemeinsame Konzepte meines Erachtens viel nützlicher wären. Denken Sie an Button, AppBarButton, MenuItem. Alle diese zeigen Text und ein Symbol, alle werden verwendet, um eine Aktion auszulösen. Häufig stellen Sie dieselben Befehle sowohl in einem MenuItem (ContextMenu) als auch in einer AppBar/CommandBar bereit. Hier wäre ein gemeinsames Konzept sehr hilfreich, wo Sie Ihren Befehl, Text, Symbol, vielleicht auch eine lange Nachricht (Tooltip) unterbringen könnten. Aber ein gemeinsames Konzept für ToolTip und MessageBar? Ich sehe wirklich keine Notwendigkeit dafür. Sicher, wenn wir UWP von Grund auf neu schreiben würden, hätten wir vielleicht eine gemeinsame Basisklasse entwickelt. Aber ich denke nicht, dass es notwendig oder übermäßig hilfreich ist.

@lukasf Deine Punkte machen Sinn; Dies kann in der App selbst erfolgen. Allerdings gibt es viele sehr ähnliche Konzepte und alle können hier von einer Vereinheitlichung profitieren.

ToolTip wurde in die Diskussion geworfen, weil es von Vorteil sein könnte, eine Glyphe und einen Titel zusammen mit einer Nachricht zu haben. Konzeptionell sind all diese Steuerelemente auch Nachrichten in irgendeiner Form - nur wo/wie sie angezeigt werden, ist unterschiedlich. Selbst wenn wir keine große Standardisierung vornehmen, würden eine MessageBar und eine MessageCard immer noch viele gemeinsame Eigenschaften/Typen erfordern. Wir wollen MessageBarPriority nicht zusammen mit MessageCardPriority-Enems haben. Es muss noch nachgedacht werden, um sicherzustellen, dass auch die Basistypen zukunftssicher sind.

All dies mit bestehenden Ideen im Unterrichtstipp zu kombinieren erscheint mir nur logisch. Ich bin mir sicher, welche Richtung bei einem direkten Vergleich aller genannten Steuerelemente und ihrer Eigenschaften sinnvoll wäre. Wenn ich Zeit habe, vergleiche ich selbst.

Ihre Kommentare zu Button/AppBarButton/etc. sind ein perfektes Beispiel für das Denken, das wir nicht verbreiten wollen. Microsoft gewöhnt sich daran, mehrere ähnliche, aber unterschiedliche Steuerelemente zu erstellen, ohne die Zeit/Mühe aufzuwenden, sie zusammenhängend zu machen. Diese lange Laufzeit ist aus mehreren Gründen nicht gut für einen Rahmen jeglicher Art.

Ich habe einen Vergleich der Messaging-Steuerelemente zusammengestellt. Ich gebe es als kostenlose Beratung ab, da es so rau ist, wie es ist :)

Dies ist die Art von High-Level-Vergleichs- und Strategiedokumentation, von der ich erwarte, dass sie intern bei Microsoft erstellt wird. Wenn ich selbst die Spezifikations-/Designüberprüfungen leiten würde, würde ich diese Art von Analyse verlangen, sonst kann niemand erwarten, mit Zustimmung zu gehen. Es ist absolut wichtig:

1. Überbrücken Sie Verständnislücken zwischen Teammitgliedern
2. Überwinden Sie die „Silos“, die in großen Teams und Organisationen auftreten
3. Gewährleistung einer kohärenten zukünftigen Ausrichtung des Frameworks, damit zukünftige Funktionen auf einer guten Grundlage hinzugefügt werden können (am wichtigsten)

Microsoft hat diese Gesamtbildprinzipien nach WPF irgendwie verloren, und es scheint keine „übergeordnete“ Vision der Führung in diesem Bereich mehr zu geben. Wie auch immer, ich bin nicht in die internen Diskussionen eingeweiht, daher hoffe ich, dass intern viel mehr Planung mit einigen Personen stattfindet, die viel Erfahrung und eine lange Geschichte der Prinzipien mit XAML haben.

Vor diesem Hintergrund können Sie das Dokument unten zerreißen. Das Wichtigste ist die Diskussion selbst.

MessageControlComparison 20200929.xlsx

Danke für das Vergleichsdokument, sehr cool, Ihre Gedanken zu den Info-Steuerelementen ganzheitlich zu sehen! Zwei Hauptthemen, über die ich die Diskussion fortsetzen möchte, sind 1. Warum _sollte_ nicht_ der Unterrichtstipp und die Infoleiste unterschiedliche APIs/Eigenschaften/Funktionalitäten haben? und 2. Was wäre der Unterschied zwischen einer InfoBar und einer InfoCard, wenn die InfoCard kein Popup wäre, wie im Vergleichsdokument beschrieben?

Bei der ersten Frage kann ich die Designentscheidungen hervorheben, die für die rot markierten Elemente getroffen wurden, und etwas mehr Klarheit schaffen:

• TeachingTip Subtitle vs. InfoBar Message: Funktional, ja, sie sind gleich! Sie sind die sekundäre Nachricht mit nicht fettgedrucktem Text in diesen Steuerelementen. In einem Unterrichtstipp wird diese Nachricht immer unter dem Titel angezeigt und sinnvollerweise als Untertitel bezeichnet. Für InfoBar wird diese Nachricht meistens inline und direkt rechts neben dem Titel angezeigt, was konzeptionell nicht so sinnvoll ist wie ein Untertitel.
• TeachingTip HeroContent vs. InfoBar Content: Teaching Tip hat sowohl HeroContent als auch Content, während InfoBar nur Content hat. Die HeroContent-Eigenschaft ist einzigartig für Teaching Tip, da sie diese größeren Bilder unterstützt, um den Unterricht zu erleichtern. InfoBar unterstützt Bilder nicht explizit, da es sich auf ein horizontales Layout konzentriert. Die Content-Eigenschaft für beide Steuerelemente dient für zusätzlichen benutzerdefinierten Inhalt und befindet sich in beiden unter den übrigen UI-Elementen.
• Unterrichtstipp Schaltflächenstrategie vs. InfoBar-Schaltflächenstrategie: Die Hauptunterschiede hier bestehen darin, dass InfoBar mehr Arten von Schaltflächen als die klassische "Schaltfläche" unterstützt und keine Anpassung der Schließen-Schaltfläche zum Einschließen von Text unterstützt.
  
  
  
  • Ein häufiges Szenario für InfoBars ist das Einfügen einer Hyperlink-Schaltfläche. Aufgrund des Farbkontrasts mit der Standard-Vordergrundfarbe der Hyperlink-Schaltfläche und unseren verschiedenfarbigen Hintergrundfarben wollten wir sicherstellen, dass wir unser eigenes benutzerdefiniertes Design auf alle in der Infoleiste enthaltenen Hyperlink-Schaltflächen anwenden können, damit sie zugänglich bleiben.
  
  
  • Wir haben uns nach unseren Designüberprüfungen entschieden, die Anpassung der Schaltfläche „Schließen“ nicht in die Infoleiste aufzunehmen (für Text gibt es immer noch eine CloseButtonStyle-Eigenschaft, um bei Bedarf ein leichtes Styling vorzunehmen), um sicherzustellen, dass der Fokus weiterhin auf dem enthaltenen Text und der einzelnen Aktion liegt. Entsprechend denken wir, wie in der Spezifikation erwähnt, über eine ActionContentArea in V2 nach, um hier mehr als eine Aktionsschaltfläche zu unterstützen, und könnten prüfen, ob die Anpassung der Schaltfläche „Schließen“ dort wieder aktiviert werden kann.
  
  
• InfoBar IsClosable & IsIconVisible: Unterrichtstipp hat kein IsClosable, da ein Unterrichtstipp immer schließbar sein sollte, da es sich um ein PopUp handelt und nicht blockierende/dringende Informationen anzeigt. Es hat auch kein IsIconVisible, da ein Symbol nicht mit seinem Standardstil angezeigt wird, den InfoBar über die verschiedenen Schweregrade ausführt. Wir wollten Entwicklern eine Möglichkeit bieten, das bereitgestellte Symbol zu entfernen, wenn sie dies wünschen. Wir haben versucht, IconSource auf null zu setzen, was viele irre Fehler verursachte und über die IsIconVisible-Eigenschaft vereinfacht wurde.

Sind diese sinnvoll? Ich glaube, dass beide Steuerelemente unterschiedliche Zwecke haben, und die Unterschiede in der Funktionalität spiegeln dies wider. Ich hoffe, diese Erklärungen und Designbegründungen waren hilfreich!

Bearbeiten für Formatierungsprobleme und Tippfehler😊 x2

Ich würde nicht direkt für eine Harmonisierung zwischen diesen Kontrollen plädieren, da es eine Rechtfertigung dafür gibt, dass diese Kontrollen in ihrem eigenen Kontext ihr eigenes Ding machen.

Das Erstellen einer In-App-Messaging-API, die als vereinheitlichende Struktur fungiert, sich jedoch an den Formfaktor anpassen kann, erfordert keine Änderungen an den Steuerelementen.

Es gibt Fragen, die für diese Art von API diskutiert und beantwortet werden müssen:

• Soll / Wie können Sie als Entwickler festlegen, welche Art von Steuerung ein Nachrichtenaufruf auf dem Bildschirm anzeigt?
• Wenn kein Steuerelementtyp angegeben wird, nimmt die API die angegebenen Eigenschaften und "wählt" die am besten geeignete aus?
• Wie würden Sie Verhaltensentscheidungen an die zugrunde liegenden Steuerelemente weitergeben?
• Welche Formfaktoren würden sich je nach Eignung der Plattform überschreiben?

Und wahrscheinlich noch viele mehr, an die ich nicht gedacht habe lol

Xbox als Plattform nehmen
Die Eingabemethoden sind sehr unterschiedlich, ebenso wie die Bildschirmgröße/Skalierung.

Informationsleisten in voller Breite müssten Overscan an den Bildschirmrändern berücksichtigen, daher ist für diese Apps möglicherweise eine Informationskarte besser geeignet.

Aber wie würden Sie mit einer Kündigung umgehen?

Kein Cursor zum Bewegen über eine Schließen-Schaltfläche, aber möchten Sie, dass die Karte die Controller-Eingaben übernimmt? Dadurch wird es modal. Aber wenn es dann über den Inhalt gelegt wird, wie wählen Sie es aus und geben ihm den Fokus?

Erscheint es dann also inline und drückt den Inhalt nach unten, aber nicht in voller Breite?

Außerdem hat Xbox ein eigenes Toast-ähnliches Benachrichtigungssystem, also würde/sollte diese API damit funktionieren? Kann es damit funktionieren oder ist es nur System?

1. Warum sollten der Unterrichtstipp und die Infoleiste nicht unterschiedliche APIs/Eigenschaften/Funktionalität haben?

Das Ziel sollte immer sein, gemeinsame APIs für die gleichen Dinge bereitzustellen. In dieser ganzen Diskussion geht es um benutzerorientierte Nachrichten im Allgemeinen, und sobald das verstanden wurde, traten mehrere Ähnlichkeiten auf. Es ist unbestreitbar, dass die Anwendungsfälle für TeachingTip und ein Steuerelement vom Typ MessageBar unterschiedlich sind. Grundsätzlich präsentiert einer eine Nachricht und der andere auch einen Tipp. Ich stelle hier nicht die allgemeinen Designentscheidungen in Frage. Es gibt jedoch weitaus mehr Ähnlichkeiten als Unterschiede mit diesen Kontrollen. Schauen Sie sich nur das Design an: Sie alle haben ein Symbol, einen Titel, einen Untertitel, einen Inhalt, eine Aktionsschaltfläche und eine Schließen-Schaltfläche (Sie haben sie jedoch anders benannt und es gibt eine andere API-Oberfläche). Wenn Sie nicht verstehen, warum es eine gute Idee ist, hier zumindest Namen und Aufzählungen zu standardisieren, kann ich nichts mehr sagen. Das ist einfach etwas Grundlegendes für gute Architektur.

Bei Schaltflächen unterstützen beide Steuerelemente eine Aktionsschaltfläche und eine Schließen-Schaltfläche. Aber Sie haben das auf ganz unterschiedliche Weise gemacht. Sie haben oben einige Gründe erklärt, aber jetzt haben wir eine "hässliche" API für die Verwendung von Schaltflächen in Situationen wie dieser. Warum verallgemeinern wir das nicht jetzt, damit wir etwas Gutes für die Zukunft haben? Schaltflächen wie diese gelten für mehrere Steuerelemente: ContentDialog, TeachingTip, InfoBar und wer weiß was als nächstes. Wir denken beim Entwerfen immer nur an die aktuelle Kontrolle - schlechte Architektur!

Für den Text der Nachricht oder des Hinweises heißt das eine Subtitle und das andere Message im Grunde können diese gleich sein, warum werden unterschiedliche Begriffe verwendet, außer dass unterschiedliche Projektmanager an diesen Kontrollen arbeiten?

Wäre es insgesamt nicht hilfreich für Entwickler, wenn die Steuerelemente einfach auf die gleiche Weise funktionieren würden? Ja, natürlich! Bedeutet das, dass es unter all dem die gleiche Kontrolle geben wird? Nicht unbedingt, aber wir sollten die gleichen Eigenschaftsnamen, die gleichen Aktionsschaltflächenkonzepte und die gleichen Typen verwenden. Ich hoffe immer noch, dass wir eine Nachrichtenstruktur oder Schnittstelle haben könnten, die verwendet wird, um alles zusammenzubinden. Wäre es nicht großartig, einfach eine Nachricht für die MessageBar festzulegen und anzuzeigen, anstatt all diese Eigenschaften manuell festlegen zu müssen?

Was wäre der Unterschied zwischen einer InfoBar und einer InfoCard, wenn die InfoCard kein Popup wäre, wie im Vergleichsdokument beschrieben?

Meine abschließende Schlussfolgerung aus dem Vergleich ist, dass MessageBar/MessageCard dasselbe Steuerelement sein und auch den Anwendungsfall meines Inline-Hinweises oder Tipp-Beispiels durch Stilanpassung unterstützen sollten.

• Es ist möglich, MessageBar/MessageCard und Tip in einem einzigen Steuerelement zu vereinen. Die einzige Sorge ist der konzeptionelle Unterschied zwischen „Nachricht“ und „Tipp“.
• Sollte das gleiche zugrunde liegende Steuerelement sein, muss das Styling jedoch hochgradig anpassbar sein, um beide Fälle zu unterstützen. Die einzige Sorge ist der konzeptionelle Unterschied zwischen „Nachricht“ und „Tipp“. Das Design ist sehr ähnlich.

Bearbeiten: Insgesamt denke ich, dass meine grundlegende Sorge darin besteht, dass wir im architektonischen Denken irgendwie rückwärts gegangen sind. Das Steuerelementdesign wird jetzt so durchgeführt, als wäre es zu Zeiten von Windows Forms gewesen. Neue UWP-Steuerelemente sollten auf WPF-Konzepten basieren. Steuerelemente werden hochspezialisiert, und ich sehe nicht die vereinheitlichenden Fäden, die das Framework überspannen, die Entwickler, die WPF zum ersten Mal berührt haben, wirklich „beeindruckt“ haben. Meiner Meinung nach müssen wir zurück zur „Big Picture“-Mentalität.

Ich stimme @robloo zu 100 % zu, dass Eigenschaftsnamen und Aufzählungsnamen für ähnliche Dinge (soweit möglich) an vorhandenen Steuerelementen ausgerichtet werden sollten. Ähnliche Steuerelemente sollten eine ähnliche API-Oberfläche haben. Wenn zu einem späteren Zeitpunkt eine MessageCard-Klasse hinzugefügt werden sollte (anstatt MessageBar zu erweitern, was ich persönlich bevorzugen würde), sollte sie zumindest eine sehr ähnliche API wie MessageBar haben.

Es gibt andere Bereiche, in denen gemeinsame Konzepte meines Erachtens viel nützlicher wären. Denken Sie an Button, AppBarButton, MenuItem. Alle diese zeigen Text und ein Symbol, alle werden verwendet, um eine Aktion auszulösen. Häufig stellen Sie dieselben Befehle sowohl in einem MenuItem (ContextMenu) als auch in einer AppBar/CommandBar bereit. Hier wäre ein gemeinsames Konzept sehr hilfreich, wo Sie Ihren Befehl, Text, Symbol, vielleicht auch eine lange Nachricht (Tooltip) unterbringen könnten.

@lukasf Kennen Sie die XamlUICommand -Klasse? Dadurch können Sie diese Eigenschaften an einem Ort bündeln und sie dann Ihrem Button/MenuItem/... zuweisen, indem Sie einfach Ihren definierten XamlUICommand an die Command -API dieser Steuerelemente übergeben.

@Felix-Dev Ja, du hast Recht. Das hätte ich fast vergessen. Ich verwende es nicht, da es beim letzten Versuch in WinUI nicht verfügbar war, aber auch, weil es keine vollständige Lösung ist. AppBar und ContextMenu haben mehr als nur Befehlslinks. Für eine vollständige Lösung benötigen wir:

• XamlUICommand
• XamlToggleUICommand
• XamlUICommandSubItem (Untermenü / Flyout)
• XamlUICommandSeparator

Was auch fehlt, ist eine "Visible"-Eigenschaft und/oder eine Eigenschaft "HideIfDisabled".

Dann benötigen wir eine ItemsSource für MenuFlyout und AppBar/CommandBar und ähnliche Steuerelemente. Die Steuerung der obersten Ebene würde dann die entsprechenden Untersteuerungen für jedes Befehlselement erstellen.

Erst als all dies vorhanden war, konnten wir eine Sammlung von Befehlen in unserer App haben und sie an MenuBar, ContextMenu, AppBar, NavigationView binden. Aber so wie es jetzt ist, muss ich eine Liste benutzerdefinierter Klassen führen, Dinge wie DataTemplateSelectors und andere lästige Problemumgehungen manuell implementieren und verwenden, nur um die gleiche Befehlsdefinition an verschiedenen Stellen zum Laufen zu bringen.

XamlUICommand war ein guter Anfang, aber es ist keine vollständige Geschichte.

Entschuldigung für meine verspätete Antwort hier, @robloo , danke, dass du deine Perspektive und die Vergleichstabelle von vor ein paar Wochen geteilt hast. Ich schätze wirklich all die Gedanken und Überlegungen, die in die Verbesserung von WinUI einfließen! 😊

In InfoBar und auf der gesamten Plattform bin ich der Ansicht, dass wir beim Entwerfen danach streben, die richtige Balance für Steuerelemente zu finden, die speziell für bestimmte Szenarien als definiertes UI-Muster entwickelt werden – während sie generisch und anpassbar genug sind, um sich auf die Szenarien zu erstrecken, die wir nicht haben noch identifiziert. Als jemand, der neu im Team ist, würde ich gerne hören, warum WinUI-Steuerelemente auf WPF-Konzepte zurückgreifen sollten. Welchen alltäglichen Problemen stehen Sie und andere UWP-Entwickler gegenüber, wenn ähnliche konzeptionelle Steuerelemente nicht dieselbe zugrunde liegende Struktur haben? Welche Vorteile ergeben sich für Sie, damit wir besser verstehen können, warum wir Ressourcen für die Schaffung dieser Struktur einsetzen sollten? Gibt es andere Steuerelemente in WinUI, die von einer Vereinheitlichung profitieren würden (ich sehe die Konversation über die Schaltfläche oben von @lukasf). Ich denke, wir können diese Konversation auch in einer neuen allgemeinen Ausgabe fortsetzen, wenn es einen Bereich gibt, in dem wir bestehende Steuerelemente/Brainstorming-Ansätze ändern können zukünftige Kontrollen. @SavoySchuler für jeden Input hier.

Für die InfoBar sehe ich nach wie vor keine Änderungen vor, wenn sie von diesem Gespräch in die Vorschau geht. Wenn bestimmte Anforderungen nicht erfüllt werden, teilen Sie uns dies bitte mit, wenn bestimmte Anforderungen nicht erfüllt werden, damit wir mögliche Änderungen bewerten können. Ich könnte davon ausgehen, dass eine gemeinsame AppMessage-Basisklasse oder -Schnittstelle mit einer v2 in Verbindung mit einem InfoCard-Steuerelement oder als separater DisplayMode implementiert wird, um die zuvor angesprochene „Auto“-Funktionalität des variablen Layouts @mdtauk zu aktivieren. Darüber hinaus sieht das WinUI-Team derzeit noch keinen Wert darin, Teaching Tip und InfoBar weiter aufeinander abzustimmen, aber wir können hier die Diskussion fortsetzen, um dies anzusprechen, wenn Nutzungsanforderungen nicht erfüllt werden. Sobald InfoBar in die Vorschau geht und in Anwendungen implementiert werden kann, wäre jedes spezifische Szenario oder Nutzungsfeedback vor der offiziellen Veröffentlichung großartig.

Wenn Sie Szenarien haben, die der Absicht einer Infoleiste entsprechen, und Aspekte der Funktionalität oder des visuellen Designs Ihren Anforderungen nicht entsprechen, teilen Sie uns dies bitte mit, wenn wir in die Vorschau gehen. Nochmals vielen Dank für all Ihre Kommentare und Gespräche!

In InfoBar und auf der gesamten Plattform bin ich der Ansicht, dass wir beim Entwerfen danach streben, die richtige Balance für Steuerelemente zu finden, die speziell für bestimmte Szenarien als definiertes UI-Muster entwickelt werden – während sie generisch und anpassbar genug sind, um sich auf die Szenarien zu erstrecken, die wir nicht haben noch identifiziert. Als jemand, der neu im Team ist, würde ich gerne hören, warum WinUI-Steuerelemente auf WPF-Konzepte zurückgreifen sollten. Welchen alltäglichen Problemen stehen Sie und andere UWP-Entwickler gegenüber, wenn ähnliche konzeptionelle Steuerelemente nicht dieselbe zugrunde liegende Struktur haben? Welche Vorteile ergeben sich für Sie, damit wir besser verstehen können, warum wir Ressourcen für die Schaffung dieser Struktur einsetzen sollten? Gibt es andere Steuerelemente in WinUI, die von einer Vereinheitlichung profitieren würden (ich sehe die Konversation über die Schaltfläche oben von @lukasf). Ich denke, wir können diese Konversation auch in einer neuen allgemeinen Ausgabe fortsetzen, wenn es einen Bereich gibt, in dem wir bestehende Steuerelemente/Brainstorming-Ansätze ändern können zukünftige Kontrollen. @SavoySchuler für jeden Input hier.

Der Sinn einer Struktur besteht darin, dass Programmierer schneller und mit weniger Fehlern codieren können, um qualitativ hochwertigen Code zu erhalten.

Da ein Großteil von Microsoft isolierte Teams sind, gibt es in vielen Fällen mehrere Möglichkeiten, etwas zu tun, aber keine Vereinheitlichung der genannten Verfahren, was zu Redundanz und dem Versuch führt, etwas zu beheben, das bereits behoben ist.

Nachdem WPF geschaffen wurde, ging Microsoft in eine "es ist gut genug"-Mentalität ein, die sich direkt in der Qualität der Apps ausdrückt, sogar von Microsofts eigenen Teams. Wenn Microsofts eigene Posteingangs-Apps nicht mit qualitativ hochwertiger, einheitlicher Konsistenz im Code und Einheitlichkeit von Apps auf die gleiche Seite kommen können, wie können wir dann von Drittanbietern erwarten, dass sie solche liefern?

Die Bereitstellung von generischem, aber anpassbarem Code führt zu generischen Baseline-Apps. Die meisten Entwickler werden keine zusätzlichen Anstrengungen unternehmen, um ihre App funktional und ausgefeilt aussehen zu lassen, sie werden nur genug tun, um ihre App funktionsfähig zu machen. Dieses Maß an „genug tun, damit es funktionsfähig ist“ wird vom Endbenutzer als „halbe Sache“ aufgegriffen.

Meiner Meinung nach besteht der Sinn von Kontrollen darin, qualitativ hochwertigen Code zu haben, den Sie einfach verwenden können, und Sie können ihn nach Belieben anpassen.

Den Entwicklern Optionen zu geben, wie sie Steuerelemente verwenden, hat auch ihre Vorteile, anstatt sie auf eine einzige Art der Verwaltung von Nachrichten und Benachrichtigungen festzulegen.

Aber sicherzustellen, dass jede Option, die sie wählen, auf vertraute Weise aussieht und sich verhält und zu Fluent Design „gehört“, hat den Vorteil der Konsistenz.

Wenn also die Steuerelemente selbst in WinUI keinen einheitlichen Ansatz bieten, könnte das Windows-Toolkit vielleicht eine Hilfs-API erstellen, die es verwaltet.

Ich würde vorschlagen, dass Sie es in diesem Repo vorschlagen, und es kann die WinUI-Steuerelemente verwenden, um es in der App darzustellen

Hallo zusammen, als Update befindet sich das InfoBar-Steuerelement jetzt in der Vorschau 🎉 Wenn Sie eine Anwendung haben, die von diesem Steuerelement profitieren würde, probieren Sie es bitte aus und teilen Sie uns Ihr Feedback mit.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
Vielen Dank für Ihr bisheriges Engagement für diese Kontrolle!

Hier ist ein weiteres Beispiel für eine Informationsleiste/Box/Karte

Bearbeiten: Ich habe gerade festgestellt, dass das folgende Problem bereits von https://github.com/microsoft/microsoft-ui-xaml/issues/3581 behoben wurde. Bitte ignorieren Sie das Problem unten. Danke für die Kontrolle! Sieht toll aus in Nightingale :)

@gabbybilka Ich werde die Infoleiste in meiner Nightingale-REST-Client-App verwenden. Es ist perfekt für eines meiner Szenarien. In meinem Schnelltest sieht es so aus, als ob das Symbol in der Infoleiste kein helles Design unterstützt? Oder vielleicht mache ich etwas falsch in meiner XAML-Nutzung des Steuerelements. Hier sind einige Screenshots

Würden Sie erwägen, dem Steuerelement ein "Opened"-Ereignis hinzuzufügen? In einigen Fällen ist es angebracht, die Infoleiste nach einigen Sekunden automatisch zu schließen. Ein "Opened"-Ereignishandler wäre der richtige Ort, um den Timer zu starten.

Ich denke, die Success -Farbe im Dark Theme sollte geändert werden. @YuliKl @anawishnoff @chigy @teaP
Die aktuelle Farbe des dunklen Themas ist #393D1B – was eine gelblich-grüne Farbe zu sein scheint, fast olivfarben. Während das helle Thema ein klareres Grün verwendet, fast mintgrün.

_Oben die aktuellen Farben, unten eine vorgeschlagene Änderung_

#1d3d1b

Das liegt nicht nur an der Ästhetik, sondern auch daran, dass der olivfarbenere Balken nicht so sehr von der Warnfarbe zu unterscheiden ist

So würde es aussehen