$30 off During Our Annual Pro Sale. View Details »

Yönetilebilir Arayüz Mimarisi

Yönetilebilir Arayüz Mimarisi

Web ve Mobil için arayüz geliştirirken yönetilebilir kod hazırlamanın önemi

Bilal Çınarlı

March 28, 2015
Tweet

More Decks by Bilal Çınarlı

Other Decks in Technology

Transcript

  1. Yönetilebilir Arayüz Mimarisi Web, Mobil ve Karmaşık Sistemler için HTML/CSS

  2. Bilal Çınarlı
 Front-end Architect Senior UX Developer@Turkcell
 @bcinarli github.com/bcinarli

  3. Siz?

  4. Arayüz Atölyesi

  5. • Tasarımı Nasıl Ele Almayız? • Tekrar Kullanılabilirlik • Seçiciler

    • İsimlendirme / Gruplama • Kod tekrarlarını azaltma Neler Yapacağız?
  6. Başlamadan

  7. Chat Odası http://tlk.io/arayuz2015 Çalışmalar İçin https://jsfiddle.net http://codepen.io/

  8. • Text editor • Sass • Photoshop (Size bağlı) •

    Github Gün Boyu İhtiyacınız Olabilecekler
  9. Arayüz Mimarisi

  10. • Sistemler ve takımlar büyüdü • Arayüz geliştirme karmaşıklaştı •

    Çok fazla tarayıcı ve cihaz çeşitliliği • Sayfalardan uygulamalara geçildi Neden?
  11. None
  12. None
  13. • Daha kolay ve hızlı çalışma • Daha akıllıca çalışma

    • Daha kısa öğrenme/adapte olma süresi • Daha kolay yönetim ve geliştirme Hedef
  14. None
  15. SASS

  16. • Fonksiyonlar • Değişken • Modüler Çalışabilme

  17. Biraz Elimizi Kirletelim

  18. $ git clone https://github.com/bcinarli/scalable-frontend-architecture.git arayuz2015 GitHub

  19. None
  20. • Klasörünüzü Prepros ya da Codekit içine ekleyin • “styles-sass/styles.scss”

    dosyasını “styles/styles.css” şeklinde çıktı vermeye ayarlayın Prepros/Codekit
  21. None
  22. Çalışma (5 dakika) Örnek repoyu inceleyelim, istediğiniz kod örneğini ve

    denemeyi yapın
  23. Markup

  24. • Sayfa mimarisinin temeli • Bütün sunum ve etkileşim katmanını

    etkiler • Karmaşık kurguların kolay uygulanmasını sağlar ya da kabus haline gelmesine neden olur!
  25. Tasarımı İnceleyelim

  26. None
  27. Komponentler

  28. • Sayfaları unutun • Sayfalar içindeki komponentleri düşünün • Komponentleri

    birleştirerek sayfaları oluşturuyoruz
  29. Komponentleri Planlama

  30. • Bir tane komponenti ele alın • Kullanım yapısını düşünün

    • Aynı yapıyı başka elemanlarda arayın • Farklı noktaları ayırın • Benzer noktaları ortak tanımlayın
  31. Çalışma (10 dakika) Tasarımdaki ana menümüzü oluşturalım

  32. None
  33. Çalışma (Beraber) Menü için hazırladığımız yapıyı başka nerde kullanabiliriz?

  34. None
  35. None
  36. None
  37. Mimari’nin Temelleri

  38. Front-end Kimdir?

  39. • OOCSS - Arayüz geliştirmeye mühendis bakış açısı • Kurgu

    - Sadece renkleri ekleyen değil, akışı planlayan • Adaptive - Sürekli değişen/güncellene teknoloji ve sistemlere hızlı çözüm üretebilen
  40. None
  41. Tasarımı Yönetmek

  42. Öğeleri Nasıl Sadeleştirebiliriz? Benzer görünüme sahip elemanları en sade şekilde

    tanımlama
  43. None
  44. Çalışma (Beraber) Ögeler için genel grupları en sade haliyle planlayalım

  45. Reusable CSS

  46. Single Responsibility Principle

  47. Object Oriented Programlamada, bütün ortamlar (class, function, variable vs), sadece

    bir işlemden sorumlu olmalı ve bu işlem o ortamın içinde başlayıp sonlanmalı.
  48. Tanımlanan her stil, temel anlamda her zaman bir iş için

    tanımlanmalı ve her zaman o iş için uygun kullanılmalı CSS’de Karşılığı
  49. None
  50. Bunu istemiyoruz!

  51. None
  52. Başlıksız, kırmızı arkaplan, beyaz metin Widget - Banner

  53. <div class=“sidebar-banner”> … </div>

  54. • Widget • Beyaz Metin • Kırmızı Arkaplan Widget -

    Banner
  55. <div class=“widget
 widget-banner”> … </div>

  56. • Daha sade kodlama • Tekrar kullanılabilen kod bloklarına sahip

    olma • Farklı tanımları bir arada kullanabilme avantajı Single Responsibility Principle
  57. Çalışma (Beraber) Tasarım’dan SRP kullanımlarını inceleyelim

  58. None
  59. None
  60. Seçim Sorunu

  61. • İyi kurgulanmamış tanımlarda sayfaya göre küçük değişiklikleri olan komponentleri

    düzenleme zorlaşmaktadır • İstenilen görünüm vermek için çok spesifik seçiçi tanımı gerekmektedir • Kod tekrarı artar, dolayısıyla kontrol zorlaşır
  62. CSS Seçiciler - Atomik Yaklaşım

  63. • Tahmin edilebilir - isimleri, tanımları ile yaptıkları uyumlu olmalı

    • Tekrar kullanılabilir - farklı ögeler için de kullanılabilmeli • Stabil olmalı - eklendiği ögeyi etkilerken başka bir ögeyi bozmamalı • Düşük Spesifiklikte olmalı - bir ögeye “nokta atışı” yapmamalı Uyulması Gerekenler
  64. • * (global selector) • a, div (tag selector) •

    [class*=“like”], [class^=“like”], [class$=“like”], [class~=“like”] • .class, .media • #unique
  65. Belki de bütün kötü kodun temeli! Spesificity

  66. header .menu ul { }

  67. .main-navigation { }

  68. None
  69. Anlamlı/Anlaşılır Tanımlar

  70. • HTML - tanımları itibariyle anlamlı ve makine/tarayıcı için bir

    ifadeye sahiptir • Class - cihaz için anlamlı değildir, insanın okuyup, anlamlandırması için tanımlanır, subjektiftir
  71. <div class=“headline”></div> <div class=“baslik”></div> <div class=“publizierte”></div>

  72. <article class=“widget widget-secondary resources”> <h1 class=“resources-title”>Kaynaklar</h1> <p class=“resources-text”>Lorem ipsum dolor…</p>

    </article>
  73. <article class=“widget widget-secondary resources”> <h1 class=“resources-title”>Kaynaklar</h1> <p class=“resources-text”>Lorem ipsum dolor…</p>

    </article>
  74. <article class=“widget widget-secondary resources”> <h1 class=“resources-title”>Kaynaklar</h1> <p class=“resources-text”>Lorem ipsum dolor…</p>

    </article>
  75. • Class ismi verirken görünümden bahsetmek gereksizdir • Tanımın yapıtığı

    iş/eyleme göre isimlendirmek her zaman daha doğrudur Anlamlı/Anlaşılır Tanımlar
  76. <div class=“border mt10 blue pill”> … </div>

  77. <div class=“widget widget-round”> … </div>

  78. <button class=“blue-button”>…</button>

  79. <button class=“primary-action”>…</button>

  80. İsimlendirme

  81. • Her zaman kafa patlatıcı bir iş olmuştur • Programlamadaki

    en zor işlerden biri olarak düşünülür • Düzgün yapıldığında her zaman değerli olur
  82. • Görünümden çok işlevselliğe odaklanmalı • İş güdüsel olmalı •

    Farklı ögelere uygulanabilir olmalı İsimlendirme Nasıl Yapılmalı
  83. <nav class=“navigation-list”> <a href=“#” class=“navigation-list-item”>…</a> <a href=“#” class=“navigation-list-item”>…</a> <a href=“#”

    class=“navigation-list-item”>…</a> <a href=“#” class=“navigation-list-item”>…</a> </nav>
  84. Çalışma (Beraber) Tasarımımızdaki anlamlı ögeleri bulalım

  85. • Tasarımdaki ögelerin özelleşmiş durumlarıdır • Objelere göre daha tanımlayıcı

    isimleri olabilir Componentler
  86. <nav class=“navigation-list main-navigation”> <a href=“#” class=“navigation-list-item main-navigation-item”>…</a> <a href=“#” class=“navigation-list-item

    main-navigation-item”>…</a> <a href=“#” class=“navigation-list-item main-navigation-item”>…</a> <a href=“#” class=“navigation-list-item main-navigation-item”>…</a> </nav>
  87. .main-navigation { }

  88. .button-primary { }

  89. İsimlendirme Yöntemleri

  90. • Elemanın ne işe yaradığını anlatmalı • Elemanın ek özelliğe

    sahip olup olmadığını anlatmalı • Elemanın hangi durumda olduğunu anlatmalı
  91. • Yandex! • Block / Element / Modifiers BEM Metodolojisi

  92. <div class=“block block- -modifier”> <p class=“block__element”>…</p> </div> Block

  93. <div class=“block block- -modifier”> <p class=“block__element”>…</p> </div> Element

  94. <div class=“block block- -modifier”> <p class=“block__element”>…</p> </div> Modifier

  95. • Elemanın ne olduğunu anlatıyor • Markup ve CSS içinde

    elemanların ilişkisini gösteriyor • Tanımları bir namespace içine ekliyor BEM Metodolojisi
  96. • Tanıtım ayraçlarından hoşlanmıyorsanız • modifier için kullanılan “- -“

    tanımı • element için kullanılan “__” tanımı BEM Metodolojisi - Alternatif
  97. <div class=“block mofied-block”> <p class=“block-element”>…</p> </div> Block

  98. <div class=“block modified-block”> <p class=“block-element”>…</p> </div> Element

  99. <div class=“block modified-block”> <p class=“block-element”>…</p> </div> Modifier

  100. <nav class=“navigation main-navigation”> <a href=“#” class=“navigation-item”>…</a> <a href=“#” class=“navigation-item”>…</a> <a

    href=“#” class=“navigation-item”>…</a> </nav> Örnek
  101. <div class=“widget promo-widget”> <h1 class=“widget-title”>…</h1> <div class=“widget-content”>…</div> </div> Örnek

  102. Tanım Sıralaması

  103. • Spesifikliğin yanında, tanım kurgusu da overwritelerı azaltır. • Piramidin

    durumuna göre yazılan kodlar, SRP kullanımını arttırır. • Tanım kurgusu içinde ilk en üstteki kodlar genel kullanım içindir • En altta kalan tanımlar ise, atomik yapıda, ögeye ya da duruma özel kodlardır
  104. None
  105. Kod/Yeni Geliştirme Süreci

  106. • Bir sürü dosya • Farklı klasörler Kod Kurgusu

  107. None
  108. Layout

  109. • Bir bütün olarak düşünülmeli • Elemanların kendi genişlikleri yerine

    bulundukları yerler planlanmalı • Grid sistem ile karıştırmamak önemli
  110. Layout Kurgusu Yoksa

  111. Layout Kurgusu Olduğunda

  112. Toparlarsak

  113. None
  114. • Her zaman html ögesini olabilecek en sade yapı ile

    kurgulayın • CSS seçicileri kısa, düşük spesifiklikte ve tekrar kullanılabilir olacak şekilde tanımlayın • Küçük parçaları yönetmek daha kolaydır, kodunuzu küçük bloklara bölerek yönetin • Uygulamayı bir bütün olarak düşünüp, her zaman tekrar kullanım ve extend etmeyi planlayarak çalışın
  115. Teşekkürler @bcinarli