Siapa yang berencana untuk bekerja pada kontrol Pita WinUI, mereka mungkin memiliki beberapa pertanyaan yang harus dipertimbangkan?

@mdtauk panggilan yang bagus. Saya bisa melihat Ribbon berisi TabView karena ini adalah paradigma yang sangat mirip. Akan menyenangkan untuk memanfaatkan kembali komponen untuk pengomposisian dengan cara ini.

Saya juga bisa melihat beberapa kebaikan datang dengan Ribbon dan docking. Referensi #668

Mungkinkah ada mode ringan untuk hal-hal seperti Palet Alat dan Tab Dialog.

Siapa yang berencana untuk bekerja pada kontrol Pita WinUI, mereka mungkin memiliki beberapa pertanyaan yang harus dipertimbangkan?

@mdtauk , pertanyaan bagus. #168 melacak fitur Pita. Sampai sekarang, Pita ada di "freezer". Yang mengatakan, saya melakukan prototipe pita dasar menggunakan TabView v1 sebagai blok bangunan. Ini adalah tangkapan layar konsep yang sangat kasar dan sangat lama menggunakan TabView prarilis dari beberapa bulan yang lalu:

Masalah ini melacak potensi peningkatan pada TabView, yang mungkin memiliki persyaratan khusus Ribbon. Namun, karena Ribbon ada di "freezer", kita tidak boleh mengaitkan kedua topik ini dengan erat.

@stmoy Apa pendapat Anda tentang membulatkan sudut dalam tab?

Terlihat lebih bagus & lebih konsisten bagi saya daripada hanya membulatkan di luar. Itu juga akan membuat kami lebih konsisten dengan browser Edge baru.

@stmoy Apa pendapat Anda tentang membulatkan sudut dalam tab?

Saya suka tampilan ini! Saya menambahkan ini ke tabel di atas. Kami melakukan beberapa penyelidikan awal dari visual khusus ini dan memutuskan bahwa terlalu sulit untuk "mendapatkan yang benar" untuk rilis kontrol v1, tetapi saya ingin melihat lagi untuk v2.

@shaheedmalik saya pikir itu perilaku normal sehingga mudah untuk menyeret tab dan garis 1px adalah batas jendela yang aktif

Juga, menyeret tab dengan implementasi saat ini tidak terasa menyenangkan.

Akan lebih baik jika tab lain yang tidak dipilih/diseret tidak menyusut atau menjadi "tidak aktif" (berwarna abu-abu). Itu juga harus masuk ke strip tab sehingga perlu ada kekuatan untuk membuat jendela baru. Chrome/Chromium/Edge (Anaheim) seperti lambang tab :p

TabView Perilaku ListView yang Tidak Diinginkan

@stmoy Dalam skenario aplikasi saya, kami memiliki ObservableCollection yang berisi objek kelas InstanceTabItem yang masing-masing berisi properti untuk Konten. Koleksi ini terikat ke properti TabItemsSource. Properti Content berisi Frame yang menjadi konten TabView ContentPresenter. Namun, saya perhatikan bahwa menutup setiap TabViewItem tidak akan melepaskan memori yang digunakan oleh properti konten InstanceTabItem meskipun sepenuhnya dihapus dari koleksi. Faktanya, acara Loaded untuk TabViewItems sendiri hanya dipanggil satu kali. Artinya menutup TabViewItem tidak membongkar/membuangnya. Perilaku ini menyiratkan bahwa TabView harus memiliki semacam mekanisme virtualisasi yang digunakan untuk mendaur ulang item yang memiliki konsekuensi yang tidak diinginkan yaitu tidak menghancurkan konten TabViewItem saat ditutup. Mudah-mudahan, Anda dapat melihat bagaimana ini menjadi masalah untuk skenario aplikasi saya. Mengingat kami sedang dalam masalah menghapus/memodifikasi perilaku ListView yang tidak diinginkan dari TabView, saya ingin memastikan ini dicatat.

Pertanyaan-pertanyaan terbuka:
Apakah virtualisasi ListView diperlukan untuk TabView, jika demikian, bagaimana cara menonaktifkannya atau mencegah masalah ini?

Haruskah ada cara mudah untuk menonaktifkan virtualisasi untuk TabView?

Apakah ada cara yang lebih baik untuk mengaitkan konten Halaman dengan setiap tab dan menampilkannya di TabView ContentPresenter saat dipilih?

Tidak yakin apakah ini masalah yang benar, tapi...

Saya ingin hanya dapat menggunakan TabStrip dari TabView.

Pembaruan Cakupan (13 Jan 2020)

Halo semua! Saya ingin memberikan pembaruan cepat tentang ini. Terima kasih kepada semua orang yang memberikan masukan dan ide mereka! Saya telah mengambil ide-ide ini dan mengajukannya ke tim kami untuk melihat apa yang ada dalam ruang lingkup untuk versi WinUI berikutnya.

Beberapa ide yang paling kami sukai adalah yang meningkatkan polesan keseluruhan dan pengalaman pengguna TabView. Salah satu tujuan awal kami adalah mencoba membuat TabView terasa sebagus yang Anda lihat di browser dan kami menemukan bahwa penerapan saat ini belum memenuhi tujuan itu. Alasan utamanya adalah TabView dibuat menggunakan ListView khusus "di bawah selimut" yang membatasi kemampuan kami untuk mendapatkan beberapa fitur fit-and-finish yang benar-benar kami inginkan.

Untuk itu, kita akan menukar implementasi ListView ke implementasi berdasarkan ItemsRepeater yang lebih fleksibel. Dengan demikian, kami berharap dapat mengatasi beberapa fitur yang sebelumnya diblokir - yaitu seputar animasi dan drag-and-drop. Ini juga berarti bahwa kita tidak akan mendapatkan semua yang ada di daftar karena ini akan menjadi penulisan ulang yang cukup besar dan kuat.

Saya telah memodifikasi masalah di atas untuk mencerminkan kumpulan fitur yang kami harapkan di 2.4 vs. fitur yang tidak akan bisa kami dapatkan saat ini. Seperti semua latihan perencanaan, ini datang dengan beberapa pemotongan yang menyakitkan - tetapi harapan saya adalah bahwa kita akan lebih siap untuk mendapatkan fitur ini setelah 2.4 setelah kita memiliki fondasi yang lebih kuat untuk dibangun.

@ToddThomson Jika Anda tidak memberikan konten item tab apa pun, maka tab hanya akan berdiri sendiri, jadi itu akan memungkinkan Anda untuk hanya menggunakan tab.

@stmoy jika pembulatan sudut hanya diekspos sebagai sumber daya, maka itu dapat dimodifikasi, sehingga pengembang dapat dengan mudah membuat templat ulang atau memalsukan memiliki tab bawah hingga properti lokasi tab diimplementasikan.

@stmoy Saya juga baru menyadari bahwa TabView menggunakan IconSource vs. NavigationView Icon (IconElement). Apakah ini akan lebih selaras di WinUI3?

Hal ini berguna untuk hanya dapat menempatkan Icon="Home" untuk konstruksi sederhana dan kemudian menguraikan IconSource dengan tipe kompleks jika diperlukan.

@stmoy kami juga memiliki #1999 mirip dengan #1511 kami harus memastikan bahwa animasi penutupan dan pembukaan diperbarui dengan vnext.

Sesuatu yang mungkin perlu ditelusuri dan @Felix-Dev dan saya diskusikan di UWP Community Discord adalah kemampuan untuk mengubah akselerator keyboard untuk menutup tab. Misalnya, beberapa pengembang mungkin ingin menggunakan hotkey yang sama dengan Edge untuk menutup tab, yang saat ini agak sulit diterapkan.

@chingucoding @Felix-Dev

Setuju bahwa pengembang harus dapat mengatur/mengubah/menyesuaikan penekanan tombol yang didorong pengguna untuk menutup tab. Cara yang kami sarankan agar aplikasi mencapai perilaku tersebut hari ini didokumentasikan dalam Dokumen Panduan Papan Ketik TabView

Saya sama sekali tidak menentang untuk membuat ini lebih mudah bagi pengembang aplikasi, tetapi ini adalah area yang dapat menggunakan lebih banyak pemikiran karena saya tidak tahu bagaimana cara terbaik untuk mengekspos API ini. Apakah Anda punya ide? Mungkin bermanfaat untuk mengajukan masalah GitHub baru yang melacak ini secara khusus.

@stmoy Terima kasih telah menautkan dokumen. Saat ini kami memiliki tiga akselerator keyboard bawaan untuk kontrol TabView:

• Ctrl+F4 yang menutup tab yang dipilih (perhatikan bahwa dokumen merekomendasikan pengembang untuk menggunakan Ctrl+W . Kita mungkin harus mengatasi hal ini (baik dengan memperbarui akselerator keyboard tab tutup bawaan ke (juga) menggunakan Ctrl+W atau ubah dokumentasi untuk merekomendasikan Ctrl+F4).
• Ctrl+Tab yang memilih tab berikutnya
• Ctrl+Shift+Tab untuk memilih tab sebelumnya

Karena kita sudah memiliki tiga akselerator keyboard bawaan ini....mungkin kita harus meningkatkan ruang lingkup pemikiran kita di sini. Mengapa tidak

• tambahkan akselerator keyboard bawaan untuk menambahkan tab baru (default ke Ctrl+T )?
• tambahkan akselerator keyboard bawaan untuk memilih tab tertentu atau melompat cepat ke awal dan akhir daftar tab?

Berpotensi menambahkan semua ini ke dalam kontrol TabView itu sendiri dapat sangat meningkatkan perintah bawaan yang harus dibuat dapat disesuaikan untuk pengembang. Ini dapat memengaruhi pendekatan yang kita putuskan untuk dipilih.

Karena itu, saya tidak yakin apakah kita harus menambahkan semua akselerator Ctrl+[Num], tetapi rasanya aneh bagi saya bahwa kita memiliki pintasan bawaan untuk menutup tab, tetapi tidak untuk membuka tab. Saya pikir kita setidaknya harus menambahkan pintasan keyboard bawaan untuk membuka tab baru.

Pendekatan termudah untuk memberi pengembang pengalaman akselerator keyboard tab yang dapat disesuaikan mungkin akan menambahkan properti individual untuk setiap akselerator bawaan yang ingin kami tampilkan untuk penyesuaian:

• TabCloseButtonKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator

Jika kami ingin membuat setiap akselerator keyboard bawaan dapat disesuaikan, kami akan menambahkan dua properti lagi:

• SelectNextTabKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator
• SelectPreviousTabKeyboardAccelerator : Windows.UI.Xaml.Input.KeyboardAccelerator

Pertanyaan-pertanyaan terbuka

Jika kami membuat akselerator keyboard bawaan dapat disesuaikan, apakah kami mengizinkan pengembang untuk tidak menyetel akselerator keyboard sama sekali? Saat ini, selalu ada akselerator untuk menutup tab atau menggulir daftar tab. Namun, semua interaksi potensial lainnya (seperti menambahkan tab baru atau melompat ke tab pertama/terakhir) dapat memiliki akselerator keyboard atau tidak. Itu terserah pengembang.

Jika kami mengizinkan pengembang untuk tidak menyetel akselerator keyboard bawaan (yaitu tidak ada akselerator sama sekali untuk menutup tab), ini akan memperkenalkan perubahan signifikan pada perilaku TabView standar saat ini.

Jika kami melarang pengembang untuk menghapus akselerator keyboard bawaan, kami dapat kembali ke akselerator bawaan saat ini jika pengembang tidak menyetel akselerator keyboard yang valid.

@stmoy Terima kasih telah menautkan dokumen itu! Cara-cara untuk menambahkan akselerator keyboard baru tampaknya layak untuk sebagian besar pengembang.

Namun satu masalah yang saya lihat adalah, apa yang harus dilakukan jika mereka sudah menggunakan Ctrl+F4. Dari apa yang saya lihat, saat ini tidak mungkin untuk membatalkan penetapan akselerator keyboard. Jadi pengembang perlu memastikan bahwa mereka tidak menggunakan Ctrl+F4 di tempat lain, yang mungkin sedikit bermasalah.

Saya setuju dengan @Felix-Dev , menambahkan properti akselerator keyboard mungkin merupakan cara termudah, dan mungkin juga salah satu cara yang lebih intuitif untuk menanganinya dari pengalaman pengguna.

Namun satu masalah yang saya lihat adalah, apa yang harus dilakukan jika mereka sudah menggunakan Ctrl+F4. Dari apa yang saya lihat, saat ini tidak mungkin untuk membatalkan penetapan akselerator keyboard. Jadi pengembang perlu memastikan bahwa mereka tidak menggunakan Ctrl+F4 di tempat lain, yang mungkin sedikit bermasalah.

• tambahkan akselerator keyboard bawaan untuk menambahkan tab baru (default ke Ctrl+T)?
• tambahkan akselerator keyboard bawaan untuk memilih tab tertentu atau melompat cepat ke awal dan akhir daftar tab?

Ini saling terkait. Karena tidak ada cara yang baik untuk membatalkan penetapan akselerator keyboard bawaan, kami sengaja tidak memasang banyak akselerator jika aplikasi sudah menggunakan kombo tombol tertentu.

rasanya aneh bagi saya bahwa kami memiliki pintasan bawaan untuk menutup tab, tetapi tidak untuk membuka tab

Setuju dan kami menghabiskan banyak waktu untuk memperdebatkan topik ini. Seperti di atas, ini adalah kelalaian yang disengaja. Kami menambahkan akselerator untuk menutup tab karena kombo ini adalah salah satu yang diandalkan oleh pengguna aksesibilitas dan tampaknya cukup jelas sehingga tidak akan bertentangan dengan pintasan aplikasi jika mereka memilikinya. CTRL+T tampak lebih umum, dan kami tidak ingin berkonflik.

Sebelum kita menambahkan lebih banyak akselerator keyboard bawaan, saya pikir kita perlu mencari cara untuk membiarkan aplikasi tidak disetel/menonaktifkannya sehingga mereka dapat melakukannya jika pintasan sudah digunakan oleh aplikasi.

Yang mengatakan, saya rasa tidak _itu_ sulit untuk menambahkan pintasan ke TabView dengan mengikuti dokumen/panduan. Dengan kata lain: Saya tidak tahu apakah ini masalah yang perlu dipecahkan sekarang.

Dengan membatalkan penetapan akselerator keyboard menjadi tidak mudah, saya pikir perilaku saat ini cukup baik. Kecuali kami memiliki cara mudah untuk menghapus akselerator keyboard yang ada, saya pikir yang terbaik adalah menahan diri untuk tidak menambahkan banyak akselerator, seperti yang ditunjukkan oleh @stmoy dengan benar.

Dan menambahkan akselerator keyboard baru tidak terlalu sulit asalkan seseorang telah membaca dokumen jadi mungkin ini bukan area di mana kita perlu melakukan banyak hal.

@chingucoding ya, jika ada contoh yang menunjukkan penambahan pintasan keyboard tambahan untuk berinteraksi dengan tab di tingkat aplikasi atau tingkat tab individual, itu akan berguna untuk mengatasi beberapa masalah ini.

Mungkin perlu ada proposal terpisah untuk cara yang lebih baik untuk memiliki akselerator keyboard yang dapat diekspos dan diganti sebagai bagian dari gaya atau templat atau semacamnya?

Bisakah kita mengharapkan akrilik dan mengungkapkan kuas di TabView baru? Desain TabView saat ini TIDAK "fasih".

Selain itu, pengaturan gaya atau latar belakang untuk TabViewItem tidak akan berpengaruh.

Beberapa di antaranya adalah contoh lama ketika Sets diumumkan, dan sebelum chromium Edge - tetapi ini menunjukkan bagaimana Tab dapat menggunakan Fluent Acrylic dan area Title Bar untuk memberikan UX yang hebat

Berikut adalah contoh akrilik yang digunakan di Tabs di Files UWP.

@yaichenbaum Contoh itu lebih merupakan Pita XAML WinUI, tapi ya, Akrilik dan Tab.

@mdtauk Kebetulan menyertakan pita, tetapi poin utamanya adalah tab di bagian atas.

@mdtauk Kebetulan menyertakan pita, tetapi poin utamanya adalah tab di bagian atas.

Saya mendahului komentar apa pun yang mencoba menolak untuk mengizinkan Acrylic, dengan argumen tentang Ribbon vs Tabs

Apakah akan ada dukungan yang ditambahkan ke TabView untuk menangani UI Layar Ganda?

Membungkus kumpulan Tab menjadi dua grup dengan lebar engsel di antaranya saat aplikasi direntangkan di kedua layar?

Mungkin lihat bagaimana Edgium menangani berbagai hal, jika tidak ada cara langsung yang jelas untuk menanganinya.

Tautan ke masalah Tab Vertikal baru #2194

Mengenai masalah yang disebutkan di atas, apakah itu dalam cakupan untuk versi berikutnya?

Jadi karena Edge memungkinkan untuk Tab dengan jendela PWA, kami melihat gaya baru untuk bilah Tab, menggunakan warna yang dipilih.

Apakah TabView perlu menawarkan opsi gaya untuk memungkinkan penggunaan warna Aksen.

Terminal dapat mengambil manfaat dari langkah apa pun ke arah ini, karena ia berharap dapat menambahkan opsi tema XAML untuk pengguna - atau untuk memungkinkan pilihan pengguna dari TitleBar berwarna untuk bekerja dengan TabViews meluas ke area bilah judul.

Jadi karena Edge memungkinkan untuk Tab dengan jendela PWA, kami melihat gaya baru untuk bilah Tab, menggunakan warna yang dipilih.

Apakah TabView perlu menawarkan opsi gaya untuk memungkinkan penggunaan warna Aksen.

Dengan versi TabView saat ini, Anda dapat mengubah semua warna yang diperlukan untuk mencapai efek yang sama seperti tangkapan layar yang Anda bagikan. Ini dapat dilakukan melalui penataan yang ringan (menggantikan kuas tertentu), membuatnya cukup mudah diterapkan untuk pengembang.

@mdtauk Apakah ide Anda untuk menyediakan satu warna properti dan TabView secara otomatis menghitung warna hover, dipilih, diklik dan default untuk TabView? Ini dapat menimbulkan masalah dengan gaya ringan karena Anda perlu memutuskan kapan harus menggunakan sumber daya yang mana, yang dapat menyebabkan kebingungan.

Jadi karena Edge memungkinkan untuk Tab dengan jendela PWA, kami melihat gaya baru untuk bilah Tab, menggunakan warna yang dipilih.

Apakah TabView perlu menawarkan opsi gaya untuk memungkinkan penggunaan warna Aksen.

Dengan versi TabView saat ini, Anda dapat mengubah semua warna yang diperlukan untuk mencapai efek yang sama seperti tangkapan layar yang Anda bagikan. Ini dapat dilakukan melalui penataan yang ringan (menggantikan kuas tertentu), membuatnya cukup mudah diterapkan untuk pengembang.

@mdtauk Apakah ide Anda untuk menyediakan satu warna properti dan TabView secara otomatis menghitung warna hover, dipilih, diklik dan default untuk TabView? Ini dapat menimbulkan masalah dengan gaya ringan karena Anda perlu memutuskan kapan harus menggunakan sumber daya yang mana, yang dapat menyebabkan kebingungan.

Saya berpikir lebih banyak tentang menyediakan Gaya yang mengambil nuansa Warna Aksen dan menerapkannya ke kontrol TabView - membuat warna tertentu akan menjadi opsi biasa untuk kontrol ini, bahkan jika itu akan lebih fleksibel daripada menggunakan sistem Warna Aksen .

Ini akan membutuhkan kode untuk mengambil warna, dan menghasilkan nuansa untuk digunakan dan menghitung rasio kontras, dll.

Saya berpikir lebih banyak tentang menyediakan Gaya yang mengambil nuansa Warna Aksen dan menerapkannya ke kontrol TabView - membuat warna tertentu akan menjadi opsi biasa untuk kontrol ini, bahkan jika itu akan lebih fleksibel daripada menggunakan sistem Warna Aksen .

Benar, jadi itu akan menjadi sesuatu yang mirip dengan AccentButtonStyle, hanya untuk TabView. Itu pasti ide yang keren menurut saya. Saya tidak sepenuhnya yakin seberapa mudah untuk membenarkannya (misalnya pemeliharaan, dampak RAM, penyelarasan dengan Sistem Desain Lancar), tapi mari kita tunggu apa yang @stmoy dan @chigy pikirkan tentang ini.

Saya berpikir lebih banyak tentang menyediakan Gaya yang mengambil nuansa Warna Aksen dan menerapkannya ke kontrol TabView - membuat warna tertentu akan menjadi opsi biasa untuk kontrol ini, bahkan jika itu akan lebih fleksibel daripada menggunakan sistem Warna Aksen .

Benar, jadi itu akan menjadi sesuatu yang mirip dengan AccentButtonStyle, hanya untuk TabView. Itu pasti ide yang keren menurut saya. Saya tidak sepenuhnya yakin seberapa mudah untuk membenarkannya (misalnya pemeliharaan, dampak RAM, penyelarasan dengan Sistem Desain Lancar), tapi mari kita tunggu apa yang @stmoy dan @chigy pikirkan tentang ini.

Saya tahu Edge memimpin dalam mengarahkan kontrol TabView - dan ini adalah fitur baru di mana PWA dapat menggunakan jendela tab, dan saya yakin itu dapat mengontrol Warna Titlebar.

Terminal memiliki banyak permintaan untuk Titlebar berwarna, dan mereka berencana untuk mengimplementasikan tema XAML pengguna.

Saya tahu Edge memimpin dalam mengarahkan kontrol TabView - dan ini adalah fitur baru di mana PWA dapat menggunakan jendela tab, dan saya yakin itu dapat mengontrol Warna Titlebar.

Ya, saya pikir memiliki paritas fitur dengan edge adalah sesuatu yang harus kita tuju.

Terminal memiliki banyak permintaan untuk Titlebar berwarna, dan mereka berencana untuk mengimplementasikan tema XAML pengguna.

Hanya ingin tahu, dapatkah menautkan beberapa masalah tersebut untuk memahami fitur yang akan membantu mereka dengan lebih baik? 😄

Lihatlah PR ini (Spesifikasi tema): https://github.com/microsoft/terminal/pull/5772

Saya tahu Edge memimpin dalam mengarahkan kontrol TabView - dan ini adalah fitur baru di mana PWA dapat menggunakan jendela tab, dan saya yakin itu dapat mengontrol Warna Titlebar.

Ya, saya pikir memiliki paritas fitur dengan edge adalah sesuatu yang harus kita tuju.

Terminal memiliki banyak permintaan untuk Titlebar berwarna, dan mereka berencana untuk mengimplementasikan tema XAML pengguna.

Hanya ingin tahu, dapatkah menautkan beberapa masalah tersebut untuk memahami fitur yang akan membantu mereka dengan lebih baik? 😄

Berikut adalah beberapa
https://github.com/microsoft/terminal/issues/4862
https://github.com/microsoft/terminal/issues/3973
https://github.com/microsoft/terminal/issues/3624
https://github.com/microsoft/terminal/issues/1963

Terima kasih atas tautannya @mdtauk dan @Felix-Dev !

Saya tidak bermaksud terdengar kasar di sini, tetapi saya pikir itu perlu dikatakan. Desain TabView WinUI saat ini terlihat sangat tidak pada tempatnya di aplikasi UWP. Ini jelas diambil dari tab Edgium, yang merupakan klon dari tab Chrome. Saya tidak mengerti mengapa kami mencuri gaya itu, terutama karena kami sudah memiliki UI Desain Lancar untuk TabView di WCT.

Saya tidak bermaksud terdengar kasar di sini, tetapi saya pikir itu perlu dikatakan. Desain TabView WinUI saat ini terlihat sangat tidak pada tempatnya di aplikasi UWP. Ini jelas diambil dari tab Edgium, yang merupakan klon dari tab Chrome. Saya tidak mengerti mengapa kami mencuri gaya itu, terutama karena kami sudah memiliki UI Desain Lancar untuk TabView di WCT.

Edgium dan Chrome tidak menggunakan desain Tab yang sama

Dan desainer WinUI telah memutuskan ini adalah gaya tab yang harus digunakan, dan sudut membulat cocok dengan nilai WinUI.

Sekarang saya kira beberapa akan lebih memilih desain tab Edge sebelumnya.

Dan ada proposal tentang memberikan gaya alternatif untuk kontrol. #2587

Tentu, ada perbedaan kecil antara gaya tab Chrome dan Edgium, tetapi Anda masih dapat mengetahui bahwa yang satu adalah tiruan dari yang lain. Rata-rata pengguna (termasuk saya pada awalnya) bahkan tidak dapat membedakan keduanya secara sekilas. Desain tampilan tab saat ini bukanlah Desain Lancar. Faktanya, ini melanggar sebagian besar prinsip yang menjadi dasar Fluent Design.

Adaptif: Pengalaman lancar terasa alami di setiap perangkat

Desainnya terasa rata-rata di desktop (bagaimanapun juga, ini didasarkan pada desain Chrome), tetapi sulit digunakan dengan layar sentuh, terutama tombol tutup. Itu terlalu kecil untuk disentuh, bahkan pada layar 13" (yang merupakan skala laptop kecil, bahkan tablet berukuran rata-rata). Bagian dari mengapa tampilan tab WinUI terasa tidak pada tempatnya adalah karena tidak menyentuh- ramah seperti kontrol lainnya. Dua platform lain yang disebutkan di halaman ini adalah Xbox dan Mixed Reality/Hololens. Desain ini sudah terasa aneh jika disandingkan dengan aplikasi yang menggunakan Fluent Design di desktop. Bayangkan betapa buruknya jika seluruh sistem operasi , dan semua aplikasi di dalamnya, menggunakan deskripsi resmi asli dan terkini dari Desain Lancar? Pengguna selalu menggunakan Microsoft untuk ketidakkonsistenan UI, mengapa memberi mereka alasan lain?

Empati: Pengalaman yang lancar bersifat intuitif dan kuat

Baik tampilan tab WinUI/Edgium dan WCT saat ini melakukan ini dengan sangat baik, bagus!

Indah: Pengalaman yang lancar menarik dan mendalam

Halaman dokumen yang saya tautkan sebelumnya mencantumkan lima "pilar" ini untuk mencapai ini: cahaya, bayangan, gerakan, kedalaman, dan tekstur.

Kedalaman & Bayangan

Desain WinUI/Edgium saat ini memiliki beberapa kedalaman karena bayangan yang ditambahkan ke tepi tab. Itu tidak banyak, tetapi tidak harus begitu. Adapun kedalaman secara umum, dokumen secara khusus merujuk paralaks untuk menciptakan kedalaman. Ini tidak terlalu praktis untuk tampilan tab, karena tidak ada gambar latar belakang atau apa pun.

Lampu

Dalam Desain Lancar, cahaya biasanya digunakan untuk menyorot saat ada sesuatu yang dapat diklik. Itu sebabnya kontrol seperti Buttons, AppBarButtons, dan NavigationView menggunakan sorotan pengungkapan pada latar belakang dan batasnya. Ini adalah sesuatu yang tidak dimiliki tampilan tab WinUI sama sekali. Bahkan tab Chrome memiliki sedikit efek seperti terbuka saat Anda mengarahkan kursor ke atasnya. Seperti berdiri, sebenarnya tidak ada visual yang mengisyaratkan bahwa tab ini dapat berinteraksi. Setidaknya harus ada beberapa pengungkapan di perbatasan tab.

Gerakan

Desain saat ini juga memiliki beberapa gerakan, terutama saat tab diseret. (Ini cukup bermasalah, baik secara visual maupun teknis, tetapi itu adalah masalah terpisah yang telah diajukan dan sedang diperbaiki.) Satu-satunya tempat lain untuk menambahkan gerakan adalah konten tampilan tab. Saat ini, konten tab muncul begitu saja tanpa transisi apa pun. Mungkin ada transisi konten default di template, seperti yang dilakukan NavigationView.

Tekstur & Bahan

Satu-satunya tekstur/bahan yang berlaku di sini (dan benar-benar satu-satunya yang ada di Fluent Design) adalah akrilik. Legacy Edge menggunakan akrilik untuk latar belakang tampilan bilah judul/tab, yang sangat bagus, tetapi tidak semua orang menyukainya. Tampilan tab WinUI memungkinkan pengembang untuk memutuskan apakah akan menggunakan akrilik sebagai latar belakang atau tidak, yang sangat kami hargai oleh para pengembang (termasuk saya).

TL:DR; Nyaman dengan mouse dan keyboard di desktop, tetapi aneh pada perangkat layar sentuh besar dan benar-benar tidak dapat digunakan di Xbox, Mixed Reality, dan Mobile (atau perangkat berukuran seluler).

WinUI 3 saat peluncuran tidak akan mendukung Acyrlic HostBackdrop atau Reveal. Saya akan membayangkan begitu WinUI 3 mendukung hal-hal ini, Windows 10 versi Edge, dapat mengadopsinya.

@yoshiask saya bahkan tidak tahu lagi apa yang masih Fasih Desain dan apa yang tidak. Pertimbangkan akrilik dalam aplikasi: Melihat WinUI, tampaknya pada Windows, UI sementara seperti menu konteks dan flyout harus menggunakan akrilik dalam aplikasi secara default. Panel NavigationView juga menggunakan akrilik dalam aplikasi saat ditampilkan sebagai overlay. Selanjutnya, dokumentasi resmi menyatakan hal berikut mengenai kapan harus menggunakan akrilik:

Ini, sekali lagi, dicocokkan dengan tampilan default dari kontrol yang dikirimkan dengan WinUI yang "mewujudkan Desain Lancar".

Namun, beberapa hari yang lalu, tim Microsoft Edge mengumumkan hal berikut :

[...] Anda akan melihat bahwa versi baru Edge diselaraskan dengan arah saat ini yang sedang dituju oleh Fluent [...]. Contoh lain adalah bahwa tidak ada fokus penting pada transparansi dalam desain Fluent terbaru, dan permukaan Edge versi baru mencerminkan hal ini.

Namun tidak ada UI sementara di browser Edge yang menggunakan akrilik dalam aplikasi, seperti menu konteks:

Jadi ... ini menimbulkan pertanyaan berikut:

• Apakah Edgium menggunakan iterasi Desain Lancar yang lebih baru daripada WinUI di Windows? Apakah akrilik dalam aplikasi digunakan sebagai latar belakang untuk UI sementara seperti menu konteks sudah usang dan harus diganti dengan warna latar belakang yang solid?
• Jika tidak, mengapa tim Edgium tampaknya mengatakan Edgium di Windows 10 sudah "Fluent Design'ed" ketika salah satu pilar Fluent Design - Acrylic - hilang di mana-mana di browser? Dan sepertinya mereka tidak berencana untuk menambahkan akrilik dalam aplikasi ke UI sementara browser?

Saya pribadi percaya tim Edge tidak ingin melalui tugas menciptakan kembali efek akrilik yang mereka dapatkan secara gratis ketika mereka mengirimkan Edge UWP. Tetapi dalam hal ini, saya akan menyambutnya jika mereka cukup jujur ​​untuk mengatakannya seperti itu, dan tidak bertindak seperti akrilik dalam aplikasi untuk UI sementara tidak lagi menjadi default untuk Desain Lancar di Windows.

Komentar mereka tentang aspek transparansi dalam Desain Lancar dan bagaimana Edgium mencerminkan hal ini, adalah - berdasarkan WinUI dan dokumentasi resmi - tidak akurat. Polos dan sederhana. UI sementara mereka harus dikirimkan dengan akrilik latar belakang dalam aplikasi. Mereka tidak. Untuk alasan apa pun.

Mungkin Edium menggunakan iterasi Desain Lancar terbaru dan WinUI akan segera menyusul? Mungkin akrilik dalam aplikasi dan efek pengungkapan akan segera tidak lagi menjadi bagian dari Desain Lancar? Jika itu masalahnya maka ya, Edgium memang akan mengimplementasikan pilar Desain Lancar yang dinyatakan oleh tim Edgium.

Saya tidak bermaksud mengalihkan pembicaraan ke desain Edgium secara umum. Saya hanya ingin menunjukkan bahwa kita tampaknya mengambil isyarat dari desain tab Edgium ketika sama sekali tidak ada alasan atau manfaat untuk itu. Ini adalah WinUI, dan berjalan di Windows 10. Saya mengerti bahwa WinUI 3 tidak memiliki akrilik latar belakang host sekarang, tetapi 2.x memilikinya. Selain itu, kedua versi telah mengungkapkan dan dimaksudkan untuk ramah sentuhan.

Saya tidak bermaksud mengalihkan pembicaraan ke desain Edgium secara umum.

@yoshiask Ya, saya tahu itu. Maksud dari komentar saya di atas adalah mungkin Edgium sudah mengikuti iterasi Desain Lancar terbaru yang belum kita sadari. Mungkin akrilik dan pengungkapan dalam aplikasi tidak lagi penting bagi Desain Lancar. Setidaknya posting blog oleh tim Edge yang ditautkan di atas tampaknya menunjukkan hal itu.

Yang mengatakan, saya akan senang jika efek pengungkapan dapat ditambahkan ke tab dan tombol TabView (seperti di Edge UWP). Tapi saya tidak tahu apakah itu cocok dengan pedoman Desain Lancar paling mutakhir lagi.

(Catatan: Tombol gulir TabView menggunakan pengungkapan saat ini. Mengapa hanya mereka? Mengapa tidak memperluasnya ke elemen UI TabView lainnya juga?)

Inilah konsep bagaimana Edge seharusnya terlihat.

https://www.reddit.com/r/Windows10/comments/hwsgyc/so_its_been_more_than_a_year_since_we_got_the/

Akrilik membuatnya terlihat lebih bersih, tetapi masih belum terlalu Lancar. Tata letak UI tidak berubah sama sekali, dan tombol tutup masih sama sulitnya untuk diketuk.

Akrilik membuatnya terlihat lebih bersih, tetapi masih belum terlalu Lancar. Tata letak UI tidak berubah sama sekali, dan tombol tutup masih sama sulitnya untuk diketuk.

Jadi yang Anda minta adalah target sentuh yang lebih besar untuk tombol tutup?

Area target hit sentuh umumnya harus berukuran 40x40 piksel di WinUI menurut pemahaman saya (kita dapat melihat yang digunakan untuk chevron NavigationView/TreeView dan tombol putar NumberBox Popup). Nilai seperti tinggi minimum 32 piksel juga terkadang digunakan (lihat contoh Kotak Centang). Sementara area target hit 40x40px atau 32x32px untuk tombol Tutup bermasalah mengingat UI TabVíew saat ini, saya melakukan beberapa pengujian cepat dan peningkatan dari 16x16px menjadi 24x24px untuk area target hit tampaknya mungkin:

| 16x16px (saat ini) | 24x24px (kemungkinan perubahan) |
|----|----|
| | |

(Saya juga telah menyesuaikan margin kanan tombol tutup pada tangkapan layar di atas. Dengan margin kanan asli, akan terlihat seperti ini:
)

@Felix-Dev Target Sentuh bisa lebih besar dari visual untuk latar belakang melayang - saya berpendapat target sentuh 32x32 dengan melayangkan visual 20x20 akan terlihat bagus, dan berfungsi dengan baik.

@mdtauk Jadi sesuatu seperti visual hover Kotak Centang (ini adalah kotak centang yang dimodifikasi dengan latar belakang centang transparan dalam keadaan istirahat):

@mdtauk Jadi sesuatu seperti visual hover Kotak Centang (ini adalah kotak centang yang dimodifikasi dengan latar belakang centang transparan dalam keadaan istirahat):

Itu akan membantu dalam ukuran target jari, dan tidak terlihat buruk.

Latar belakang diatur ke sikat Transparan dan Template Latar BelakangBinding masuk ke Rectangle baru yang digunakan sebagai visual Hover/Pressed. Fokus Visual akan berukuran sekitar 32 x 32.

@mdtauk Berikut adalah bagaimana hal itu bisa terlihat seperti itu (area melayang visual 20x20px):

dengan area target hit (32x32px) yang ditunjukkan dengan warna merah di bawah ini:

Tombol Tutup saat ini tidak berpartisipasi dalam penghentian tab, jadi tidak ada Visual Fokus untuk pemahaman saya, tetapi jika itu untuk berpartisipasi, itu bisa terlihat seperti ini:

Bagaimana menurutmu?

Terlihat bagus untukku. Saya yakin itu perlu dilihat oleh tim desain dan aksesibilitas untuk memastikannya berfungsi dengan baik untuk audiens tersebut.

Ya, mungkin margin antara ContentPresenter TabViewItem dan simbol 'x' dapat dikurangi sedikit lebih jauh (terutama jika tidak ada Focus Visual yang perlu diingat untuk saat ini). Ping @stmoy di sini untuk keseluruhan pemikiran tentang diskusi di atas.

Sunting: Ini adalah tangkapan layar yang menunjukkan margin yang sedikit berkurang (bandingkan dengan tangkapan layar/GIF di atas):

Akrilik membuatnya terlihat lebih bersih, tetapi masih belum terlalu Lancar. Tata letak UI tidak berubah sama sekali, dan tombol tutup masih sama sulitnya untuk diketuk.

Perubahan Tata Letak UI apa yang Anda pikirkan - seandainya Target Sentuh untuk tombol tutup berubah?

Saya memindahkan target sentuh Modern IE pada Windows 8.1 ke tab Tabview dan muncul dengan ini.

Ini dia dengan target sentuh 40x40.

Akrilik membuatnya terlihat lebih bersih, tetapi masih belum terlalu Lancar. Tata letak UI tidak berubah sama sekali, dan tombol tutup masih sama sulitnya untuk diketuk.

Perubahan Tata Letak UI apa yang Anda pikirkan - seandainya Target Sentuh untuk tombol tutup berubah?

Target sentuh adalah masalah terbesar saya. Proposal untuk tombol tutup terlihat bagus, tetapi tombol tab baru memiliki masalah yang sama. Hanya itu yang bisa saya ungkapkan dengan kata-kata; desain saat ini tidak terasa selancar Desain WCT, tapi saya tidak bisa menjelaskan alasannya.

Ini adalah mockup dengan tombol tab baru 20x20 dan tombol tutup 20x20.

Ini adalah mockup dengan tombol tab baru 20x20 dan tombol tutup 20x20.

Mesin terbang Tutup terasa terlalu besar

Mesin terbang Tutup terasa terlalu besar

Aku juga tidak terlalu menyukainya. Seharusnya seperti 17x17 mungkin.

@stmoy beberapa di antaranya telah ditangani sekarang, ya? Haruskah masalah ini ditutup atau diperbarui untuk mempertimbangkan pemikiran terkini tentang pembaruan di masa mendatang (jika ada)?