Kenar çubuğu ögesini tek tek anlatmak yerine, gerçek bir hesabı baştan sona sizinle gezelim. Diyelim ki bu, platformdaki ilk haftasında, küçük bir müşteri için bir alışkanlık takip uygulaması inşa eden bir serbest çalışan. İşte o build'in panoda ilerlerken başına gelenler, gerçekte gerçekleştiği sırayla — ve her durağın beş dakikanızı nerede kazandırdığı ya da nerede harcadığı.
İstem (prompt)
AI Builder'ı açarlar ve "bana bir alışkanlık takip uygulaması yap" gibi bir şey yazarlar. Bu makul bir ilk cümledir ama kötü bir nihai komuttur. Geri gelen kod değildir — sade bir dille yazılmış bir plandır ve "iyi görünüyor" noktasında okumayı bırakıp onaylarsanız, teknik olarak "alışkanlık takip uygulaması" kelimelerine karşılık gelen ama önemli olan her açıdan sıradan bir şey elde edersiniz. Serbest çalışanın müşterisi sosyal özellik istemiyordu, sadece yerel depolama istiyordu, varsayılan olarak karanlık mod istiyordu. Bunların hiçbiri ilk komutta yoktu. Bunun yerine plana, onaydan önce üç düzenleme olarak eklenir: planın kendiliğinden uydurduğu "seriyi paylaş" özelliğini sil, depolama satırını değiştir, varsayılan temayı çevir. Otuz saniyelik düzenleme. Sonunda ortaya çıkan yapı, sadece "alışkanlık takip uygulaması" kelimesiyle değil, brief'le eşleşir.
İnsanların atladığı plan adımı
Diğer kullanıcılarda tam olarak bu anın yanlış gittiğini gördüm — ilk planı okumadan onaylamak, üç iterasyon sonra sıkışıp kalmak ve plan aşamasında belirlenmesi gereken kısıtlamaları yeniden anlatmaya başlamak. Plan adımı tam olarak bunun olmaması için var. Neredeyse hiçbir maliyeti yoktur ve döngüde ajanla kendi dilinizde pazarlık ettiğiniz, kodundaki çıktısını hata ayıklamak yerine, tek noktadır.
Yapının gerçekte nereye ulaştığı
Oluşturulduğunda, alışkanlık takip uygulaması My Builds'da — türe göre filtrelenebilen kütüphane sayfasında — bir kart olarak belirir; üçüncü hafta beş altı yapı üst üste bindiğinde bu serbest çalışanın diğer sayfalardan daha sık açacağı sayfa budur. Showcase'de görünmez; o sayfa küratörlüdür, otomatik değildir ve orada tanıtılmadan duran bir müşteri yapısı doğru varsayılan davranıştır. Serbest çalışan onu şablon olarak kaydetmeyi düşünmedikçe Templates'de de görünmez — burada bunu yapmak gerçekten değerlidir, çünkü bir alışkanlık takip uygulaması iskeleti tam olarak serbest çalışanın bir sonraki müşteri için farklı markalamayla yeniden kuracağı türden bir şeydir. Çoğu insan "şablon olarak kaydet"i altıncı yapıya kadar keşfetmez, keşke birinci yapıda yapsaymışım diye düşünür.
Yayınlanmış, ya da daha ağır bir şey
Şimdi dağıtım sorusu. Üç isimli tek seçenek değil, üç gerçek seçenek var. Published ücretsiz bir alt alan adı verir, saniyeler içinde canlıya geçer, kurulum sıfırdır — müşteri hâlâ inceleme aşamasındayken ve yeniden tasarım isteyebilecekken doğru tercih budur. Domain Management, müşterinin kendi alan adı buna yönlendirilmeye hazır olduğunda kullanılır ve bu adım çifte görev görür: burada bir alan adı bağlamak sadece bir URL değişikliği değildir, aynı zamanda kenar çubuğunun aşağısındaki analiz sayfalarının bağlanacak bir şeyi olmasını da sağlar. Ayarlar altındaki Deploy ise, müşterinin yapının kendi kontrol ettiği altyapıda barınmasında ısrar ettiği durumlar için SFTP yoludur — daha fazla kurulum gerektirir ve serbest çalışan artık çalışma süresi konusunda hiçbir sorumluluk taşımaz; bu, kazara keşfedilmek yerine açıkça ele alınmaya değer gerçek bir değiş tokuştur.
Bu yapı için önce Published. Alt alan adından özel alan adına geçmek daha sonra sorunsuz bir işlemdir. İptal edilen bir müşteri projesinde özel alan adı dağıtımını geri almak, değeceğinden daha fazla temizlik gerektirir — ve serbest çalışan zaten daha önceki bir projede tam olarak bundan dolayı zor durumda kalmıştır, bu da "varsayılan olarak Published" alışkanlığının tüm nedenidir.
Uygulama mağazası sapması
Bu özel müşteri ayrıca bir uygulama mağazası listelemesi istedi, bu yüzden yapı Published'de durmak yerine Shipped'den geçer — bu sayfa, mağaza incelemesinin web dağıtımlarının aksine asenkron olması nedeniyle var. Bir mağazaya gönderin ve iki gün beklesin; başka bir mağazaya gönderin ve yirmi dakikada onaylansın. Shipped, her biri kendi girişi ve kendi durum terminolojisi olan beş farklı mağaza konsolunda beş tarayıcı sekmesi açmadan bunu takip edebileceğiniz yerdir.
Kimsenin uyarmadığı boş sayfa
Alan adı bağlandıktan bir hafta sonra, serbest çalışan durumu kontrol etmek için Search Performance'ı açar. Boş. Aslında biraz hüzünlü görünüyor — ne grafik ne sayı, sadece bir hesap bağlama isteği var. Bu bozuk değil, dürüst bir durum: henüz veri yok, çünkü Search Performance, Google Analytics ve Store Analytics hepsi ayarlar altındaki Google hesap bağlantısına dayanır ve hiçbiri geçmişe dönük veri doldurmaz. Senkronizasyon, bağlandığınız andan itibaren ileriye doğru çalışır. Alan adını ilk gün bağlarsanız ikinci haftada bir haftalık geçmişiniz olur; unuttuğunuz için onuncu günde bağlarsanız, onuncu günde sıfırdan başlarsınız. Serbest çalışan alan adını bağlamış ama Google hesabını bağlamamıştı — tek bir adım gibi görünmesi gereken ama aslında iki ayrı adım.
Burada asıl maliyeti olan şey eksik grafik değil. Optimizasyon ajanları da bu aynı veriyi okuyor ve arkasında hiç Arama Performansı geçmişi olmayan bir sayfanın sıralamasını iyileştirmesi istenen bir ajan, sitenin gerçek verilerinden değil genel en iyi uygulamalardan yola çıkmak zorunda kalıyor. Bağlantıyı atlamak sadece bir gösterge paneli sayfasını boş bırakmıyor — ajanların yapabileceklerini de sınırlıyor.
Sorulmadan ortaya çıkan brief
İki hafta sonra Discovery'de bir kart beliriyor: müşterinin sitesindeki bir içerik boşluğunu işaret eden bir fırsat brief'i, yanında bir Build-this düğmesi ile. Zaten yapmayı düşündüğünüz bir şeye denk geldiğinde gerçekten faydalı. Ancak Discovery, tasarım gereği hassasiyetten çok hacme yatkın — kimsenin harekete geçmeyeceğinden daha fazla brief üretiyor — bu yüzden doğru yaklaşım, temizlenmesi gereken bir kuyruk değil, bir öneri kutusu olmalı. Serbest çalışan bunu birkaç günde bir göz atıp çoğunu görmezden geliyor, bu da amaçlanan kullanım, geride kalmak değil.
İlk günden yapılması gereken ayarlar
Bu noktaya gelindiğinde serbest çalışan, ayarlar menüsünü kasıtlı olarak hiç açmadan dört ayrı ayarlar sayfasına dokunmuş oldu — her biri başka bir şeyin boş çıkması sayesinde keşfedildi.
| Sayfa | Aslında neyin kapısını tutuyormuş |
|---|---|
| Google Hesapları | Arama Performansı, Google Analytics ve ajanların temellendirme verileri — tek bir bağlantı, üç yüzey |
| Dağıt | SFTP hedefleri, yalnızca müşteri tarafından kontrol edilen sunucu yolunda gerekli |
| AI medya | Build'ler içinde kullanılan görsel oluşturma varsayılanları |
| Planlar ve Krediler | Kullanım hakkı, kredi paketleri, makbuzlar |
Google Hesapları önden halledilmesi en değerli olanı. Üç ayrı gösterge paneli yüzeyinin arkasında tek bir bağlantı noktası ve bunu zor yoldan öğrenmek — üç farklı boş sayfa, üç farklı "ah, bir şey bağlamam gerekiyormuş" anı — ilk günden yapılacak beş dakikalık bir kurulumla önlenebilecek tam da o sürtünme.
Baştan beri orada duran iki şey
Kayan Ask-AI düğmesi bu sayfaların her birinde baştan beri duruyordu ve bu sınırlı kapsamlı bir SSS botu değil — sizin adınıza bir hesap bağlayabilir, bir build başlatabilir ya da bir sayfanın neden boş olduğunu açıklayabilir. Serbest çalışanın İngilizce bilmeyen müşterisi, bir inceleme görüşmesi için arayüzün tamamen farklı bir dilde olmasını istedi; navigasyondaki küre yirmi dilin tamamına, oturum ortasında, devam eden build'i kaybetmeden geçiş yapıyor. Bu ikisinin de, bu rehberdeki her şeyin aksine, deneme yanılmayla keşfedilmesi gerekmiyordu. Zaten oradaydılar.
Bu hesabın ilk iki haftasının dürüst özeti tam olarak bu — "önce dokümanları oku, sonra inşa et" değil, tam tersi. My Builds, içinde bir kart olana kadar bir soyutlamaydı. Arama Performansı, bir alan adı beslemeden önce boş bir durumdu. Kat planını ilk build'den önce okumak zararsız bir ön bilgi, ama kat planı ancak içinde gerçek bir alışkanlık takipçisi oturduğunda anlam kazanıyor.
