Kullanıcıların anlayacağı çevrimdışı-öncelikli mobil uygulama senkron kuralları: net çatışma desenleri, basit durum mesajları ve çevrimdışında kafa karıştırmayı azaltan metinler.
Çoğu insan ağları düşünmez. Önlerinde duran görevi düşünürler. Eğer hâlâ yazabiliyor, Kaydet'e dokunabiliyor veya ekranda değişikliği görebiliyorlarsa, bunun başarılı olduğunu varsayarlar.
Beklentileri genellikle birkaç kurala indirgenir:
Bunların altında iki korku yatar: kaybolan işler ve sürpriz değişiklikler.
Kaybolan işler, uygulama onlara devam etme izni verdiği için ihanet gibi gelir. Sürpriz değişiklikler daha da kötü hissettirebilir çünkü uygulama sonradan “fikir değiştirmiş” gibi görünür.
Bu yüzden "senkronlandı"yı açık kelimelerle tanımlamanız gerekir. Senkronlandı demek “telefonumda görebiliyorum” demek değildir. Senkronlandı demek “bu değişiklik sunucuya yüklendi ve kabul edildi, diğer cihazlara da ulaşacak” demektir. Arayüzünüz insanların hangi durumda olduklarını anlamalarına yardım etmelidir.
Yaygın bir başarısızlık örneği: birisi metrodayken teslimat adresini düzenler, ekranda güncellendiğini görür ve uygulamayı kapatır. Daha sonra evde açtığında eski adres geri gelmiştir. Sistem mantıklı bir şey yapmış olsa bile kullanıcı bunu veri kaybı olarak deneyimler.
Öngörülebilir kurallar ve net mesajlar bunun çoğunu önler. “Bu cihazda kaydedildi” ile “Hesabınıza senkronlandı” gibi kısa durum satırları çok işe yarar.
İyi bir çevrimdışı-öncelikli yaklaşım tek bir basit vaazla başlar: Kaydet'e dokunduğunuzda, internet olmasa bile çalışmanız şu an güvende.
Kullanıcı bir şeyi düzenlediğinde, uygulama önce cihazda kaydetmelidir. Kullanıcının hemen görmeyi bekleyeceği versiyon bu olmalıdır.
Ayrı olarak, uygulama bu değişikliği mümkün olduğunda sunucuya göndermeye çalışır. Telefon çevrimdışıysa, bu düzenlemeler “kaybolmuş” veya “yarım kaydedilmiş” değildir. Sadece gönderilmek için bekliyorlardır.
Arayüzde “kuyrukta” veya “bekleyen yazılar” gibi teknik kelimelerden kaçının. Düz bir dil tercih edin: “Çevrimiçi olduğunuzda değişikliklerinizi göndereceğiz.”
Uygulama hangi durumda olduğunu açıkça gösterdiğinde insanlar daha sakin hisseder. Çoğu durumu küçük bir durum setiyle kapsayabilirsiniz:
Sonra uygulama gerçekten kullanıcı olmadan tamamlayamazsa bir özel durum ekleyin: Dikkat gerekiyor.
Basit bir görsel sistem iyi çalışır: küçük bir simge ve ilgili işlemin yakınında kısa bir metin satırı (örneğin düzenleme ekranının altında).
Örnek metin:
Bir senkronizasyon çatışması, aynı şey üzerinde iki düzenleme sunucu ile karşılaştırma yapılmadan önce gerçekleştiğinde ortaya çıkar.
Çatışmalar genellikle normal davranıştan kaynaklanır:
Kullanıcıları şaşırtan nokta, yanlış bir şey yapmamış olmalarıdır. Düzenlemelerinin yerelde başarılı olduğunu gördükleri için bunun kesin olduğunu varsayarlar. Uygulama daha sonra senkronize olduğunda sunucu bunu reddedebilir, beklenmedik şekilde birleştirebilir veya başkasının sürümüyle değiştirebilir.
Tüm veriler aynı riski taşımaz. Bazı değişiklikler kolayca uzlaştırılabilir (beğeniler, okunma durumları, önbelleğe alınmış filtreler). Diğerleri yüksek risklidir (teslimat adresleri, fiyatlar, stok sayımları, ödemeler).
En büyük güvensizlik yaratan durum sessiz üzerine yazmadır: uygulama kullanıcının çevrimdışı değişikliğini sessizce daha yeni bir sunucu değeriyle (veya tersini) değiştirir ve bunu bildirmez. İnsanlar daha sonra, genellikle iş önem kazandığında fark eder ve destek talepleri başlar.
Kurallarınızın bir şeyi öngörülebilir kılması gerekir: değişiklikleri kazanacak mı, birleştirilecek mi yoksa bir seçim mi gerekecek?
Uygulama çevrimdışı değişiklikleri kaydettiğinde, aynı öğe başka bir yerde değiştirilmişse sonunda ne yapılacağına karar vermesi gerekir. Amaç mükemmellik değil. Amaç kullanıcıların tahmin edebileceği bir davranıştır.
Son-yazan-kazanır demek, en son düzenlemenin nihai versiyon olacağı anlamına gelir. Hızlı ve basittir, fakat başkasının işini üzerine yazabilir.
Bunu yanlış yapmanın ucuz ve kolay düzeltilebildiği durumlarda kullanın; örneğin okunma durumu, sıralama düzeni veya “son görüntülenen” zaman damgaları. LWW kullanıyorsanız, takasları saklamayın. Açık bir metin yardımcı olur: “Bu cihazda güncellendi. Daha yeni bir güncelleme varsa bu sürüm yerine geçebilir.”
Birleştirme, uygulamanın her iki değişiklik kümesini de korumaya çalışması demektir. Bu, öğelere ekleme yapmak, mesaj eklemek veya profilin farklı alanlarını düzenlemek gibi değişikliklerin üst üste gelmesini bekledikleri durumlarda uygundur.
Başarıyla birleştirdiğinizde sakin ve belirli bir mesaj kullanın:
Eğer bir şey birleştirilemediyse, ne olduğunu açıkça söyleyin:
Sorma, otomatik kararın gerçek zarar verebileceği durumlarda (ödemeler, izinler, tıbbi bilgi veya yasal metin gibi) başvurulacak yoldur.
Pratik bir kural:
Son-yazan-kazanır (LWW) mantıklı görünür: aynı alan iki yerde düzenlendiğinde en yeni düzenleme doğru kabul edilir. Karışıklık, “en yeni”nin gerçekte ne anlama geldiğiyle ortaya çıkar.
Tek bir zaman kaynağına ihtiyaç vardır; yoksa LWW hızla karışır.
En güvenli seçenek sunucu zamanı: sunucu her değişikliği aldığında bir “güncellendi” atar ve sonra en yeni sunucu zaman damgası kazanır. Cihaz saatine güvenirseniz, yanlış saati olan bir telefon doğru veriyi üstüne yazabilir.
Sunucu zamanı olsa bile, LWW insanları şaşırtabilir çünkü “sunucuya ulaşan en son değişiklik” onların yaptığı “en son değişiklik” gibi hissetmeyebilir. Yavaş bağlantı geliş sırasını değiştirebilir.
LWW, üzerine yazmanın kabul edilebilir olduğu veya sadece son değerin önemli olduğu alanlarda en iyi çalışır: çevrimiçi/çevrimdışı durum bayrakları, oturum ayarları (sessize alma, sıralama) ve benzeri düşük riskli alanlar.
LWW’nin zarar verdiği yerler ise anlamlı, dikkatle düzenlenen içeriklerdir: profil bilgileri, adresler, fiyatlandırma, uzun metinler veya kullanıcıların “kayboldu” diye hissedeceği herhangi bir şey. Bir sessiz üzerine yazma veri kaybı gibi algılanabilir.
Kafa karışıklığını azaltmak için sonucu görünür ve suçlayıcı olmayan bir dille gösterin:
Birleştirme, insanların sonucu yardım almadan tahmin edebildiği durumlarda en iyi çalışır. En basit yaklaşım: güvenli olanı birleştir, sadece birleştirilemeyen durumlarda kullanıcıyı kesintiye uğrat.
Tüm profil için tek bir sürüm seçmek yerine alan alan birleştirin. Bir cihaz telefon numarasını değiştirmiş, diğeri adresi değiştirmişse, her ikisini de tutun. Bu, kullanıcıların alakasız düzenlemeleri kaybetmemesi nedeniyle adil hissettirir.
Başarılı olduğunda yardımcı metin:
Eğer bir alan çatıştıysa, bunu açıkça belirtin:
Bazı veri türleri doğası gereği ekleyicidir: yorumlar, sohbet mesajları, etkinlik günlükleri, makbuzlar. İki cihaz çevrimdışı eklemeler yaptığında genellikle hepsini tutabilirsiniz. Bu, üzerine yazma olmadığından en az kafa karıştıran desenlerden biridir.
Açık durum mesajı:
Bir cihaz bir öğeyi silerken diğeri onu düzenlediyse listeler karışıklaşır. Basit bir kural seçin ve bunu açıkça söyleyin.
Yaygın bir yaklaşım: eklemeler her zaman senkronize olur, düzenlemeler öğe silinmedikçe senkronize olur ve silmeler düzenlemelere karşı kazanır (çünkü öğe artık yoktur).
Kafa karıştırmayı önleyen çatışma metni:
Bu seçimleri sade dille belgelerseniz, insanlar tahmin etmeyi bırakır. Destek talepleri düşer çünkü uygulamanın davranışı ekranda gösterilen mesajlarla eşleşir.
Çoğu çatışma bir diyaloğa ihtiyaç duymaz. Sadece uygulama güvenli bir kazanan seçemiyorsa (örneğin iki kişi aynı alanı farklı şekillerde değiştirdiyse) kullanıcıya sorun.
Kesinti sadece bir net anda olmalı: senkronizasyondan hemen sonra çatışma tespit edildiğinde. Eğer diyaloğu kullanıcı yazarken açarsanız, uygulama onların işini bozuyormuş gibi hissedilir.
Seçimleri mümkün olduğunca iki butona indirgeyin. “Benimkini koru” vs “Onlarınkini kullan” genellikle yeterlidir.
Kullanıcıların hatırladığı şekilde sade bir dil kullanın:
Teknik bir diff yerine farkı küçük bir hikaye gibi anlatın: “Telefon numarasını 555-0142 olarak değiştirdiniz. Başka biri bunu 555-0199 yaptı.”
Diyalog başlığı:
İki farklı sürüm bulduk
Diyalog gövde örneği:
Bu telefon çevrimdışıyken profiliniz düzenlendi ve başka bir cihazda da güncellendi.
Bu telefon: Telefon numarası (555) 0142 olarak ayarlandı Diğer güncelleme: Telefon numarası (555) 0199 olarak ayarlandı
Butonlar:
Benimkini koru
Onlarınkini kullan
Seçtikten sonra onay:
Kaydedildi. Seçiminizi şimdi senkronize edeceğiz.
Biraz ekstra güven vermek isterseniz, butonların altına sakin bir satır ekleyin:
Bunu daha sonra Profil’den yine değiştirebilirsiniz.
İlk önce kullanıcıların bağlantı olmadan neleri yapmasına izin verileceğini kararlaştırın. Her şeyi çevrimdışı düzenlemesine izin verirseniz, daha sonra daha fazla çatışmayı kabul etmiş olursunuz.
Basit bir başlangıç: taslaklar ve notlar düzenlenebilir; hesap ayarları sınırlamalarla düzenlenebilir; hassas işlemler (ödemeler, parola değişiklikleri) çevrimiçi olana kadar salt görüntüleme olsun.
Sonra her veri türü için bir çatışma kuralı seçin, tüm uygulama için tek bir kural değil. Notlar genelde birleştirilebilir. Profil alanı genelde birleştirilemez. Ödemeler hiçbir şekilde çatışma olmamalı. Burada kuralları sade cümlelerle tanımlarsınız.
Ardından kullanıcıların karşılaşacağı görünür durumları eşleyin. Ekranlar arasında tutarlı tutun ki insanlar ne anlama geldiğini tekrar tekrar öğrenmek zorunda kalmasın. Kullanıcıya yönelik metinlerde “Bu cihazda kaydedildi” ve “Senkronizasyon bekleniyor” gibi ifadeleri dahili terimler yerine tercih edin.
Metni bir arkadaşınıza açıklıyormuş gibi yazın. “Çatışma” kelimesini kullanıyorsanız hemen açıklayın: “telefonunuz sunucu ile eşleştiremeden önce iki farklı düzenleme yapıldı.”
Söz konusu metinleri teknik olmayan kullanıcılarla test edin. Her ekrandan sonra bir soru sorun: “Bir sonraki adımda ne olacağını düşünüyorsun?” Yanlış tahmin ediyorlarsa, metin görevini yapmıyor demektir.
Son olarak, hataların kalıcı olmaması için bir çıkış yolu ekleyin: son düzenlemeler için geri al, önemli kayıtlar için sürüm geçmişi veya geri yükleme noktaları. Koder.ai gibi platformlar kenarda snapshot ve geri alma özellikleri kullanır: uç durumlar olduğunda kurtarma güven verir.
Çoğu senkronizasyon destek talebi tek bir kök sorundan gelir: uygulama ne olduğunu biliyordur ama kullanıcı bilmiyordur. Durumu görünür kılın ve sonraki adımı belirgin yapın.
“Senkronizasyon başarısız” çıkıp kullanıcıya hiçbir yol göstermezse çıkmaz sokaktır. Ne olduğunu ve kullanıcının ne yapabileceğini söyleyin.
Daha iyi: “Şu anda senkronize edilemedi. Değişiklikleriniz bu cihazda kaydedildi. Çevrimiçi olduğunuzda tekrar deneyeceğiz.” Eğer bir seçenek varsa, sunun: “Tekrar dene” ve “Senkronize edilmeyi bekleyen değişiklikleri gözden geçir.”
İnsanlar gönderilmemiş güncellemelerini göremezse işin kaybolduğunu varsayarlar. Yerelde depolananları doğrulayabilecekleri bir yer verin.
Basit bir yaklaşım: “Senkronize edilmeyi bekleyen 3 değişiklik” gibi küçük bir durum satırı ve öğe adlarıyla kısa bir liste açan bir yol.
Otomatik çözümlemeler düşük riskli alanlar için uygun olabilir, ancak anlamlı bir şeyi (adresler, fiyatlar, onaylar) iz bırakmadan üzerine yazmak öfke yaratır.
En azından etkinlik geçmişinde bir not bırakın: “Bu cihazın en son sürümünü tuttuk” veya “Değişiklikleri birleştirdik.” Daha iyisi: yeniden bağlantı sonrası bir kez gösterilecek bir bant: “Senkronizasyon sırasında 1 öğe güncellendi. Gözden geçir.”
Kullanıcılar adaleti zamana göre değerlendirir. “Son güncelleme” sunucu zamanı veya farklı bir zaman dilimi kullanıyorsa, uygulama arkadan bir şeyler değiştirmiş gibi görünebilir.
Zamanları kullanıcının yerel zaman diliminde gösterin ve daha kullanıcı dostu ifadeler kullanmayı düşünün: “5 dakika önce güncellendi.”
Çevrimdışı olmak normaldir. Günlük kopmalarda kırmızı ve korkutucu durumlardan kaçının. Sakin bir dil kullanın: “Çevrimdışıyken çalışma” ve “Bu cihazda kaydedildi.”
Birisi trende profili düzenleyip daha sonra Wi‑Fi’da eski veriyi görse bile eğer uygulama açıkça “Yerelde kaydedildi, çevrimiçi olunca senkronize edilecek” ve sonra “Senkronize edildi” veya “Dikkat gerekiyor” gösteriyorsa genellikle destek istemezler. Eğer sadece “Senkronizasyon başarısız” görünüyorsa, yardım isterler.
İnsanlar senkron davranışınızı tahmin edemiyorsa uygulamaya güvenmeyi bırakırlar.
Çevrimdışı durumu farkedilir kılın. Başlıkta küçük bir rozet genellikle yeterli olur, ama önemli olduğunda (uçak modu, sinyal yok, sunucu ulaşılamaz) görünmesi gerekir ve çevrimiçi olunca hızlıca kaybolmalıdır.
Sonra Kaydet'e dokunduktan sonraki anı kontrol edin. Kullanıcı yerel olarak güvende olduğunu hemen görmelidir, senkron gerçekleşmese bile. “Bu cihazda kaydedildi” panik ve tekrar tekrar dokunmayı azaltır.
Akışı kontrol etmek için kısa bir liste:
Ayrıca kurtarmayı normal hissettirin. Eğer son-yazan-kazanır bir şeyi üzerine yazdıysa “Geri al” veya “Önceki sürümü geri yükle” sunun. Bunu yapamıyorsanız, açık bir sonraki adım verin: “Çevrimiçi olduğunuzda tekrar deneyin” ve destekle iletişim kurmanın açık bir yolu.
Basit bir test: bir arkadaşınıza çevrimdışı olmalarını, bir alanı düzenlemelerini ve sonra başka bir cihazda aynı alanı tekrar düzenlemeyi söyleyin. Eğer ne olacağını tahmin edebiliyorlarsa, kurallarınız işe yarıyor demektir.
Maya trende, sinyal yokken profilini açıp teslimat adresini şu şekilde değiştirir:
“12 Oak St, Apt 4B” -> “12 Oak St, Apt 4C”.
Ekranın üstünde şu görünür: “Çevrimdışısınız. Değişiklikleriniz çevrimiçi olunca senkronize edilecek.” Kaydet'e dokunur ve ilerler.
Aynı anda partneri Alex evde çevrimiçi, aynı hesabın adresini “14 Pine St” olarak düzenler ve hemen senkronize olur.
Maya sinyal alır almaz şunu görür: “Tekrar çevrimiçi. Değişiklikleriniz senkronize ediliyor…” Sonra bir bildirim: “Senkronize edildi.” Sonraki adım sizin çatışma kuralınıza bağlıdır.
Son-yazan-kazanır: Maya’nın düzenlemesi daha sonra yapıldığı için adres “12 Oak St, Apt 4C” olur. Alex değişikliğinin kaybolduğunu görüp şaşırır. Daha iyi bir takip mesajı: “Senkronize edildi. Sürümünüz başka bir cihazdaki daha yeni bir güncellemenin yerine geçti.”
Alan düzeyinde birleştirme: Alex sokağı, Maya apartman numarasını değiştirdiyse, bunları birleştirebilirsiniz: “14 Pine St, Apt 4C”. Bildirim şöyle olabilir: “Senkronize edildi. Başka bir cihazdaki değişikliklerle birleştirildi.”
Kullanıcıya sor: Eğer her ikisi de aynı alanı (sokak satırını) değiştirdiyse sakin bir istem gösterin:
“Teslimat adresine iki farklı güncelleme bulundu”
“Başka bir cihazdan değişiklikler bulduk. Hiçbir şey kaybolmadı. Hangi sürümü tutmak istediğinizi seçin.”
Butonlar: “Benimkini tut” ve “Diğer güncellemeyi kullan”.
Kullanıcının öğrendiği şey basit: senkronizasyon öngörülebilirdir ve çakışma olursa hiçbir şey kaybolmadı — seçim yapabilirler.
Tahmin edilebilir çevrimdışı davranış istiyorsanız, önce kurallarınızı sade cümlelerle yazın. Yararlı bir varsayılan: düşük riskli alanlar için birleştirme (notlar, etiketler, açıklamalar), yüksek riskli veriler için sorma (ödemeler, stok sayımları, yasal metin).
Bu kuralları küçük bir metin setine dönüştürün ve her yerde tekrar kullanın. Sözcükleri tutarlı tutun ki kullanıcı bir kez öğrensin.
Tam özelliği inşa etmeden önce ekranları ve metni prototipleyin. Tüm hikâyeyi görmek istersiniz: çevrimdışıyken düzenleme, yeniden bağlanma, senkronizasyon ve çatışma durumunda ne oluyor.
Hafif bir test planı çoğu karışıklığı yakalar:
Eğer Koder.ai kullanıyorsanız, planlama modu çevrimdışı durumları haritalamanıza ve tam mesajları tasarlamanıza, ardından bir Flutter prototipi üreterek akışı doğrulamanıza yardımcı olabilir.
Default to: save locally first, then sync later.
When the user taps Save, confirm immediately with copy like “Saved on this device.” Then, separately, sync to the server when a connection is available.
Because seeing an edit on screen only proves it’s stored on that device right now.
“Synced” should mean: the change was uploaded, accepted by the server, and will appear on other devices too.
Keep it small and consistent:
Pair one icon with one short status line near the action that mattered.
Use plain language and say what’s safe:
Avoid technical terms like “queued writes” or “pending mutations.”
A conflict happens when two different edits hit the same item before the app can sync and compare with the server.
Common causes:
Use last-write-wins only for low-stakes values where overwriting is cheap, like:
Avoid it for addresses, prices, long text, approvals, and anything users would feel as “lost work.”
Prefer server time.
If devices decide “latest” using their own clocks, a wrong device time can overwrite correct data. With server time, “last” becomes “last received and accepted by the server,” which is at least consistent.
Use merge when users expect both changes to survive:
If a specific field can’t be merged, say exactly what you kept and why in one sentence.
Ask only when being wrong is expensive (money, permissions, legal/medical info).
Keep the dialog simple:
Make waiting changes visible.
Practical options:
Also add recovery when possible (undo, version history, snapshots/rollback) so mistakes aren’t permanent—tools like Koder.ai use snapshots and rollback for this reason.
