Düğmeysen yapman gereken tek bir iş var

• Fotoğraf döndürme gibi basit bir düğmede bile hızlı tekrar eden girdilerin nasıl işlendiği, kullanıcı deneyimini büyük ölçüde değiştirir
• iPhone, art arda verilen 90 derece döndürme girdilerini hatırlar ve animasyon biter bitmez bir sonraki döndürmeyi sürdürür
• Nothing Phone/Android, dokunuşu haptik ve sesle onaylar ama döndürme animasyonu sırasında gelen sonraki dokunuşları yok sayar
• Birden fazla belge fotoğrafını döndürmek gereken durumlarda, gündelik fotoğraf düzenleme arayüzü bile daha hızlı ve öngörülebilir bir etkileşim gerektirir
• Düğmeler, kullanıcıyı animasyonun bitmesini beklemeye zorlamak yerine dokunuş arabelleğe alma ya da animasyonu durdurma/hızlandırma yoluyla girdiyi kabul etmelidir

---

Fotoğraf döndürme düğmesinin tekrar eden girdileri ele alış biçimi

• Fotoğraf döndürme düğmesi, bir kez basıldığında genelde saat yönünün tersine 90 derece döndürür; yeniden basıldığında da aynı işlemi tekrarlayan standart bir kontroldür
• Döndürme animasyonu, fotoğraf yönünün değişme sürecini göstererek kullanıcının yön duygusunu kaybetmemesine yardımcı olur
• Hızlıca 8 kez 90 derece döndürmeye basılırsa, mühendislerin dediği “no op” gibi görüntü iki tur dönüp başlangıç yönüne geri dönmelidir
• iPhone'da bu beklenti gerçekten karşılanır
  • Hızlı dokunuş girdilerini hatırlar
  • Önceki döndürme bittiğinde bekleyen sonraki döndürmeyi çalıştırır
• Nothing Phone/Android'de ise farklı bir sonuç ortaya çıkar
  • Düğme, dokunuş onayını haptik ve sesle verir
  • Önceki döndürme animasyonu bitmediyse yeni dokunuşu yok sayar

Gündelik arayüzler de tekrar eden işlerde daha güçlü girdi işleme ister

• Durumsal engellilik, engelliliğin yalnızca bazı insanlara özgü olmadığını; herkesin belirli durumlarda etkili biçimde engel yaşayabileceğini anlatan bir kavramdır
• Fotoğraf çekmek çoğunlukla gündelik bir kullanım olsa da telefon kamerası, aşağı doğru tutularak çekildiğinde fotoğraf yönünü karıştırabilir
• Birden fazla yatay belge fotoğrafı çektikten sonra her birini döndürmek gerekiyorsa, kullanıcı fotoğrafları tek tek onlarca kez döndürmek zorunda kalabilir
• Böyle durumlarda düğmenin, istenen hızda üç kez basıldığında bile öngörülebilir çalışması daha keyifli ve daha az zahmetlidir
• Yeterince uzun bir zaman diliminde ya da yeterince büyük bir kullanıcı kitlesinde, gündelik arayüzler de daha ciddi ele alınmaları gereken anlarla karşılaşır
  • Bu tür “durumsal ileri kullanıcı” hali, telefon fotoğraf düzenleme veya GarageBand gibi örneklerde de görülür
• Çözümün mutlaka dokunuş arabelleğe alma olması gerekmez
  • Kesintiye uğratan bir dokunuş geldiğinde animasyon durdurulabilir ya da hızlandırılabilir
  • Esas mesele, kullanıcıyı animasyonun bitmesini beklemeye zorlamamaktır

[GN⁺]

Hacker News yorumları

• Kullanıcı yanlışlıkla çok fazla tıklarsa ya da ilk tıklamanın kaydedilmediğine inanırsa ne yapılmalı?
  Steve Jobs’un yeni macOS’ta PDF belgelerinin ne kadar hızlandığını gösterdiği keynote hâlâ aklımda. Mühendisler PDF’i ekranda kaydıran bir düğme hazırlamıştı; Jobs yanlışlıkla birden fazla kez bastı ve “İki kez sonuna kadar mı kaydıracak?” dediğinde gerçekten de eylem tamponlanmıştı. Sonunda tekrar yukarı çıkıp ikinci kaydırmanın bitmesini beklemek zorunda kaldı.
  Jobs bunu “Belgeyi ikinci kez gözden geçirme süresini dahil etsek bile önceki OS’in PDF’inden daha hızlı” diyerek toparladı.

  • Debouncing boşuna var değil. Bir düğmeye iki kez basıldığında iki kez çalışması gereken durumlar da var, çalışmaması gereken durumlar da. Hangi durumda hangisinin daha iyi olduğunu ayırt etmek basit değil.
    En azından hangi durumda hangi işlemenin uygun olduğunu düşünmek gerekir. UI içinde bazı düğmelerde bir taraf barizdir, bazı düğmelerde tersi barizdir; ama bazıları belirsizdir ve iki davranış da savunulabilir olduğunda sonuçta tutarsız bir UI ortaya çıkar.
    İyi bir çözümünü pek bilmiyorum.

  • Yazıya göre:

    The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating.

    Sorun bu. Uygulamanın düğme girişinin kaydedildiğini belirttiği sayı ile gerçekten yapılan eylem sayısı aynı olmalı. Debouncing iyi bir uygulamadır, ama kullanacaksanız debounce edilen dokunuşlara geri bildirim vermemelisiniz.

  • “Kullanıcı yanlışlıkla çok fazla tıklarsa ya da ilk tıklamanın kaydedilmediğine inanırsa?” kısmında erişilebilirlik konusunun açılması beni epey şaşırttı. Çünkü hemen, el titremesi olan birinin bir kez basmaya çalışırken iki kez basması durumu aklıma geldi.
    Ayrıca her düğmeye çift tıklayan insanlar da var. Bu tür durumları ele almak için onclick içinde gönder düğmesini devre dışı bırakmak çok yaygın.

  • Eskisi gibi bir Apple/Mac/Jobs fanboy’u değilim ama harika bir şey göstermek isteyen birinin sunduğu hissini veren Apple sunumlarını özlüyorum.
    Son Apple sunumları fazla katı ve insanlıktan uzak; takım elbiseli insanların yönettiği bir şey gibi hissettiriyor, sonuna kadar izleyemiyorum bile. Herkes, kutsal senaryodan saparsa kovulacakmış gibi duygularını ve insaniliğini saklayan robotlara benziyor.
    Konudan sapmış olabilirim ama Jobs’un biraz dağınık doğaçlama sunumlarının bile ne kadar keyifli olduğunu hatırlatıyor.

  • “Peki ya böyle bir durumda?” demek için bu durum kesinlikle o değil. İki nedeni var:

    1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]”
    2. Bu düğmeye arka arkaya 3 kez basmak için iyi bir neden var.

• Başka yerlerde geçen “debouncing ne olacak?” argümanını desteklemek istiyorum; yazarın bunu öylece görmezden gelmemesi gerekir.
  Ama you had one job meme’inden de hoşlanmıyorum ve düşünmeden kullanılmasına karşı çıkmak istiyorum. Çoğu zaman bu meme yanlıştır; düğmelerde de genelde böyledir. Sıradan bir kullanıcı arayüzünde belirli bir düğme aynı anda şu rollerden birkaçına sahip olur:

  • Düğmeye basılınca hangi eylemin gerçekleşeceğini iletmek
  • Bazen sistemin bir bölümünün mevcut durumunu iletmek; örneğin bir modu açıp kapatan düğmenin mevcut modu görsel olarak göstermesi
  • Tıklanınca amaçlanan eylemi yürütmek
  • Bazen komutun alındığını ve yürütülmekte olduğunu iletmek; örneğin orijinal örnekte olduğu gibi, karışıklığı önlemek için döndürme animasyonu sırasında düğmeyi devre dışı bırakmak
  • you had one job meme’inin arkasına neredeyse her zaman “çünkü işinin gerçek karmaşıklığını dikkate almayı reddettim” ifadesi eklenebilir.
  • İyi bir nokta; özellikle de insanların düğmenin ne olup olmadığına dair beklentilerinin farklı olduğunu vurgulaması güzel. Her bir madde etiketli bir düğmeyi, toggle’ı olan bir düğmeyi, gerçek bir düğmeyi ve ilerleme göstergesini anlatıyor. Kullanıcıya bağlı olarak bunların hepsi “düğme” olabilir.
  • “Debouncing ne olacak?” deniyorsa, düğme işlevini dokunmanın başlangıcında değil dokunmayı bırakma anında çalıştırmak yeterli olmaz mı?

• Bir düğme için “tek bir işi var” ifadesi pek uymuyor. Çünkü düğmelerin yalnızca tıklanabilir olmak dışında yapması gereken birden fazla iş var.
  Tıklanınca verilen geri bildirim, fare üzerine gelince verilen geri bildirim, yüklenme durumu, devre dışı durum ve bunların tüm kombinasyonları var. Bu da çok sinir bozucu gelebiliyor. Örneğin bir backend servisine bağlı bir düğmeye basıyorsunuz ama hiçbir görsel geri bildirim yoksa, o düğmeye basılıp basılmadığını bilemezsiniz. Yüklenme durumu da yoksa arka planda bir şey işlenip işlenmediğini anlayamaz, tekrar tekrar basmaya devam edersiniz.

• Yazar, hangi hızda olursa olsun üç kez tıklayınca her zaman aynı işlevin çalışmasını istiyor. Fotoğraflar arasında hızlıca geçerken her birini öngörülebilir biçimde döndürmek istiyor; bu da makul.

  And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you.

Yazar gerekçe olarak erişilebilirliği gösteriyor
Ancak bunun tam tersini savunan bir argüman da hayal edilebilir. Örneğin motor bozukluğu ya da Parkinson hastalığı olan biri, niyet zaten kesinleşmişken fazladan tıklamaların yok sayıldığı davranışı daha çok tercih edebilir
Böyle bir şeyi doğru yapmak zor

• iOS’ta Ignore Repeats adlı bir erişilebilirlik seçeneği var; sistem geneli bir ayar olduğu için daha iyi bir yaklaşım gibi görünüyor. Böyle bir düzeltmeye ihtiyaç duyan kişiler bunu ekran klavyesi gibi yerlerde de kullanabilir, ayrıca herkesin yazmayı yavaşlatmasına gerek kalmaz

• Her UI bileşeninin bu tür şeyleri de düşünmesi gerektiğini sanmıyorum
  Cihaz genelinde bir ayarla çözülebilir gibi. Örneğin birbirine 50px mesafede olan dokunmalar 100ms içinde tekrarlanırsa yok saymak gibi

• Tamamen katılıyorum. Parkinson’a kadar gitmesek bile, çok ileri yaşlı olmasa da yaş almış insanların telefon ve dokunmatik ekran kullandığını izleyince küçük bir düğmeye tam doğru noktadan basmanın ve “bastım” hissini almanın çoğu zaman zor olduğunu görebilirsiniz
  Bu yüzden erişilebilirlik açısından Nothing Phone’un davranışı çok daha uygun görünüyor. Bu kullanıcılar bir görseli belirli bir konuma getirmek için sayarak 6 kez tıklamaz. Üstelik mevcut konuma tam olarak geri dönmek için önceden 8 kez tıklamak da pek mantıklı değil
  Bu durumdaki düşünme biçimi daha çok “tıkla ve bekle, istenen konumda mı karşılaştır, sonra tekrar tıkla” şeklinde. Buna karşılık girdiyi tamponlayan hassas bir düğme fazla ileri gitme, sonra da fazla geri gelme gibi overshooting yaratabilir. Bir listede istediğiniz noktaya kaydırmaya çalışırken sürekli ıskalamaya benzer
  iPhone yaklaşımı, beklemeden hızlıca işlem yapmak isteyen gençler ya da teknoloji meraklıları için daha uygun. Bilgisayar klavyesinde de gecikme yüzünden ilk harf ekranda görünmeden önce birkaç harfi peşinen yazabilmeniz gibi

• Eskiden fiziksel düğmeli bir cihaz kullanmıştım; basınca bip sesi çıkaran ve süreye 30 saniye ekleyen bir düğmeydi. Ama bazen bip sesi çıkıyor, 30 saniye eklenmiyordu; bazen de ses çıkmadan 30 saniye ekleniyordu. Bu yüzden her seferinde karanlık göstergeye gözlerimi kısarak bakıp çalışıp çalışmadığını kontrol etmem gerekiyordu
  Bunun özellikle kötü bir tasarım olduğunu düşünmüştüm, ama o zamandan beri tamamen yazılım düğmelerinde de bu bozuk davranışın aynen yeniden üretildiğini sayısız kez gördüm. Ekranda düğmenin renginin değişmesi ile istenen eylemin gerçekten gerçekleşmesi yalnızca gevşek biçimde bağlantılı. Bu neden böyle? Nasıl bir uygulama yapmış olabilirler ki?

  • Buna iki iş yapma problemi deniyor
    Emir kipinde kod yazıp iki komut verirsiniz; ikisi de bağımsız olarak başarısız olabilir
    Bunu “hallettik” gibi göstermenin birçok yolu var
    Öncelikle testlerin hepsi geçeceği için çoğu geliştirici hemen düşünmeyi bırakabilir
    İstisnayı yakalayıp sadece loglamak yeter sanabilirsiniz, ama bu sorunu düzeltmez
    Üretim ortamında bir süre çalıştırıp sorun çıkıp çıkmadığını görebilirsiniz. Sonunda sorun çıkarsa geliştirici tekrar deneyecektir; ikinci seferde muhtemelen çalışacağı için yine düşünmeyi bırakabilir
    Birkaç gün önce outbox pattern hakkında da büyük bir tartışma vardı. İlk işi iki yarıya bölüp atomik olarak ele almak, ikinci işi ise okuyucuya bırakmak gibi
    Gerçekte bu sorunun sürekli ortaya çıkmasının nedeni bence geliştiricilerin “öyle bir şey olmaz”, “ben düzelttim”, “düzeltilemez” durumlarının kuantum süperpozisyonunda bulunması
  • Bu, çoğu UI framework’ünün paylaştığı iki tasarım özelliği yüzünden gerçekten yaygın:
    Düğmenin rengini değiştiren kod “button” bileşeninin iç davranışıdır, bu yüzden her düğme için ayrı ayrı uygulanması gerekmez. Ama bu, gerçek eylemi gerçekleştiren koddan bir ölçüde ayrıldığı anlamına gelir. on click işleyicisinde metindeki gibi “döndürme animasyonu sürüyorsa görseli döndürme” türünden son bir kontrol varsa, düğmeye renk değişimini iptal etmesini söylemenin çoğu zaman bir yolu yoktur. Tersine, renk değişimi animasyonu düzgün oynatılmasa bile on click işleyicisi çalışabilir
    Düğmeler genellikle fare düğmesine basıldığında renk değiştirir, ama eylem fare düğmesi bırakıldığında gerçekleştirilir. Bu yaklaşım, basılı tutup düğmenin dışına sürükleyerek son anda iptal etme fırsatını özellikle verir; mobilde de etkileşim bazen tıklama değil kaydırma olarak yeniden yorumlanır. Başka zamanlarda ise renk zaten değiştikten sonra eylemin engellenmesi için daha fazla fırsat yaratır
  • Asansörlerde bunu oldukça düzenli görüyorum. Düğmeye çok kısa basarsanız basılı tuttuğunuz sırada ışık yanar ama aslında düğme girdisi kaydedilmez
  • Düğmenin renk değiştirmesi, basmanın başarılı olduğunu gösterir. Bunu anında yapmazsanız çoğu insan yeniden denemeye koşullanmıştır. Özellikle motor kontrolü zayıf kişiler için önemlidir
    Bu, mevcut yazılım durumunda o basışın yararlı bir girdi olup olmamasından tamamen bağımsızdır. İyi yazılmış bir yazılım, girdi alamayacağını bilip düğmeyi devre dışı bırakmış olmalıydı; makul yapılmış bir yazılım bile eylemin işlendiğine ya da iptal edildiğine dair neredeyse anlık geri bildirim sağlamalı
  • Muhtemelen test eksikliği ve eylem başarısızlığının dikkate değmeyecek kadar nadir olduğu varsayımı yüzündendir. Ama bu tür kalıplar arayüze güvenmeyi ve onu verimli kullanmayı zorlaştırır

• İnsanlar animasyonun tamamen yardımcı bir rolü olduğunu, animasyonun kendisinin amaç olmadığını sık sık unutuyor
  Animasyonlar yükleme süresini gizlemek ve bir durumdan diğerine yumuşak geçiş sağlamak için vardır. Bu yüzden kullanılırlar
  Bu bilgi sonunda kayboldu ve artık animasyon bitene kadar beklemek zorunda olan kodlar ortaya çıktı
  Bu, şaşırtıcı bir cargo cult örneği daha

  • “Yükleme süresini gizlemek ve bir durumdan diğerine yumuşak geçiş sağlamak” açıklamasını biraz genişletmek isterim. İyi kullanıldığında, kullanıcının belirli bir eylemi nedeniyle durum değişiminin doğrudan gerçekleştiğini gösterir ve bunu geri almanın ya da düzeltmenin yolunu da ima eder
    Aslında “gizlemek” ifadesine katılmıyorum. Bir şeyin neden belirdiğine dair ipucu olmadan aniden görünmesi dokunmatik ekranlarda açık bir anti-pattern’dir
  • Animasyonlar yalnızca bu amaç için yoktur. Bir uygulamayı kullanırken oluşan hisse de yaratıcı biçimde katkı sağlarlar
  • Apple eskiden bunu biliyordu. Bir öğe kaybolduktan sonra animasyon eklerdi, ama bir öğeyi göstermeden önce animasyondan kaçınırdı
    Eski Apple, tasarımın güzel görünmesini sağlamaktan fazlası olduğunu anlardı. Günümüzün cam hissiyatlı Apple’ında her şey demoda nasıl göründüğüyle ilgili
  • Animasyon neredeyse her zaman gereksiz geliyor. Uygulama ya da sistem izin verdiği her durumda kapatıyorum
  • Android’de tüm animasyonları kapattım ve çok daha iyi hissettiriyor. Özellikle fazla kaydırmaya çalışınca tüm ekranın esnediği o overscroll animasyonundan gerçekten nefret ediyorum

• İlk karşılaştırmaya baktığımda, dürüst olmak gerekirse sorunun iPhone örneğinde olduğunu düşündüm. Döndürme düğmesine her basıldığında görüntünün altındaki düğme ve kaydırıcı kaybolup sonra yeniden fade-in yapıyor; bu, iOS’ta birçok uygulamada gördüğüm ve durmadan rahatsız eden bir davranış. Özellikle Screenshot uygulaması kişisel olarak büyük bir şikâyet konum
  Bir etkileşimin hem öncesinde hem sonrasında kullanılabilen bir UX öğesiyse, dönüşüm ya da işleme sırasında da sürekli görünür kalmalı. iPhone’da döndürme sırasında bu düğmeleri gizlemenin ne gibi bir UX kazancı var? Daha iyi de görünmüyor. Elbette son dönemde Apple yazılımları, gerçek UX iyileştirmelerini görünüş sunağında kurban eder oldu
  Yine de bu tür dokunuşların animasyondan bağımsız işlenmesi gerektiği yönündeki yazarın iddiasına katılıyorum

  • Yazılım uygulamalarında da bilgisayar çiplerindeki gibi tape-out kuralları olsa iyi olurdu. Çip tasarlarken bir program tasarımı inceler ve “X metali ile Y metalinin kablolaması Z mesafesinden daha yakın olmamalı” gibi 300 sayfalık kurallarla karşılaştırır
    UX için de benzeri yapılabilir. Bilinen UX kusurları varken yayınlamaya kalkarsanız uyarı veren bir tasarım deseni kısıtları kümesi gibi

• Bir zamanlar bebeklerin kullanabilmesi için yaptığım BabyButton’ı uyguladığım anı hatırladım. Normal tıklama davranışı yerine touchdown olayını kullanmıştım; böylece çocuk bir şey olduğunu hemen görebiliyor, düğmeye çok uzun basması ya da basılı tutarken parmağını hareket ettirmesi sorun olmuyordu
  O yaş grubu için bir sistem yapmanın gerekip gerekmediği bambaşka bir konu, ama kullanıcı ihtiyacına uygun bir şey tasarlamak iyi bir meydan okumaydı diye düşünüyorum

  • GUI düğmelerinin yalnızca fare düğmesi bırakıldığında çalışmasına ve basılı tutarken düğme alanından çıkıp tekrar girmek gibi belirli davranışlara ne kadar alıştığımız ilginç
    Gerçek dünyadaki düğmelerin %99’dan fazlası basılır basılmaz işini yapar. Ama GUI’de böyle çalışan bir düğme tuhaf hissettirecektir

• Yazarın anlatmak istediği asıl noktaya daha yakın olan gerçek yazı şu: https://aresluna.org/show-your-hands-honor/

• Bir arama sırasında iPhone’un ekranı açma/kapatma düğmesine bastığınızda bazen aramayı sonlandırıp bazen de sadece ekranı kapattığı oluyor mu?
  Hâlâ kalıbını bilmiyorum ama iPhone’u cebime koymadan önce o düğmeye basıp bazen yanlışlıkla aramayı kapattığım oldu

  • Hoparlör/hands-free modundayken sadece ekran kapanıyor. Kulağınıza dayadığınızda ekran zaten otomatik kapandığı için kilit düğmesine basmayacağınızı varsayıyor gibi. Sorun şu ki bazen bir hata yüzünden ekran açık kalıyor ya da sessiz bir odada hands-free gibi kullandığınız durumlar da oluyor

[GN⁺]

Lobste.rs yorumları

• Hafif bir iğneleme ama iyi UI/UX’ten söz edeceksek kontrolü de göstergesi de olmayan gömülü video en kötüsü.
  Otomatik oynatmayı varsayılan olarak kapatan çok kişi var; ben de neredeyse aynı iki görsele bakıp uzun süre “Peki fark ne?” diye kaldım.

  • “Video mu vardı?” diye düşündüm; sanırım ben de kaçırmışım.
  • Neden “en kötüsü” olduğunu anlamadım. Biraz aşağı kaydırıp sorunun açıklamasını okumadan sürekli “Eee?” diye mi düşündün?
  • Bu konu özelinde GitHub’ın animasyonlu GIF’lerde oynatma kontrolleri göstermesini takdir etmek gerekir. Başka yerlerde neredeyse hiç görmüyorum.
  • Tarayıcı farkı da olabilir. Android’de Vivaldi’de büyük bir oynat düğmesi ve ilerleme çubuğu görünüyordu.

• “Animasyon bitene kadar kullanıcıyı asla bekletme” fikrine tamamen katılıyorum.
  Bir uygulamada kullanıcı komutu, güzel görünmekten her zaman önce gelmeli.

• Bence bu ilke oyunlar için de geçerli. Bazı oyunlarda menüyü açtıktan sonra girdinin kaydedilmesine kadar çok kısa bir gecikme oluyor.
  Gösterişli menü animasyonları olan bir oyunda duraklatma ve aşağı ok tuşuna hızlıca basınca, menü açıldığında ikinci öğenin seçili olması gerekir mi gibi bir mesele.
  Oyunlarda girdi tamponlama hassas bir konu ama menü kullanımında genelde kötü hissettirdiği durumlar nadirdir.

• Video, bilgiyi aktarma biçimi olarak pek iyi değildi. Düğmeye art arda birkaç kez basıldığı anı fark etmek için dikkatle bakmak gerekiyordu.
  Asıl konuya gelirsek, Android telefonun gerçekten yanlış yapıp yapmadığı da belirsiz. İstediğin sonucu almak için hızlıca 8 kez basma isteğinin yarattığı hayal kırıklığını anlıyorum ama masaüstü işletim sistemlerindeki yanlışlıkla çift tıklama algılama aklıma geliyor.
  Sonuçta bu daha çok üreticinin düşündüğü kullanılabilirlik ile kullanıcının hissettiği kolaylık arasındaki farka benziyor. İlla karşılaştıracaksak, iPhone’un animasyon sırasında da “Done” düğmesini göstermesi bana daha dikkat dağıtıcı geliyor.

• Android’in tamamen hatalı olduğunu söylemek zor. Yavaş tepki veren bir UI yüzünden bir işlemi yanlışlıkla iki kez çalıştırdığım oldu.
  En iyisi, animasyon bitene kadar düğmeyi devre dışı bırakmak olabilir.

  • O zaman yazıda gösterilen sorun aynen ortaya çıkar. Ekrana bakmadan saat yönünün tersine 90 derece döndürme yapmak neredeyse imkânsız hale gelir.
    “Üç kez tıkla” işe yaramaz; animasyon sırasında yapılan ek tıklamalar yok sayılır. Tıklayıp ekrana bakarak animasyonun bitmesini beklemek, sonra tekrar tıklayıp yine beklemek yavaş ve kullanıcının dikkatini fazlasıyla isteyen bir süreçtir.
    Daha iyi çözüm, UI’ın anında geri bildirim vermesi gibi görünüyor. Tıklamanın işlendiğini gösteren düğme durumunu hemen render edebilir ya da yavaş tam animasyon başlamadan önce geçici olarak ekranı hızlıca yeniden çizip mevcut ilerlemeyi gösterebilir.

• Yazının tamamına güçlü biçimde katılıyorum. Bunu, animasyonun Hipokrat Yeminini bozması olarak ifade etmek isterim.
  Animasyonun birinci ilkesi “Önce zarar verme”, yani “Önce kullanıcı girdisini engelleme” olmalı.

• Yetişemeyen bir rotary encoder ile hiç karşılaştınız mı? Kulaklık amfimin ses düğmesini çok hızlı çevirirsem hiçbir şey olmuyor.
  Bir günlüğüne başkan olsam…

• Böyle şeyleri her gördüğümde kendi GUI toolkit’imde nasıl olurdu diye düşünüyorum. Benim toolkit’im, Windows platformundan ödünç alınmış davranış gibi hızlı iki tıklamayı çift tıklama olarak ele alıyor; bu da bazen insanı çıldırtıyor.
  Çift tıklamanın kendisi yaygın bir teamül ve tek tıklamadan ayrı bir değeri var. İdeal olarak tıklama olaylarını idempotent yapıp iki kez gerçekleşseler de sorun çıkarmamalarını sağlamak gerekir. Örneğin tıklama öğeyi seçiyor, çift tıklama varsayılan eylemi çalıştırıyorsa aynı öğeyi iki kez seçmek zararlı değildir. Ama gerçek hayat her zaman böyle değil.
  Sorun şu: Bir düğmeye çok hızlı tıklarsanız düğme yalnızca bir kez çalışabilir, sonraki olay çift tıklama olayına gidip hiçbir şey yapmayabilir. Bu yüzden hızlı basınca tıklamaların yarısının yok sayıldığı bir davranış ortaya çıkar.
  Bu sorun yüzünden triggersOnMultiClick adlı bir boolean oluşturdum; true olarak ayarlanırsa çift tıklama gibi hızlı çoklu tıklamalarda da trigger olayı gönderiyor. Ancak geriye dönük uyumluluk nedeniyle varsayılanı false bıraktım; artık yeni bir major sürüm çıkarma zamanı geldiğine göre yazıdaki argümanı haklı bulup varsayılanı şimdi true yapmayı düşünüyorum.
  “2 Temmuz 2021’de eklendi, varsayılan false. 5 Temmuz 2026’da (v13.0) varsayılan true yapılarak düğmelerin tüm tıklamalarının varsayılan olarak tetiklenmesi sağlandı. Eski davranışı istiyorsanız çift tıklama olayını override edin ya da üst sınıf constructor çağrısından sonra triggersOnMultiClick = false ayarlayın” gibi bir not bırakılabilir.
  Animasyon uygulama tarafında da benzer bir davranış tesadüfen ortaya çıkabilir. Nesnenin içinde animasyon konumu değişkeni tutup tıklamada değer atıyorsanız, iki kez tıklandığında seçenekler kabaca iki tanedir: kalan animasyonu atlayıp doğrudan sonraki iç duruma geçmek ya da görsel akıcılığı korumak için if(animationCounter) return; gibi olayları yok saymak. Yazıdaki Android geliştiricisi ikincisini seçmiş gibi görünüyor.
  Apple tarafı muhtemelen üçüncü bir yöntem, yani bekleyen animasyon kuyruğu tutup olayları oraya koyma yöntemini kullanıyor. Merak ettiğim, iç durumun kuyruğa ekleme anında mı, tamamlanma anında mı değiştiği, yoksa gerçekten görüntüyü animasyonla döndürüp döndürmedikleri. Ortada animasyonu kesip kaydederseniz 45 derece döndürülmüş bir görüntü çıkabilir mi? Ben olsam EXIF’i atomik olarak 90 derece günceller, geçiş animasyonunu ayrı çalıştırırdım.
  Uygulama basitliği, görsel sadakat ve UI davranışı arasında makul birden fazla seçenek olabilir. Kişisel olarak ikinci basışın animasyonu beklemeden yeni duruma anında sıçraması da hoşuma gider. Animasyon kuyruğu oluşturmaya kadar gitmezdim.
  Kodu benzer bir tarihte değiştirmek komik. Önceki düzeltme de 2 Temmuz’daydı, bu seferki tesadüfen 5 Temmuz. Böyle geçmiş bilgilerini doğrudan dokümantasyon yorumuna yazmayı seviyorum. Daha sonra değiştirirken anı niyetine okumak da güzel oluyor.
  Apple muhtemelen varsayılan bir animasyon kuyruğu sağlıyordur ama durumun ne zaman değiştiği yine ayrı bir mesele. Web’de durumu atomik olarak güncelleyip CSS transform transition’ı gibi yalnızca görsel amaçlı animasyonu ayrı tutardım. Layout yeniden hesaplamasını da önleyebildiği için uygulaması kolay ve verimli olur gibi. Sınıf adını animasyondan daha hızlı değiştirirsen sıçrar mı yoksa kuyruğa mı alınır, bunu sonra denemek isterim.

• Yaşlandığım için mi bilmem, yanlışlıkla iki kez dokunduğumda bu tür davranışların canımı sıktığı birkaç kez oldu.
  Aynı konumdaki düğmeleri ya da çift dokunmayı onay aracı olarak kullanmak korkunç. Gerçekten onay gerekiyorsa, yanlışlıkla onaylamayı kolaylaştırmamak gerekir.
  Yine de bu örnekte hızlı ardışık girdiyi kabul etmek iyi bir fikir gibi görünüyor. Başka durumlarda öyle olmayabilir. Fiziksel düğmelerden bazıları, bir şey “bitene” kadar iki kez basmayı özellikle engeller; her zaman bilinçli bir tasarım olmasa da bazen doğru seçimdir.
  Takılan ya da bozuk cihaz kullanmak zorunda olan çok kişi var; ellerde veya parmaklarda titreme gibi sağlık sorunları varsa girdiyi sınırlamanın faydaları olabilir.
  Bu örnek, iki tarafın da makul görülebileceği bir vaka gibi. Beklemek zorunda kalmanın daha sinir bozucu olduğu örnekler de var; animasyon ya da başka koşullar nedeniyle girdi sınırlaması olmasını isteyeceğiniz örnekler de kesinlikle var.

• Mobil tarayıcı arama sonuçlarının parmağımın altında güncellenip basmak üzere olduğum seçeneği başka bir yere itmesi bitmek bilmeyen bir sinir bozuculuk.
  Kendimi daha fazla beklemeye alıştırdım ama UI etkileşiminin, alım durumuna göre tamamlanma süresi değişen arka plan asenkron işlerine duyarlı olması hiç mantıklı değil.