← Günlüğe dön

Tuvalin gizlemeye alışık olduğu yerleşim katmanı

0.8.0 önizlemesindeki bir topluluk yanıtı, ajan-yerel tasarımın arkasındaki asıl soruyu adlandırdı: tuval iş birimi olmaktan çıkarsa, kullanıcılar yerleşimi nasıl hâlâ anlayacak?

Tuvalin gizlemeye alışık olduğu yerleşim katmanı

Faydalı bir topluluk yanıtı, daha büyük bir buton istemez. Eksik katmanı adlandırır.

Open Design 0.8.0-preview tartışmasının altında olan tam da budur. Lansman başlığı iki kaymayı savundu: tuvali birincil iş birimi olarak görmeyi bırakmak ve ajanı birinci sınıf tasarım çalışanı yapmak. Bir yanıt yöne katıldı, sonra zor kısmı işaret etti: tuval kaybolduğunda, kullanıcılar onu güvenle düzenleyebilmeden önce ajanın ne yaptığını anlamak için hâlâ bir yola ihtiyaç duyar.

Yanıttaki ifade "Yerleşim Anlama Katmanı" idi. İyi bir isim, çünkü tembel cevabı reddediyor. Ajan-yerel tasarım, "ekran görüntüsüne güven" anlamına gelemez. Eserin okunabilir bir modeline ihtiyacı vardır: bölümler, niyet, düzenlenebilir parçalar, kararlı referanslar ve önerilen düzenleme hamleleri. Bu yazı, o yanıtı ciddiye alma denemesidir — böyle bir katmanın neyi taşıyabileceğini, Open Design'da nerede yaşaması gerektiğini ve neden bir yol haritası vaadi değil de bir katkı yolu olduğunu çizmek için.

Tuval, tasarımcılara mekânsal güven verdi

Figma'nın tuvali yalnızca bir çizim yüzeyi değildir. Aynı zamanda bir açıklama yüzeyidir. Uzaklaştırabilir, sayfa hiyerarşisini görebilir, bir çerçeveye tıklayabilir, kısıtlamaları inceleyebilir, katmanları yeniden adlandırabilir ve işin bir parçasının nerede bitip diğerinin nerede başladığını anlayabilirsiniz.

Tuval ortadan kalktığında gerçekte ne kaybedersiniz

O anlayışı, kaybolana kadar küçümsemek kolaydır. Üretilen bir açılış sayfası, korumalı bir önizlemede doğru görünebilir ama yine de yönlendirmesi zor olabilir. Sorun pikseller değil — insan ile ajan arasında ortak bir kelime dağarcığının yokluğudur.

"Hero'yu daha kendinden emin yap" yalnızca ajan ile insan hero'nun ne olduğu konusunda hemfikirse faydalıdır. "Fiyatlandırma bölümünü sıkılaştır" yalnızca eser revizyonlar arasında kararlı bir bölüm kimliği taşıyorsa işe yarar. Bu olmadan, her talimat işaret etmeye dönüşür: tasarımcı bir bölgeyi konumuyla tanımlar ("üstten ikinci blok"), ajan işlenen çıktıdan tahmin eder ve sonraki yeniden üretim her şeyi sessizce yeniden numaralandırır. Tuval bu maliyeti sessizce soğurmaya alışıktı. Parçaları sizin için adlandırdı, siz çalışırken o adları kararlı tuttu ve onu tanımlamadan birini seçmenize izin verdi.

Birim yanlış olsa bile bu netlik korumaya değer

Bu, #DeFigma argümanının dikkat gerektiren kısmı. Tuval, ajan-yerel bir sistem için yanlış iş birimi olabilir — dosya yazan bir ajanı değil, dikdörtgenleri sürükleyen bir insanı varsayar — ama insanların tuvalden aldığı netlik hâlâ değerlidir. Hata, "tuvali bırak" ile "tuvalin sağladığı anlayışı bırak"ı aynı karar olarak görmek olurdu. Değiller. Open Design, o netliği atmak yerine esir modeline taşımak zorundadır. Yerleşim katmanı, o taşımanın adıdır.

Open Design'da zaten doğru ilkel öğeler var

Bu önerinin Open Design'a uymasının nedeni, projenin zaten açık sözleşmeler etrafında kurulmuş olmasıdır. Bir beceri, bir SKILL.md dosyasıdır. Bir tasarım sistemi, bir DESIGN.md dosyasıdır. Bir eklenti, bir open-design.json yan dosyası ekler. Sistemde tersine mühendislik yapmanız gereken hiçbir ikili blob yoktur; sözleşmeler metindir ve metin, hem bir ajanın hem de bir insanın okuyabileceği bir şeydir. Mekanikler 31 beceri, 72 sistem: Open Design kütüphanesi nasıl çalışır yazısında ele alınır ve ürün argümanı Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik yazısındadır.

Yerleşim katmanı aynı örüntüyü izlemelidir. Ajanın okuyabileceği metin, arayüzün işleyebileceği durum ve başka bir ajanın yeniden kullanabileceği meta veri olmalıdır. Üçünü birden aynı anda karşılayamıyorsa, yanlış biçimdir.

Depo açısından bu, üç yüzeyi işaret eder:

YüzeyNeyi taşımalı
Eser bildirimiBölümler, bileşenler, varlıklar ve üretilen dosyalar için kararlı kimlikler
Eklenti anlık görüntüsüEseri hangi beceri, tasarım sistemi, girdiler ve işlem hattı aşamalarının ürettiği
Gözden geçirme arayüzü / başsız çıktıBir yerleşim haritası, düzenlenebilir yönler ve önerilen düzenleme niyetleri

Önemli kısıtlama: katman ikinci bir tescilli tuvale dönüşmemelidir. Kaçınılacak başarısızlık modu, Figma'nın sahne grafiğini yeni bir adla yeniden inşa etmektir — yalnızca Open Design arayüzünün işleyebileceği ve uygulamadan çıktığınız anda ölen, zengin, uygulamaya özgü bir yapı. Yerleşim katmanı bunun yerine, dosyalarla birlikte seyahat eden düz bir eser haritası olmalıdır, böylece bir katkıda bulunan onu bir metin düzenleyicide okuyabilir ve farklı bir ajan onu bir SDK olmadan tüketebilir.

Neredeyse beyaz bir editöryel zemin üzerinde, boş bir tuvalin üzerinde kendi seçilebilir katmanı olarak yükselen, yeşil bir çerçevedeki bir wireframe yerleşim iskeleti
Yerleşim katmanı, tuvalin örtük tuttuğu yapıdır — hem bir ajanın hem de bir insanın okuyabileceği yere çıkarılmış.

Yerleşim katmanı için pratik bir biçim

İşte ajan-yerel tasarımı daha az opak hissettirecek en küçük versiyon:

  1. Üretilen her eser kararlı anlamsal kimlikler alır: hero, proof-strip, pricing, faq, final-cta.
  2. Her kimlik bir niyet cümlesi taşır: "Ürün vaadini tek bir ekranda açıkla", "üst bölüm" değil.
  3. Her bölüm düzenlenebilir yönleri listeler: metin, yoğunluk, yerleşim, renk, medya, hareket, veri kaynağı.
  4. Üretilen her dosya, onu üreten bölüm kimliğine geri bağlanır.
  5. Her gözden geçirme turu önerilen düzenleme niyetleri yayar: "hero başlığını kısalt", "fiyatlandırma kartlarında kontrastı artır", "referans bloğunu böl".
  6. Arayüz bunu bir gezgin olarak işler, başsız kullanıcılar ise aynı yapıyı JSON veya Markdown olarak alır.

Bir bildirimin gerçekte nasıl görünebileceği

Bunu yazıya dökmenin amacı, yapının sıradan olmasıdır — ki bu da tam olarak onun özel bir numara yerine herkese açık bir sözleşme olabilmesinin nedenidir. Üretilen bir açılış sayfası için bir bildirim şöyle okunabilir:

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

Bu anahtarların hiçbiri egzotik değil. sections bir liste, editable bir enum, files bir geri referans. Değer şemanın zekiliğinde değil — değer, kimliklerin bir yeniden üretimde hayatta kalmasında; böylece aynı pricing bloğu, ajan onu iki kez yeniden yazdıktan sonra hâlâ pricing'tir.

Bu, bir tasarımcının "pricing'i üç plandan ikiye değiştir" demesine ve bir kod ajanının piksellerden tahmin etmeden doğru dosyaya yama yapmasına izin vermeye yeter. Talimat bir bölüm kimliğine çözümlenir, bölüm kimliği bir dizi dosyaya çözümlenir ve düzenleme amaçlanan yere düşer.

Bunun neden bir özellik isteği değil, bir katkı yolu olduğu

Ayrıca topluluğa temiz bir katkı yolu verir. Bir katkıda bulunanın burada yardımcı olmak için ürünü yeniden tasarlamasına gerek yoktur. Bir eser türü için bildirim yayan bir beceri, düzenleme niyetleri öneren bir gözden geçirme atomu, diğer becerilerin okuyabileceği bir alan ekleyen bir bildirim uzantısı veya bölüm kimliklerinin bir yeniden üretim boyunca kararlı kaldığını öne süren bir test durumu yazabilirler. Bunların her biri, bir çıktıyı daha az opak yapan küçük, birleştirilebilir bir değişikliktir — ve katman düz metin olduğu için, bir sunum ve bir mobil ekran üzerinde çalışan iki katkıda bulunanın paylaşılan bir ikili formatı koordine etmesine gerek yoktur. Yerleşim katmanı, uygulamanın içine gömülü özel bir yetenek değil, herkese açık bir sözleşme haline gelir.

Sırada ne yapılmalı

Üzerinde çalışmak istediğiniz türden bir problem buysa, bir eseri incelemeyi kolaylaştıran küçük bir beceri veya eklenti katkısında bulunun. Somut bir çıktıyla başlayın: bir açılış sayfası, bir sunum veya bir mobil ekran. Kararlı bölüm kimlikleri ekleyin, düzenlenebilir yönleri tanımlayın, bunları eserle birlikte JSON veya Markdown olarak yayın ve bir gözden geçirenin incelenebilir bir katmanın yarattığı farkı görebilmesi için öncesi/sonrası eseriyle PR'ı açın.

Bu hâlâ bir yön, gönderilmiş bir özellik değil — şimdi adlandırmanın değeri, ilkel öğelerin zaten var olması, böylece işin bir yeniden yazım değil, ek niteliğinde olmasıdır.

Bir beceri katkısında bulunun.

İlgili okumalar


← Günlüğe dön GitHub · Kaynak ↗