Tarayıcıda Çalışan Görsel Üretici

Tasarım programında elle hazırlanan kartları şablona indirgeyen; fotoğrafları kırpıp yerleştiren, metni kutuya otomatik sığdıran, telefonda çalışan üretim aracı.

3Kart tipi
YokSunucu
TarayıcıÇalıştığı yer
JavaScriptCanvas APIFileReaderOtomatik Metin SığdırmaSunucusuz Mimari
1Fotoğraf SeçimiTelefondan çoklu seçim, önizleme2Otomatik KırpmaHer görsel kendi kutusuna oranı bozulmadan oturur3Metin YerleşimiYazı kutuya sığana kadar punto küçültülür4KompozisyonIzgara, kurdele ve başlık tek tuvalde birleşir5İndirme1080×1350 PNG olarak cihaza inerBeş adım, hepsi kullanıcının cihazında

Çözülen Problem

Bir işletme için yaptığım içerik performans analizinde şu ortaya çıkmıştı: satışı getiren içerikler, tasarım programında elle hazırlanan kartlardı. Ama tam da bu kartlar en çok vakit alan işti, dolayısıyla en az üretilendi.

Yani darboğaz fikir değil, üretim hızıydı. Aynı düzen her seferinde sıfırdan kuruluyordu: altı fotoğrafı yerleştir, çerçeveyi ayarla, başlığı ortala, dışa aktar. Her kart için on beş dakika, her gönderi için beş kart.

Bu, otomasyona uygunluk ölçütlerinin dördünü de karşılıyordu: tekrar eden, tahmin edilebilir, girdisi dijital ve hata maliyeti geri alınabilir.

Neden Sunucusuz

Bu araç bir web servisi olarak da yazılabilirdi: fotoğraflar sunucuya yüklenir, görsel orada üretilir, kullanıcıya indirilirdi. Yapılmadı, çünkü:

  • Fotoğraflar cihazdan çıkmıyor. Kişisel tatil fotoğraflarını bir sunucuya yüklemek gereksiz bir mahremiyet riski. Tüm işlem tarayıcıda yapılınca bu risk tamamen ortadan kalkıyor.
  • Sürekli maliyet yok. Sunucu demek aylık ödeme, bakım ve bir gün kapanma ihtimali demek. Statik bir dosyanın böyle bir yükü yok.
  • Telefonda çalışıyor. İçerik üretimi telefonda yapılıyor; araç da orada çalışmalıydı. Kurulum, giriş ve hesap gerektirmiyor.

Otomasyonda en sık yapılan hatalardan biri, işi gereğinden ağır bir altyapıya taşımaktır. Doğru soru şudur: bu iş kullanıcının cihazında yapılabilir mi? Cevap evetse, sunucu eklemek sadece kırılacak bir parça daha demektir.

Teknik Kararlar

1. Fotoğraf kırpma

Kullanıcının seçtiği fotoğraflar farklı oranlarda geliyor: kimi dikey, kimi yatay. Bunları kareye zorla sığdırmak görüntüyü eziyor. Araç bunun yerine örtme yöntemi kullanıyor: görsel oranı korunarak kutuyu tamamen dolduracak kadar büyütülüyor, taşan kısım kırpılıyor ve merkeze hizalanıyor.

2. Metnin kutuya sığması

Şehir adı "Roma" da olabilir "Rothenburg ob der Tauber" da. Sabit punto kullanılsa uzun isimler taşardı. Araç metni ölçüp kutuya sığana kadar puntoyu kademeli düşürüyor; ayrıca kullanıcıya genel bir yazı boyutu ayarı bırakılıyor.

Aynı mantık liste kartlarında da çalışıyor: satır sayısı arttıkça hem yazı hem madde işaretleri satır yüksekliğine göre küçülüyor, böylece sekiz maddelik bir liste de üç maddelik kadar düzenli duruyor.

3. Panoya kopyalama ve indirme

Üretilen görsel doğrudan cihaza iniyor. Metin kopyalama tarafında modern pano arayüzü kullanılıyor; desteklenmediği durumlar için eski yönteme düşen bir yedek yol bırakıldı — çünkü mobil tarayıcıların davranışı tek biçimli değil.

Şablonun Sınırı

Araç üç kart tipi üretiyor: kapak, gün gün içerik ve kapanış. Daha fazlası eklenebilirdi ama eklenmedi.

Sebebi şu: şablon çoğaldıkça kullanıcı hangi şablonu seçeceğine karar vermek zorunda kalır ve kazanılan zaman bu kararla geri gider. Üç tip, bir gönderinin tamamını kurmaya yetiyor; fazlası hız kazandırmıyor, seçim yorgunluğu yaratıyor.

Aynı sebeple renk teması altı seçenekle sınırlı tutuldu. Serbest renk seçici koymak teknik olarak daha kolaydı, ama sonuçların bir kısmı okunmaz kombinasyonlar olurdu. Hazır paletler, kötü sonucu baştan imkânsız kılıyor.

Diğer projeler