Mükemmel Akordiyonu Tasarlamak

Bazen bu kalıpları hiç düşünmeden kullanırız ve bunun iyi bir nedeni vardır: Bir arayüz sorunuyla her karşılaştığımızda yepyeni bir çözüm bulmak zaman alıcı ve risklidir, çünkü ne kadar olduğunu bilmiyoruz. yeni bir çözümü uygulamak için zamana ihtiyaç duyulacak ve kullanılabilirlik testlerinde incelikle başarılı mı yoksa sefil bir şekilde başarısız mı olacak.

Tasarım desenleri, çoğunlukla zamandan tasarruf ettikleri ve bize daha iyi sonuçları daha hızlı aldıkları için son derece yardımcı olabilir . Bunları, karşılaştığımız her soruna tam olarak olduğu gibi uygulamamız gerekmiyor, ancak kararlarımızı bildirmek için deneyimimizi kullanarak bunların üzerine inşa edebiliriz çünkü diğer projelerde oldukça iyi çalıştıklarını biliyoruz.

Son birkaç yılda, çeşitli yaklaşımları deneyen ve bunları kullanılabilirlik testlerinde inceleyen çeşitli şirketlerle çok fazla zaman harcadım. Bu makale dizisi, zaman içinde yapılan gözlemlerin ve deneylerin bir özetidir . Emniyet kemerlerinizi sıkın: SmashingMag hakkındaki bu yeni makale dizisinde, atlıkarıncalardan filtrelere, hesap makinelerine, çizelgelere, zaman çizelgelerine, haritalara, çok sütunlu tablolara, muazzam fiyatlandırma planlarına ve koltuk seçimine kadar her şeyin örneklerini inceleyeceğiz. Havayolu ve sinema sitelerinde. Ancak karmaşık arayüz problemlerine geçmeden önce, görünüşte basit ve bariz bir şeyle başlayalım: bir akordeon.

Bir Akordeonun Barebones

Akordeon'un duyarlı tasarımda muhtemelen en yerleşik iş gücü olmasının iyi bir nedeni var. Aşamalı açıklama için son derece yararlı bir modeldir - bir bölümün önemli ayrıntılarını vurgulayarak ve gerekirse bir dokunuş veya tıklamayla daha fazla ayrıntıyı ortaya çıkarır. Sonuç olarak, tasarım odaklı kalır ve diğer her şeye kolayca erişilebilirken önce kritik bilgileri görüntüler. Aslında, herhangi bir sorunla karşılaşırsanız - çok fazla gezinme seçeneği, çok fazla içerik, çok ayrıntılı bir görünüm - bu sorunu çözmek için iyi bir akordeondan nasıl yararlanabileceğinizi keşfetmek iyi bir başlangıç ​​noktası olacaktır. Çoğu zaman, şaşırtıcı derecede iyi çalışıyor.

Bununla birlikte, öngörülebilir ve akordeon gibi sıklıkla kullanılan bir bileşen bile yorumlama ve belirsizlik için çok fazla alana sahiptir. Beni yanlış anlamayın: bağlam önemlidir. Navigasyon için bir akordeon, Soru-Cevap bölümünden farklı bir yaklaşım gerektirecektir. Ancak tüm farklı bağlamlarda iki şeyi etraflıca ele almalıyız: tüm karışıklık ve yanlış yorumlama noktalarını ortadan kaldırmak için görsel tasarım ve bir akordeonun etkileşim tasarımı .

Şimdi, akordeonun barebone'larına biraz daha yakından bakarsak, tüm atomik elementlerini görmek zor olmayacaktır. Bir akordeon her zaman kategori başlığını, genişletilmiş ve daraltılmış bir durumu, genişlemeyi gösteren bir simgeyi ve aralarındaki boşluğu içerir. Kategori genişletildikten sonra, simge çökmekte olduğunu gösterecek şekilde değişmelidir. Ancak, başka bir kart açıkken kullanıcı daraltılmış bir karta tıklarsa ne olur? Genişletilmiş kart otomatik olarak kapanmalı mı, kapanmamalı mı? Ya tüm öğeler görüntülenemiyorsa - kullanıcı otomatik olarak yukarı kaydırılmalı mı? Gelin bunlara ve ilgili konulara tek tek daha yakından bakalım.

Genişlemeyi Belirtecek Bir Simge Seçme

Şimdi başlayalım. Biz ne biliyoruz? Açıkçası, çoğu soldan sağa arabirimde, kategori adı da sola hizalı olacaktır. Birçok akordeonda olduğu gibi, alt öğelerin iki bölüm arasında kayacağını varsayarsak, bu davranışı iletmek için hangi simgeyi seçersiniz? Aşağıyı gösteren bir ok, sağı gösteren bir ok, aşağıyı gösteren bir şerit, bir artı, daire içine alınmış bir artı - belki tamamen farklı bir şey?

Tecrübelerime göre, aynı kullanıcı arayüzünde çeşitli anlamlarla aşırı yüklenmediği sürece simge seçiminin gerçekten önemli olmadığı görülüyor. Örneğin, bir fiyatlandırma planında genişleme, yakınlaştırma ve iki öğeden oluşan bir paketi belirtmek için potansiyel olarak daire içine alınmış artı kullanabilirsiniz - ve bu, kafa karışıklığına neden olabilir. Bununla birlikte, akordeon bağlamında, kullanıcılar, gezinme öğelerinin bazılarında bir simge varsa, diğer bölümlerde yoksa, bunun tıklama veya dokunma ile daha fazla içeriğin mevcut olduğunun bir tür işareti olduğunu anlamış görünüyorlar. Bir simgenin diğerlerinden daha fazla veya daha az tanınabilir olduğuna dair herhangi bir belirti bulamadık. Ancak bu, bazı seçeneklerin diğerlerinden daha fazla kafa karışıklığına neden olmayacağı anlamına gelmez.

Örneğin, Slack sağı gösteren bir ok kullanır, ancak akordeon öğeleri kategori başlıkları arasında sağdan ziyade dikey olarak kayar. Şimdi, bu noktada simgenin yönünün ne amaçla olması gerektiğini sormakta fayda var. Muhtemelen hareket yönünün veya daha spesifik olarak, simgeye dokunulduğunda veya tıklandığında kullanıcının görüşünün nereye taşınacağının bir göstergesi olarak hizmet etmelidir. Örneğin iOS'taki Apple Mail'de, sağı gösteren şerit, kullanıcının görüşünün soldan sağa hareketini eşler.

Simgenin yönü ile kullanıcının görüşünün hareketi arasında bir eşleme yapmak mantıklı görünüyor, ancak farklı arayüzler farklı davrandığından (gizemli simgeler genellikle kullanıcılarla akıl oyunları oynuyor) herkes bu davranışı beklemeyecektir. Sonuç olarak, tasarımcı olarak ne yaptığınız gerçekten önemli değil: öyle ya da böyle, bazı kullanıcılarınızın beklentilerini karşılayamayacaksınız. Tasarlarken, tasarladığımız şeye odaklanma eğilimindeyiz, ancak kullanıcı arayüzlerimizde son derece tutarlı olsak bile, kullanıcılarımız hiç görmediğimiz web sitelerindeki deneyimlerinden etkilenen beklentilerle gelecekler. O halde anahtar, mümkün olduğu kadar esnek olmak ve beklentilerin karşılanmaması durumunda kolay, doğrudan bir iyileşme sağlamaktır.

Simge seçimine geri dönüp baktığımızda, akordeon öğeleri dikey olarak kayarsa, sezgisel olarak, sağı gösteren simge dışında yukarıda listelenen simgelerden herhangi birini kullanmak güvenli görünüyor. Burada dikkate alınması gereken tek sorun, seçtiğiniz simgenin zaten farklı bir bağlamda başka bir anlamla aşırı yüklenmiş olup olmadığıdır - örneğin, bir fiyat planındaki bir paket anlaşmasının bölümlerini vurgulamak için bir artı simgesi kullanıyorsanız (burada artı tıklanabilir değil) ve ardından akordeon için tam olarak aynı artı simgesini kullanın. Böyle bir durumda, kafa karışıklığına neden olabileceğinden, tamamen aynı simgeyi farklı amaçlar için kullanmaktan kaçınmak daha iyidir.

O zaman her şey temizlendi mi? Pek değil.

Bir saniye için beklenen etkileşimi düşünelim. Ok ve şerit genellikle belirtilen yönde değişiklik için ipuçları olarak hizmet ederken, artı, ekleme ve genişlemeyi gösterir. Her iki durumda da, değişiklik çeşitli şekillerde olabilir: simgeye bir dokunuş, içeriğin üzerinde gezinme öğelerinin göründüğü bir kaplamaya veya öğelerin dikey olarak (yatay değil) kaymasına neden olur. Çok uzak çok iyi.

Bununla birlikte, bir kullanıcı bir sayfaya ulaştığında, başlangıçta, sayfanın bazı bölümlerine atlayan bağlantılara sahip uzun kaydırmalı bir sayfaya mı, yoksa yalnızca kendi ayrı bölümleri olan "normal" bir web sitesine mi geldiğini bilmiyorlar. sayfalar. Oldukça sık, aşağıyı gösteren bir ok, gezinme seçeneklerini genişletmek yerine sayfa içindeki bölümlere atlamayı tetikler . Kullanıcının geçmişte yönünü şaşırmış olması, uzun bir sayfanın bir bölümüne getirilmesi ve ardından sayfanın başına geri dönüp oradan devam etmesi muhtemeldir.

Sonuç olarak, bir ok kullanmayı seçerseniz, bazı kullanıcıların kategoriler arasında kayan alt öğeleri görmek yerine sayfanın o bölümüne aşağı kaydırılmayı beklemesiyle karşılaşabilirsiniz. Böylece şerit daha güvenli ve daha öngörülebilir bir seçenek gibi görünüyor; kullanmayı seçerseniz, daraltılmış durumda aşağı ve genişletildiğinde yukarı doğru tutun. Artı simgesi için bunun yerine eksi simgesi veya bir kapat simgesi arasında seçim yapabilirsiniz.

Peki tüm bunlar tasarımcılar olarak bizler için ne anlama geliyor? İlk olarak, akordeon öğelerinin yatay olarak soldan sağa kayması gerekiyorsa, sağa dönük bir ok kullanmak güvenlidir. İkinci olarak, akordeon öğelerinin yukarıdan aşağıya dikey olarak kayması gerekiyorsa, aşağıyı gösteren bir şerit (ok değil!) veya bir artı simgesi iyi çalışabilir.

Bunu akılda tutarak, simge seçimi oldukça basit bir karar olmalıdır. Ancak bu simgenin kategori başlığına ne kadar yakın olduğuna bağlı olarak kafa karışıklığına da neden olabilir. Şimdi, o simgenin konumunu seçerken hangi seçenekleri göz önünde bulundurmamız gerekiyor?

Simgenin Konumunu Seçme

Seçenekler! Hangi simgeyi seçtiğinizden bağımsız olarak, onu a) kategori adının soluna veya b) sağına ya da c) simgeyi tüm gezinme öğesi çubuğunun sağ kenarı boyunca boşluk bırakarak yerleştirmeyi seçebilirsiniz. simgesini ve kategori adını çıkarın.

Pozisyon önemli mi? Aslında öyle. Viget'in “Akordeon Menü Tasarımlarını ve İkonografisini Test Etme”ye göre, bazı kullanıcılar gezinme çubuğunun tamamından ziyade özellikle simgeye basmaya odaklanma eğilimindedir. Bunun olmasının basit bir nedeni var: Geçmişte, bazı kullanıcılar akordeonun alternatif uygulamalarıyla “yakılmış” olabilir. Bazı web sitelerinde kategori başlığı genişlemeyi tetiklemez ve bunun yerine doğrudan kategoriye gider. Diğer uygulamalarda, gezinme çubuğuna bir dokunuş genişlemeye neden olmaz veya kategoriye atlamaz - kesinlikle hiçbir şey yapmaz.

Elbette tüm alanı bir isabet hedefi olacak şekilde tasarlayacak olsak da, her navigasyon bu davranışa sahip olmadığından, bazı kullanıcılar gerçekten tıklayana kadar navigasyonunuzun “kötü olanlardan” veya “iyilerden” biri olup olmadığını bilemezler. (veya üzerine gelin). Fareyle üzerine gelme her zaman mümkün olmadığından, simgeye basmak daha güvenli bir bahis gibi görünüyor - simgeye tıklamak neredeyse her zaman beklenen davranışı tetikleyecektir. Bu bir akordeon tasarlarken bilinmesi gereken önemli bir ayrıntıdır.

Çeşitli arayüzler ve uygulamalar arasında, kategori başlığının sağına yerleştirilen simgeyle, kullanıcıların simgeye, simgenin sola yerleştirilmesinden (kullanıcıların kategori başlığını veya boş Çubuk). Ancak, bazı kullanıcılar hala simgeyi seçme eğilimindedir. Sonuç olarak, simgeyi, her ihtimale karşı , en az 44×44 piksel boyutunda, rahat dokunma için yeterince büyük yapmak iyi bir karardır.

Sola hizalı, sağa hizalı veya sağa hizalı mı? O kadar da önemli değil gibi. Ancak, kategori başlıklarının uzunluğu çok farklı olan bir akordeon grubunuz varsa (belki bir gezinme menüsünde yaşıyorsanız), akordeon durumlarını birçok bölüm arasında değiştirmek, gezinme çubuğunu yukarıdan aşağıya doğru çalıştırmaktan biraz daha fazla odak gerektirecektir. . Sadece, o süslü simgeye ulaşmak için fare işaretçisinin veya parmağının her zaman yeniden konumlandırılması gerekiyor! Ayrıca, simge sağa hizalanmışsa, dar bir ekranda parmağın gezinme alanı boyunca hareket etmesi ve görünümü karartması gerekir. Çubuğun sağ kenarına yerleştirilen simge ile bu sorun çözülecektir.

Ancak simge çubuğun sağ kenarına hizalanmışsa, yine de onu kategori adından çok uzağa yerleştirmemeye dikkat etmemiz gerekir. Görsel olarak, genişlemenin kategoriyle ilgili olduğu açık olmalıdır; bu nedenle, farklı görünümlerde, görsel bağlantıyı açık tutmak için simgenin konumu değişebilir. Ayrıca, daha geniş ekranlarda simge biraz daha büyüyebilir. Bu seçenek bir grup akordeon için tercih edilebilir gibi görünüyor, ancak tek bir akordeon için gerçekten büyük bir fark yaratmıyor - tabii verileriniz aksini kanıtlamadıkça.

Akordeon İçin Etkileşim Tasarımı

Bununla birlikte, tüm bu ince ayrıntılar ortadan kalkmış olsa bile, etkileşim hala bazı soruları gündeme getiriyor. Kategori başlığının sola hizalı olduğunu ve simgenin çubuğun sağ kenarına hizalandığını varsayalım. Yukarıdaki tartışmayı takiben, bir kullanıcı kategori adını veya simgeyi veya aradaki boş alanı tıkladığında ne olmalıdır? Hepsi genişlemeyi tetiklemeli mi yoksa farklı amaçlara mı hizmet etmeli?

Bir şeyden oldukça emin olabiliriz: Kullanıcı simgeye tıkladığında, muhtemelen bir çeşit genişleme bekliyorlar, bu nedenle bir simgeye dokunmak kesinlikle genişlemeyi tetiklemelidir. Ancak kategori başlığı, doğrudan kategoriye atlamak veya genişletmek amacıyla tıklanabilir.

Kategori başlığı genişlemeyi tetiklerse, kullanıcıların doğrudan o bölüme atlayabilmesi için alt açılır menüde kategoriye bir bağlantı sağlamamız gerekir ("Tüm öğeler" gibi). Bu, kullanıcının ön sayfadan bir kategoriye yolculuğunun, kategori başlığına tıklarken fazladan bir dokunuşa ihtiyaç duymayı beklemedikleri için kafa karışıklığına neden olabileceği anlamına gelir. Bununla birlikte, bu durumda kurtarma açıktır ve hemen devam edebilecekleri için kullanıcıyı önceki durumu geri yüklemeye gerçekten zorlamaz.

Akordeondaki kategoriye bağlantı açıksa, rahatsız edici hissetmezken, gezinme öğesini genişletmek ve ardından geri dönmek yerine bir kategoriye atlamak rahatsız edici olabilir. Bu nedenle , hem simgenin hem de kategori başlığının genişlemeyi tetiklemesi muhtemelen daha mantıklıdır. Bu şekilde daha az rahatsız edici. Bu etkileşim, kategori başlığı ile simge arasında da mı olmalı? Bazı tasarımcılar, bir kullanıcı sitede gezinirken alana dokunduğunda, genişlemeyi değil, fare işaretçisini sayfada kaydırmaya başlamak için "sabitlemek" isteyebileceklerini ve sonuç olarak bunun rahatsız edici olduğunu iddia edebilirler. Bu elbette mümkündür, ancak kullanıcı gezinme seçeneklerini keşfetmek için bir gezinme menüsü açmayı seçerse gerçekleşmesi pek olası değildir.

Akordeonlar genellikle kartlar için kullanılır ve görünümün genişliğine bağlı olarak kartlar oldukça geniş olabilir, bu nedenle bazı kullanıcılar umutsuzca simgeye basmaya çalışırken, bazı kullanıcılarınız boş alana dokunarak kartları daraltmaya ve genişletmeye alışacaktır. barda. Diğer kullanıcılar hiçbir işe yaramayan boş alana alışacak ve onu görmezden gelecekler. Çubuğun kategoriye bir bağlantı olarak hizmet etmesini yalnızca birkaç kişi bekleyecektir. Testlerimizde, açıkçası, başka herhangi bir şeyden ziyade, boş alan tetikleyici genişlemesine sahip olmanın daha az kafa karıştırıcı olduğu kanıtlandı, bu yüzden biz de kullanmayı seçtik.

Peki ya kategori başlığının doğrudan kategoriye bağlanmasını istiyorsanız? Bir fikir, öğelerin sınırlarını "ima eden" görsel olarak ayırt edici iki öğeye sahip olarak netlik getirmek olabilir - örneğin, simge için farklı arka plan rengi ve kategori başlığı (yukarıdaki örneğe bakın). Deneylerimizde, davranış ve beklentilerde herhangi bir değişiklik fark edemedik - bazı insanlar yine de kategoriyi tıklayıp ne olduğunu merak edecek. Yine, bölümün genişletilmiş akordeon içinde bağlanması daha güvenli bir bahis gibi görünüyor.

Yeterince iyi? Eh, henüz tam olarak orada değiliz. Kullanıcı genişletme için simgeye dokunursa ancak ekranda tüm alt öğeleri göstermek için yeterli alan yoksa ne olur? Ekibinizden biri, genişletilmiş alanın ekranın en üstünde görüntülendiğinden emin olmak için sayfayı otomatik olarak yukarı kaydırmayı önerebilir. Bu iyi bir fikir mi?

Kontrolü kullanıcıdan almaya çalıştığımızda, bu karar tamamen test edilmeli ve dikkate alınmalıdır. Belki de kullanıcı aynı anda birden fazla bölümü görüntülemekle ilgileniyor ve bu bölümlerin içerikleri arasında hızla atlamak istiyor. Kullanıcıyı otomatik kaydırma veya atlama davranışı hakkında merak ettirmek ve ardından önceki durumu geri yüklemek için geri kaydırmak yerine, her şeyi olduğu gibi tutmak, aşağı kaydırabilecekleri için kararı kullanıcıya bırakmak daha az rahatsız edici görünüyor Eğer gerekliyse. Pek çok kullanıcı zirveye çıkmayı beklemez - akışı kesmemek veya belki de bölüme kalıcı bir bağlantıya sahip olmak (gerçekten uzunsa) daha iyi bir seçenek gibi görünüyor.

Ve sonra başka bir soru ortaya çıkıyor: Bir bölüm zaten genişletilmişse ve kullanıcı başka bir bölüme tıklarsa, ilk bölüm daraltılmalı mı yoksa olduğu gibi mi kalmalı? İlk bölüm otomatik olarak daraltılırsa, ancak kullanıcının umduğu gibi değilse, her zaman yeniden açabilirler, ancak her iki kategoriyi aynı anda tarayamaz veya karşılaştıramazlar. Bölüm genişletilmiş kalırsa, ihtiyaç duymadıkları kategoriyi aktif olarak kapatmaları gerekir. Her iki seçeneğin de makul kullanım durumları var gibi görünüyor.

Bir akordeonun doğası, otomatik çökmeyi gerektirir, ancak kullanılabilirlik açısından en iyi seçenek olmayabilir. Birçok öğeye sahip akordeonlar için, bölümleri geniş bırakma eğilimindeyiz, çünkü panellerin aynı anda açılıp kapanmasının bir sonucu olarak meydana gelen atlama çok gürültülüdür. Bu nedenle, alternatif olarak, bir program veya ayrıntılı bir tablo tasarlarken çok yardımcı olabilecek bir "tümünü daralt"/"tümünü genişlet" düğmesi sağlayabilirsiniz. Bu kadar çok öğe yoksa, atlama minimum olacağından bölüm varsayılan olarak daraltılabilir. (Lütfen, yatay akordeonlar için bölümün kesinlikle çökeceğini unutmayın - açık tutmak mantıklı olmaz.)

Ve sonra başka bir şey var. Simge seçimini veya konumunu boşverin, bir akordeon genişletildiğinde, onu hemen daraltmak kolay olmalıdır. Bu etkileşim, tıpkı diğer herhangi bir gizle ve göster etkileşiminde olduğu gibi, fare imlecinin veya parmağının fazladan hareket etmesini gerektirmemelidir. Bu, çökme ve genişleme simgesinin etkinleştirildiğinde elbette değişmesi gerektiği, ancak konumunun tam olarak aynı kalması gerektiği ve akordeonun durumunun anında değişmesine izin vermesi gerektiği anlamına gelir.

Toplama

Ah, görünüşte bariz bir tasarım modelinin uzun bir incelemesiydi. Peki, mükemmel akordeon nasıl tasarlanır? Genişlemeyi gösteren bir simge seçiyoruz (şevron aşağıyı gösteriyor veya bir artı simgesi), onu rahat dokunma için yeterince büyük hale getiriyoruz ve çubuğun sağ kenarına yerleştiriyoruz. Tüm gezinme çubuğu, durumları değiştirmek için çubuğun çevresinde yeterli dolgu ve akordeon kategorisi içinde kategorinin ana sayfasına bir bağlantı ile genişlemeyi tetikler.

Bir şerit kullanmayı seçersek, yön dokunuşta değişmelidir ve bu bir artı simgesiyse, çökmeyi belirtmek için kolayca bir "-" veya "x"e geçebilir. Etkileşimi daha da net tutmak için, kategori öğelerini kaydıran ve kaydıran ince geçişler veya animasyonlar kullanabiliriz.

Elbette, bağlamınız da çok farklı olabileceğinden, çözümünüz çok farklı olabilir, bu nedenle alternatif bir çözüm arıyorsanız, aşağıda bir akordeon tasarlarken her zaman sorduğumuz bazı soruları bulacaksınız.

Akordeon Tasarım Kontrol Listesi

1. Genişlemeyi belirtmek için hangi simgeyi seçeceksiniz?
2. Çökmeyi belirtmek için hangi simgeyi seçeceksiniz?
3. Simgeyi tam olarak nereye yerleştireceksiniz?
4. Kategori başlığını nasıl tasarlarsınız?
5. Daralma ve genişletilmiş durumları (simgenin ötesinde) nasıl belirtirsiniz?
6. Kullanıcı kategoriye tıklarsa ne olur?
7. Akordeon, kategorinin ana sayfasına bir bağlantı içermeli mi?
8. Kullanıcı boş alana tıklarsa ne olur?
9. Genişletilmiş bir bölüm, başka bir bölüm seçildiğinde otomatik olarak daraltılmalı mı?
10. Tüm öğeleri görüntülemek için yeterli alan yoksa ne olur?
11. Bir "tümünü daralt/tümünü aç" bağlantınız veya düğmeniz mi olmalı?

Bir akordeon gibi görünüşte yerleşik ve öngörülebilir bir bileşen için gereken dikkat düzeyi, neredeyse hiç bitmeyen bir tasarım deneyleri ve kullanılabilirlik oturumları hikayesi haline gelir, çünkü bu bileşenin görünümü ve etkileşimi için yalnızca birkaç yerleşik kılavuz vardır. Erişilebilir bir akordeon yapmak zor olmasa da, evrensel olarak anlaşılan bir akordeon tasarlamak o kadar kolay değil. Sonuç olarak, kullanıcılar beklentileri karşılanmadığı veya etkileşim akışlarını kesintiye uğrattığı için genellikle kendilerini kaybolmuş hissederler. Bizim işimiz sürtünmeyi azaltmak ve bunun gerektiği kadar nadiren gerçekleşmesini sağlamaktır. Bağışlayıcı ve esnek bir tasarımla tam da bunu başarabiliriz.

Belki de makalede bahsedilenlerden çok farklı deneyimler yaşadınız? Bu makalenin yorumlarında bize bildirin! Ayrıca, ele almayı seveceğiniz başka bir bileşen varsa, bize de bildirin - neler yapabileceğimizi görelim!

Bizi izlemeye devam edin!

Bu makale, burada, gerçekten Smashing Magazine'inizde, duyarlı tasarım kalıpları hakkında devam eden yeni serinin bir parçasıdır . Bu seride iki haftada bir makale yayınlayacağız. Bir sonrakini kaçırmayın - süslü (ya da çok süslü olmayan) tarih seçicilerde ! Ah, yukarıdaki de dahil olmak üzere tüm kalıpları kapsayan (basılı) bir kitapla ilgileniyor musunuz? Yorumlarda da bize bildirin - belki tüm bu kalıpları tek bir kitapta birleştirmeyi ve Smashing Magazine'de yayınlamayı düşünebiliriz. Sallamaya devam et!