Tasarım Uygulamasının Dokuz İlkesi

İlk başta kafam karıştı. Onlara "doğru yapmak" için ihtiyaç duydukları her şeyi anlatmak için saatler harcadım. Ancak üzerinde düşündükten sonra, sorunun, genellikle bir dizi öznel seçimin ne olduğunu - bazen farklı zamanlarda birçok farklı insan tarafından yapılan seçimler - yönlendirme ve değerlendirmeye yönelik daha derin bir ihtiyaçtan kaynaklandığını fark ettim. Tutarlı adlandırma kuralları ve canlı stil kılavuzları gibi şeyler nihai sonuçtur, ancak bu "en iyi uygulamalar", her zaman açık olmayan daha derin bir değerler kümesine dayanır. Örneğin, "Başka bir sınıfın işbirliği yaptığı sınıfların sayısını en aza indirin" gibi özel tavsiyeler, modülerlik için daha geniş bir takdir olmadan o kadar yardımcı olmaz.

Yaptığımız işin iyi olup olmadığını gerçekten bilmek için, tasarımı uygulamak için bir ölçüm çubuğu olarak kullanılabilecek daha yüksek düzeyde ilkelere ihtiyacımız olduğunu fark ettim. CSS gibi belirli bir dilden kaldırılmış bir şeye veya onu yazmanın üzerinde düşünülmüş bir yoluna ihtiyacımız var. Tasarımın evrensel ilkeleri veya Nielsen'in kullanılabilirlik buluşsal yöntemleri gibi, bize tam olarak nasıl yapacağımızı söylemeden tasarımı uygulama şeklimize rehberlik edecek bir şeye ihtiyacımız var. Bu boşluğu kapatmak için tasarım uygulamasının dokuz ilkesini derledim.

Bu bir kontrol listesi değil. Bunun yerine, temel bir değeri korumayı amaçlayan bir dizi geniş yönergedir. Uygulama üzerinde çalışan biri için bir rehber olarak veya mevcut bir projeyi değerlendirmek için bir araç olarak kullanılabilir. Bu nedenle, ister kodu gözden geçirin, ister CSS'yi denetleyin veya ekibinizdeki bir rol için adaylarla görüşüyor olun, bu ilkeler belirli teknikleri aşan bir yapı sağlamalı ve tasarımın uygulanmasına yönelik ortak bir yaklaşımla sonuçlanmalıdır.

1. Yapılandırılmış Belge, stillerle veya stiller olmadan anlamsal ve mantıksal olarak yazılmıştır.
2. Verimli Tasarıma ulaşmak için en az miktarda işaretleme ve varlık kullanılır.
3. Ortak değerler için Standartlaştırılmış Kurallar serbestçe saklanır ve kullanılır.
4. Soyutlanmış Temel öğeler belirli bir bağlamdan ayrılır ve bir çekirdek çerçeve oluşturur.
5. Modüler Ortak elemanlar mantıksal olarak yeniden kullanılabilir parçalara bölünür.
6. İsteğe bağlı parametreler aracılığıyla temel öğeler için Yapılandırılabilir Özelleştirmeler mevcuttur.
7. Ölçeklenebilir Kod kolayca genişletilebilir ve gelecekte geliştirmeleri öngörür.
8. Belgelenmiş Tüm öğeler, başkalarının kullanması ve genişletmesi için açıklanmıştır.
9. Doğru Nihai çıktı, amaçlanan tasarımın uygun bir temsilidir.
   

Takip etmeyi ve her ilkenin bir projeye nasıl uygulandığını görmeyi kolaylaştırmak için, bu makalenin temeli olarak projelerimden birinden bir tasarım maketi kullanacağız. Mevcut bir e-ticaret web sitesinde günlük fırsatları tanıtan özel bir açılış sayfasıdır. Bazı stiller mevcut web sitesinden devralınacak olsa da, bu öğelerin çoğunun yepyeni olduğunu belirtmek önemlidir. Amacımız bu statik görüntüyü alıp bu ilkeleri kullanarak HTML ve CSS'ye dönüştürmektir.

1. Yapılandırılmış

Belge, stillerle veya stiller olmadan anlamsal ve mantıksal olarak yazılır.

Buradaki ilke, belgemizin içeriğinin (HTML) sunum stilleri (CSS) olmadan da anlam ifade etmesidir. Elbette bu, düzgün sıralanmış başlık düzeyleri ve sırasız listeler kullandığımız anlamına gelir - ama aynı zamanda <header> ve <article> gibi anlamlı kaplar da kullanırız. ARIA etiketleri, alt nitelikler ve erişilebilirlik için ihtiyaç duyabileceğimiz diğer şeyleri kullanmayı atlamamalıyız.

Önemli bir şey gibi görünmeyebilir, ancak görsel olarak aynı olsalar bile bağlantı etiketi veya düğme kullanmanız önemli çünkü bunlar farklı anlamlar iletmekte ve farklı etkileşimler sağlamaktadır. Semantik işaretleme, bu anlamı arama motorlarına ve yardımcı teknolojilere iletir ve hatta çalışmalarımızı diğer cihazlarda yeniden amaçlandırmayı kolaylaştırır. Projelerimizi geleceğe daha dayanıklı hale getirir.

İyi yapılandırılmış bir belge oluşturmak, anlamsal HTML yazmayı öğrenmek, W3C standartlarını ve hatta diğer uzmanların en iyi uygulamalarını tanımak ve kodunuzu erişilebilir kılmak için zaman ayırmak anlamına gelir. En basit test, HTML'nize stili olmayan bir tarayıcıda bakmaktır:

• CSS olmadan kullanılabilir mi?
• Hâlâ görünür bir hiyerarşisi var mı?
• Ham HTML kendi başına anlam ifade ediyor mu?

Yapılandırılmış bir belge sağlamak için yapabileceğiniz en iyi şeylerden biri HTML ile başlamaktır. Görsel stiller hakkında düşünmeden önce, belgenin nasıl yapılandırılması gerektiğine ve her bir parçanın ne anlama geldiğine ilişkin düz HTML'yi yazın. div 'lerden kaçının ve uygun bir sarma etiketinin ne olacağını düşünün. Sadece bu temel adım, uygun bir yapı oluşturmanıza yardımcı olmak için uzun bir yol kat edecektir.

 <section> <header> <h2>Daily Deals</h2> <strong>Sort</strong> <span class="caret"></span> <ul> <li><a href="#">by ending time</a></li> <li><a href="#">by price</a></li> <li><a href="#">by popularity</a></li> </ul> <hr /> </header> <ul> <li aria-labelledby="prod7364536"> <a href="#"> <img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" /> <small>Ends in 9:42:57</small> <h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3> <strong>$199.99</strong> <small>List $299</small> <span class="callout">10 Left</span> </a> </li> </ul> </section>

Yalnızca HTML ile başlamak ve her öğenin anlamını düşünmek, daha yapılandırılmış bir belgeyle sonuçlanır. Yukarıda, tüm işaretlemeyi tek bir div kullanmadan oluşturduğumu görebilirsiniz.

2. Verimli

Tasarıma ulaşmak için en az miktarda işaretleme ve varlık kullanılır.

Kısa olduğundan ve gereksiz biçimlendirme veya stiller içermediğinden emin olmak için kodumuzu düşünmeliyiz. Sağa hizalanmış blok düzeyinde bir öğe elde etmek için çerçeveye özgü sınıf adlarını kullanarak div s içinde div s içinde div s olan kodu gözden geçirmem benim için yaygın. Çoğu zaman, HTML'nin aşırı kullanımı, CSS'yi veya altta yatan çerçeveyi anlamamanın sonucudur.

İşaretleme ve CSS'ye ek olarak simgeler, web yazı tipleri ve resimler gibi başka harici varlıklara da ihtiyacımız olabilir. Özel simge yazı tiplerinden base64 yerleştirmelerine ve harici SVG'lere kadar bu varlıkları uygulamanın en iyi yolları hakkında birçok harika yöntem ve görüş vardır. Her proje farklıdır, ancak bir düğmedeki tek bir simge için 500 piksellik bir PNG'niz varsa, verimlilik konusunda kasıtlı olmama ihtimaliniz vardır.

Bir projeyi verimlilik açısından değerlendirirken sorulması gereken iki önemli soru vardır:

• Aynı şeyi daha az kodla başarabilir miyim?
• En küçük ek yükü elde etmek için varlıkları optimize etmenin en iyi yolu nedir?

Uygulamadaki verimlilik aynı zamanda aşağıdaki standardizasyon ve modülerlik ilkeleriyle de örtüşür, çünkü verimli olmanın bir yolu tasarımları belirlenmiş standartları kullanarak uygulamak ve onları yeniden kullanılabilir hale getirmektir. Modüler bir standart oluştururken, ortak bir kutu gölgesi için bir karışım oluşturmak verimlidir.

3. Standartlaştırılmış

Ortak değerler için kurallar serbestçe saklanır ve kullanılır.

Bir web sitesi veya uygulama için standartlar oluşturmak, genellikle her bir başlık düzeyinin boyutu, ortak bir oluk genişliği ve her bir düğme türü için stil gibi şeyleri yöneten kuralların oluşturulmasıyla ilgilidir. Düz CSS'de, bu kuralları harici bir stil kılavuzunda tutmanız ve bunları doğru bir şekilde uygulamayı hatırlamanız gerekir, ancak bunları değişkenlerde ve karışımlarda saklayabilmeniz için LESS veya Sass gibi bir ön işlemci kullanmak en iyisidir. Buradaki ana paket, piksel mükemmel tasarımlar yerine standartlara değer vermektir .

Bu nedenle, başka bir yerde kullandığımız 15 piksel yerine 22 piksellik bir oluk genişliğine sahip bir tasarım maketi aldığımda, böyle bir hassasiyetin buna değmediğini varsayacağım ve bunun yerine standart 15 piksellik oluk kullanacağım. . Bir adım daha ileri gidildiğinde, elemanlar arasındaki tüm boşluklar bu standardı katlar halinde kullanacaktır. Ekstra geniş alan, sabit kodlanmış bir değer yerine $gutter-width * 2 (30 piksele eşittir) olacaktır. Bu şekilde, tüm uygulama tutarlı ve uyumlu bir his verir.

 .product-cards { li { display: inline-block; padding: @gutter-width/4; color: @text-color; text-decoration: none; background-color: @color-white; .border; margin-bottom: @gutter-width/2; margin-right: @gutter-width/2; } } .product-status { font-size: @font-size-small; color: @grey-darker; font-weight: @font-weight-bold; margin-bottom: @gutter-width/4; }

LESS değişkenlerinden veya karışımlarından türetilen standartlaştırılmış değerler kullandığımız için, CSS'mizin kendi sayısal değerleri yoktur. Her şey merkezi bir değerden miras alınır.

Standardizasyonu kontrol etmek için CSS'yi inceleyin ve herhangi bir sabit kodlanmış birimi arayın: pikseller, HEX renkleri, ems veya hemen hemen herhangi bir sayısal değer.

• Bu birimler mevcut bir standart değer veya değişken kullanmalı mı?
• Birim, yeni bir değişkenden yararlanacak şekilde yeniden kullanılıyor mu? Belki bunun kısmen opak bir arka plan uyguladığınız ikinci sefer olduğunu fark etmişsinizdir ve her ikisinde de aynı opaklığa ihtiyaç vardır.
• Birim, mevcut bir değişkenin hesaplanmasından türetilebilir mi? Bu, renk varyasyonları için yararlıdır - örneğin, standart bir renk kullanmak ve elde edilen HEX değerini sabit kodlamak yerine %10 daha koyu bir şey elde etmek için üzerinde bir hesaplama yapmak.

Mümkün olduğunca sık standart değerler kullanıyorum ve yalnızca istisna olarak yenilerini oluşturuyorum. Kendinizi burada 5 piksel ve burada 1 piksel olan bir öğeyi ayarlarken bulursanız, standartlarınız tehlikeye girmiş olabilir.

Tecrübelerime göre, önceden işlenmiş CSS'nin çoğunluğu merkezi değişkenler ve karışımlar kullanmalı ve bireysel bileşenlerde neredeyse hiç sayısal, piksel veya HEX değeri görmemelisiniz. Bazen, tek bir bileşenin konumunu ayarlamak için birkaç piksel eklemek uygun olabilir - ancak bu durumlar bile nadir olmalı ve standartlarınızı iki kez kontrol etmenize neden olmalıdır.

4. Soyutlanmış

Temel öğeler belirli bir bağlamdan ayrılır ve bir çekirdek çerçeve oluşturur.

Başlangıçta bu ilkeye "çerçeveli" adını verdim çünkü şu anda üzerinde çalıştığınız belirli bir projeyi yaratmanın yanı sıra, orijinal bağlamın ötesinde kullanılabilecek bir tasarım sistemi üzerinde de çalışıyor olmalısınız. Bu ilke, tüm proje boyunca veya gelecekteki projelerde kullanılması gereken daha büyük ortak unsurları belirlemekle ilgilidir. Bu, tipografi ve form alanı girdileri kadar geniş başlar ve farklı navigasyon tasarımlarına kadar uzanır. Bunu şu şekilde düşünün: CSS'niz Bootstrap veya Foundation gibi bir çerçeve olarak açık kaynaklı olacak olsaydı, tasarım öğelerini nasıl ayırırdınız? Onları farklı şekilde nasıl şekillendirirsiniz? Halihazırda Bootstrap kullanıyor olsanız bile, projenizin Bootstrap'in sağlamadığı temel öğeler içermesi ve bunların da projenizin tasarım sisteminde bulunması gerekir.

Buradaki anahtar, her bir öğeyi projenizin özel bağlamından ziyade daha genel terimlerle düşünmektir. Belirli bir öğeye baktığınızda, onu parçalara ayırın ve şu anda üzerinde çalıştığınız belirli uygulamadan bağımsız olarak her parçaya o öğenin sahip olacağı genel stiller verin. En yaygın öğeler tipografi (başlık stilleri, satır yüksekliği, boyutlar ve yazı tipleri), form öğeleri ve düğmelerdir. Ancak, açıklama etiketi veya Günlük Fırsatlarımız için tasarlanmış olabilecek ancak başka yerlerde de yararlı olabilecek herhangi bir özel fiyat biçimlendirmesi gibi diğer öğeler de "çerçeveli" olmalıdır.

Projenizi soyutlama için kontrol ederken şunu sorun:

• Farklı ihtiyaçlarla başka bir bağlamda yeniden kullanılacağını bilseydim, bu öğeyi nasıl oluştururdum?
• Tüm uygulama boyunca değerli olabilecek parçalara nasıl ayırabilirim?

Her öğenin daha genel bir uygulamasını düşünmek anahtardır. Bu parçalar tamamen ayrı ve bağımsız sınıflar olarak veya daha iyisi, son CSS ile derlenebilen ayrı LESS veya Sass dosyaları olarak saklanmalıdır.

Bu ilke, bir web bileşeninde veya modül uygulaması mimarisinde daha kolaydır çünkü widget'lar muhtemelen bu şekilde zaten ayrılmıştır. Ancak düşüncemiz üzerinde başka herhangi bir şey kadar çok etkisi vardır. Esnek bir şey yarattığımızdan emin olmak için çalışmamızı her zaman türetildiği bağlamdan soyutlamalıyız .

5. Modüler

Ortak öğeler mantıksal olarak yeniden kullanılabilir parçalara bölünür.

“Soyut” ilkesiyle örtüşen tasarımlarımızı modüler hale getirmek, çalışması ve bakımı kolay bir somut tasarım sistemi oluşturmanın önemli bir parçasıdır. İkisi arasında ince bir çizgi vardır, ancak fark prensipte önemlidir. Buradaki nüans, küresel temel öğelerin bağlamlarından soyutlanması gerekirken, bağlamdaki bireysel öğelerin de yeniden kullanılabilir olması ve bağımsız stilleri sürdürmesi gerektiğidir. Modüller, uygulamamıza özel olabilir ve tüm çerçevede ihtiyaç duyduğumuz bir şey olmayabilir - ancak yine de, o modülü her kullandığımızda kodu çoğaltmamamız için yeniden kullanılabilir olmaları gerekir.

Örneğin, bir Günlük Fırsatlar açılış sayfası için önceki örnekteki ürün kartı listesini uyguluyorsanız, HTML ve CSS'yi Daily Deals'e özel yapmak yerine, Daily daily-deal-product gibi sınıf adlarıyla bunun yerine daha genel bir Tüm soyutlanmış sınıfları içeren product-cards sınıfı, Günlük Fırsatlar sayfasının dışında da yeniden kullanılabilir. Bu muhtemelen bileşeninizin stillerini aldığı üç ayrı yerle sonuçlanacaktır:

• temel CSS . Bu, tipografi, oluklar, renkler ve daha fazlası için varsayılan değerler de dahil olmak üzere temel çerçevedir.
• CSS bileşenleri . Bunlar, genel tasarımın yapı taşlarını oluşturan, ancak herhangi bir bağlamda kullanılabilen tasarımın soyutlanmış parçalarıdır.
• ana bileşenler . Bunlar, Günlük Fırsatlara özel stiller veya özelleştirmeler içeren daily-deal bileşenidir (ve tüm alt öğelerdir). Birçokları için bu gerçek bir JavaScript web bileşeni olacaktır, ancak tasarımın tamamını oluşturmak için gerekli HTML'yi içeren bir üst şablon olabilir.

Tabii ki, bunu çok ileri götürebilirsin, bu yüzden muhakeme yapman gerekecek. Ancak çoğunlukla, oluşturduğunuz her şey, uzun vadeli bakımı fazla karmaşık hale getirmeden, mümkün olduğunca yeniden kullanılabilir olmalıdır.

6. Yapılandırılabilir

İsteğe bağlı parametreler aracılığıyla temel öğelerde özelleştirmeler yapılabilir.

Bir tasarım sistemi oluşturmanın bir kısmı, projenin şimdi veya gelecekte ihtiyaç duyabileceği seçenekleri düşünmekle ilgilidir. Tasarımı sadece öngörüldüğü şekilde uygulamak yeterli değildir. Ayrıca hangi parçaların isteğe bağlı olabileceğini, farklı bir konfigürasyonla açılıp kapatılabileceğini de düşünmeliyiz.

Örneğin, tasarımımızdaki belirtme çizgisi bayrakları, tümü solu işaret eden yalnızca üç renk varyasyonu gösterir. Üç ayrı sınıf oluşturmak yerine, varsayılan bir sınıf oluşturacağız ve isteğe bağlı parametreler olarak ek sınıf adları ekleyeceğiz. Bunun ötesinde, birinin gelip bayrağı farklı bir bağlam için doğru yönlendirmek isteyebileceğini düşünüyorum. Aslında, bu belirtme çizgileri için varsayılan marka renklerimizi kullanmak, tasarım özellikle bunu gerektirmese de yararlıdır. Seçenekler olarak hem sol hem de sağ dahil olmak üzere, bunu hesaba katmak için CSS'yi özel olarak yazardık.

Belirli bir tasarım öğesini düşünürken değerli olabilecek seçenekleri de düşünün. Bunu anlamanın önemli bir parçası, bu öğenin yeniden kullanılabileceği diğer bağlamlar hakkında eleştirel düşünmektir.

• Hangi parçalar harici bir değişken aracılığıyla yapılandırılabilir, isteğe bağlı veya etkinleştirilebilir?
• Elemanın renginin veya konumunun değişebilmesi değerli olur mu?
• Küçük, orta ve büyük bedenler sağlamak faydalı olur mu?

CSS'nizi düzenlemek ve adlandırma kuralları oluşturmak için BEM, OOCSS veya SMACSS gibi bir metodoloji kullanmak bu kararları vermenize yardımcı olabilir. Bu kullanım durumları üzerinde çalışmak, yapılandırılabilir bir tasarım sistemi oluşturmanın büyük bir parçasıdır.

7. Ölçeklenebilir

Kod kolayca genişletilebilir ve gelecekte geliştirmeleri öngörür.

“Yapılandırılabilir” ilkesiyle aynı ruhla, uygulamamız da gelecekte değişiklikler beklemelidir. İsteğe bağlı parametreler oluşturmak faydalı olsa da, projemizin ihtiyaç duyacağı her şeyi tahmin edemeyiz. Bu nedenle, yazdığımız kodun gelecekteki değişiklikleri nasıl etkileyeceğini düşünmek ve geliştirmesi kolay olacak şekilde kasıtlı olarak düzenlemek önemlidir.

Ölçeklenebilir CSS oluşturmak, genellikle karışımlar ve işlevler yazmak için LESS ve Sass'ın daha gelişmiş özelliklerini kullanmamı gerektirir. Renkler dışında tüm çağrı bayraklarımız aynı olduğundan, her varyasyon için kodu çoğaltmaya gerek kalmadan her çağrı için CSS oluşturacak tek bir LESS karışımı oluşturabiliriz. Kod ölçeklenecek şekilde tasarlanmıştır ve tek bir yerde güncellenmesi kolaydır.

 @angle: 170; .callout { &.qty-left { .callout-generator(@color-deals, @color-white, @angle); } &.qty-sold { .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals); } &.qty-out { .callout-generator(@color-grey, darken(@color-grey, 10%), @angle); } }

Bilgileri ölçeklenebilir hale getirmek için, arka plan rengi, metin rengi, noktanın açısı ve kenarlık gibi şeyler için değerleri kabul eden .callout-generator adında DAHA AZ bir karışım oluşturacağız.

 .review-flag { .callout-generator(@color-brand, @color-white, 75); }

Gelecekte, yeni bir gereksinim benzer bir tasarım deseni gerektirdiğinde, yeni bir stil oluşturmak kolay olacaktır.

Ölçeklenebilir bir tasarım sistemi oluşturmak için projelerde yaygın olan değişiklikleri tahmin etmeyi öğrenin ve yazdığınız kodun bu değişikliklere hazır olduğundan emin olmak için bu anlayışı uygulayın. Yaygın çözümler, değişkenleri ve karışımları kullanmanın yanı sıra değerleri dizilerde depolamayı ve bunlar arasında döngü oluşturmayı içerir. Kendine sor:

• Bu unsurların hangi kısımlarının değişmesi muhtemeldir?
• Gelecekte bu değişiklikleri kolayca yapabilmek için kodu nasıl yazabilirsiniz?

8. Belgelenmiş

Tüm öğeler, başkalarının kullanması ve genişletmesi için açıklanmıştır.

Tasarımın belgelenmesine gereken değer verilmemektedir ve genellikle bir projede kesilecek ilk köşedir. Ancak işinizin bir kaydını oluşturmak, bir sonraki kişinin ne amaçladığınızı anlamasına yardımcı olmaktan daha fazlasıdır - aslında tüm paydaşlarınızı tüm tasarım sistemine dahil etmenin harika bir yoludur, böylece her seferinde tekerleği yeniden icat etmemiş olursunuz. . Belgeleriniz, geliştiricilerden yöneticilere kadar ekipteki herkes için bir referans olmalıdır.

Çalışmanızı belgelemenin en iyi yolu, doğrudan kodunuzdaki yorumlardan oluşturulan canlı bir stil kılavuzu oluşturmaktır. DocumentCSS ile birlikte stil rehberli geliştirme adı verilen bir yaklaşım kullanıyoruz. Ancak projenizin canlı stil kılavuzu olmasa bile, manuel olarak HTML'de veya hatta baskı formatlı bir PDF'de bir tane oluşturmak sorun değil. Hatırlanması gereken ilke, yaptığımız her şeyin belgelenmesi gerektiğidir .

Tasarım sisteminizi belgelemek için, başka birinin tasarımın nasıl uygulandığını ve onu yeniden oluşturmak için ne yapmaları gerektiğini anlamasına yardımcı olacak talimatlar yazın. Bu bilgi, bir öğenin arkasındaki özel tasarım düşüncesini, kod örneklerini veya eylem halindeki öğenin bir demosunu içerebilir.

• Kodumu nasıl kullanacağını başka birine nasıl söylerim?
• Yeni bir ekip üyesine katılsaydım, onu nasıl kullanacaklarını bildiklerinden emin olmak için ne açıklardım?
• Kullanılabileceği tüm yolları göstermek için her bir widget'ın hangi varyasyonlarını gösterebilirim?

9. Doğru

Nihai çıktı, amaçlanan tasarımın uygun bir temsilidir.

Son olarak, yarattığımız şeyin yansıtmayı amaçladığı orijinal tasarım konsepti kadar harika görünmesi gerektiğini de unutmamalıyız. Görsel çekicilik beklentilerini karşılamayan hiç kimse bir tasarım sistemini takdir etmeyecektir. Sonucun yalnızca tasarımın uygun bir temsili olabileceğini ve piksel mükemmelliği olmayacağını vurgulamak önemlidir. "Mükemmel piksel" tabirinden hoşlanmıyorum çünkü bir uygulamanın tam olarak maket gibi, piksel piksel olması gerektiğini önermek, herhangi bir kısıtlamayı unutmak ve standardizasyonun değerini düşürmektir (her tarayıcının CSS'yi biraz oluşturduğunu boşverin) farklı). Duyarlı uygulamalar için statik tasarımların nadiren olası her cihaz boyutunu hesaba katması, doğruluğu karmaşık hale getirir. Mesele şu ki, belirli bir derecede esneklik gerekli.

Projeniz için ne kadar uygun bir temsil gerektiğine karar vermeniz gerekecek, ancak bunun birlikte çalıştığınız kişilerin beklentilerini karşıladığından emin olun. Projelerimizde, aynı sayfada olduğumuzdan emin olmak için müşteriyle piksel mükemmelliğinden büyük sapmaları gözden geçireceğim. "Tasarımlar, kenarlıklı varsayılan mavi düğme stilini gösteriyor, ancak standart düğme rengimiz biraz farklı ve kenarlığı yok, bu yüzden bunun yerine bunu seçtik." Beklentileri belirlemek buradaki en önemli adımdır.

Bir Düşünme Sistemi

Bu dokuz ilkenin amacı, tasarımın HTML ve CSS'de uygulanması için bir kılavuz sağlamaktır. Harika tasarım ve harika kod arasındaki en iyi dengeyi optimize edebilmeniz için işiniz hakkında düşünmenin bir yolu olduğu kadar bir dizi kural veya kuralcı tavsiye değildir. Bu ilkeleri uygularken kendinize bir miktar esneklik vermeniz önemlidir. Her seferinde her biri ile mükemmelliğe ulaşamayacaksınız. Onlar ideallerdir. Her zaman işimizi en iyi şekilde yapmamızı engelleyen başka dikkat dağıtıcı unsurlar, ilkeler ve öncelikler vardır. Yine de prensipler her zaman için çabalamanız, sürekli kendinizi kontrol etmeniz ve tasarımınızı çizim tahtasından deneyimleneceği son ortama taşırken agresif bir şekilde takip etmeniz gereken bir şey olmalıdır. Umarım daha iyi ürünler yaratmanıza ve uzun yıllar dayanacak tasarım sistemleri oluşturmanıza yardımcı olurlar.

Tasarım uygulama deneyiminiz hakkında sizden haber almayı çok isterim. Bir yorum gönderin ve kendi işinizde kullanabileceğiniz herhangi bir tavsiye veya diğer ilkeleri paylaşın.