@sapallie , bisakah Anda membuat maket desain dapat diakses publik? Kecuali mereka tidak dibagikan pada saat ini.

Saat ini sedang melakukan pengembangan XAML, dan saya ingin melihat sesuatu seperti ini. Atau, sesuatu seperti kontrol pesan bergulir yang bagus.

Dari sudut pandang branding Microsoft, spanduk kesalahan standar sepertinya bisa sangat salah. Saya khawatir pengguna akhir mengaitkan setiap kesalahan aplikasi dengan merek Microsoft. Saya baru saja membaca proposalnya, dan hal pertama yang muncul di benak saya adalah memelord yang men-tweet tentang spanduk kematian yang mencolok.

@sapallie , bisakah Anda membuat maket desain dapat diakses publik? Kecuali mereka tidak dibagikan pada saat ini.

Maaf @adrientetar , saya belum bisa membagikannya. Desainnya hanya Microsoft untuk saat ini.

@sapallie , terima kasih atas ide fitur yang fenomenal ini! Saya seorang Manajer Program untuk WinUI dan saya bersemangat untuk menyampaikan ini kepada tim!

Saya ingin menulis sedikit tentang proses kami sehingga Anda dapat selaras dengan bagaimana kami akan melanjutkan dari sini. Mulai sekarang, saya akan bekerja untuk menyempurnakan cakupan/persyaratan tingkat tinggi dari proposal ini dan justifikasi untuk pengembangannya. Kemudian saya akan mengajukannya ke seluruh tim WinUI dan kami akan membahas apakah itu sejalan dengan Peta Jalan kami (#717) dan jika kami pikir kami dapat menindaklanjutinya dalam waktu dekat. Jika demikian, saya akan disetujui untuk mengetahui detailnya dan mulai menulis spesifikasi sehingga fitur tersebut siap untuk pengembang.

Berikut adalah beberapa hal yang saya sudah tahu saya perlu mendapatkan sedikit lebih banyak ide untuk...

• Perilaku visual

Apakah proposal Anda untuk edge-to-banner? Atau ubin notifikasi seperti yang dilakukan Notifikasi Windows tetapi di jendela aplikasi seperti di tengah, di sepanjang tepi bawah, atau di sudut?

Maaf @adrientetar , saya belum bisa membagikannya. Desainnya hanya Microsoft untuk saat ini.

Saya tidak berpikir saya akan bisa mendapatkan proposal ini disetujui tanpa dapat memasukkan visual publik dari permintaan sebagai repo _is_ open source dan close-sourcing sisi visual percakapan akan melibatkan proses dan pengalaman untuk komunitas kami . Berdasarkan tanggapan di atas, saya dengan senang hati mencoba menyusun tiruan untuk proposal tersebut. Apakah Anda lebih suka ini atau apakah Anda memiliki garis waktu yang dibayangkan untuk memberikan izin Anda untuk membuat desain Anda publik? Saya suka maket Anda dan akan sangat ingin memasukkannya ke dalam brainstorming kami di sini agar kami tidak membawa diskusi ke arah yang berbeda dengan niat Anda. Tolong beritahu saya! :merah:

Spanduk akan membuat pengguna mengetahui kesalahan yang mencegah mereka menggunakan aplikasi/fitur

Spanduk akan ditutup untuk kesalahan non-kritis

Apakah saya benar dalam membaca pernyataan ini yang berarti Anda juga harus memiliki opsi untuk spanduk yang tidak dapat ditutup untuk kesalahan kritis? Jika demikian, dapatkah Anda memberi tahu saya lebih banyak tentang skenario aplikasi spesifik Anda untuk menerima satu/melanjutkan dari titik memiliki spanduk yang tidak dapat ditutup? Apakah pengguna diturunkan untuk menutup aplikasi kecuali masalahnya terpecahkan? Atau di sinilah tombol akan datang, katakanlah, navigasikan ke halaman pengaturan Jaringan & Internet?

Terima kasih lagi dan saya berharap untuk menyempurnakan ide ini!

Semuanya, silakan merasa terdorong untuk menyumbangkan kebutuhan, desain, dan perspektif Anda ke percakapan ini! :merah:

Saya ingin mengatakan, ada beberapa proposal yang semuanya meminta hal serupa. Daripada menjadikan ini secara khusus sebagai spanduk Kesalahan - mengapa tidak membawa Pemberitahuan Dalam Aplikasi saja dari Toolkit Komunitas. Mungkin ada properti ikon yang ditambahkan, yang akan membuatnya menampilkan ikon kesalahan, atau ikon konfirmasi, dll.

@SavoySchuler – senang mendengar dari Anda. Saya mencoba menjawab semua pertanyaan Anda, tetapi beri tahu saya jika Anda membutuhkan yang lain.

Perilaku visual:
Idealnya spanduk akan mirip dengan ubin Pemberitahuan Windows dan akan disematkan ke bagian atas atau bawah jendela aplikasi. Di mana itu disematkan tergantung pada elemen visual lain di aplikasi dan di mana fokusnya. Keputusan ini harus dibuat oleh seorang desainer.
Saya pikir GIF @mdtauk yang diposting akan menjadi titik awal yang bagus.

Mengabaikan:
Saya pikir masuk akal untuk menggali lebih dalam apa yang saya maksud dengan kesalahan kritis vs. tidak kritis:

• Kesalahan kritis = fungsionalitas aplikasi terganggu karena masalah di seluruh sistem (mis. koneksi internet terputus) – ini harus ditautkan ke pengaturan sistem tempat pengguna mungkin dapat memperbaiki masalah
• Kesalahan tidak kritis = beberapa fungsi terganggu atau satu fitur tidak berfungsi tetapi pengguna masih dapat melakukan hal lain di aplikasi
• Ini juga keren untuk memperkenalkan iterasi spanduk yang murni informasi juga yang dapat digunakan untuk memberi tahu pengguna bahwa pembaruan aplikasi atau fitur baru tersedia.

Dan saya pikir semua ini harus dapat diabaikan (saya memperbaruinya dalam deskripsi proposal juga)

Contoh visual
Saya melakukan beberapa perubahan pada visual dan dapat membagikannya seperti ini:

Contoh-contoh ini adalah iterasi di mana seluruh spanduk pada dasarnya adalah tombol besar. Pengguna dapat mengabaikannya atau mengkliknya untuk membuka pengaturan sistem (kesalahan kritis), membuka halaman web dengan detail tentang perbaikan fitur (peringatan 1), memuat ulang halaman aplikasi (peringatan 2) atau pergi ke toko Microsoft untuk memperbarui aplikasi (informasi).
Dimungkinkan untuk memperluas konsep ini untuk menambahkan beberapa tombol di dalam spanduk.

Saya sangat suka visual untuk spanduk itu. Saya akan memindahkan teks dan ikon ke atas sebesar 4 px, sehingga keduanya dipusatkan di area putih, bukan bilah putih dan berwarna.

Sepakat. Visual yang diposting terlihat cukup bagus.

Saya sangat suka visual untuk spanduk itu. Saya akan memindahkan teks dan ikon ke atas sebesar 4 px, sehingga keduanya dipusatkan di area putih, bukan bilah putih dan berwarna.

Saya belum menghitung pikselnya tetapi sepertinya ini terpusat jika ruang untuk tanda diakritik di atas tinggi-X diperhitungkan.

@sapallie Sudahkah Anda berpikir untuk mengizinkan kontrol ini secara otomatis, atau diberhentikan secara terprogram?

Jika menanyakan tentang sedang/akan offline, masuk akal untuk menghapus prompt seperti itu secara terprogram saat online lagi. (Saya telah melihat aplikasi tidak melakukan ini dan itu dapat menyebabkan pengalaman yang membingungkan.)

Demikian pula, memiliki pesan yang tidak penting yang tidak ditampilkan tanpa batas waktu dapat menghindari kekacauan UI yang tidak perlu dan dapat mencegah pengguna yang kuat untuk keluar dari arus setelah mereka membaca pesan dengan tidak memaksa mereka untuk menutup pemberitahuan secara manual.

Saya mengerti bahwa ada potensi pertimbangan aksesibilitas ekstra di sekitar kontrol dan perilaku ini, tetapi saya yakin cara mengabaikan kontrol ini penting.

Saya pikir penting untuk menyebutkan bahwa kontrol seperti itu tidak dimaksudkan untuk perpesanan umum dalam suatu aplikasi. Kecuali itu benar-benar kasus penggunaan yang diinginkan.

Haruskah aplikasi diizinkan untuk menampilkan beberapa spanduk sekaligus?
Jika demikian, bagaimana mereka akan diatur? Dan apakah ini sesuatu yang dapat dikontrol oleh aplikasi?

Ini akan memuaskan mereka yang telah meminta gaya Android Toast di kontrol notifikasi aplikasi, mungkin juga berguna untuk skenario validasi, untuk menampilkan teks kesalahan di mana ruang dalam formulir sangat mahal.

Saya juga akan menyebutnya sesuatu seperti StatusTip atau StatusNotification sehingga tidak hanya dikaitkan dengan penggunaan negatif.

Saya berasumsi desain akan beradaptasi dengan mengubah penempatan pada bilah berwarna solid ketika ditempatkan di bagian bawah jendela?

Itu mungkin harus memiliki properti batas waktu, dan bahkan dapat memiliki kemampuan untuk menampilkan pesan yang tertunda, seperti cincin kemajuan dan beberapa teks seperti "Masuk sekarang" sebelum beralih ke konfirmasi pesan kesalahan.

Saya sangat suka visual untuk spanduk itu. Saya akan memindahkan teks dan ikon ke atas sebesar 4 px, sehingga keduanya dipusatkan di area putih, bukan bilah putih dan berwarna.

Saya belum menghitung pikselnya tetapi sepertinya ini terpusat jika ruang untuk tanda diakritik di atas tinggi-X diperhitungkan.

Saya pikir kemungkinan besar teks itu dipusatkan secara vertikal di dalam kotak tanpa memperhitungkan bilah berwarna

Berikut adalah bagaimana penempatan bilah berwarna dapat berubah dengan penempatan kontrol

@mrlacey ya, pemecatan terprogram/otomatis ketika spanduk tidak relevan lagi cukup penting – saya menambahkannya ke deskripsi proposal.

Perubahan dan kesalahan status: Untuk itulah spanduk harus digunakan. Bukan pesan umum – saya setuju akan hal itu.

Dan saya pikir banyak spanduk harus berfungsi. Mereka hanya harus ditumpuk.

@mdtauk Saya menamainya "Spanduk status" – terima kasih atas saran Anda.

Untuk status pemuatan – Saya tidak percaya itu harus terjadi di spanduk. Memuat konten harus ditampilkan di aplikasi tempat konten akan benar-benar muncul.

Dan ketika harus mengubah penempatan bilah berwarna – akan sangat bagus jika memiliki fleksibilitas di sana tergantung di mana spanduk kesalahan ditempatkan di jendela aplikasi. 👍

Masalah #622 dan #792 juga dapat dicakup oleh kontrol ini, jika akan dibuat.

@sapallie Catatan Anda tentang keadaan kesalahan kritis menarik sehubungan dengan panduan yang disarankan bahwa spanduk status mengarahkan pengguna ke solusi. Intuisi saya mengatakan bahwa Anda mungkin juga memerlukan API untuk menonaktifkan, atau setidaknya untuk sementara diberhentikan?

Saya mengerti bahwa ada potensi pertimbangan aksesibilitas ekstra di sekitar kontrol dan perilaku ini, tetapi saya yakin cara mengabaikan kontrol ini penting.

@mrlacey , info yang bagus! Untungnya, saya telah mengerjakan sebagian besar hal ini selama mempertimbangkan penghentian otomatis berwaktu di TeachingTip, dan sementara beberapa bermitra dengan tim yang memiliki pengaturan aksesibilitas akan diperlukan, saya tidak percaya fitur ini akan diblokir karena masalah aksesibilitas. +1 pada semua poin Anda yang lain!

Mungkinkah ada kemampuan untuk menambahkan tautan HyperlinkButton ke solusi, atau ke pintasan pengaturan, seperti Jaringan?

Mungkinkah ada kemampuan untuk menambahkan tautan HyperlinkButton ke solusi, atau ke pintasan pengaturan, seperti Jaringan?

Saya membayangkan subteks yang berisi hyperlink ke dalam aplikasi atau Pengaturan Aplikasi (lihat halaman Kode Galeri Kontrol Xaml TeachingTip). Apakah Anda memikirkan sesuatu yang lebih standar @mdtauk?

@SavoySchuler Konten properti bukan MessageText?

Catatan Anda tentang keadaan kesalahan kritis menarik sehubungan dengan panduan yang disarankan bahwa spanduk status mengarahkan pengguna ke solusi. Intuisi saya mengatakan bahwa Anda mungkin juga memerlukan API untuk menonaktifkan, atau setidaknya untuk sementara diberhentikan?

Ya, mungkin saya kira ... Pasti tidak ada salahnya untuk menambahkannya. Bagaimanapun, ini menambah fleksibilitas dan mungkin akan sangat berguna untuk beberapa kasus penggunaan.

@mdtauk - Ya, maksud saya tentu saja properti konten!

@sapallie

Catatan Anda tentang keadaan kesalahan kritis menarik sehubungan dengan panduan yang disarankan bahwa spanduk status mengarahkan pengguna ke solusi. Intuisi saya mengatakan bahwa Anda mungkin juga memerlukan API untuk menonaktifkan, atau setidaknya untuk sementara diberhentikan?

Ya, mungkin saya kira ... Pasti tidak ada salahnya untuk menambahkannya. Bagaimanapun, ini menambah fleksibilitas dan mungkin akan sangat berguna untuk beberapa kasus penggunaan.

Di satu sisi Anda memiliki pop-up yang tidak dapat ditutup yang menutupi UI (dan mungkin menyebabkan kesalahan berbasis skenario sendiri dalam melakukannya) dan di sisi lain Anda memiliki peringatan aplikasi/kesalahan kritis yang tidak persisten yang juga membuat indra spidey saya tergelitik.

Mungkin alih-alih pop-up gaya UI + tip, akankah spanduk di UI + tepi-ke-tepi (seperti yang digunakan oleh Office Suite untuk memberi tahu tentang pembaruan - lihat di bawah) memenuhi kebutuhan sementara juga sedang memberikan ruang persisten di UI Anda?

@SavoySchuler Mungkin ada perilaku pada kontrol, di mana ia menempatkan header dan konten pada satu baris, jika lebar kontrol cukup lebar.

Saran saya sebelumnya dengan tata letak pemosisian yang berbeda juga akan berfungsi jika kontrol meluncur keluar dari tepi kontrol lain - tidak hanya di dalam jendela atau panel.

Mungkin alih-alih pop-up gaya UI + tip, akankah spanduk di UI + tepi-ke-tepi (seperti yang digunakan oleh Office Suite untuk memberi tahu tentang pembaruan - lihat di bawah) memenuhi kebutuhan sementara juga sedang memberikan ruang persisten di UI Anda?

Ya, itu juga berhasil. 👍

Sepertinya akan ideal untuk memiliki opsi inline dan overlay karena dalam retrospeksi Office Suite dapat mengandalkan semua aplikasi mereka yang memiliki Pita. @mdtauk Saya suka saran Anda yang mulai mengisyaratkan bagaimana kita berpikir tentang perilaku penampilan/penghilangan.

@all , adakah yang bisa berbagi dengan saya skenario spesifik di aplikasi nyata Anda di mana Anda membayangkan kontrol ini digunakan? Secara khusus, saya tertarik pada pemikiran tentang pintu masuk visual dan interaksi pengguna yang diperlukan untuk meminta pemberhentian? Apakah persyaratan di sini mencakup perilaku inti yang Anda butuhkan dari kontrol ini?

@SavoySchuler Mempertimbangkan Masuk dan Keluar, itu bisa meluncur dari tepi, tetapi juga bernyawa sebagai hamparan mengambang jika pengembang memilih. Geser masuk dari tepi kanan layar pada tingkat OS - dari tepi kanan jendela aplikasi, atau keluar dari tepi kontrol atau elemen UI.

Ada tombol tutup untuk menutup, tetapi untuk layar sentuh, kemampuan untuk menggesernya ke arah sebaliknya dari tempat munculnya juga bisa berfungsi. Untuk memastikan konsistensi, ini perlu dibangun ke dalam kontrol.

Mengetuk kontrol mungkin akan memicu tindakan yang akan ditentukan oleh teks pesan.
Pengecualian adalah untuk menampilkan kemajuan suatu tindakan yang tidak akan dapat diabaikan sampai waktu habis dengan kesalahan atau berhasil diselesaikan.

Contoh Animasi

Masuk, Perbarui, Keluar - Tautan YouTube

Animasi Dalam - Tautan YouTube

TeachingTip ada dan merupakan cara yang baik untuk menargetkan Kontrol atau Elemen UI tertentu, dan bagus untuk menyoroti fitur baru dalam aplikasi. Secara teknis dapat digunakan untuk tujuan yang sama seperti StatusBanner ini, jadi beberapa pemikiran perlu masuk ke penggunaan semantik masing-masing, dan mengidentifikasi apa yang membuat masing-masing unik.

Di bawah ini adalah pemikiran pribadi saya tentang perbedaan antara Spanduk Status dan Tip Mengajar

• Spanduk Status _Saya percaya_ harus didorong untuk status aktual yang dapat ditindaklanjuti, dan karenanya harus meminta satu tindakan saat diketuk.

  • Tip Pengajaran akan menampilkan tindakan sebagai tombol atau hyperlink, biasanya digunakan untuk informasi yang dapat dengan mudah diabaikan.

• Ketika sebuah aplikasi atau kondisi OS berubah, yang diperlukan untuk aplikasi tersebut, maka itu akan memicu Banner Status untuk ditampilkan.

  • Tip Pengajaran tidak akan memberikan informasi penting, dan sekali diberhentikan tidak akan ditampilkan lagi kecuali sesuatu yang baru ditambahkan untuk dipanggil.

• Spanduk Status harus tetap ada saat ditampilkan, kecuali ditutup dengan tombol Tutup, atau mungkin digesek saat bersentuhan. Dengan pengecualian untuk penyelesaian skenario kemajuan yang sedang berlangsung, atau status OS diselesaikan (Jaringan dipulihkan).

  • Tip Pengajaran mungkin akan menyertakan fungsi batas waktu, tidak akan ditampilkan secara acak saat aplikasi sedang berjalan, sebagian besar ditampilkan pada peluncuran aplikasi atau navigasi ke halaman/layar.

• Status Banner harus digunakan di OS Shell secara konsisten - mungkin ada satu set banner lokal standar dengan konten, ikon, warna, sebagai enum.

• Mungkin ada beberapa logika OS untuk menambahkan Spanduk Status ke jendela aplikasi.
  Misalnya ketika aplikasi mencoba mengakses jaringan, dan tidak tersedia, OS dapat menampilkan Spanduk Status standar di dalam jendela aplikasi, bukan di ruang layar, atau menyerahkannya kepada pengembang untuk diterapkan.

  • Tip Pengajaran akan khusus untuk aplikasi, dan tidak ada konten standar yang ditentukan, dan untuk pengembang saja untuk disertakan.

@mdtauk , karya yang luar biasa di video! Mereka sangat membantu dalam menghidupkan ide-ide ini.

Kebutuhan untuk ketekunan adalah poin yang sangat baik dan saya pikir fitur pemberhentian juga dapat dikurangi dengan Pedoman yang menyarankan membuat pemberitahuan status tersedia secara terus-menerus di panel pemberitahuan jika kritis atau, _mungkin_ memunculkannya kembali pada interval non-invasif jika masalah tetap ada. Ini bukan pernyataan pasti, hanya poin pertimbangan yang harus dibuat untuk memastikan bahwa solusi ini komprehensif dengan tepat dalam solusi skenarionya.

Kebutuhan untuk membedakan TeachingTip dari fitur ini sangat tepat dan saya setuju dengan poin Anda. Kontrol ini akan melayani kebutuhan yang berbeda bahwa TeachingTip tidak dirancang untuk dipecahkan meskipun mungkin ada peluang untuk beberapa fitur atau kode bersama.

Apakah ada pemangku kepentingan yang tidak terpenuhi kebutuhannya dengan hal seperti yang dibagikan @mdtauk di atas?

Tampaknya ada perbedaan antara Spanduk Status yang diolok-olok di OP dan pemberitahuan lebar penuh seperti yang terlihat di Office (gambar di atas dalam komentar sebelumnya) atau Visual Studio (seperti di bawah)

Perbedaan antara keduanya berarti saya bertanya-tanya apakah mereka harus menjadi kontrol yang sama atau terpisah.

Berikut adalah daftar cepat properti yang dibutuhkan masing-masing. (nama misalnya, tidak tetap tetapi dimaksudkan untuk menyimpulkan makna)

Spanduk Status

• _Ikon_
• Pesan teks
• Teks Tambahan (baris kedua)
• Jenis (Kritis, Peringatan, atau Informasi)
• Warna
• Lokasi
• Arah Animasi
• Ketuk Acara/Perintah
• Waktu habis

Pemberitahuan lebar penuh

• _Ikon (mungkin)_
• Pesan teks
• Gaya Tautan (Tombol atau HyperLink)
• Tautan (Teks dan Ketuk Acara/Perintah - beberapa)
• Waktu habis

Hanya properti yang dicetak tebal yang ada di keduanya. _Icon_ berpotensi membingungkan karena berbagai jenis ikon (dalam lingkaran, atau garis besar) diperlukan untuk setiap jenis.
Juga perlu ada properti untuk menunjukkan gaya mana yang akan digunakan.

Bagi saya ini terasa seperti ada terlalu banyak perbedaan untuk satu kontrol dan menyatukan semua fungsi ini akan membingungkan dan rumit.
Saya pikir dua konsep ini:

• spanduk lebar penuh yang dapat ditutup dengan nol atau lebih sub-elemen yang dapat ditindaklanjuti
• spanduk yang dimaksudkan untuk menunjukkan perubahan status dan yang beroperasi sebagai satu tombol

akan memberikan nilai paling banyak dan paling sedikit kebingungan sebagai kontrol terpisah.

Bagaimana spanduk status animasi mendukung menampilkan beberapa pemberitahuan sekaligus?
Atau apakah ini sekarang di luar jangkauan?

• Status Banner harus digunakan di OS Shell secara konsisten - mungkin ada satu set banner lokal standar dengan konten, ikon, warna, sebagai enum.
• Mungkin ada beberapa logika OS untuk menambahkan Spanduk Status ke jendela aplikasi.
  Misalnya ketika aplikasi mencoba mengakses jaringan, dan tidak tersedia, OS dapat menampilkan Spanduk Status standar di dalam jendela aplikasi, bukan di ruang layar, atau menyerahkannya kepada pengembang untuk diterapkan.

Tingkat integrasi OS ini menunjukkan ambisi di luar kendali tunggal dan di luar WinUI.

Apakah hanya "spanduk terlokalisasi standar" yang tersedia atau apakah ini selain dapat memiliki sesuatu yang sepenuhnya dapat disesuaikan?
Jika menyediakan beberapa secara default, apakah itu?
Saya akan prihatin bahwa hanya menyediakan serangkaian opsi terbatas yang tidak perlu membatasi potensi kontrol semacam itu.

Memiliki OS menunjukkan spanduk di aplikasi terbuka untuk skenario sistem yang luas seperti hilangnya konektivitas jaringan menimbulkan sejumlah kekhawatiran bagi saya.

• Pusat tindakan sudah menyediakan cara untuk menyediakan pemberitahuan di seluruh sistem.
• Dengan beberapa jendela terbuka, melihat spanduk yang ditampilkan di masing-masing jendela tampaknya tidak perlu mengganggu.
• Memiliki pemberitahuan tampilan sistem (spanduk) di dalam aplikasi adalah sesuatu yang saya harapkan pengembang ingin kontrol atau nonaktifkan.
• Jika aplikasi hanya sesekali membutuhkan koneksi jaringan, melihat permintaan tentang kehilangan koneksi dapat membingungkan atau mengganggu pengguna jika tidak relevan dengan apa yang sedang mereka lakukan.
• Ini akan mengikat aplikasi ke versi OS tertentu untuk mendapatkan pembaruan atau perilaku yang diinginkan. Perubahan fungsi OS di masa mendatang dapat merusak atau mengubah aplikasi dengan cara yang tidak diinginkan.
• Pembaruan dan perbaikan bug hanya akan tersedia pada jadwal rilis level OS. Bagian dari alasan di balik keberadaan WinUI adalah untuk memutuskan sambungan itu dengan fungsionalitas OS dan aplikasi.

• Salah satu tujuan dari kontrol seperti yang dijelaskan di sini adalah untuk memudahkan pengembang untuk mengimplementasikannya. Menghapus kemampuan mereka untuk mengontrolnya akan menyebabkan masalah untuk aplikasi di mana skenario tertentu harus ditangani dengan cara khusus.

Baru saja menemukan masalah ini dari posting Twitter tentang mock-up animasi. Tampaknya tumpang tindih dengan banyak pekerjaan yang telah kami lakukan dengan kontrol InAppNotification di toolkit. Termasuk hal-hal seperti bagaimana banyak pesan ditangani.

Kami telah belajar bahwa meskipun ini tampak seperti kontrol sederhana, ini cukup rumit. Akan menyenangkan untuk memiliki solusi holistik yang dapat dibangun di dalam WinUI meskipun untuk mencakup semua kasus ini. Kemudian kita dapat menghentikan kontrol toolkit.

Berunding dengan @ryandemopoulos , dan saya ingin sedikit memperbaiki percakapan awal ini untuk fokus pada masalah (perlunya kesalahan UI) sebelum solusi (setiap bagian/bagian tertentu dari kesalahan UI).

Untuk tujuan ini, tujuan pertama saya adalah mengunci skenario dan persyaratan untuk kesalahan UI ( @sapallie , skenario "Kritis: konektivitas wifi hilang" Anda adalah awal yang sempurna). Dari sana, kita dapat bekerja sama untuk memutuskan apakah solusinya menyertakan satu bagian dari UI pemberitahuan kesalahan atau sekumpulan komponen UI kesalahan. Dari situ, kami akan memperluas perincian kesamaan API @mrlacey (terima kasih telah memulai ini) untuk memutuskan apakah ada cukup kesamaan untuk pendekatan derivasi vs. kontrol yang berbeda jika ada beberapa keluaran dari percakapan ini. Saya tidak ingin mendahului diri saya sendiri tetapi argumen @mrlacey untuk solusi berbeda _is_ sudah terlihat jelas dan tidak apa-apa. Fokus saya adalah menciptakan rangkaian solusi yang tepat untuk semua orang di sini.

Jadi, untuk siapa saja ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , dan @mrlacey) yang sangat relevan dengan kontrol ini, dapatkah Anda memberikan saya yang berikut di sini atau dm @ [email protected] :

• Judul aplikasi
• Deskripsi skenario (kesalahan, kritis/tidak kritis, dan deskripsi bagaimana Anda ingin mempresentasikannya)
• Cuplikan layar layar aplikasi tempat kesalahan akan muncul (jika tersedia)

Saya telah memperbarui Masalah untuk mencerminkan pendekatan yang berfokus pada masalah ini dan saya telah membuat katalog persyaratan, skenario, dan kemungkinan solusi yang dijelaskan sejauh ini.

@sapallie Saya mencoba bersikap sopan semampu saya dalam melestarikan pekerjaan awal Anda. Riwayat versi dapat dilihat di menu tarik-turun "diedit oleh..." di bagian atas terbitan. Tolong beri tahu saya jika saya tidak menangkap apa pun dengan benar.

Saya mengajukan ini ke tim WinUI dan kami percaya bahwa fungsi yang ditentukan di sini akan mampu melayani tidak hanya pesan kesalahan tetapi juga pesan status seluruh aplikasi yang berumur panjang secara keseluruhan. Ini termasuk jenis pesan status "pembaruan tersedia" dan "pencadangan selesai" selain skenario khusus kesalahan.

Saya telah memperbarui masalah ini untuk mencerminkan pendekatan yang lebih holistik ini. Saya berharap untuk menyelesaikan persyaratan dan skenario dalam beberapa minggu mendatang sehingga kami dapat memeriksa bagian keluaran UI yang diperlukan untuk menampilkan pesan-pesan ini.

Saya akan mengulangi permintaan saya di atas. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , dan @mrlacey , untuk status/pesan kesalahan yang ingin Anda tampilkan di aplikasi Anda, dapatkah Anda memberikan yang berikut ini di sini atau di [email protected] :

• Judul aplikasi
• Deskripsi skenario (pesan status, kritis/tidak kritis, dan deskripsi bagaimana Anda ingin mempresentasikannya)
• Cuplikan layar layar aplikasi tempat kesalahan akan muncul (jika tersedia)

Perlu dicatat bahwa, imo, dialog popup harus dihindari jika memungkinkan. Web penuh dengan permintaan munculan di mana-mana dan mereka mengganggu aliran yang mencoba menarik perhatian Anda. Misalnya, saya pikir status kosong ( contoh ) harus lebih disukai misalnya jika sesuatu tidak dapat dimuat dalam kontrol.

Sehubungan dengan visual yang diposting @mdtauk , apakah kita benar-benar membutuhkan popup yang ditampilkan dari keempat tepi layar/aplikasi? Inti dari WinUI adalah untuk menstandardisasi posisi dan tampilan item tersebut sehingga semua aplikasi akan menggunakan hal yang sama, dan dalam hal ini, Android Snackbar adalah referensi yang jelas. Hal lain yang perlu diperhatikan dengan Snackbar adalah tidak menampilkan kesalahan dengan warna merah cerah atau apa pun, ia memiliki penampilan yang tenang yang menurut saya bermanfaat lagi untuk tidak terlalu mengganggu pengguna dari apa yang dia lakukan.

Kami juga memerlukan panduan tentang kapan harus menggunakan popup ini alih-alih dialog misalnya, jika tidak, itu hanya akan membuat fragmentasi (aplikasi yang berbeda menggunakan kontrol perpesanan dengan cara yang berbeda).

Flyout memiliki konsep penempatan, kontrol ini bisa melakukan hal yang sama. Muncul dari tepi bagian dalam kontrol wadah, baik itu Konten Halaman atau Tab, dll.

@adrientetar Tidak semua aplikasi sama, jadi meskipun akan ada default untuk kontrol ini, perlu ada cara bagi pengembang untuk mengubah lokasi ini, tanpa harus membuat template ulang, atau merekayasa ulang kontrol.

Office menggunakan ruang di bawah Pita. Edge menggunakan bagian bawah layar. Hanya Windows itu sendiri, yang dapat melampirkannya ke tepi Shell atau Layar, dan mungkin ada alasan bagus untuk mencegah aplikasi meniru peringatan tingkat sistem.

Selain itu, setiap pengembang memiliki kemampuan untuk mengubah gaya kontrol peringatan mereka sendiri, jadi pada tahap ini, itu harus sefleksibel mungkin, dan kemudian tim Shell akan menentukan batasan apa yang digunakan untuk penggunaan kontrol.

Tim Telepon Anda memiliki salah satu dari jenis kontrol ini, jadi mungkin Anda dapat bertanya kepada mereka masalah apa yang mereka temui, dan membujuk mereka untuk beralih menggunakan kontrol WinUI setelah selesai dan disertakan?

Dropbox juga menggunakan Snackbar dalam sistem desain mereka (gulir ke bawah, baris kedua hingga terakhir gambar).

Baru-baru ini melihat beberapa contoh lagi dari pesan status seluruh aplikasi yang berumur panjang:

(Pesan "perekaman dimulai" di teams)

("mencoba terhubung ke koordinator game" di Dota 2)

Maaf ini kecil--gambar pertama diambil dari desktop saya dengan monitor ultrawide. :)

Beberapa snackbar dropbox berisi progress bar di bagian bawah. Haruskah ini dimasukkan di sini? Masuk akal misalnya untuk hal-hal seperti mengunggah, mengunduh, memperbarui, menyinkronkan kemajuan. Ini bukan imo yang harus dimiliki, tapi mungkin bisa atau harus?

Haruskah ini dibulatkan? Atau tidak?

Ya, saya pikir perbedaan utama di sini dari Tip Pengajaran adalah bahwa aplikasi ingin mengoordinasikan ruang perpesanan mereka dan mungkin memiliki beberapa pembaruan kesalahan/status untuk ditampilkan pada saat yang sama (atau berturut-turut).

Saya pikir idealnya, ini adalah satu kontrol yang dikonfigurasi dan ditempatkan oleh pengembang di dalam aplikasi mereka dan kemudian menyalurkan pesan juga (yang saya bayangkan memiliki semacam jenis untuk menunjukkan apakah itu kesalahan, status, peringatan, atau pesan umum lainnya).

Dalam kasus spanduk dan pop-up, saya telah melihat aplikasi yang mungkin memiliki banyak pesan. Terkadang mereka menumpuk spanduk yang kemudian mendominasi real-estate UI, jadi alangkah baiknya jika solusi ini menghindarinya (meskipun tidak ada yang akan mencegah pengembang menggunakan beberapa contoh kontrol untuk membuat kembali perilaku itu).

Saya terkejut kami juga belum memanggil VS Code, karena mereka memiliki panel notifikasi pop-up yang menumpuk di kanan bawah yang juga memiliki tombol tindakan tambahan (untuk melompat ke pengaturan misalnya).

Cuplikan Layar Contoh Kode VS:

Mereka memiliki berbagai jenis ikon yang muncul di kiri atas, tindakan tombol yang dapat disesuaikan, dan kemampuan untuk memiliki ikon 'roda gigi' untuk mengonfigurasi pengaturan tentang pemberitahuan per ekstensi, dalam kasus mereka.

Baru saja melihat tangkapan layar Cortana ini ...

MessageBar Office UI Fabric tampak hebat, IMO:

saya perhatikan bahwa Samsung Notes untuk Windows 10 menggunakan pemberitahuan bersulang untuk menjelaskan bahwa catatan dibuang karena tidak ada apa pun di dalamnya yang sangat mengganggu

Halo semuanya! Saya Manajer Program untuk WinUI dan mengambil proposal ini kembali dari @SavoySchuler. Sudah ada banyak diskusi hebat dan berbagi ide di utas ini, terima kasih atas semua saran Anda!

Karena sudah beberapa bulan sejak ada beberapa aktivitas di sini, saya ingin memeriksa kembali dengan semua orang dan mengulangi di mana kita berada saat ini.

Sebagai ringkasan cakupan kami saat ini di bagian atas proposal:

• Pemberitahuan akan untuk memperingatkan pengguna tentang informasi penting yang terkait dengan aplikasi secara keseluruhan
• Akan mendukung konten dan gaya khusus
• Akan dapat diberhentikan secara otomatis dan terprogram
• Notifikasi harus dapat ditutup oleh pengguna
• Harus mendukung beberapa notifikasi yang dapat ditumpuk sesuai dengan cara yang ditentukan aplikasi
• Harus responsif terhadap pengubahan ukuran aplikasi dan perubahan UI
• Notifikasi bukan untuk menampilkan notifikasi di seluruh sistem

Silakan berkomentar dan beri tahu saya jika saya melewatkan sesuatu dalam ringkasan ruang lingkup saya atau jika Anda tidak setuju. Saya ingin memastikan kita semua berada di halaman yang sama sebelum melangkah maju 😊

Sekarang setelah kami mendefinisikan cakupannya, ada beberapa skenario dan pengalaman pengguna tertentu yang masih perlu ditentukan. Harapan saya adalah mendefinisikan pengalaman ini akan membantu memandu keterjangkauan UI untuk kontrol. Apa pemikiran Anda untuk skenario Anda?
CC: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

Pengalaman-pengalaman tersebut adalah:

• Bagaimana notifikasi meninggalkan tampilan
  
  
  
  • Pengguna secara manual mengabaikan notifikasi
  
  
  • Notifikasi secara otomatis habis dan menghilang dengan sendirinya
  
  
  • Notifikasi hanya menghilang setelah pengguna melakukan tindakan yang berhubungan dengan mengapa notifikasi muncul pertama kali
    
    
    
    
    
    • yaitu Setelah menerima notifikasi bahwa internet terputus, notifikasi tersebut hanya hilang saat internet terputus
    
    
    
  
  
  • Lainnya?
  
  
• Bagaimana reaksi pengguna terhadap notifikasi
  
  
  
  • Segera ambil tindakan terkait notifikasi tersebut
  
  
  • Tunda tindakan mereka terkait dengan pemberitahuan di lain waktu
  
  
  • Abaikan dan/atau abaikan pemberitahuan sepenuhnya
  
  
  • Lainnya?
  
  
• Kapan notifikasi akan muncul
  
  
  
  • Saat peluncuran aplikasi
  
  
  • Secara terprogram dari status aplikasi
  
  
  • Setelah pengguna melakukan tindakan (yaitu memilih untuk membuat cadangan dokumen mereka)
  
  
  • Lainnya?
  
  
• Jika memungkinkan agar beberapa notifikasi muncul sekaligus dan alasannya

Sekali lagi terima kasih atas semua pemikiran Anda dan saya berharap dapat mengungkapkannya!

Senang melihat proposal ini tidak dilupakan @gabbybilka dan terima kasih telah menerimanya!

Jika memungkinkan, Anda dapat menghubungi mereka yang bekerja pada aplikasi pihak pertama yang menyertakan jenis UI pemberitahuan ini untuk membuat daftar persyaratan, bagi mereka untuk berpindah dari solusi khusus mereka, ke kontrol asli WinUI. Kebutuhan mereka, dikombinasikan dengan keinginan dan kebutuhan masyarakat, harus cukup menutupi V1 dari kontrol ini.

@chigy akan menjadi seseorang untuk diajak bicara tentang spesifikasi desain akhir, karena dia bekerja dengan tim Desain Lancar.

Microsoft harus memimpin dengan memberi contoh dengan ini, jika orang lain didorong untuk menggunakan kontrol WinUI yang konsisten.

• Cortana
• musik alur
• Film dan TV
• Telepon Anda

Itulah aplikasi yang muncul di pikiran.

@gabbybilka kami juga memiliki kontrol di Windows Community Toolkit , jadi senang membicarakannya dengan Anda kapan saja. Akan sangat bagus jika memiliki jalur peningkatan untuk pengguna kami di sini dan memigrasikannya dari Toolkit ke WinUI.

Saya pikir dari ringkasan awal Anda yang mencakup sebagian besar hal, tetapi mungkinkah baik untuk menyebut sesuatu di sekitar memiliki tombol opsional yang dapat ditindaklanjuti juga? Atau apakah itu selalu hanya konten khusus?

Tindak lanjut dari toolkit dengan beberapa riwayat kontrol dari toolkit (sudah ada beberapa saat):

• Masalah Asli
• Tinjauan PR Pertama
• GitHub History - tidak yakin bagaimana cara mengambil daftar lengkap pada satu halaman, jadi gulir ke bawah dan terus klik 'Lama'

Gaya dalam toolkit dimodelkan setelah gaya pemberitahuan Microsoft Edge dan VS Code asli (yang keduanya telah diperbarui sejak saat itu). Tetapi seperti yang ditunjukkan, ini fleksibel dan dapat ditempa ulang dan akan berfungsi baik untuk bilah status tingkat atas peringatan gaya Office ATAU pemberitahuan gaya pop-up umum.

Halo lagi! Sebagai pembaruan tentang ini, saya baru-baru ini mengajukan kembali proposal ini ke tim dan menerima izin untuk mendefinisikan lebih lanjut fitur ini.

Untuk skenario yang diuraikan sebelumnya, kami ingin bergerak maju dengan membuat kontrol yang saat ini berjudul InformationBar (singkatnya InfoBar) untuk mewakili pesan status penting yang berumur panjang, di seluruh aplikasi. Pemikiran desain visual awal terinspirasi oleh MessageBar FluentUI dan bagaimana Teams menampilkan pesan "Sekarang Merekam" dan "Internet terputus".
Secara khusus, termasuk ikon, judul, area pesan fleksibel, dan tombol tutup sebagai komponen visual utama, minimum, dalam wadah yang secara default sesuai dengan lebar area konten tempatnya berada. Seperti yang dicakup sebelumnya, InfoBar akan ditutup melalui pengguna atau secara terprogram ketika fungsionalitas aplikasi yang memengaruhi status diselesaikan, yaitu konektivitas internet dipulihkan, tanpa animasi masuk/keluar.

Tim (sekarang merekam)

Kantor (mode kompatibilitas)

Tim (tidak ada internet)

Saat API mulai mengkristal, saya akan mulai memandu diskusi ke spesifikasi. Sementara itu jangan ragu untuk terus membagikan skenario Anda di mana Anda akan menggunakan InfoBar dan fungsi apa yang Anda butuhkan 😊

Sebelumnya dalam diskusi @mrlacey dan yang lainnya mengemukakan potensi untuk memiliki dua kontrol terpisah yang dapat mencakup skenario yang disebutkan.

Saya pikir dua konsep ini:

• spanduk lebar penuh yang dapat ditutup dengan nol atau lebih sub-elemen yang dapat ditindaklanjuti
• spanduk yang dimaksudkan untuk menunjukkan perubahan status dan yang beroperasi sebagai satu tombol

akan memberikan nilai paling banyak dan paling sedikit kebingungan sebagai kontrol terpisah.

Saya menyadari bahwa gaya visual dan komponen InfoBar mungkin tidak cocok untuk beberapa kasus penggunaan yang dibagikan sebelumnya. Jika skenario dan fungsionalitas aplikasi spesifik Anda memerlukan gaya visual yang berbeda, jangan ragu untuk terus membagikan situasi tersebut di utas ini.

Terima kasih lagi semuanya!

Kontrol harus dirancang untuk bekerja dengan baik dengan template dan gaya - sehingga dapat dibentuk agar sesuai dengan kebutuhan sementara semua perilaku adalah properti dari kontrol.
Animasikan atau Jangan Animasikan.
Tampilkan Tombol Tutup atau Sembunyikan.
Posisi.
Tampilkan Ikon atau tidak.

dll

Saya menyadari bahwa gaya visual dan komponen InfoBar mungkin tidak cocok untuk beberapa kasus penggunaan yang dibagikan sebelumnya. Jika skenario dan fungsionalitas aplikasi spesifik Anda memerlukan gaya visual yang berbeda, jangan ragu untuk terus membagikan situasi tersebut di utas ini.

Terima kasih lagi semuanya!

Hebat itu ke depan. Gaya visual itu seperti yang ditunjukkan, Anda meninggalkan banyak hal yang diinginkan sampai-sampai saya tidak ingin menggunakan aplikasi.

Desain yang diposting @mdtauk atau tangkapan layar Cortana di atas akan jauh lebih disukai. Desain aplikasi harus maju tidak terhalang oleh program.

Akankah/dapatkah ini juga bertindak sebagai CommandBar yang dapat diabaikan seperti yang digunakan saat menyajikan/berbagi desktop? Misalnya

Saya tahu itu tidak akan mendukung overlay di atas segalanya, tetapi dalam hal memperbaiki lebarnya dan meletakkannya di lapisan overlay aplikasi, saya bisa melihat tumpang tindih dalam desain/fungsi yang serupa dalam arah ini.

@mdtauk

Kontrol harus dirancang untuk bekerja dengan baik dengan template dan gaya - sehingga dapat dibentuk agar sesuai dengan kebutuhan sementara semua perilaku adalah properti dari kontrol.
Animasikan atau Jangan Animasikan.
Tampilkan Tombol Tutup atau Sembunyikan.
Posisi.
Tampilkan Ikon atau tidak.

@shaheedmalik

Hebat itu ke depan. Gaya visual itu seperti yang ditunjukkan, Anda meninggalkan banyak hal yang diinginkan sampai-sampai saya tidak ingin menggunakan aplikasi.

Desain yang diposting @mdtauk atau tangkapan layar Cortana di atas akan jauh lebih disukai. Desain aplikasi harus maju tidak terhalang oleh program.

Terima kasih atas tanggapan Anda di sana! Saya setuju bahwa kontrol harus cukup fleksibel untuk perilaku dasar ini dan kemampuan penyesuaian dalam sistem Desain Lancar. Visual yang saya bagikan sebagian besar adalah referensi dari contoh yang diterapkan sebelumnya.
Kami akan terus mencoba untuk mencapai keseimbangan antara membebani satu kontrol dengan terlalu banyak fungsionalitas sambil memastikannya dapat disesuaikan dan cukup berguna untuk berbagai skenario pesan status di seluruh aplikasi yang berumur panjang.

Akankah/dapatkah ini juga bertindak sebagai CommandBar yang dapat diabaikan seperti yang digunakan saat menyajikan/berbagi desktop? Misalnya

@michael-hawker

Saya pikir ini adalah skenario menarik yang belum diangkat di utas dan berpotensi didukung oleh kontrol ini. Terima kasih telah membawanya ke perhatian kami! Mengenai pelingkupan, ini tampaknya merupakan skenario prioritas yang lebih rendah tetapi saya setuju bahwa desain/fungsinya serupa di luar prioritas overlay.

Apakah ada pembaruan tentang masalah ini? Kami sedang merencanakan UI untuk menampilkan status operasi file di File UWP, desain yang kami condongkan dapat mengambil manfaat dari fitur yang diusulkan di sini.

Hai @yaichenbaum , terima kasih sudah check in! Sebagai pembaruan pada proposal ini, dengan senang hati saya membagikan dokumen spesifikasi yang mulai kami buat.

Sebagai ringkasan dari apa yang telah didefinisikan sejauh ini, kami memilih untuk membuat satu kontrol dengan dua mode visual, "Bar" dan "Toast" atau "Kartu". Upaya kami saat ini adalah dalam mendefinisikan dan membuat prototipe mode "Bar". Komponen dari kedua mode ini sama dan direncanakan hanya berbeda dalam tata letak visual. Karena akan ada beberapa mode visual, saat ini saya menganggap kontrol ini StatusBanner alih-alih InformationBar untuk tidak membatasi pada gaya "Bar" tunggal, namun, jangan ragu untuk membagikan ide Anda untuk penamaan 😊

Komponen utama StatusBanner dari kiri ke kanan dalam tata letak adalah:

• Warna status
• ikon
• Judul
• Pesan
• tombol tindakan
• Tutup tombol

Properti ini opsional dan konten khusus melalui properti "Konten" masih merupakan opsi.

Selain itu, kami berencana untuk mendefinisikan berbagai Jenis Spanduk yang dapat disetel oleh pengembang yang memiliki ikon prasetel dan kombinasi warna bergantung pada statusnya. Ini dapat menyederhanakan pemilihan Ikon atau BannerColor yang benar berdasarkan kekritisan notifikasi dan memberikan beberapa konsistensi di seluruh aplikasi. Menyesuaikan Ikon atau BannerColor juga didukung.

Prototipe kertas StatusBanner dalam mode "Bar" tanpa tombol tindakan atau tombol tutup khusus.

Desain tata letak bilah StatusBanner saat ini sangat terinspirasi oleh desain @mdtauk untuk kartu status, terima kasih!

Jika Anda ingin berbagi umpan balik sehubungan dengan keadaan spesifikasi saat ini, jangan ragu untuk berkomentar di masalah ini. Langkah kami selanjutnya adalah memperkuat desain dan cuplikan kode (dan memperluas untuk mencakup lebih banyak kasus penggunaan) dan mendefinisikan fungsionalitas seperti penumpukan dan pembungkusan pesan. Terima kasih semuanya!

@yaichenbaum sementara itu ada kontrol InAppNotification dari Toolkit.

@gabbybilka Terima kasih atas pembaruannya, fitur penting yang saya perlukan untuk kasus penggunaan saya adalah kemampuan untuk menampilkan beberapa pesan status sekaligus, seperti @hawkerm yang dibagikan sebelumnya di utas ini. Memiliki kontrol yang menangani penempatan beberapa pesan status akan menjadi nilai tambah.

@yaichenbaum sementara itu ada kontrol InAppNotification dari Toolkit.

@hawkerm Saya belum banyak melihat InAppNotification tetapi saya lebih suka menunggu versi WinUI daripada beralih ke kontrol baru ketika sudah siap.

Halo semuanya!
Mohon maaf atas kurangnya waktu antara pembaruan terakhir dan sekarang, kami telah bekerja keras untuk mendefinisikan kontrol ini 😊
Anda mungkin telah melihat prototipe @chenss3 bergabung dalam repo beberapa minggu yang lalu, kami sangat senang melihat ini menjadi hidup! Pada tahap ini, kami tertarik untuk terhubung dengan konsumen mana pun dari kontrol ini yang tertarik untuk membuat prototipe dan menggunakan ini dalam aplikasi mereka. Harap hubungi dan bagikan aplikasi apa yang Anda kembangkan, skenario saat Anda menggunakan kontrol ini, jika Anda memerlukan bantuan untuk memulai, dan umpan balik Anda menggunakan prototipe.

Saat kami mulai mencari tahu detail implementasi untuk versi pop-up dari kontrol ini dengan dukungan untuk pemosisian dan penumpukan beberapa notifikasi, kami memutuskan untuk terus mengerjakan versi sebaris dalam waktu dekat . Kami mendengar tanggapan Anda tentang memerlukan fungsionalitas pop-up untuk beberapa skenario Anda dan akan terus bergerak ke arah itu! Sementara itu, kami sedang mengembangkan versi prototipe berikutnya yang lebih mirip dengan maket di bawah ini.

Silakan periksa spesifikasi jika Anda ingin melihat beberapa contoh lagi:

Terima kasih semuanya dan saya menantikan kabar dari Anda!

Apakah ini hanya tersedia di WinUI 3, atau akan masuk ke pra-rilis WinUI 2?

@kmgallahan WinUI 2 pra-rilis, belum begitu yakin dengan versi kapal yang tepat karena kami ingin menerima lebih banyak umpan balik dari komunitas dan pelanggan tentang versi prototipe dan pratinjau.

Untuk memaksimalkan umpan balik awal, saya sarankan membuatnya semudah mungkin untuk mencoba prototipe seperti ini. Mungkin mendorongnya ke build pra-rilis dengan penafian, atau memberikan rilis dev/beta.

Diwajibkan untuk membangun cabang dev WinUI untuk mencoba prototipe memberikan sedikit gesekan yang baik, terutama jika Anda terutama konsumen WinUI daripada kontributor (to the codebase anyways).

Setuju, setelah prototipe dalam keadaan solid (tampak mirip dengan maket yang ditampilkan dan dengan dukungan opsi input yang berbeda), kami ingin memasukkannya ke dalam pratinjau 2.5. Apakah Anda bisa/tertarik untuk mencobanya saat itu juga?

Saya tertarik untuk mencobanya sekarang, saya hanya lebih suka mengkonsumsi dari NuGet daripada menambahkan proyek besar seperti WinUI ke build saya.

Untuk saat ini saya akan menunggu apa pun yang membuatnya menjadi pratinjau.

Halo lagi! Beberapa pembaruan:

• Spesifikasi terus ditinjau dan diulang. Silakan periksa di PR ini dan tinggalkan komentar. Perubahan penting adalah penambahan properti ActionButton generik yang akan mengambil konten Anda sendiri yang diwarisi dari ButtonBase.

  • Inkonsistensi dalam maket saat ini yang ingin saya tunjukkan adalah lokasi ActionButton ini. Dalam spesifikasi, tombol tindakan saat ini ditampilkan rata kanan langsung di kiri tombol tutup namun lokasi sebenarnya akan langsung di sebelah kanan pesan. Gambar yang ditampilkan dalam komentar saya sebelumnya dan di bawah ini adalah lokasi yang benar. Maket yang ditingkatkan akan terus diperbarui dan ditambahkan ke spesifikasi seiring pengembangan berlanjut 😊

• @teaP telah menerapkan versi asli dari kontrol ini saat bergerak menuju prarilis WinUI 2.5 . Terima kasih!

Seperti sebelumnya, jika Anda melihat diri Anda sebagai pengguna potensial dari kontrol ini, jangan ragu untuk berkomentar tentang aplikasi yang sedang Anda kembangkan dan skenario di mana Anda akan menggunakan InfoBar. Terima kasih semuanya!

Halo lagi! Sekedar menyoroti, @teaP baru-baru ini membuka permintaan tarik #3325 untuk InfoBar jika Anda ingin memeriksanya 😊

Mengapa ini disebut InfoBar? Info hanyalah satu kelas kecil informasi yang dapat dikandungnya. Ini juga mendukung kesalahan dan peringatan ditambah tindakan berdasarkan mereka. Bar juga secara artifisial membatasi 'bentuk' kontrol. Ada beberapa kasus penggunaan lain untuk itu selain bilah.

NotificationView atau MessageView, dll akan menjadi nama yang lebih baik menurut saya.

Mengapa ini disebut InfoBar? Info hanyalah satu kelas kecil informasi yang dapat dikandungnya. Ini juga mendukung kesalahan dan peringatan ditambah tindakan berdasarkan mereka. Bar juga secara artifisial membatasi 'bentuk' kontrol. Ada beberapa kasus penggunaan lain untuk itu selain bilah.

NotificationView atau MessageView, dll akan menjadi nama yang lebih baik menurut saya.

Awalnya diusulkan sebagai StatusBanner
Kemudian diubah menjadi InformationBar / InfoBar

Versi FluentUI dari kontrol ini disebut MessageBar

Terima kasih untuk ringkasannya. Nama itu masih tidak masuk akal bagiku. Cara kontrol saat ini dirancang adalah sebagai notifikasi. Lebih umum itu harus menjadi 'pesan' sehingga dapat mendukung skenario bantuan/pengajaran juga. Menggeneralisasi berbagai konsep, berikut adalah desain yang lebih baik untuk kontrol:

1. ~ MessageView ~ atau Tip : Kontrol untuk menampilkan status, petunjuk, atau informasi pengajaran kepada pengguna dengan tindakan opsional, judul, mesin terbang, gambar, dan tombol. Ini dapat ditempatkan di mana saja dan bukan popup. Itu juga akan mendukung tata letak yang berbeda.

2. Tips Pengajaran : Flyout/popup yang menghosting MessageView.

   • Tips yang Dihosting

3. NotificationBar atau StatusTip : Pemberitahuan seluruh aplikasi dalam format 'bilah' di bagian atas aplikasi atau tampilan.

   • Tips yang Dihosting

4. ToolTip : Sekarang akan dapat meng-host tip juga yang akan memberikan dukungan untuk tindakan dan gambar, dll.

   • Tips yang Dihosting

Kami benar-benar perlu berpikir secara umum dan menggabungkan konsep tingkat tinggi ke dalam kontrol yang sama. Jika tidak, kita akan membuat banyak kontrol yang sangat khusus dengan properti yang serupa tetapi berbeda.

Memikirkan nama yang sempurna untuk kontrol 'MessageView' umum: Sebut saja 'Tip'. ToolTip dapat meng-host-nya juga. Diperbarui sesuai.

Berikut adalah contoh 'dunia nyata' lain dari bilah notifikasi di bagian atas beberapa bidang input. Kontrol saat ini akan berguna untuk skenario itu:

Berikut adalah contoh 'dunia nyata' lain dari bilah notifikasi di bagian atas beberapa bidang input. Kontrol saat ini akan berguna untuk skenario itu:

TextBoxes akan mendapatkan status validasi yang dapat mencakup beberapa hal ini, tetapi inilah cara saya melihat berbagai kontrol...

• Keterangan alat untuk satu elemen di mana pengguna secara aktif ingin mengidentifikasi;
• TeachingTip untuk satu elemen yang ingin diperhatikan oleh pengembang (dapat juga tidak dilampirkan ke elemen);
• InfoBar untuk seluruh area aplikasi/konten tempat pengembang ingin menyampaikan beberapa informasi;
• Flyout/Dialog ketika pengembang ingin pengguna mengonfirmasi bahwa mereka telah membaca sesuatu sebelum menutupnya;
• Dialog Konten ketika pengembang mengharuskan pengguna untuk membuat pilihan atau mengambil tindakan di atas segalanya;

Saya juga akan menghindari penggunaan kata Notifikasi karena ada notifikasi Level OS dan pusat notifikasi untuk ini

Saya juga akan menghindari penggunaan kata Notifikasi karena ada notifikasi Level OS dan pusat notifikasi untuk ini

Yah, saya pikir pengembang akan tahu perbedaannya, tetapi itu pasti poin yang adil.

Itu juga benar kita bisa membuat banyak kontrol terpisah. Tetapi tentu saja ada beberapa konsep tingkat tinggi seputar notifikasi/status/pesan/petunjuk/ajaran yang dapat digabungkan bersama. Setidaknya kita harus membuat antarmuka dari semua ini.

Dialog Flyout/Konten adalah konsep terpisah karena sebagian besar merupakan kontrol konten generik.

Saya memikirkan nama yang sempurna untuk kontrol tipe 'tampilan pesan' umum untuk di-host dalam berbagai skenario: sebut saja 'Tip'. Saya telah memperbarui komentar saya di atas sesuai: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

Saya memikirkan nama yang sempurna untuk kontrol tipe 'tampilan pesan' umum untuk di-host dalam berbagai skenario: sebut saja 'Tip'. Saya telah memperbarui komentar saya di atas sesuai: #913 (komentar)

Saya tidak akan merasa nyaman menempatkan peringatan penting atau pesan kesalahan di Tip ...

Itu juga benar kita bisa membuat banyak kontrol terpisah. Tetapi tentu saja ada beberapa konsep tingkat tinggi seputar notifikasi/status/pesan/petunjuk/ajaran yang dapat digabungkan bersama. Setidaknya kita harus membuat antarmuka dari semua ini.

Dialog Flyout/Konten adalah konsep terpisah karena sebagian besar merupakan kontrol konten generik.

Saya sangat menyukai ide ini. Saya pikir ada kesamaan dalam ikon, judul, pesan, API tombol tindakan yang dapat konsisten di seluruh kontrol info ini. Dengan InfoBar, saya tidak yakin apakah itu sesuatu yang dapat kami implementasikan dalam versi saat ini tetapi berpotensi untuk kontrol kami berikutnya seperti ini.

Saya memikirkan nama yang sempurna untuk kontrol tipe 'tampilan pesan' umum untuk di-host dalam berbagai skenario: sebut saja 'Tip'. Saya telah memperbarui komentar saya di atas sesuai: #913 (komentar)

Saya tidak akan merasa nyaman menempatkan peringatan penting atau pesan kesalahan di Tip ...

Saya juga setuju dengan ini ... lebih banyak eksplorasi yang harus dilakukan.

Saya memikirkan nama yang sempurna untuk kontrol tipe 'tampilan pesan' umum untuk di-host dalam berbagai skenario: sebut saja 'Tip'. Saya telah memperbarui komentar saya di atas sesuai: #913 (komentar)

Saya tidak akan merasa nyaman menempatkan peringatan penting atau pesan kesalahan di Tip...

Saya juga setuju dengan ini ... lebih banyak eksplorasi yang harus dilakukan.

Pikirkan seberapa cocoknya dengan semua kontrol dan ide yang ada -- sempurna dalam hal itu. Tapi ya, sepertinya tidak pada tempatnya dalam konteks kesalahan/peringatan. Saya pikir orang akan cepat memahaminya tapi saya tidak bisa berdebat dengan logika itu.

Mengapa ini disebut InfoBar? Info hanyalah satu kelas kecil informasi yang dapat dikandungnya. Ini juga mendukung kesalahan dan peringatan ditambah tindakan berdasarkan mereka. Bar juga secara artifisial membatasi 'bentuk' kontrol. Ada beberapa kasus penggunaan lain untuk itu selain bilah.

NotificationView atau MessageView, dll akan menjadi nama yang lebih baik menurut saya.

Saya setuju dengan pendapat Anda bahwa InfoBar mungkin tidak selalu berupa bilah namun saya pikir memasukkan "bilah" dalam namanya menyiratkan bahwa itu dimaksudkan untuk skenario di seluruh aplikasi baik secara visual maupun konseptual. Mencari gambar "bilah informasi" Anda menemukan gambar pengalaman serupa dari IE (bukan berarti kami harus mencoba mencocokkan IE) dan saya pikir itu berkonotasi dengan tata letak visual dan fungsional yang diharapkan. Saya tidak melihat ini sebagai 'Tampilan' tetapi saya suka fokus pada pesan atau notifikasi.

@gabbybilka Ya, ini sangat mirip dengan StatusBar lama atau AppBar yang lebih baru... CommandBar... dll. Masalahnya adalah penggunaan kontrol harus digeneralisasikan sedikit untuk juga menampilkan petunjuk dan pesan di lokasi yang berubah-ubah. 'Tampilan' juga tidak cocok 100% tetapi lebih dekat dengan nama umum. Sungguh perhatian saya adalah dalam menyatukan konsep-konsep yang mendasarinya sehingga kami tidak berakhir dengan banyak kontrol melakukan variasi dari hal yang sama.

Diedit karena membingungkan diri saya sendiri dengan banyak komentar di dua lokasi.

Menggaungkan pemikiran yang saya posting di salah satu masalah lain ...

_Menanggapi fakta bahwa mode mengambang untuk kontrol tidak lagi dipertimbangkan untuk V2_
Saya dapat memahami bahwa perubahan perilaku dan bentuk akan membuat Anda beralih ke Tips Mengajar sebagai alternatif, tetapi saya akan menyarankan kurangnya tingkat keparahan, warna status, dan desain tip pengajaran itu sendiri - tidak akan kompatibel dengan jenis yang sama pesan yang dilayani oleh kontrol InformationBar.

Lebar layar dan perbedaan dalam tata letak UI antara aplikasi WinUI Layar Penuh, jendela lebar sempit, dan hal-hal seperti Hololens dan Xbox - tidak akan cocok untuk faktor bentuk Bar yang di-dok.

Jadi dengan mengingat hal itu, mungkin InformationBar harus dibungkus, bersama dengan kontrol InformationCard ke dalam AppMessage API - jadi properti yang sama dari Severity, Color, Title, Message, Action Buttons, dll dapat ditempatkan ke dalam XAML, atau ke dalam kode aplikasi - dan cara penyajiannya di layar berubah agar sesuai dengan faktor bentuk/keluarga perangkat.

Tip Pengajaran yang tidak dilampirkan dapat digunakan, tetapi tidak akan mendukung penyesuaian yang sesuai untuk Pesan Status Aplikasi - yang merupakan tujuan awal di balik kontrol ini.

Jadi bagaimana jika kita memiliki 'Tip' yang sebenarnya hanya sebuah pesan. Ini memiliki mesin terbang, gambar, teks pesan, judul.

Kemudian berasal dari Tip kami memiliki AppMessage yang menambahkan keparahan, tindakan, dan hal-hal. Tip akan tetap dapat digunakan di TeachingTip dan ToolTip seperti yang ada saat ini. itu juga akan berguna dalam skenario saya untuk inline, petunjuk kontekstual.

Jadi bagaimana jika kita memiliki 'Tip' yang sebenarnya hanya sebuah pesan. Ini memiliki mesin terbang, gambar, teks pesan, judul.

Kemudian berasal dari Tip kami memiliki AppMessage yang menambahkan keparahan, tindakan, dan hal-hal. Tip akan tetap dapat digunakan di TeachingTip dan ToolTip seperti yang ada saat ini. itu juga akan berguna dalam skenario saya untuk inline, petunjuk kontekstual.

TeachingTip tanpa Ekor tampaknya cocok untuk situasi Anda...

TeachingTip tanpa Ekor tampaknya cocok untuk situasi Anda...

Tidak tahu Anda bisa melakukannya dengan TeachingTip. Juga, kendali saya telah ada jauh lebih lama daripada TeachingTip jadi tidak pernah benar-benar menyelidiki untuk meningkatkannya sampai sekarang. Either way, jika Anda bisa melakukan itu, itu adalah kesalahan saya.

Sunting: Nevermind, bahkan tanpa ekor itu masih merupakan overlay yang diberhentikan dengan satu atau lain cara. 'Petunjuk' yang saya jelaskan semuanya sebaris dan tetap ada hingga pengguna pada dasarnya membuat elemen pertama. Ini hanyalah kontrol yang menyajikan informasi -- bukan dalam popup, flyout, atau tampilan non-persisten lainnya.

Saya masih yakin ada banyak kesamaan untuk dipecah menjadi antarmuka/kontrol yang digunakan di banyak tempat. Semua kontrol yang kita diskusikan ini memiliki lebih banyak persamaan daripada perbedaan. Hanya di mana/bagaimana informasi yang mendasari disajikan yang berubah. Ini semua matang untuk penyederhanaan.

TeachingTip tanpa Ekor tampaknya cocok untuk situasi Anda...

Tidak tahu Anda bisa melakukannya dengan TeachingTip. Juga, kendali saya telah ada jauh lebih lama daripada TeachingTip jadi tidak pernah benar-benar menyelidiki untuk meningkatkannya sampai sekarang. Either way, jika Anda bisa melakukan itu, itu adalah kesalahan saya.

Saya masih yakin ada banyak kesamaan untuk dipecah menjadi antarmuka/kontrol yang digunakan di banyak tempat. Semua kontrol yang kita diskusikan ini memiliki lebih banyak persamaan daripada perbedaan. Hanya di mana/bagaimana informasi yang mendasari disajikan yang berubah. Ini semua matang untuk penyederhanaan.

Saat Anda memecahnya, itu hanya ikon dan teks, dan tidak ada "konteks" yang terkait dengannya. Tetapi saran saya untuk membungkusnya menjadi AppMessage dapat menyertakan Tips Pengajaran Tidak Terlampir sebagai bentuk lain dari UI, saya kira.

Saat Anda memecahnya, itu hanya ikon dan teks, dan tidak ada "konteks" yang terkait dengannya. Tetapi saran saya untuk membungkusnya menjadi AppMessage dapat menyertakan Tips Pengajaran Tidak Terlampir sebagai bentuk lain dari UI, saya kira.

Maaf, lihat hasil edit saya di atas. Tip mengajar masih belum sebaris dan hanya mengambang di bawah sampai dibubarkan. Ada juga gambar dan judul yang perlu dipertimbangkan juga.

Saat Anda memecahnya, itu hanya ikon dan teks, dan tidak ada "konteks" yang terkait dengannya. Tetapi saran saya untuk membungkusnya menjadi AppMessage dapat menyertakan Tips Pengajaran Tidak Terlampir sebagai bentuk lain dari UI, saya kira.

Maaf, lihat hasil edit saya di atas. Tip mengajar masih belum sebaris dan hanya mengambang di bawah sampai dibubarkan.

Tidak harus di bawah.

Inline mungkin merupakan kasus penggunaan yang tidak biasa untuk petunjuk, karena akan menggantikan konten lain di sekitarnya.

Anda dapat menyarankan agar V2 menambahkan dukungan untuk mode tampilan inline/non floating

Untuk memberi komentar @mdtauk sedikit lebih banyak konteks, berikut adalah jawaban awal saya untuk pertanyaannya seputar menghapus mode mengambang dari bagian "Fitur yang dimaksudkan untuk InfoBar V2" di spesifikasi.
Dari saya:

Melompat ke sini untuk diskusi desain. Perhatikan baik-baik bahwa fitur yang dimaksudkan V2 berubah Saat ini kami tidak menggunakan mode mengambang untuk InfoBar dalam versi V2 karena beberapa alasan. Saya ingin mengeksplorasi lebih lanjut apakah mode mengambang _should_ berada di InfoBar atau apakah notifikasi seperti roti panggang harus menjadi kontrol yang berbeda sama sekali. Saat menyelidiki, kami menyadari bahwa implementasi dasar mode mengambang akan sangat mirip dengan Tip Pengajaran dan bahwa untuk sepenuhnya menjelajahi fungsionalitas skenario pemberitahuan seperti roti panggang seperti pilihan susun, pemosisian, dan overlay (lihat StackMode WCT InAppNotification ) kemungkinan diperlukan. Ini akan memperluas cakupan dan maksud InfoBar menjadi lebih luas daripada fokus awalnya. Untuk dicatat, kami belum sepenuhnya menutup pintu untuk menambahkan kemampuan mengambang ke InfoBar tetapi condong ke arah tidak.

Untuk proposal InformationBar dan InformationCard berdasarkan kelas AppMessage dasar, saya menyukai ide ini. Anda menyebutkan bahwa "cara mereka disajikan di layar akan berubah agar sesuai dengan faktor bentuk/keluarga perangkat" yang ingin saya jelajahi lebih dalam. Saya pikir ada skenario yang lebih cocok untuk UX kartu (khususnya pesan sementara, pesan kesalahan khusus halaman, dan aplikasi tanpa permukaan yang dapat dipasang ke dok) daripada bilah UX dan sebaliknya.

Bagi saya, ada perbedaan dalam "kapan" menggunakan InfoBar/InfoCard/Tips Pengajaran (terkait dengan kebutuhan visual dan fungsional) serta "mengapa" menggunakan (berdasarkan persepsi pengguna akhir dan konsistensi pengalaman). Pesan sementara adalah sorotan yang jelas bagi saya sebagai sesuatu yang harus didukung oleh InfoCard dan tidak didukung oleh InfoBar. Pesan yang tidak dapat ditutup oleh pengguna adalah contoh kebalikannya karena konten overlay yang persisten sulit untuk didukung dari perspektif aksesibilitas.

Namun, jangan teralihkan :) Semua dari berbagai kontrol ini menyajikan, sebagian besar, jenis informasi yang sama -- hanya di area/gaya yang berbeda. Ini perlu digeneralisasi dan disatukan. Saya pikir kita dapat menyatukan di sekitar satu kontrol 'AppMessage' yang umum jika Anda ingin menyebutnya demikian. Kemudian miliki wadah yang berbeda untuk menyajikan 'AppMessage' itu dengan cara yang berbeda. Itu bisa disajikan dalam TeachingTIp, ToolTip a NotificationBar, sebagai kartu di suatu tempat, dll. Setiap wadah dapat memodifikasi gaya agar sesuai dengan kasus penggunaannya. Properti dan tipe yang mendasarinya akan disatukan.

Saya tidak mencoba salah mengartikan konteks apa pun dengan balasan @gabbybilka

Untuk proposal InformationBar dan InformationCard berdasarkan kelas AppMessage dasar, saya menyukai ide ini.

Di sinilah penamaan masuk. Saya suka "AppMessage" ("Tip" akan luar biasa meskipun sepertinya itu adalah rencananya selama ini) tetapi jika kita menggunakan itu, itu harus menjadi hosting "MessageBar" dan "MessageCard" dia.

Bagi saya, ada perbedaan dalam "kapan" menggunakan InfoBar/InfoCard/Tips Pengajaran (terkait dengan kebutuhan visual dan fungsional) serta "mengapa" menggunakan (berdasarkan persepsi pengguna akhir dan konsistensi pengalaman).

Saya sangat setuju dengan kasus penggunaan dan presentasi yang berbeda ini. Namun, mereka tetap menyajikan pesan yang dapat digeneralisasikan dan dibakukan. Saya pikir kita semua setuju dengan konsep itu sekarang :)

Contoh Pesan/Kiat Kartu

Salah satu tujuan yang menurut saya adalah untuk mendorong kotak masuk dan aplikasi pihak pertama/Windows Shell untuk menjauh dari solusi khusus mereka untuk menggunakan kontrol kotak masuk/API yang konsisten

Saya mungkin harus menambahkan bahwa dalam aplikasi UWP saya mengerjakan beberapa konsep ini sudah menyatu. Versi sederhana yang relevan dengan diskusi ini adalah:

Ada kelas 'Pesan' (ini bukan kontrol, hanya struktur data) dengan properti berikut:

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

Prioritas pada dasarnya sama dengan apa yang telah Anda putuskan (sekarang sudah cukup terstandarisasi). DisplayMode mendukung Notification, None dan Popup. Ketika sebuah Pesan dibuat oleh kode back-end, itu diteruskan ke front-end yang akan menampilkannya dengan tepat baik sebagai pemberitahuan cepat di 'bilah' di bagian atas aplikasi yang akan ditutup. Atau sebagai popup pemblokiran untuk pesan yang lebih parah.

Selain itu ada kontrol 'MessageView' yang mengambil pesan dengan sendirinya tetapi menambahkan mesin terbang dan judul dan menyajikannya sebagai 'Petunjuk' kontekstual sebaris yang telah kita bicarakan sebelumnya.

Itulah yang akan saya usulkan: Lakukan abstraksi pada lapisan Aplikasi. Miliki kelas ViewModel sederhana yang dapat Anda lampirkan ke salah satu tampilan. Ini mudah dilakukan dan lebih fleksibel. Mungkin Anda juga ingin melakukan logging dengan kerangka logging pilihan Anda, Anda ingin memiliki prioritas khusus, ingin menambahkan data Anda sendiri. Semua mudah dilakukan di ViewModel Anda.

Maksud dari kontrol yang Anda sebutkan adalah untuk menyediakan cara terpadu dalam melakukan skenario tertentu, di banyak aplikasi dan kasus penggunaan OS, alih-alih membuat setiap aplikasi hadir dengan UI dan perilaku yang sedikit berbeda. ToolTips dan InfoBar/MessageBar adalah konsep yang terkenal, baik untuk pengembang maupun pengguna akhir. Meskipun keduanya menyajikan informasi, mereka digunakan untuk hal-hal yang sangat berbeda. Saya tidak melihat banyak manfaat dalam memiliki kelas dasar umum atau konsep umum untuk ini. Mengapa Anda ingin meletakkan pesan di Tip Alat, yang sudah ditampilkan di InfoBar aplikasi global (dan di mana Anda akan melampirkan Tip Alat ini)? Ini tidak seperti ini akan menyebabkan banyak digunakan kembali.

Ada area lain di mana konsep umum akan menjadi IMO yang jauh lebih berguna. Pikirkan Button, AppBarButton, MenuItem. Semua ini menunjukkan teks dan ikon, semuanya digunakan untuk memicu suatu tindakan. Seringkali Anda memberikan perintah yang sama di MenuItem (ContextMenu) dan AppBar/CommandBar. Di sini, konsep umum akan sangat berguna, di mana Anda bisa meletakkan perintah, teks, ikon, mungkin juga pesan panjang (tooltip). Tetapi memiliki konsep umum untuk ToolTip dan MessageBar? Saya benar-benar tidak melihat perlunya ini. Tentu, jika kami menulis ulang UWP dari awal, kami mungkin akan menemukan kelas dasar yang sama. Tapi menurut saya itu tidak perlu atau terlalu membantu.

@lukasf Poin Anda masuk akal; itu bisa dilakukan di aplikasi itu sendiri. Namun, ada banyak konsep yang sangat mirip dan setiap orang dapat memperoleh manfaat dari penyatuan di sini.

ToolTip dimasukkan ke dalam diskusi karena memiliki mesin terbang dan judul bersama dengan pesan dapat bermanfaat. Secara konseptual semua kontrol ini adalah pesan dari beberapa bentuk juga - hanya di mana/bagaimana mereka ditampilkan berbeda. Bahkan jika kita tidak melakukan standarisasi besar, MessageBar dan MessageCard masih memerlukan banyak properti/tipe bersama. Kami tidak ingin memiliki MessageBarPriority bersama dengan musuh MessageCardPriority. Pemikiran masih perlu dimasukkan untuk memastikan bahkan tipe dasar terbukti di masa depan.

Menggabungkan semua ini dengan ide-ide yang ada dalam Tip Pengajaran hanya tampak logis bagi saya. Saya yakin arah mana yang harus dituju akan masuk akal dengan perbandingan berdampingan dari semua kontrol yang disebutkan dan propertinya. Jika saya punya waktu sakit melakukan perbandingan sendiri.

Komentar Anda tentang Button/AppBarButton/dll. adalah contoh sempurna dari pemikiran yang tidak ingin kita kembangkan. Microsoft mulai terbiasa membuat beberapa kontrol yang serupa tetapi berbeda tanpa menghabiskan waktu/usaha untuk membuatnya kohesif. Jangka panjang ini tidak baik untuk kerangka kerja apa pun karena sejumlah alasan.

Saya telah mengumpulkan perbandingan kontrol perpesanan. Saya akan memberikannya sebagai konsultasi gratis karena sangat kasar :)

Ini adalah jenis dokumentasi strategi dan perbandingan tingkat tinggi yang saya harapkan akan dibuat secara internal di Microsoft. Jika saya sendiri yang memimpin tinjauan spesifikasi/desain, saya akan menuntut jenis analisis ini atau tidak ada yang bisa berharap untuk pergi dengan persetujuan. Sangat penting untuk:

1. Menjembatani kesenjangan dalam pemahaman antara anggota tim
2. Mengatasi 'silo' yang terjadi di tim dan organisasi besar
3. memastikan arah masa depan yang koheren dari kerangka kerja sehingga fungsionalitas masa depan dapat ditambahkan di atas fondasi yang baik (paling penting)

Microsoft entah bagaimana kehilangan prinsip-prinsip gambaran besar ini setelah WPF dan tampaknya tidak ada lagi visi 'tingkat yang lebih tinggi' oleh para pemimpin di bidang ini. Bagaimanapun, saya tidak mengetahui rahasia diskusi internal jadi saya berharap lebih banyak perencanaan terjadi secara internal dengan beberapa individu yang memiliki banyak pengalaman dan sejarah panjang prinsip-prinsip dengan XAML.

Dengan itu, jangan ragu untuk merobek dokumen di bawah ini. Diskusi itu sendiri yang paling penting.

MessageControlComparison 20200929.xlsx

Terima kasih atas dokumen perbandingannya, sangat keren untuk melihat pemikiran Anda tentang kontrol info secara holistik! Dua topik utama yang ingin saya lanjutkan diskusinya adalah 1. Mengapa _tidak boleh_ Tips Pengajaran dan InfoBar memiliki API/properti/fungsi yang berbeda? dan 2. Apa perbedaan antara InfoBar dan InfoCard jika InfoCard bukan Popup sebagaimana diuraikan dalam dokumen perbandingan?

Untuk pertanyaan pertama saya dapat menyoroti keputusan desain yang dibuat pada item teks merah dan memberikan sedikit lebih banyak kejelasan:

• TeachingTip Subtitle vs InfoBar Pesan: Secara fungsi, ya, keduanya sama! Mereka adalah pesan sekunder dengan teks yang tidak dicetak tebal dalam kontrol ini. Dalam Tip Pengajaran, pesan ini akan selalu ditampilkan di bawah Judul dan masuk akal disebut sebagai Subtitle. Untuk InfoBar, pesan ini akan paling sering sejajar dan langsung di sebelah kanan Judul yang secara konseptual tidak masuk akal disebut sebagai Subtitle.
• TeachingTip HeroContent vs InfoBar Content: Teaching Tip memiliki HeroContent dan Content sedangkan InfoBar hanya memiliki Content. Properti HeroContent unik untuk Tip Pengajaran karena dukungannya terhadap gambar yang lebih besar ini untuk membantu mengajar. InfoBar tidak secara eksplisit mendukung gambar karena berfokus pada tata letak horizontal. Properti Konten untuk kedua kontrol adalah untuk konten khusus tambahan dan berada di bawah elemen UI lainnya di keduanya.
• Strategi tombol Tip Pengajaran vs strategi tombol InfoBar: Perbedaan utama di sini adalah bahwa InfoBar mendukung lebih banyak jenis tombol di luar "Tombol" klasik dan tidak mendorong penyesuaian tombol tutup untuk menyertakan teks.
  
  
  
  • Skenario umum untuk InfoBars adalah menyertakan tombol hyperlink. Karena kontras warna dengan warna latar depan tombol hyperlink default dan warna latar belakang kami yang beraneka warna, kami ingin memastikan bahwa kami dapat menerapkan gaya kustom kami sendiri ke tombol hyperlink apa pun yang disertakan dalam InfoBar sehingga tetap dapat diakses.
  
  
  • Kami memutuskan untuk tidak menyertakan kustomisasi tombol tutup (untuk teks, masih ada properti CloseButtonStyle untuk melakukan beberapa gaya ringan jika diinginkan) ke InfoBar setelah tinjauan desain kami untuk memastikan fokus tetap pada teks yang disertakan dan tindakan tunggal. Terkait, seperti yang disebutkan dalam spesifikasi, kami sedang memikirkan ActionContentArea di V2 untuk mendukung lebih dari satu tombol tindakan di sini dan dapat menyelidiki mengaktifkan penyesuaian tombol tutup lagi di sana.
  
  
• InfoBar IsClosable & IsIconVisible: Tip Pengajaran tidak memiliki IsClosable karena Tip Pengajaran harus selalu dapat ditutup karena merupakan PopUp dan menampilkan informasi yang tidak memblokir/mendesak. Itu juga tidak memiliki IsIconVisible karena ikon tidak muncul dengan gaya default yang dilakukan InfoBar melalui tingkat Keparahan yang berbeda. Kami ingin memberikan cara bagi pengembang untuk menghapus ikon yang disediakan jika mereka mau. Kami mencoba menyetel IconSource ke null yang menyebabkan banyak bug funky dan disederhanakan melalui properti IsIconVisible.

Apakah ini masuk akal? Saya percaya ada tujuan yang berbeda untuk kedua kontrol dan perbedaan fungsionalitas mencerminkan hal itu. Saya harap penjelasan dan alasan desain ini bermanfaat!

Edit untuk masalah pemformatan dan salah ketik😊 x2

Saya tidak akan menganjurkan harmonisasi antara kontrol ini secara langsung, karena ada pembenaran untuk kontrol ini melakukan hal mereka sendiri dalam konteks mereka sendiri.

Namun, membuat In App Messaging API, yang bertindak sebagai struktur pemersatu, tetapi dapat beradaptasi untuk faktor bentuk tidak memerlukan perubahan pada kontrol.

Ada pertanyaan untuk didiskusikan dan dijawab untuk jenis API ini:

• Haruskah / Bagaimana Anda sebagai pengembang dapat menentukan jenis kontrol apa yang ditampilkan panggilan pesan di layar?
• Jika tidak menentukan jenis kontrol, apakah API mengambil properti yang diberikan dan "memilih" yang paling cocok?
• Bagaimana Anda melewati pilihan perilaku ke kontrol yang mendasarinya?
• Faktor bentuk mana yang akan ditimpa berdasarkan kesesuaian platform?

Dan mungkin masih banyak lagi yang belum saya pikirkan lol

Mengambil Xbox sebagai platform
Metode input sangat berbeda, seperti ukuran/skala layar.

Bilah Informasi lebar penuh perlu mempertimbangkan pemindaian berlebih pada tepi layar, sehingga untuk aplikasi ini, Kartu Informasi mungkin lebih cocok.

Tapi bagaimana Anda menangani pemecatan?

Tidak ada kursor untuk memindahkan tombol tutup, tetapi apakah Anda ingin Kartu mengambil alih input pengontrol? Ini menjadikannya modal. Tetapi kemudian jika itu dihamparkan di atas konten, bagaimana Anda memilihnya dan memberinya fokus?

Jadi apakah itu muncul sebaris dan mendorong konten ke bawah, tetapi tidak lebar penuh?

Plus Xbox memiliki sistem notifikasi seperti roti panggang sendiri, jadi apakah / haruskah API ini bekerja dengan itu? Bisakah itu bekerja dengannya, atau hanya Sistem?

1. Mengapa Tips Pengajaran dan InfoBar tidak memiliki API/properti/fungsi yang berbeda?

Tujuannya harus selalu menyediakan API umum untuk hal yang sama. Seluruh diskusi ini adalah tentang pesan yang dihadapi pengguna secara umum dan beberapa kesamaan muncul setelah dipahami. Tidak dapat disangkal bahwa kasus penggunaan untuk TeachingTip dan kontrol tipe MessageBar berbeda. Pada dasarnya, yang satu menyajikan Pesan dan yang lainnya juga Tip. Saya tidak mempertanyakan keseluruhan pilihan desain di sini. Namun, ada lebih banyak kesamaan daripada perbedaan dengan kontrol ini. Lihat saja desainnya: semuanya memiliki ikon, judul, subjudul, konten, tombol tindakan, dan tombol tutup (namun Anda menamakannya secara berbeda dan ada area permukaan API yang berbeda). Jika Anda tidak melihat mengapa itu ide yang baik untuk membakukan setidaknya penamaan dan enum di sini tidak ada lagi yang bisa saya katakan. Ini hanyalah sesuatu yang mendasar untuk arsitektur yang baik.

Untuk tombol, kedua kontrol mendukung tombol aksi dan tombol tutup. Tapi Anda melakukan ini dengan cara yang sama sekali berbeda. Anda menjelaskan beberapa alasan di atas tetapi sekarang kami memiliki API 'jelek' untuk menggunakan tombol dalam situasi seperti ini. Mengapa kita tidak menggeneralisasi ini sekarang sehingga kita memiliki sesuatu yang baik untuk masa depan? Tombol seperti ini berlaku untuk beberapa kontrol: ContentDialog, TeachingTip, InfoBar dan entah apa selanjutnya. Kami terus merancang dengan memikirkan kontrol saat ini saja - arsitektur yang buruk!

Untuk teks pesan atau tip yang satu disebut Subtitle dan yang lainnya Message dasarnya ini bisa sama, mengapa istilah yang berbeda digunakan selain manajer proyek yang berbeda bekerja pada kontrol ini?

Secara keseluruhan, bukankah akan membantu pengembang jika kontrolnya bekerja dengan cara yang sama? Ya, tentu saja! Apakah itu berarti akan ada kontrol yang sama di bawah semua ini? Belum tentu, tetapi kita harus menggunakan nama properti yang sama, konsep tombol tindakan yang sama, dan tipe yang sama. Saya masih berharap kita bisa memiliki struktur pesan atau antarmuka yang digunakan untuk menyatukan semuanya. Bukankah lebih baik untuk hanya mengatur pesan ke MessageBar dan menampilkannya daripada harus mengatur semua properti ini secara manual?

Apa perbedaan antara InfoBar dan InfoCard jika InfoCard bukan Popup seperti yang dijelaskan dalam dokumen perbandingan?

Kesimpulan akhir saya dari perbandingan adalah bahwa MessageBar/MessageCard harus menjadi kontrol yang sama dan juga mendukung kasus penggunaan petunjuk inline atau contoh tip saya melalui penyesuaian gaya.

• Dimungkinkan untuk menyatukan MessageBar/MessageCard dan Tip menjadi satu kontrol. Satu-satunya perhatian adalah perbedaan konseptual antara 'pesan' dan 'tip'.
• Harus menjadi kontrol dasar yang sama, gaya harus sangat dapat disesuaikan untuk mendukung kedua kasus. Satu-satunya perhatian adalah perbedaan konseptual antara 'pesan' dan 'tip'. Desain sangat mirip.

Sunting: Secara keseluruhan, saya pikir kekhawatiran mendasar saya adalah kita entah bagaimana mundur dalam pemikiran arsitektur. Desain kontrol sekarang dilakukan seolah-olah itu adalah hari-hari Windows Forms. Kontrol UWP baru harus didasarkan pada konsep WPF. Kontrol menjadi sangat terspesialisasi dan saya tidak melihat utas pemersatu yang mencakup kerangka kerja yang benar-benar 'membuat kagum' pengembang yang pertama kali menyentuh WPF. Kita harus kembali ke mentalitas 'gambaran besar' menurut saya.

Saya setuju 100% dengan @robloo bahwa nama properti dan nama enum untuk hal serupa harus disejajarkan (sejauh mungkin) dengan kontrol yang ada. Kontrol serupa harus memiliki permukaan API yang serupa. Jika kelas MessageCard akan ditambahkan di lain waktu (alih-alih memperluas MessageBar, yang mungkin saya sukai secara pribadi), setidaknya harus memiliki API yang sangat mirip dengan MessageBar.

Ada area lain di mana konsep umum akan menjadi IMO yang jauh lebih berguna. Pikirkan Button, AppBarButton, MenuItem. Semua ini menunjukkan teks dan ikon, semuanya digunakan untuk memicu suatu tindakan. Seringkali Anda memberikan perintah yang sama di MenuItem (ContextMenu) dan AppBar/CommandBar. Di sini, konsep umum akan sangat berguna, di mana Anda bisa meletakkan perintah, teks, ikon, mungkin juga pesan panjang (tooltip).

@lukasf Apakah Anda mengetahui kelas XamlUICommand ? Itu memungkinkan Anda untuk menggabungkan properti ini di satu tempat dan kemudian menetapkannya ke Tombol/MenuItem/.... dengan hanya meneruskan XamlUICommand yang Anda tentukan ke API Command dari kontrol ini.

@Felix-Dev Ya, Anda benar. Aku hampir lupa tentang itu. Saya tidak menggunakannya karena tidak tersedia di WinUI ketika saya mencobanya terakhir kali, tetapi juga karena ini bukan solusi lengkap. AppBar dan ContextMenu memiliki lebih dari sekadar tautan perintah. Untuk solusi lengkap, kita perlu:

• Perintah XamlUI
• Perintah XamlToggleUI
• XamlUICommandSubItem (sub menu/flyout)
• Pemisah Perintah XamlUI

Yang juga hilang adalah properti "Terlihat" dan/atau properti "HideIfDisabled".

Kemudian kita membutuhkan ItemsSource di MenuFlyout dan AppBar/CommandBar dan kontrol serupa. Kontrol tingkat atas kemudian akan membuat sub kontrol yang sesuai untuk setiap item perintah.

Hanya ketika semua ini ada, kami dapat memiliki satu kumpulan perintah di aplikasi kami, dan mengikatnya ke MenuBar, ContextMenu, AppBar, NavigationView. Tetapi seperti sekarang, saya perlu menyimpan daftar kelas yang ditentukan khusus, secara manual menerapkan dan menggunakan hal-hal seperti DataTemplateSelectors dan solusi menjengkelkan lainnya, hanya untuk mendapatkan definisi perintah yang sama bekerja di tempat yang berbeda.

XamlUICommand adalah awal yang baik, tetapi ini bukan cerita yang lengkap.

Maaf atas keterlambatan saya dalam menanggapi di sini, @robloo terima kasih telah berbagi perspektif Anda dan tabel perbandingan dari beberapa minggu yang lalu. Saya sangat menghargai semua pemikiran dan pertimbangan untuk membuat WinUI lebih baik! 😊

Di InfoBar dan di seluruh platform, pandangan saya adalah bahwa saat mendesain, kami berusaha menemukan keseimbangan yang tepat untuk kontrol yang dirancang khusus untuk skenario tertentu sebagai pola UI yang ditentukan – sementara cukup umum dan dapat disesuaikan untuk diperluas ke skenario yang belum kami miliki. belum diidentifikasi. Sebagai seseorang yang lebih baru di tim, saya ingin mendengar mengapa kontrol WinUI harus kembali ke konsep WPF. Masalah sehari-hari apa yang Anda dan pengembang UWP lainnya hadapi ketika kontrol konseptual serupa tidak memiliki struktur dasar yang sama? Apa manfaatnya bagi Anda sehingga kami dapat memahami lebih baik mengapa kami harus mendedikasikan sumber daya untuk menciptakan struktur ini? Apakah ada kontrol lain di WinUI yang akan mendapat manfaat dari penyatuan (saya melihat percakapan tombol di atas dari @lukasf) Saya pikir kita juga dapat melanjutkan percakapan ini dalam masalah umum baru jika ada area di mana kita dapat memodifikasi pendekatan kontrol/brainstorming yang ada untuk kontrol masa depan. @SavoySchuler untuk masukan apa pun di sini.

Untuk InfoBar, saya masih tidak melihat perubahan apa pun saat masuk ke pratinjau dari percakapan ini. Khususnya untuk Action Button dan Close Button APIs jika ada kebutuhan khusus yang tidak terpenuhi, beri tahu kami agar kami dapat mengevaluasi setiap potensi perubahan. Saya dapat mengantisipasi kelas dasar atau antarmuka AppMessage yang umum untuk diimplementasikan dengan v2 yang terkait dengan kontrol InfoCard atau sebagai DisplayMode terpisah untuk mengaktifkan fungsionalitas 'Otomatis' tata letak variabel @mdtauk yang dibawa sebelumnya. Selain itu, tim WinUI belum melihat nilai dalam menyelaraskan Tips Pengajaran dan InfoBar lebih lanjut saat ini, namun kami dapat melanjutkan percakapan di sini untuk mengatasi hal ini jika ada kebutuhan penggunaan yang tidak terpenuhi. Setelah InfoBar masuk ke pratinjau dan dapat diimplementasikan dalam aplikasi, skenario spesifik atau umpan balik penggunaan apa pun akan sangat bagus untuk didengar sebelum rilis resmi.

Sebagai pertanyaan umum, jika Anda memiliki skenario yang sesuai dengan maksud InfoBar dan ada aspek fungsionalitas atau desain visualnya yang tidak memenuhi kebutuhan Anda, beri tahu kami saat kami masuk ke pratinjau. Sekali lagi terima kasih atas semua komentar dan percakapan Anda!

Di InfoBar dan di seluruh platform, pandangan saya adalah bahwa saat mendesain, kami berusaha menemukan keseimbangan yang tepat untuk kontrol yang dirancang khusus untuk skenario tertentu sebagai pola UI yang ditentukan – sementara cukup umum dan dapat disesuaikan untuk diperluas ke skenario yang belum kami miliki. belum diidentifikasi. Sebagai seseorang yang lebih baru di tim, saya ingin mendengar mengapa kontrol WinUI harus kembali ke konsep WPF. Masalah sehari-hari apa yang Anda dan pengembang UWP lainnya hadapi ketika kontrol konseptual serupa tidak memiliki struktur dasar yang sama? Apa manfaatnya bagi Anda sehingga kami dapat memahami lebih baik mengapa kami harus mendedikasikan sumber daya untuk menciptakan struktur ini? Apakah ada kontrol lain di WinUI yang akan mendapat manfaat dari penyatuan (saya melihat percakapan tombol di atas dari @lukasf) Saya pikir kita juga dapat melanjutkan percakapan ini dalam masalah umum baru jika ada area di mana kita dapat memodifikasi pendekatan kontrol/brainstorming yang ada untuk kontrol masa depan. @SavoySchuler untuk masukan apa pun di sini.

Inti dari memiliki struktur adalah agar programmer dapat membuat kode lebih cepat dengan lebih sedikit kesalahan untuk mendapatkan kode berkualitas tinggi.

Karena sebagian besar Microsoft adalah tim yang tertutup, dalam banyak kasus ada banyak cara untuk melakukan sesuatu tetapi tidak ada penyatuan prosedur tersebut yang menghasilkan redundansi dan mencoba memperbaiki sesuatu yang sudah diperbaiki.

Setelah WPF dibuat, Microsoft masuk ke "pola pikir yang cukup baik" ini secara langsung dinyatakan dalam kualitas aplikasi bahkan dari tim Microsoft sendiri. Jika aplikasi kotak masuk Microsoft sendiri tidak dapat masuk ke halaman yang sama dengan konsistensi seragam berkualitas tinggi dalam kode & keseragaman aplikasi, bagaimana kami mengharapkan mitra pihak ketiga untuk mengirimkannya?

Memberikan hasil kode generik tetapi dapat disesuaikan dalam aplikasi dasar umum. Sebagian besar pengembang tidak akan melakukan upaya ekstra untuk membuat aplikasi mereka terlihat fungsional dan halus, mereka hanya akan melakukan cukup untuk membuat aplikasi mereka berfungsi. Tingkat "melakukan cukup untuk membuatnya berfungsi" diambil oleh pengguna akhir sebagai "setengah-setengah".

Menurut pendapat saya, titik kontrolnya adalah memiliki kode berkualitas tinggi yang dapat Anda gunakan, dan Anda dapat menyesuaikannya berdasarkan jika Anda mau.

Memberikan opsi pengembang, untuk cara mereka menggunakan kontrol juga memiliki hal positif, alih-alih menguncinya ke dalam satu cara untuk mengelola pesan dan pemberitahuan.

Tetapi memastikan opsi apa pun yang mereka pilih, terlihat dan berperilaku dengan cara yang akrab, dan "milik" dengan Desain Lancar - memiliki manfaat konsistensi.

Jadi, jika kontrol itu sendiri di WinUI tidak menyediakan pendekatan terpadu, mungkin Windows Toolkit dapat membuat API pembantu yang mengelolanya.

Saya sarankan Anda mengusulkannya di repo itu, dan itu dapat menggunakan kontrol WinUI untuk menyajikannya di aplikasi

Hai semuanya, sebagai pembaruan, kontrol InfoBar sekarang dalam pratinjau Jika Anda memiliki aplikasi yang akan mendapat manfaat dari kontrol ini, silakan coba dan bagikan umpan balik Anda dengan kami.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
Terima kasih atas semua keterlibatan Anda sejauh ini untuk kontrol ini!

Berikut adalah contoh lain dari Bilah/Kotak/Kartu Informasi

Sunting: Saya baru menyadari masalah di bawah ini sudah diperbaiki oleh https://github.com/microsoft/microsoft-ui-xaml/issues/3581 . Harap abaikan masalah di bawah ini. Terima kasih telah membuat kontrol! Itu tampak hebat di Nightingale :)

@gabbybilka Saya akan menggunakan bilah info di aplikasi klien Nightingale REST saya. Ini sempurna untuk salah satu skenario saya. Dalam pengujian cepat saya, sepertinya ikon di bilah info tidak mendukung tema ringan? Atau mungkin saya melakukan sesuatu yang salah dalam penggunaan kontrol XAML saya. Berikut adalah beberapa tangkapan layar

Apakah Anda mempertimbangkan untuk menambahkan acara "Dibuka" ke kontrol? Dalam beberapa kasus, adalah tepat untuk menutup InfoBar secara otomatis setelah beberapa detik. Penangan acara "Terbuka" akan menjadi tempat yang tepat untuk memulai pengatur waktu.

Saya pikir warna Sukses , di Tema Gelap harus diubah. @YuliKl @anawishnoff @chigy @teaP
Warna tema gelap saat ini adalah #393D1B - yang tampak seperti warna hijau kekuningan, hampir berwarna zaitun. Sedangkan light theme menggunakan warna hijau yang lebih jernih, hampir seperti mint seperti hijau.

_Atas warna saat ini, di bawah perubahan yang diusulkan_

#1d3d1b

Ini bukan hanya untuk nilai Estetika, tetapi juga karena batang berwarna lebih zaitun tidak dapat dibedakan dari warna Peringatan

Begini tampilannya