Bir toggle düğmesi mevcut durumu mu göstermeli, yoksa değişeceği durumu mu? (2010)

• Play/Pause gibi anında gerçekleştirilen eylemler ile Shuffle gibi kalıcı ayarları aynı toggle ile ele almak, kullanıcıların mevcut durumla bir sonraki eylemi karıştırmasına yol açabilir
• About Face 2.0, iki seçeneği tek bir kontrolde birleştiren flip-flop button kullanımından kaçınılmasını önerir; yer tasarrufundan çok mevcut durumun iletilmesini daha önemli görür
• Çözüm, Switch to portrait mode örneğinde olduğu gibi eylemi bir fiil öbeğiyle yazmaya ya da radyo düğmeleri, onay kutuları veya durum etiketi + eylem düğmesi ile durum ve geçişi ayırmaya daha yakındır
• iOS tarzı anahtarlarda metin düğmenin içindeyse ON ifadesinin mevcut durum mu yoksa sonraki durum mu olduğu belirsiz olabilir; OS X ve Windows Metro tarzında olduğu gibi durum metni düğmenin dışına yerleştirildiğinde bu belirsizlik azalır
• Play/Pause geleneği istisna olarak bir sonraki eylemi gösterebilir; ancak Shuffle, Like, Auto save gibi seçeneklerde mevcut durumu vurgulamak ve bunu ipucu metni, renk, basılı durum veya ayrı bir etiketle desteklemek daha güvenlidir

---

Durum göstergesi ile eylem göstergesinin çatışması

• Play/Pause, Shuffle/Regular Play gibi iki durum arasında geçiş yapan düğmelerde temel mesele, mevcut durumun mu yoksa tıklama sonrası oluşacak geçiş durumunun mu gösterileceğidir
• Play/Pause, kullanıcı tarafından “oynatmayı başlat” veya “duraklat” gibi bir eylem olarak algılanmaya daha yatkındır; bu yüzden duruyorken Play, çalıyorken Pause gösterilmesi yerleşik bir gelenektir
• Shuffle/Regular Play ise oynatma yöntemiyle ilgili bir seçenek durumuna daha yakındır; değişeceği durumu göstermek, şu anda shuffle mı yoksa sıralı oynatma mı olduğunu belirsizleştirebilir
• Xbox 360 yerleşik müzik çaları, shuffle modundayken doğrudan normal oynatma simgesini gösterip ters durumda da tersini yaparak kafa karışıklığı yaratan bir örnek olarak ele alınır

About Face'in önerisi: flip-flop button'dan kaçının

• About Face 2.0, bu türü kaçınılması gereken bir seçim kalıbı olan flip-flop button olarak sınıflandırır
• Tek bir düğmenin birbiriyle dışlayıcı iki seçeneği kontrol etmesi yer kazandırsa da, kontrolün ikinci görevi olan mevcut durumu iletme işini yerine getirmesini zorlaştırır
• Düğmede ON yazarken mevcut durum kapalıysa ayarın ne durumda olduğu belirsizleşir; kapalıyken OFF yazıyorsa da ON düğmesinin nerede olduğu karışabilir
• Önerilen çözümler iki tanedir
  • Düğmenin eylemini Switch to portrait mode gibi bir fiil öbeğiyle açıkça yazmak
  • İki radyo düğmesi gibi durum seçimini görünür kılan farklı UI teknikleri kullanmak

Eylem düğmesi ile durum düğmesini ayırmak

• action button ile state button farklı şekilde tasarlanmalıdır
  • Play/Pause gibi bir eylemse, tıklandığında ne olacağını gösterir
  • Shuffle/Linear gibi bir seçenekse, mevcut durumu gösterir
• Yalnızca simge kullanan bir Shuffle düğmesinde, shuffle simgesini sabit tutup duruma göre aktif/pasif görünmesini sağlamak uygun bir yaklaşımdır
  • Açık durumda daha parlak olabilir veya basılı bir düğme gibi görünebilir
  • Kapalı durumda sıralı oynatma olduğu kolayca anlaşılabilmelidir
  • hover desteklenen ortamlarda, bunu daha açık hale getirmek için bir ipucu metni eklenebilir
• Play/Pause için de etiketi değiştirmeden Play düğmesini basılı durumda göstermek, kafa karışıklığını azaltabilecek bir yaklaşım olarak öne sürülür

Düğme içindeki metnin yarattığı belirsizlik

• ON ve OFF, İngilizcede hem durum hem de geçiş eylemi gibi okunabildiği için düğmenin içine yazıldığında durum mu komut mu olduğu bulanıklaşabilir
• Daha açık kelime çiftleri olarak şunlar önerilir
  • Enable / Disable
  • Enabled / Disabled
  • Start / Stop
  • Running / Stopped
• Ancak yalnızca kelime seçimi sorunu tamamen ortadan kaldırmaz
  • Kullanıcının düğme metninin durum mu yoksa komut mu olduğunu hâlâ yorumlaması gerekebilir
  • Enable ile Enabled arasındaki fark, UI içinde yeterince belirgin olmayabilir

Düğme dışı etiket ve durum + eylem ayrımı

• Metni doğrudan düğmenin içine koymak yerine düğmenin dışına yerleştirmek, mevcut durum ile geçiş yapılabilecek durumu birlikte göstermeyi mümkün kılar
• OS X tarzı anahtarlarda düğme ON ya da OFF demez; bunun yerine anahtarın çevresindeki metin durumu ifade eder ve böylece “bu düğme mevcut durumu mu gösteriyor, yoksa sonraki eylemi mi?” sorusunu azaltır
• Windows Metro UI yaklaşımı, düğme rengiyle mevcut durumu gösterir ve seçenek metninin altındaki On/Off ifadesiyle bunu yeniden doğrular
• Online [Go offline] gibi durum etiketi + eylem düğmesi yaklaşımı da mümkündür
  • Online, tıklanamaz mevcut durum etiketidir
  • Go offline, tıklanabilir geçiş eylemidir
  • Tıklamadan sonra Offline [Go online] olur
• Bu yaklaşım, radyo düğmelerinden daha kompakt olabilir ve yine de durum ile eylemin görsel rollerini ayırabilir

Onay kutuları, radyo düğmeleri ve basılı durum

• Shuffle gibi seçenekler, Shuffle etiketli bir onay kutusu ile gösterildiğinde karışıklık azalır
• Tek bir kelime kullanıp etkinliği işaretli/işaretsiz durumla göstermek, kullanıcıyı birden fazla kelime arasında anlam çıkarmaya zorlamaz
• Olumsuz önekli ifadelerden kaçınmak daha iyidir
  • Not, Non-, Un-, Dis-, Im-, Mis-, In-, Il-, Ir- gibi önekler, işaretin kaldırılmış haliyle birleştiğinde çift olumsuzluk gibi okunabilir
• Facebook Android uygulamasındaki Like düğmesi, kapalıyken gri, açıkken mavi vurgulu olmasıyla buna örnek gösterilir
  • Ancak yalnızca renk kullanmak, renk görme farklılıkları olan kullanıcılar için yeterli olmayabilir

Gerçek UI örnekleri ve dikkat noktaları

• Spotify web uygulamasındaki Shuffle düğmesi gibi, kapalıyken nötr renk ve açıkken vurgu rengi kullanan bir orta yol vardır
• Twitter tarzı hover geçişi, normalde mevcut durumu gösterip fare üzerine gelince eylemi göstermeye dayanır
  • hover olan ortamlarda işe yarayabilir, ancak dokunmatik ekranlarda aynı yaklaşım geçerli olmayabilir
• iOS tarzı anahtarlar iki durumu da tek kontrolde gösterir; ancak ON ifadesinin mevcut durum mu yoksa basılınca oluşacak durum mu olduğu yönünde eleştiriler vardır
• Discord ayar arayüzü, mevcut durum ile sonraki durumu daha net kılan onay kutusu benzeri bir toggle örneğidir
• Evernote'un mouseover toggle'ı ve uçak tuvaletlerindeki kol tipi anahtar gibi, hem durumun hem de etkileşime açıklığın aynı anda görülebildiği örnekler de vardır

Tasarım ilkeleri

• Tek bir kontrol hem durumu iletme hem de eylemi iletme görevini üstlendiğinde belirsizlik doğar
• Mevcut durum, bir şekilde mutlaka iletilmelidir
  • Play/Pause için müziğin duyulması veya sürenin akması gibi dış geri bildirimler mevcut durumu destekleyebilir
  • Shuffle için ise bir sonraki şarkının nasıl seçildiğini görmeden durumu anlamak zordur; bu nedenle düğmenin kendi durum göstergesi daha önemlidir
• Birden fazla durum arasında dönen tek düğmeli yaklaşım, UI'ı sıkıştırabilir ve birbirini dışlayan ayarları tek yerde toplayabilir; ancak kullanıcı mevcut durumu hızla anlayabilmelidir
• Play/Pause, güçlü yerleşik kullanım geleneği nedeniyle bir sonraki eylemi gösteren istisna olabilir; genel seçenek toggle'larında ise mevcut durumu vurgulamak daha tutarlıdır

[GN⁺]

Hacker News yorumları

• Son zamanlarda Microsoft Teams yüzünden gerçekten bunalmış durumdayım. Masaüstü uygulamasında sessizdeyken mikrofonun üzerinde çizgi olan bir simge görünüyor; sessizden çıkınca çizgisiz mikrofona dönüşüyor, bu da anlaşılması kolay.
  Ama telefon uygulamasından katılınca aynı çizgili mikrofon simgesi “şu anda sessizde değilsin, bu düğmeye basarsan sessize alınacaksın” anlamına geliyor. Bastıktan sonra simge hâlâ çizgili mikrofon olarak kalıyor, sadece arka plan tersine dönüyor.
  Bir tarafta bu “mikrofonu aç” düğmesi, diğer tarafta “sessize almayı aç” düğmesi olduğu için aynı simgeyi mi kullanıyorlar diye düşünüyorum. Sonuçta mevcut durumu anlayabilmek için düğmenin karşı durumda nasıl göründüğünü bilmek gerekiyor; bu yüzden de bu uygulamanın hangi yaklaşımı kullandığını anlamak için her seferinde birkaç kez basıp denemek zorunda kalıyorum.
  Bunun, gerçek dünyadaki referanslarını kaybetmiş flat UI’ın bedeli olup olmadığını merak ediyorum.

  • Bu kafa karışıklığının bir kısmının, mikrofonun varsayılan olarak açık olduğu düşünce biçiminden geldiğini düşünüyorum. “Mikrofon aktif”in varsayılan olduğu, sessize almanın ise bu durumdan bir sapma sayıldığı kalıp; telekonferans sistemi arayüzlerinden analog telefonlara, hatta daha da geriye, taraflar arasında gerçek bir hattın bağlı olduğu dönemlere kadar uzanıyor.
    Canlı müzik veya kayıt için kullanılan ses mikserleri de genellikle aynı kalıbı kullanır. Kanal kapatıldığında kırmızı ışığı yanan bir “Mute” düğmesi vardır; yalnızca bazı ekipmanlarda fader’ın üzerindeki “ON” düğmesi yanarak kanalın aktif olduğunu gösterir.
    Artık toplantı uygulamalarının da ses varsayılan olarak kapalıdır yaklaşımına geçme zamanı geldiğini düşünüyorum. Konuşan kişi konuştuğunda arayüz öğesinin yanması şeklinde bunun yavaş yavaş ortaya çıktığını zaten görüyoruz.
  • Bu, gerçekten kafa karıştırıcı olmaması gereken bir düğme.
  • Plex’te de uygulamadan uygulamaya UI farklı olduğu için benzer şekilde sinir bozucu. Telefonda bir dizinin sezonuna bakınca izlenmiş bölümlerde mavi bir tik oluyor; TV’de aynı sezona bakınca mavi tik yok, izlenmemiş bölümlerde sarı bir üçgen oluyor.
    Cihazlar arasında her geçiş yaptığımda beynim bir an duraksıyor.
  • Discord daha da kötü. Mikrofonu sessize alma düğmesi ile kamerayı kapatma düğmesi birbirinin tersi mantıkla çalışıyor.
  • Mikrofon göstergesi/kontrolü meselesinin epey ilginç bir yönü var. Doğrudan görsel geri bildirim yoksa mikrofonun hangi modda olduğunu, başkası tepki verene ya da vermeyene kadar bilemiyorsunuz.
    Açık olsa bile geri bildirimi gecikmeli olan bir araç. Karşı taraf durmuş olabilir ya da yanıt vermeden önce düşünüyor olabilir; bu yüzden çoğu zaman emin olmak için iki üç kez test etmek gerekir.
    Açıp kapatınca hemen görünen karanlık mod gibi değil. Bu yüzden düğme hangi eylemi yaparsa yapsın mevcut durumu gösteren görsel bir işaret çok yardımcı olur; mikrofonda özellikle “durum” ile “kontrol”ü birleştirme girişimlerinin çok olmasına şaşmamak gerek.

• Tesla sahibiyseniz buna katılmamak elde değil. Arabanın UI’ındaki toggle düğmeleri o kadar çeşitli ki ne tutarlılık var ne de standart.
  Örneğin klima düğmesi sıcaklığı gösteren tek bir düğme, ama nasıl ve ne kadar süre bastığınıza göre farklı tepki veriyor. Kısa basınca küçük bir açılır pencere, biraz daha uzun basınca tüm klima kontrol paneli açılıyor; birkaç saniye basılı tutarsanız açık olan klima kapanabiliyor. Sorun şu ki tüm bunları, sürüş sırasında yola bakmanız gereken bir durumda yapmanız gerekiyor.
  El-göz koordinasyonu azıcık şaşsa —özellikle de sürüş sırasında bir tümsekten geçerken bunun olma ihtimali yüksek— 1 mm bile kayınca başka bir düğmeye basıp istemeden farklı bir işlem yapabilirsiniz.
  Bir başka felaket de Bluetooth cihaz bağlama UX’i. En azından 2012–2022 Model S uygulaması, piyasaya çıkmış bir üründe gördüğüm en kötü UI karmalarından biriydi. Sağ alttaki düğme, bağlantı kurulduktan sonra bile “Connect” göstermeye devam ediyor; ekranın karşı tarafında sol üstte ise önce “Connecting...” yazıyor, sonra bağlantının tamamlandığını gösteriyor.
  Bu da araba içi UI olduğu için sürüş sırasında ancak bir anlığına bakabiliyorsunuz. Tesla Bluetooth UI’ı tek başına, bir UI kitabında bir bölümü dolduracak kadar mükemmel derecede kötü.

  • Tesla mobil uygulamasında yan yana duran toggle’lar bile kendi aralarında tutarlı değil.
    Kapalı kilit simgesi kapıların kilitli olduğu anlamına geliyor; basınca kapılar açılıyor.
    Bagajdaki “Open” kelimesi bagajın kapalı olduğu anlamına geliyor; basınca bagaj açılıyor.
  • Böyle bir yazıyı doğrudan yazsanız iyi olur. Bu tür analizler her zaman ilginçtir; konu Tesla olunca Elon da işin içine girer ve muhtemelen daha çok ilgi çeker.
  • Ben klima düğmesini şöyle kullanıyorum: Önce düğmeye bakıyorum; biraz saydamsa ve açmak istiyorsam sadece tıklıyorum, açılıyor. Tekrar tıklayınca tüm kontroller açılıyor; aşağı kaydırınca kapanıyor.
    Kapatmak istediğimde düğmeye tekrar basıp tüm kontrolleri açıyorum ve kapatma düğmesine basıyorum. Sıcaklığı, düğmeye tıkladıktan sonra sağa sola kaydırarak artırıp azaltıyorum.
    Bana oldukça sezgisel geliyor. Bir dahaki sürüşte basılı tutarak kapatma yöntemini de deneyeceğim; epey kullanışlı görünüyor.
  • 2023 model Model Y’de Bluetooth gerçekten iyi çalışıyor. Önceki Audi ve Ford’umda böyle değildi, o yüzden memnunum.
    Uygulamaların hep bu kadar kötü olmasına bakınca, Bluetooth spesifikasyonunun kendisinde ciddi biçimde dolanmış bir şeyler mi var acaba diye düşünüyorum.
  • Bu yasadışı olmalı.

• Eskiden elimde birkaç NASA basmalı düğme anahtarı vardı; içlerinde iki ampul bulunuyordu. Anahtar kapalıysa ikisi de sönüktü; düğmeye basınca sarı ampul yanıyor ve anahtar komutunun alındığını gösteriyordu
  Asıl açılmak istenen cihaz gerçekten açıldığında yeşil ışık yanıyor, sarı ışık sönüyordu. Sarı durum anahtarın toggle edildiğinin onayı, yeşil ise istenen eylemin gerçekten gerçekleştiğinin onayı sayılıyordu; ilginç bir durum geri bildirimi mekanizması

  • İyi bir yöntem ve uçaklar da bunu yapıyor[1]. Bu tür sorunları kullanılabilirliği çok önemseyen insanlar zaten çözmüş durumda; bilgisayar sektörü ise başka alanlardan böyle şeyleri benimsemekte yavaş kalıyor
    Etiketi anahtarın dışına koyma yöntemi de iyi çalışıyor[2]
    [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
    [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
  • Kariyerimin ilk dönemlerinin önemli bir kısmını uzak donanımı kontrol eden ve durumunu gösteren GUI yazılımları yazarak geçirdim ve kısa süre içinde durumu kendi içinde tutan UI öğelerini tamamen dışlamaya başladım. Toggle, anahtar, checkbox, radio button gibi davranışını kendi durumuna göre değiştiren öğelerde arayüz ile donanım durumunun uyuşmaması nadir değildi
    Bunun yerine her seçenek için ayrı bir düğme koyup mevcut duruma karşılık gelen düğmenin yanmasını sağladım. Örneğin aç/kapat toggle’ını “on” ve “off” olmak üzere iki düğmeye çevirdim. Başta ikisi de griydi; donanımdan durumun açık olduğuna dair SOH gelirse on düğmesi yeşil, kapalıysa off düğmesi kırmızı oluyordu
    İletişim bir süre kesilirse durumun eskidiğini göstermek için tüm renkleri soluklaştırıyordum. Bir düğmeye basıldığında yeni durum geri gelene kadar önceki durumu göstermeye devam ediyor, yalnızca o düğme grubunu soluk gösteriyordum
    Kullanıcı, UI’ın hangi durumda olduğunu düşündüğünden bağımsız olarak istediği zaman doğrudan on veya off komutu verebiliyordu. Oysa toggle yalnızca “diğer duruma” geçirebilir
    Radio button’ları da durum adlarının yazılı olduğu düğme gruplarına çevirdim ve yalnızca UI’ın mevcut olduğunu düşündüğü öğeyi renklendirdim. Nötr durumların çoğu mavi, operatörün vurgulamak istediği iyi/dikkat/kötü anlamı varsa yeşil/sarı/kırmızı kullanıyordum
    Alışılmadık bir tasarımdı ama operatörler genelde ayrı bir eğitim almadan anladı. Düğmeler düğme gibi görünüyor ve tıklanabilir izlenimi veriyordu; aralıklar bunların bir grup olduğunu gösteriyordu; 90’ların UI’larında gri varsayılan olduğundan farklı renkteki düğme doğal olarak mevcut durum diye göze çarpıyordu
    Günümüzde UI öğelerinin estetik nedenlerle veya dönüşümü teşvik etmek için rastgele renklendirildiği, yalnızca ara sıra bilgi ilettiği ortamlarda bunun böyle olup olmayacağını bilmiyorum. NASA düğmesi gibi komut durumunu ve alınan durumu aynı anda göstermeyi de denedik ama hepsi daha kafa karıştırıcıydı
  • Hoşuma gitti. Yanlış anlamanın insanları öldürebileceği havacılık/askeri alanlara sektörümüzün neden daha sık bakmadığını bilmiyorum

• Ey checkbox, 1990~2009. Kusursuz ve belirsizliğe yer bırakmıyordu ama akıllı telefon tasarımcıları nedense ondan nefret etti

  • Daha komik olan, aslında checkbox olan bir şeyi gayet güzel ve toggle gibi görünecek şekilde tasarlayabilmeniz. İyi bir örnek değil ama mutlaka içinde tik işareti olan bir kare olmak zorunda olmadığını gösteriyor: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
  • Kullandığım tıbbi görüntülü görüşme/uzaktan muayene sistemi checkbox’ı bozmuş. Doğrudan mesaj arayüzünde, işaretli olup olmamasına göre checkbox alanının etiketini değiştiriyor
    İşaretli değilse “Not Urgent”, işaretliyse “Urgent” diye gösteriliyor. Acil olmadığını işaretlediğimi sanıp birkaç kez hızlıca tıkladıktan sonra gönder’e bastım
  • Checkbox’ın mükemmel olduğuna katılıyorum. Ama bunun bir nedeni de akıllı telefonda form doldurmaya çalışmıyor olmamız
    Tarayıcının varsayılan checkbox’ı akıllı telefonda başparmakla basmak için çok küçük; bu yüzden sık kullanmak zor
  • Checkbox widget’ını kim yaptı acaba? System 1’de (1984) menüdeki tik işaretine denk gelen bir “x kutusu” vardı ama bildiğim kadarıyla checkbox’ın kendisi değildi
  • Jony Ive tasarım dünyasının Thomas Midgley Jr’ı mı? iOS 7 ile kullanılabilirliği düşük flat design’ı yaygınlaştırdı; yuvarlak iMac faresi ve kolay bozulan MacBook klavyesinden de o sorumlu

• Gördüğüm en kötü örnek Tesla gösterge paneli ekranı UI’ı. Araba görselinin üzerinde düğme gibi görünmeyen bir etiket var ve üzerinde “Open” yazıyor
  Bu, açıkça o bölümün açık olduğu anlamına geliyor gibi okunuyor ama gerçek anlamı bu değil. O etiket, ilgili bölümü açan bir düğme ve kullanıcının bunu bilmesinin bir yolu yok

  • Evet. Bu hafta sonu kiraladığım Tesla’yı kullanırken ön ve arka bagajın ikisinin de açık olduğunu sanıp birkaç kez kafam karıştı ve panikledim
  • %100 katılıyorum. Tesla bagaj UX’inde ikinci en sinir bozucu nokta bu. Birincisi, parka aldıktan sonra bagajı açmak için beklemek zorunda bırakan aşırı uzun animasyon
    Genel olarak Tesla UX’i diğer arabalardan çok ileride, ama böyle küçük şeyler çok sinir bozucu
  • Hiç kafa karıştırıcı olmadığını düşünüyorum. Render edilmiş araba, bagajın mevcut durumunu açıkça gösteriyor; açma düğmesine basınca bagajın açıldığı animasyon da çıkıyor
    Herkes farklı hissediyor gibi
  • İlginç şekilde bu bir İngilizce sorunu. İngilizcede fiil ile sıfat çoğu zaman aynı oluyor. İspanyolcada “Abrir” (mastar fiil) ile “Abierto” (sıfat) farklı olduğu için böyle bir şey olmaz
    “Do open” ya da “Is open” gibi yazılsa önlenebilir gibi, ama ana dili İngilizce olanlara tuhaf mı gelir?
  • Bu yalnızca İngilizceye özgü bir özellik mi? Örneğin İspanyolcada fiil ile sıfat farklı kelimeler

• Geçiş düğmelerindeki temel sorun, tek bir nesnenin aynı anda hem sistemin durumunu hem de onu değiştiren eylemi taşımasıdır.
  Bu yüzden düğmede görünen “ON”un mevcut durum mu, yoksa basınca çalışacak eylem mi olduğu net değildir.
  Çözüm, durum ile eylemi bir ölçüde ayırmaktır. Bunun birkaç yolu var; bağlantıdaki yanıtlardan birinde olduğu gibi etiketi düğmenin dışına yazmak bunlardan biri.
  Bir anahtar değil de Teams örneğindeki gibi bir geçiş düğmesiyse, simgeyi aynı bırakıp düğmenin başka bir özelliğini değiştirebilirsiniz. Örneğin onlarca yıldır sorunsuz yapıldığı gibi basılı durumda bırakarak “ON” durumunu göstermek gibi.

  • Windows 11’in sistem ses özelliklerinde “Allow apps and Windows to use this device for audio” seçeneği ve yanında “Don't allow” düğmesi var. Bu yüzden mevcut durumun ne olduğu hiç anlaşılmıyor.

• Sonuca katılıyorum, ama hem mevcut durumun ne olduğu hem de geçiş değiştirildiğinde hangi duruma geçileceği açık olmalı. Çoğu zaman geçişi değiştirip ancak sonra değiştirmenize gerek olmadığını fark ediyorsunuz.
  Oynat/duraklat noktası ilginç, çünkü sonucun tersine benziyor. Ancak bu, iyi anlaşılmış fiziksel bir emsali izliyor ve genelde müzik ya da videonun oynatılıp oynatılmadığı da açıktır. Bu yüzden düğme simgesi değişmese bile kullanıcı basınca ne olacağını anlayabilir.
  Geçişlere ve UI’a dönersek, geçiş rengini açık griden biraz daha açık griye değiştirmek son derece yararsızdır. Lütfen etiket koyun. Etiket tasarım motifine uymuyorsa daha iyi bir tasarımcı bulmanız gerekir.

  • Fiziksel emsal söz konusuysa düğme görseli eylemi, yani oynatmayı göstermeli; basılı/basılı değil görsel durumu da bu eylemin etkin olup olmadığını belirtmeliydi.
    Yazılım tasarımcıları bunu izlemedi ve oynat/duraklat simgelerini birbirinin yerine değiştiren bir yöntem yaratarak yeni bir kafa karışıklığı doğurdu. Bu, kullanıcı dostu nedenlerden çok skeuomorfik 3D düğmelerin modasının geçmesinden kaynaklandı.
    Durum göstergesinin tek avantajı, bir sorun çıktığı zamandır. Özellikle seste bu çok yaygındır: sessize alma, kulaklığın çıkarılması, Linux ses sürücüsünün yine bozulması gibi durumlar.
    Bugün bile oynat/duraklat düğmesine bakınca hafif bir bilişsel uyumsuzluk yaşıyorum; duraklat düğmesinin tam olarak ne anlama geldiğinden %100 emin olamıyorum ve sorun olduğunda bazen sadece iki kez basıyorum.
  • Mevcut durumun açık olması gerektiğine katılıyorum. Bir ışık anahtarında hangi yönün “açık” olduğunu bilmenize gerek yoktur, zaten genelde bilmezsiniz. Çünkü ışığın yanıp yanmadığına bakarsınız.
  • “Etiket koyun; etiket tasarım motifine uymuyorsa daha iyi bir tasarımcı bulun” sözü özellikle mobilde yararsız ve gerçekçi değil.
    Örneğin Spotify’da her düğmenin arkasına etiket koyacak yer yok. Albüm kapağını gösterecek alana da ihtiyaç var ve ben de bunu istiyorum.
    Bu daha iyi tasarımcı meselesi değil; alan kısıtları gerçekten var. Bazı işlevler tek dokunuşla hemen yapılabilmeli. Karıştırmayı bir açılır menünün arkasına saklamak istemem.

• Geçiş düğmesi mevcut durumu göstermeli. Onay kutusu iyi bir örnek.
  Muted [] ve Muted [x] oldukça net.
  İşler, tasarımcı kelimelerle görsel tasarım arasındaki bağlantının net olmadığı bir UI yaptığında zorlaşıyor. Örneğin Mute Off [---( )], Mute On [( )---] gibi şeyler, durum açıklamasına eylemi karıştırdığı için ne anlama geldiği anlaşılmıyor.

  • Yeterli alan varsa iki tarafında da etiket olan geçiş taklidi iyi çalışır.
    Loudspeaker [()---] Crossed-out loudspeaker
  • Onay işareti bir tik işaretidir[1]. Durum sayfasında[2] tik “çalışıyor”, çarpı ise başarısızlık anlamına gelir. “Apaçıklık” açısından bakarsak Muted [x], bir şeyin başarısız olduğu anlamında okunabilir.
    Bunu farklı anlamak için bilgisayar UX’ini öğrenmiş olmak gerekir; bu da apaçıklığın tersidir. Ya da “X marks the spot” gibi, sessize almak istediğinizde tıklamanız gereken hedef anlamına da gelebilir.
    [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
    [2] ör. https://www.githubstatus.com/
  • Onay kutusu, mevcut durumu ve olası seçimi basit bir evet/hayır biçiminde birlikte gösterir.
    Geçiş düğmesi ise tasarımcının niyeti bilinmediği için kafa karıştırır. İki seçeneği birlikte göstermediği sürece anlamak zordur.
    Mute On[---()]Off
  • Düğme, tıklandığında ne yapacağını söylemelidir. Mevcut durumu göstermek istiyorsanız bu ayrı bir göstergedir, düğme değildir.
    Düğme tıklanmak için vardır; bu nedenle tıklanınca ne olacağını iletmelidir.
  • Sağdan sola yazılan yazı sistemlerinde iki tarafın da değişmesi gerekir mi?

• Analog anahtar gibi ikisini de göstermeli. Mevcut durumu açık ve yanlış anlaşılmayacak şekilde gösterirken, aynı anda geçilecek durumu da göstermeli.
  Apple’ın sağ-sol kaydırmalı geçişi bunu gerçekten iyi başardı. Geçişin şu anda nerede olduğu, nereye geçeceği ve mevcut ayarın özelliği etkinleştirip etkinleştirmediği mavi arka planla, devre dışı olup olmadığı ise gri arka planla açıkça görülüyor.

• Sevdiğim tasarımlardan biri, anahtarın yanında bir durum ışığı olması ve durum açılınca o ışığın yanmasıydı; ama şimdi bulamıyorum.
  En iyi yanı, asenkron işlemlerdeki gecikmeyi de çözmesiydi. Anahtara basınca anahtar değişiyor, kısa süre sonra ışık yanıyordu. Etkileşimin gerçekten bir şey yaptığına dair güven verdiği için çok tatmin ediciydi.

  • Gerçek tasarımı görmeden, bu da yazıda ele alınan belirsizliği gösteren bir örnek gibi görünüyor. Simgenin gelecekte olacak şeyi mi, yoksa şu anda olan şeyi mi ifade ettiği belirsiz.
    Sorun bunun durum mu eylem mi olduğudur. Belirli tasarım belirsiz olmayabilir, ama yalnızca açıklamaya bakınca öyle değil.
  • Uzun zaman sonra o sayfaya tekrar gidip ışığın yandığını görürseniz, bunun mevcut durumun ON olduğu anlamına mı, yoksa tıklarsanız ON’a geçeceği anlamına mı geldiğini nasıl anlarsınız? Sadece yanan ışığa bakıp bunu hemen ayırt etmenin bir yolu var mı?
  • “Akıllı” cihazlarda görülen bir arayüz özelliği gibi geliyor. Yalnızca TP-Link Kasa anahtarına aşinayım, ama o uygulamanın UI’ında da benzer şekilde renkli simgenin birkaç durumu vardı; en “açık”a yakın durum da anahtarla doğrulanıp açıldığı anlamına geliyordu sanırım.
  • HDR ekranlar için iyi bir kullanım örneği olabilir. “Gösterge ışığını” ekranın geri kalanından çok daha parlak yaparak ışığın artık yandığını çok net gösterebilirsiniz.
    Tabii bu, ancak kullanıcı en başta ekran parlaklığını fazla yüksek ayarlamamışsa işe yarar.