UI’ı Zımparalamak

 (blog.jim-nielsen.com)
2 puan yazan GN⁺ 2024-09-22 | 1 yorum | WhatsApp'ta paylaş
  • UI’ın olgunluğu, uygulama tamamlanır tamamlanmaz değil, gerçekten durmadan tıklayıp deneme şeklindeki yinelemeli süreçte artar; yazı bunu marangozluktaki zımparalamaya benzetiyor
  • Sayfa geçişleri ve gezinme; tıklama, tarayıcı geri düğmesi, sağ tık “Back”, uygulama içi geri gitme ve klavye kısayolları gibi birden fazla giriş yolu üzerinden kontrol edilmeli
  • label ile input type="radio" flexbox ile hizalanıp gap eklendiğinde, radyo düğmesi ile etiket arasında tıklanamayan bir ölü bölge ortaya çıkıyor
  • Çözüm, gapi kaldırıp labela padding vermekti; böylece görsel boşluk korunurken tıklanabilir alan genişledi
  • Küçük etkileşim kusurları da birikince kullanıcı deneyimini bozar; bu yüzden UI, “kıymıklar” artık hissedilmeyene kadar tekrar tekrar kullanılarak inceltilmeli

Tekrarlı tıklamalarla UI’daki pürüzleri bulmak

  • UI işi, bir şey yaptıktan sonra bol bol tıklamak, düzeltmek ve sonra yeniden tıklamak şeklindeki bir döngüye daha yakındır
  • Sayfa geçişlerinde yalnızca tek bir akışı kontrol etmek yetmez; farklı yollarla geri dönerek gözden geçirmek gerekir
    • Tıkladıktan sonra tarayıcının geri düğmesini kullanmak
    • Tıkladıktan sonra sağ tık bağlam menüsündeki “Back” seçeneğini kullanmak
    • Uygulama içindeki geri navigasyonunu kullanmak
    • Klavye kısayoluyla geri gitmek
  • Bu süreç QA gibi “tıklayarak bozmayı denemek”e benzer, ama daha çok marangozlukta zımpara yaparken pürüzleri ve kıymıkları bulma hissine yakındır
  • Yazılım UI’ında fazlasıyla çok durum ve değişken bulunabileceğinden, tekrar tekrar kullanıp artık hiçbir “kıymık” hissedilmeyene kadar düzeltirsiniz

flexbox gapin oluşturduğu tıklama ölü bölgesi

  • Radyo seçenekleri listesinde, <label> ile ilişkili <input type="radio"> aynı satıra yerleştirildi
  • CSS, kapsayıcıda display: flex, flex-direction: row, align-items: center, gap: .5rem kullanan basit bir yapıydı
  • Tekrarlı tıklamalar sırasında, radyo düğmesi ile etiket arasındaki boşluğa basıldığında denetimin toggle olmadığı bir ölü nokta fark edildi
  • Sebep flexbox gap idi
    • gap, görsel boşluk oluşturmayı kolaylaştırır
    • Ancak etiketin veya giriş öğesinin tıklama alanına dahil olmadığı için etkileşimde boş bir alan yaratır
  • Çözüm, gapi kaldırıp labela padding vermekti
    • Boşluk korunur
    • Etiketin tıklanabilir alanı genişler ve ölü bölge kaybolur
  • Tek bir küçük kusur önemsiz görünebilir, ancak bu tür “küçük kıymıklar” çoğaldığında UI deneyimi acı verici hale gelebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-22
Hacker News yorumları

  • Geliştirdiği ürünün aynı zamanda bizzat yoğun bir kullanıcısı olan bir geliştirici, bu tür küçük sorunları bulmakta çok avantajlıdır.
    Çünkü kullanıcı takılmadan önce geliştirici küçük rahatsızlığı kendisi fark eder ve onu hemen düzeltebilecek konumdadır.
    Bu yüzden güçlü sahiplenme duygusu olan küçük ekipler etkili görünüyor. Ürüne sahiplik hissi varsa, kullanıcının yaşadığı küçük rahatsızlıklar da kendi meselesi gibi gelir ve UX’i olabildiğince pürüzsüz hâle getirmek bir gurur meselesi olur.

    • Bu, şirketlerin mümkün olduğunda ürünü dogfooding yapmasının ve dahili beta yürütmesinin de nedenidir.
      Kurumsal ürünler gibi içeride kullanmanın zor olduğu durumlar dışında, doğrudan sahiplenme zayıf olsa da ürünün başarısında bir çıkar oluşur.

  • En iyi cilalanmış UI’ın ne olduğunu merak ediyorum.
    FAANG seviyesinde para da çok olduğundan UI/UX’in epey iyi olacağını düşünebilirsiniz, ama Amazon.com ya da AWS, GCP, Azure kullanmış olanlar farklı hissedecektir.
    Bana göre mcmaster.com en iyi cilalanmış UI/UX’e sahip. İhtiyacınız olanı birkaç dakika içinde bulabiliyorsunuz.
    Buna karşılık Home Depot veya Lowe’s gibi büyük mağaza sitelerinde vida ya da kereste gibi şeyleri tam ölçüsünde bulmak 10–15 dakika sürüyor; mobilde daha da kötü.

    • RockAuto en sevdiğim web sitesi.
      İnanması zor derecede basit ve pratik olmasına rağmen oldukça güçlü. Parçaları adım adım daraltarak bulabilir ya da arayabilirsiniz; fiyat karşılaştırması otomatik yapılır ve fiyat/kalite kategorileri de kullanışlı biçimde gruplanmıştır.
      Bir parça numarası bulduğunuzda yıl/üretici/model uyumluluğunu, kısa açıklamayı, fotoğrafları ve sepetteki diğer parçalarla aynı depodan gönderilip gönderilmediğini de görebilirsiniz. Tüm bunlar tek sayfada, sürtünmesiz biçimde ve her platformda çok hızlı çalışır.
    • FastMail, kullandığım web uygulamaları arasında hissiyatı en iyi olanlardan biri.
      Tepkileri çok hızlı ve kullanırken hiç hata görmedim. Bir web uygulamasının nereye kadar mümkün olabileceğine dair çıtayı yükseltti.
    • Linear’ın UI’ı çok iyi cilalanmış.
      Hatta sadece kullanılabilirlik sorunlarını düzeltmeye ayrılmış özel bir dönemleri de vardı.
      https://linear.app/changelog/2022-12-01-polishing-season-202...
      https://web.archive.org/web/20231003205004/https://linear.ap...
    • Facebook’ta aylardır bozuk olan birkaç özellik sayabilirim.
      Özellikle geçici profil fotoğrafı en sinir bozucusu. Neredeyse bir yıldır düzgün çalışmıyor ve eski fotoğrafa geri dönmüyor.
      Orada kimse cilalama yapmıyor gibi.
    • Küçük detaylarda zanaatkârlığın ortaya çıktığını herkesin görebildiği bir dönem.
      https://littlebigdetails.com tam da böyle bir yer.

  • Bu belirli sorun için temel çözüm, girdi öğesini etiketin içine koymaktır.

    • Bootstrap, radyo düğmeleri/onay kutuları için 4.0’daki yapıyı 5.0’da farklı bir yapıya değiştirdi [1].
      Nedenini merak etmiştim; muhtemelen etiketin veya girdi öğesinin konumunu/padding’ini ayarlarken tema uygulamayı daha basit hâle getirdiği içindir.
      [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
    • İç içe yerleştirseniz bile, genel sesli komut yazılımı erişilebilirliği için for/id öznitelikleri hâlâ gereklidir: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
    • Benim de aklıma ilk gelen buydu.
      Radyo düğmesi ya da onay kutusu, yalnızca kutuya ve padding’e değil, tüm metin etiketine basıldığında da değişmelidir.
    • Eskiden nedense bu yöntemin tabu olduğunu düşünürdüm; muhtemelen XHTML’de etiket ile girdinin bire bir bağlantısını zorunlu kılmasından kaynaklanıyordu.
      Flexbox biraz fazla gibi görünüyor. İç içe olmayan söz dizimiyle de satır içi yerleşir ve bence aynı şekilde sadece padding eklemek yeterli olur.
    • React gibi framework’lerde bu yöntem, sitede Google Translate gibi şeyler kullanıldığında yayılan hatalara yol açabilir.
      Bunu hafifletmek için Fooyu ayrı bir öğeyle sarmalamak gerekir.

  • Agile’da bu tür şeyler fazlasıyla ortadan kayboldu
    Mühendisin ürünü cilalamak için zamanı olmalı, ama gerçekte yok. QA aralık sorunları için ticket açmazsa asla düzeltilmiyor
    Müşteri muhtemelen bunları fark eder, ama bunu bildirmesi mucize, bunun sonunda bir ticket’a dönüşmesi mucize, birinin öncelik verip düzeltmesi de ayrı bir mucize
    Aslında çoğu şirketin issue board’u müşteri açısından o kadar opak ki, küçük bir sorun ya da bug bulduğunuzda bunun bug olduğunu kanıtlayıp takip sistemine ticket girmek için 50 saat gidip gelmek gerekiyor; insanı çileden çıkarıyor

    • Bunun Agile ile ne ilgisi var bilmiyorum
      Waterfall modelinin UI’ı test edip cilalamak için açıkça zaman verdiğini mi düşünüyorsunuz?
      Bu genelde ürün yöneticisinin önceliklendirmesi ve yetkin bir UX mühendisi ya da tasarımcıyla birlikte ele alması gereken bir süreç. İsterseniz bu önceliği herhangi bir geliştirme metodolojisine koyabilirsiniz; dolayısıyla burada Agile alakasız
    • Discord’da forum gibi çalışan bir gönderi özelliği var; orada yazı yazarken HOME/END tuşları berbat çalışıyor, Shift ile metin seçilemiyor, Ctrl basılıyken kelime kelime hareket de çalışmıyor
      Son 3 yılda bunu defalarca bildirdim. Çünkü yazarken metin düzenlemek aşırı zor ve sinir bozucu
      Bir web geliştiricisi olarak en başta bunun nasıl bozulduğunu merak ediyorum. Varsayılan olarak çalışan bir şeyi bozmak için nasıl bir beceriksizlik seviyesi gerekir bilmiyorum. 30 dakikadan fazla sürmeyecek bir düzeltme olmalı ve herkesin kullanıcı deneyimini 1000 kat iyileştirirdi; ama bildireli 3 yıl geçti, hâlâ aynı
      Teams’te de telefon numarası alanında HOME/END tuşlarının kullanılamadığı bir bug’ı Microsoft Premiere Support üzerinden bildirdim; yanıt “tasarlandığı gibi çalışıyor” oldu
      Müşterilerin artık bu tür bug’ları bildirmemesine şaşmamak gerek. Çünkü çalışanlar/geliştiriciler de şirket de zaten umursamıyor
    • Gerçekten doğru söz
      Ürünün lead geliştiricisiyim ve sağda solda çok sayıda küçük sorun var. Bir şeyden sorumlu olup onu düzeltme yetkisine sahip olmamak iyi hissettirecek bir durum değil
      İş açısından bakınca, gelir ya da markaya zarar vermiyorsa neden zaman ve para harcayıp düzeltsinler ki mantığı ortaya çıkıyor. Uzun vadede markayı etkiler, ama çoğu kişi 5 yıl içinde rolünü ya da şirketini değiştirdiği için umursamıyor
    • Çok bug bildiren biriyim; birçok müşteri destek görevlisi işini mühendisleri bug raporlarından korumak ve sorumluluğu başka yere atmak olarak görüyor gibi
      Yanıt alabiliyorsanız bu bile nispeten iyi durum
    • “Agile” fikri, çalışmayan şeyleri fark edip iyileştirmektir
      Müşterinin ihtiyaçlarını karşılamayan bir süreç olduğu açık; ekiple birlikte düzeltirsiniz
      Scrum ritüelleriniz varsa bunu retrospektifte gündeme getirebilirsiniz, ama aslında her zaman mümkün. Retrospektif sadece son birkaç haftaya bilerek dönüp bakılan bir oturumdur; yolda fark edilen şeyleri yoldayken çözmeye çalışmak gerekir

  • Küçük UX sorunlarını görüp düzeltebilecek sezgiye sahip kişiler gerçekten önemli
    UX tasarımında bunlar kullanıcıda oluşan kağıt kesiğine benzetilir. Ölümcül değildir ama kullanıcı memnuniyetini aşındırır
    Yazara ek olarak: o radio button, seçili durumda onay işareti değil nokta kullanma teamülünü izlemiyor. Kullanıcı ilk bakışta birden fazla seçeneğin seçilebileceğini ya da hiç seçim yapmanın gerekmediğini sanabilir

    • GitHub ve Jira’da yaşadığım şey, iletişim kutusunda metni sürükleyerek seçerken fareyi dışarıda bıraktığımda popup’ın kapanmasıydı
      Dışarıya tıklayınca kapansın diye eklenen özelliğin yan etkisi olma ihtimali yüksek
    • Katılıyorum
      Olumsuz tarafta “Papercuts” varsa, olumlu tarafta yakın zamanda HN’de de ele alınan Juice var
      1. https://garden.bradwoods.io/notes/design/juice

  • Bu yazı UI programlamadan neden nefret ettiğimi iyi gösteriyor
    Öngörülemeyen ve küçük küçük sapabilecek şeyler sabrımı aşıyor. Bir şeyin nasıl başarısız olabileceğini düşünüp test yazmaktan bir ölçüde keyif alıyorum, ama rastgele tıklayıp kırılıyor mu diye bakmak dikkat dağıtıcı ve sinir bozucu
    UI uygulamak doğası gereği bu kadar karmaşık mı, yoksa hâlâ doğru programlama modelini mi bulamadık merak ediyorum. Bazen bir şeyin baştan itibaren amaçlandığı gibi görünmesini ve çalışmasını istemek unreasonable mı diye düşünüyorum

    • Bu yüzden tasarım sistemleri var
      UI’ı cilalamak yalnızca bileşeni ilk oluştururken yapılmalı. Bazen bileşenleri farklı şekilde birleştirmeniz ya da tek seferlik bir uygulama gerekebilir
      Açıkçası ne yaptığınızı biliyorsanız o kadar uzun sürmez. İyi bir tasarım mühendisi bu rolün uzmanıdır
    • Bu UI programlama değil, HTML ve CSS üzerinde UI tasarlamak
      Serbestlik derecesi çok fazla; form gibi temel öğeler varsayılan hâlleriyle bile iyi çalışmalı
    • O kadar karmaşık değil
      UI’ı kod üzerinden iyi ifade etmenin yolları zaten var. Sorun iş tarafındaki sıfır toplamlı oyun. Cross-platform UI, en çirkin UI stack’i olan HTML/CSS/JS ile yapılmazsa maliyet çok yüksek oluyor
    • Eskiden ayrıntıları sizin yerinize temel olarak düşünen oldukça iyi platformlar vardı
      Ama web platformu belgeler için fena olmasa da uygulamalar için soyutlama düzeyi uygun değil. Bu yüzden web UI her yıl yeni ve sızdıran soyutlamalarla yeniden icat ediliyor
    • Web söz konusu olduğunda, doğru UI’a önem veren geliştiricilere yardım edecek mekanizmalar olmadan granülerliğin fazla düşük olmasının sonucu bu
      Sadece yetişmeye çalışmak bile çok iş
      Diğer alanlarda da benzer. İstek göndermenin ya da sorguya parametre eklemenin kolay bir yolu yoksa, insanlar dikkatli olmaya çalışsa bile doğal baskı yüzünden türlü yarım yamalak yöntemler icat ediyor
      Web platformu grafik tarafında en ileri seviyede, ama UI olarak gerçekten berbat. Buna rağmen kimse bunu kabul edip değiştirmeye çalışmıyor. İnsanlar sadece ilk kısma inanıyor; tarayıcıların legacy’si ve karmaşıklığı değişimi engelliyor. Kütüphane olarak yapınca da “standart” olmadığı için kimse umursamıyor

  • Öte yandan bazı UI’lar radio button için kare kutu da kullanıyor
    Vurgulanmış bir düğme var ama Enter tuşuyla etkinleşmiyor olabiliyor
    Ayrıca farklı simgelerin (üç nokta, hamburger, kebab) arkasında üçer menü saklı olabiliyor
    Kalite farkı büyük. UI’ı cilalayan insanlar gerçekten minnet duyulacak kişiler

    • Odaklanmış düğmeyi tıklanmış gibi çalıştıran tuşun genelde Enter değil Space olduğunu düşünüyorum
    • Radio button’lar da artık kare ya da yuvarlatılmış kare standardına gidiyor gibi
      Apple bile bunu yapıyor :(

  • Girdi öğelerini neden etiketin içine koyma yönteminin popüler olmadığını anlamıyorum
    Böyle yapınca sorun tamamen ortadan kalkıyor ve for için benzersiz bir id oluşturmaya da gerek kalmıyor

    • “Popüler değil” demektense bence tam tersi
      Ancak hâlâ yeni geçerli standart deseni yorumlayamayan birkaç yardımcı teknolojinin olduğu bilindiğinden, Tunç Çağı standardına bağlı kalmak en iyi uygulama hâline geliyor [1]

      Windows için Dragon Naturally Speaking ve macOS/iOS için Voice Control, örtük ilişkilendirmeyi tanımadığından, [açık bir for-id referansı olmadan input’u label içine iç içe yerleştirme] çalışmıyor
      Naturally Speaking’in “Microsoft” adlı bir şirket tarafından satın alındığı, Voice Control’ün de “Apple” adlı bir şirketle ilişkili olduğu söyleniyor
      [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

    • Rails yardımcılarıyla checkbox oluşturursanız, değerin her zaman POST edilmesi için yanında “off” değerine sahip bir hidden field koyar
      Diğer framework’lerin de benzer olduğunu sanıyorum. Bu iki input alanını bir label öğesiyle sararsanız artık geçerli HTML olmaz
      Radio button’larda sorun değil, ama bazıları bunu yaşadıktan sonra “garanti olsun” diye böyle yapıyor gibi. JavaScript satırlarının sonuna noktalı virgül koymaya benziyor. Neredeyse hiç gerekmez, ama tam olarak ne zaman gerektiğini bilmediğiniz için her yere koyarsınız
    • En az 15 yıldır, belki de 20 yıldır böyle yapıyorum
      Checkbox/radio button’ların yaygın kullanım senaryolarında sözdizimi de çok daha temiz
      Input öğesini label ile sarın; metne stil vermek istiyorsanız metni span içine koyun. label’ı display:flex yapıp metnin konumunu da bu şekilde halledebilirsiniz
    • Bunun nedeni semantik web doktrini

  • Bug bash’lerde bu yöntemi kullanıyoruz ve test senaryosu kombinasyonlarını çok boyutlu Kartezyen çarpım matrisi olarak hazırlayan kişiden çok daha fazla ticket çıkıyor
    Başlangıç noktası olarak böyle test senaryolarını bilmek iyi, ama küçük sorunları bulmak için rastgele test planlı testi hızla geride bırakıyor
    Planlı test genelde happy path’te ya da beklenen hatalarda kalıyor. Bu tür cilalama yöntemi köşe durum bug’larını çok daha hızlı buluyor

    • Bazen, özellikle de tüm bir özellik üzerinde çalışamayacak kadar yorgun olduğumda, oyunlarda sağa sola rastgele tıklıyorum ve normalde denemeyeceğim şeyleri deniyorum
      Her zaman bir sorun ya da küçük bir iyileştirme buluyorum. Planlı testle gerçekten pek ortaya çıkmayacak şeyler

  • Kişisel web sitemi (https://dustinbrett.com) neredeyse 4 yıldır cilalıyorum ve sanki sonsuza kadar sürebilirmiş gibi geliyor
    Neyse ki üzerinde çalışmaktan keyif alıyorum

    • Dürüst olmak gerekirse, buna harcanan zamanın ne kadarının 9-5 mesai içinde ve patronun parasıyla yapıldığını merak ediyorum
      Umarım tamamı öyledir :-)
    • Bu gerçekten çok iyi
      “Web sayfası üstünde masaüstü OS” gördüğümde çoğu yarım yapılmış gibi geliyor ve açıkçası artık fazla yaygınlaştığını düşünüyorum; ama bu tam tersine çok sağlam ve iyi cilalanmış
    • Gezinmesi çok keyifli
      Gerçekten iyi yapılmış ve ilham verici. Her şeyi nasıl uyguladığını düşünmek de epey eğlenceli
    • Çok akıcı ve bende olduğunu bilmediğim bir isteği kaşıyor
      Telefonda pencere tabanlı OS kullanma isteğiymiş bu
    • Gerçekten harika görünüyor
      Eksik bir şey bulacak olursam, explorer’da mouse4/mouse5 kullanılamaması. “Cilalama” gerçekten sonsuza kadar sürebilir