Cihazlar Arası Devamlılık Nerede Kopar

Telefonda başlayan bir işi masaüstünde bitirebilmek, ürün sayfalarında en çok vaat edilen, uygulamada en çok yarım kalan şeylerden biri. Vaat kolay çünkü arayüz tarafında görünmez: bir ekranda “kaldığınız yerden devam edin” yazar, gerisi arkada halledilir sanılır. Gerisi halledilmediğinde de kullanıcı bunu bir hata olarak değil, kendi suçu olarak yaşar.

Önce kimlik, sonra devamlılık

Devamlılığın ön koşulu, iki cihazdaki kişinin aynı kişi olduğunu bilmek. Bunun tek güvenilir yolu oturum açmış bir hesap. Giriş yapmamış kullanıcıda elinizde çerez ve cihaz parmak izi kalır, ikisi de cihazı tanımlar, kişiyi değil.

Buradan pratik bir sonuç çıkar: devamlılık özelliğini giriş duvarının arkasına koymadan tasarlarsanız, özellik kullanıcıların bir kısmında hiç çalışmaz ve hangi kısmında çalışmadığını da bilemezsiniz. Doğru sıralama şu: önce giriş akışını, devamlılığın değeri görünür olduğu anda (işin yarısında, tamamlanmamış bir sepette, yarım bırakılmış bir formda) teklif edin. Girişi ilk ekrana koymak dönüşümü düşürür, hiç koymamak özelliği anlamsız kılar.

Durumu nereye yazıyorsunuz

Kullanıcının bıraktığı yer bir veri. Bu veriyi ya istemcide tutarsınız (localStorage, IndexedDB) ve bir yerde eşitlersiniz, ya doğrudan sunucuda tutarsınız ve her cihaz oradan okur.

Sunucu tarafında tutulan durumu, istemcide tutup eşitleyen kurgudan belirgin biçimde daha güvenilir buluyorum. Sebebi tek bir senaryoda görünür: kullanıcı telefonda uçak modundayken formu değiştirir, aynı gün masaüstünde de değiştirir, sonra telefon internete bağlanır. İstemci eşitlemesinde son yazan kazanır ve masaüstündeki değişiklik sessizce kaybolur. Kullanıcı kaybolduğunu fark ettiğinde, kaybın nerede olduğunu size anlatamaz.

Sunucuda tutmanın bedeli var: her durum değişikliği bir istek demek, çevrimdışıyken yazma kuyruğu tutmanız gerekir, ve kayıt başına sürüm bilgisi saklamadan çakışmayı yine çözemezsiniz. Ama bu bedelin tamamı sizin tarafınızda kalır. Diğer kurguda bedeli kullanıcı, veri kaybı olarak öder.

Çakışmayı kullanıcıya sormanın sınırı

“Hangi sürümü tutalım?” diye sormak ilk bakışta dürüst bir çözüm gibi durur. İki kısa metin arasında seçim yaptırıyorsanız işe yarar. Uzun bir taslağın iki sürümünü yan yana koyup seçtirmek ise kullanıcıyı, kendi yazdığı iki metni satır satır karşılaştırmak zorunda bırakır. Bu noktada alan bazında birleştirme, sormaktan daha iyi sonuç verir: aynı alan iki yerde değişmediyse çakışma zaten yoktur.

Kişiselleştirme ile servis değiştirebilme birbirini yer

Ağ merkezli mimariyi anlatan metinlerin çoğu iki şeyi aynı anda vaat eder: biriken kullanıcı verisiyle derinleşen kişiselleştirme, ve açık standartlar sayesinde aynı işi yapan servisler arasında özgürce geçiş.

Bu ikisi aynı yöne çalışmaz. Kişiselleştirmenin kalitesi biriken geçmişe bağlıysa, servisi değiştirmek o geçmişi sıfırlamak demektir; yani kişiselleştirme iyileştikçe geçiş maliyeti büyür. Kullanıcı açısından bu, teknik bir kilit değil, deneyim kilidi: taşınma teknik olarak mümkündür ama taşındığında ürün ilk günkü haline döner.

Tasarım tarafında yapılabilecek şey, kişiselleştirmenin dayandığı veriyi kullanıcıya görünür ve dışa aktarılabilir kılmak. Tercihlerini bir ekranda görebilen ve indirebilen kullanıcı, geçiş yaptığında sıfırdan başlamaz. Bunu bir rekabet dezavantajı saymak yaygın, katılmıyorum: dışa aktarım yolu açık olan üründe kullanıcı, veri biriktirmeye daha istekli oluyor.

Ölçüm: oturum cihaza bağlıdır

Devamlılığın çalışıp çalışmadığını standart oturum analitiğiyle ölçemezsiniz, çünkü oturum tanımı cihaz ve tarayıcı düzeyinde kurulur. Telefonda başlayıp masaüstünde biten bir iş, giriş yapılmadıysa iki farklı kullanıcının iki yarım oturumu olarak görünür. Tabloda bu, iki terk edilmiş akış gibi okunur; oysa iş tamamlanmıştır.

Ölçmek için kullanıcı kimliğine bağlı ve cihaz bilgisini taşıyan bir olay akışı gerekir. Bakılacak sayı da basit: aynı kullanıcı kimliğinde başlangıç olayı bir cihazda, tamamlama olayı başka bir cihazda gerçekleşen akışların oranı. Bu oran düşükse önce özelliğin bulunabilirliğine bakın, sonra kimlik tarafına. Çoğu vakada sorun eşitlemede değil, kullanıcının böyle bir imkânın varlığından haberi olmamasında çıkıyor.