Kullanıcıların Anlayabileceği Çevrimdışı‑Öncelikli Mobil Uygulama Senkronizasyon Kuralları

Kullanıcıların çevrimdışıyken ne olacağını düşünme biçimi

Ç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:

• “Düzenlememi görebiliyorsam, kaydedilmiştir.”
• “Sinyal geri geldiğinde kendiliğinden yüklenecektir.”
• “Yaptığım hiçbir şey kaybolmamalı.”
• “Düzenlemem sessizce başkasının değişikliğiyle değiştirilmemeli.”

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.

Temel model: önce yerelde kaydet, sonra senkronize et

İ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.

Ne nerede kaydedilir

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.”

Kullanıcıların anlayabileceği durumlar

Uygulama hangi durumda olduğunu açıkça gösterdiğinde insanlar daha sakin hisseder. Çoğu durumu küçük bir durum setiyle kapsayabilirsiniz:

• Çevrimiçi (hemen senkronize edebilir)
• Çevrimdışı (bu cihazda kaydedildi)
• Yeniden bağlanıyor (çevrimiçi olmaya çalışıyor)
• Senkronize ediliyor (son değişiklikler gönderiliyor)
• Senkronize (her şey güncel)

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:

• “Telefonunuzda kaydedildi. Çevrimiçi olunca göndereceğiz.”
• “Değişiklikler senkronize ediliyor…”
• “Tüm değişiklikler senkronize edildi.”
• “Senkronize edilemedi. İncelemek için dokunun.”

Çatışmalar nereden gelir (ve neden insanları şaşırtır)

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:

• İki cihazda düzenleme yaparsınız (telefon ve tablet).
• İki kişi aynı paylaşılmış kaydı değiştirir.
• Bir cihaz uzun süre çevrimdışı kalır ve sonra “yetişir”.

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?

Üç çatışma deseni: son-yazan-kazanır, birleştir veya kullanıcıya sor

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.

1) Son-yazan-kazanır (LWW)

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.”

2) Birleştir (değişiklikleri kombine et)

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:

• “Senkronize edildi. Değişiklikleriniz başka bir cihazdaki güncellemelerle birleştirildi.”

Eğer bir şey birleştirilemediyse, ne olduğunu açıkça söyleyin:

• “Telefon numaranızı biz koruduk, diğer cihazın adresini koruduk.”

3) Kullanıcıya sor (önemli olduğunda)

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:

• Yanlış yapmanın maliyeti yüksekse, Sorma’yı tercih edin.
• Çatışmalar yaygın ama düşük riskliyse, LWW tercih edin.
• Kullanıcıların her iki değişikliğin de kalmasını beklemesi durumunda, Birleştirme tercih edin.
• Sonucun bir cümlede açıklanamayacağı durumlarda muhtemelen Sorma gerekir.
• Destek talepleri pahalı olacaksa, sessiz üzerine yazmalardan kaçının.

Son-yazan-kazanır: basit, hızlı ve yanlış anlaşılmaya açık

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.

“Son” gerçekte ne demek

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 ne zaman uygundur (ve ne zaman zarar verir)

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:

• “Hesabınızdaki en son sürüme güncellendi.”
• “Çevrimdışı düzenlemeniz başka bir cihazda yapılan daha yeni bir değişiklikle değiştirildi.”
• “Çevrimdışı kaydedildi. Çevrimiçi olduğunuzda senkronize edeceğiz.”
• “Senkronize edildi. Bu öğe artık en son güncellemeyle eşleşiyor.”
• “Senkronize olurken sorun yaşıyoruz. Değişiklikleriniz hâlâ bu cihazda.”

Kullanıcıların kabullenebileceği birleştirme stratejileri

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.

Alan düzeyinde birleştirme (tüm kaydı seçmekten daha iyi)

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:

• “Her iki güncellemeyi de kaydettik. Telefon numaranız ve adresiniz güncellendi.”

Eğer bir alan çatıştıysa, bunu açıkça belirtin:

• “İki farklı telefon numarasını birleştiremedik. En son olanı tuttuk. İsterseniz her zaman değiştirebilirsiniz.”

Yalnızca ekleme (açıklaması en kolay)

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ı:

• “Çevrimdışısınız. Yeni mesajlar çevrimiçi olduğunuzda gönderilecek.”

Listeler: eklemeler ve silmeler için öngörülebilir kurallar

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:

• “Mümkün olduğunda her iki değişiklik setini tuttuk. Bir öğe başka bir cihazda kaldırıldığı için o öğeye yaptığınız düzenleme uygulanmadı.”

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.

Kullanıcıya sormak: korkutmayan bir çatışma diyaloğu

Ç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.

Diyalogun ne göstermesi gerekir (ham veri olmadan)

Kullanıcıların hatırladığı şekilde sade bir dil kullanın:

• Çatışma hangi öğede oldu (profil, not, adres)
• Her iki tarafta ne değişti (basit kelimelerle)
• Kabaca zaman (“birkaç dakika önce”), zaman damgaları değil
• Seçtikten sonra ne olacağı

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ı.”

Yeniden kullanılabilir UX metinleri

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.

Adım adım: kuralları seçin, sonra ekranları ve metni tasarlayın

İ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.

Destek taleplerine yol açan yaygın hatalar

Ç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.

Hata 1: Eylem sunmayan belirsiz hatalar

“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.”

Hata 2: Gizli bekleyen değişiklikler

İ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.

Hata 3: Önemli verilerde sessiz otomatik çözümlemeler

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.”

Hata 4: Zaman ve tarihlerin garip görünmesi

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.”

Hata 5: Çevrimdışılığı hata gibi muamele etmek

Ç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.

Hızlı kontrol listesi: bir kullanıcı ne olacağını tahmin edebiliyor mu?

İ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:

• Çevrimdışı belirgin ve menüde gizli değil.
• Her düzenleme hemen yerel kaydı doğruluyor.
• Kullanıcılar senkronize edilmek üzere bekleyen değişiklikleri gözden geçirebiliyor.
• Senkron sonuçları açık (“Tüm değişiklikler senkronize edildi” vs “Dikkat gerekiyor”).
• Bir çatışma olursa, mesaj ne değiştiğini ve hangi kuralın kullanıldığını söylüyor.

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.

Örnek senaryo: çevrimdışıyken aynı profile iki düzenleme

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.

Farklı kurallarla nasıl oynar

• 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.

Sonraki adımlar: kurallarınızı yazın ve akışı prototipleyin

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.

• “Bu cihazda kaydedildi. Çevrimiçi olduğunuzda göndereceğiz.”
• “Çevrimdışıyken çalışma. Değişiklikleriniz çevrimiçi olunca gönderilecek.”
• “Senkronize ediliyor…”
• “Güncel.”
• “Senkronize edilemedi. Yeniden deneyeceğiz.”
• “Senkronizasyon durdu. Bağlantı bekleniyor.”
• “İki farklı düzenleme bulduk. Hangi sürümü tutmak istediğinizi seçin.”
• “Seçiminiz kaydedildi. Şimdi senkronize ediyoruz.”

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:

• Uçak modu adım adım: girişten düzenlemeye, yeniden bağlanmaya kadar.
• İlk cihaz çevrimdışıyken aynı öğeyi ikinci cihazda düzenleyin.
• Yeniden bağlanın ve neyin değiştiğine, neyin kaldığına ve kullanıcıya ne söylendiğine bakın.
• Bir “sorma” tetikleyen yüksek riskli alanı test edin.

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.