অফলাইন-প্রথম মোবাইল অ্যাপের সিঙ্ক নিয়মগুলো যাতে ব্যবহারকারী সহজে বুঝতে পারে: নির্দিষ্ট কনফ্লিক্ট প্যাটার্ন, সরল স্ট্যাটাস মেসেজ, এবং বিভ্রান্তি কমানোর কপি।
অধিকাংশ মানুষ নেটওয়ার্কের কথা ভাবেন না। তারা সামনে থাকা কাজটার কথা ভাবে। যদি তারা এখনও টাইপ করতে পারে, Save চাপতে পারে, বা স্ক্রিনে পরিবর্তন দেখতে পায়, তারা ধরে নেয় যে সেটা সফল হয়েছে।
তাদের প্রত্যাশাগুলো সাধারণত কয়েকটি নিয়মে বদলে যায়:
এর নীচে দুইটি ভয় কাজ করে: কাজ হারানো এবং অপ্রত্যাশিত পরিবর্তন।
কাজ হারানো বিশ্বাসঘাতকতার মতো লাগে কারণ অ্যাপ তাদের কাজ চালিয়ে যেতে দিয়েছে। অপ্রত্যাশিত পরিবর্তন আরও খারাপ মনে হতে পারে কারণ অ্যাপ পরে যেন "মনের পরিবর্তন" করেছে।
এই কারণেই আপনাকে “synced” শব্দটির অর্থ সরল ভাষায় নির্ধারণ করতে হবে। Synced মানে শুধু “আমি এটা ফোনে দেখতে পাচ্ছি” নয়। এর মানে হচ্ছে “এই পরিবর্তনটি সার্ভারে আপলোড হয়ে গ্রহণ করা হয়েছে, এবং অন্যান্য ডিভাইসগুলোতেও প্রদর্শিত হবে।” আপনার UI-কে ব্যবহারকারীকে বোঝাতে হবে তারা কোন অবস্থায় আছে।
একটি সাধারণ ব্যর্থতার উদাহরণ: কেউ সাবওয়েতে তাদের শিপিং ঠিকানা সম্পাদনা করে, আপডেট দেখে এবং অ্যাপ বন্ধ করে। পরে বাড়িতে খুললে পুরোনো ঠিকানা ফিরে আসে। সিস্টেম যৌক্তিক কিছু করলেও, ব্যবহারকারীর অভিজ্ঞতা ডেটা হারানো মনে হয়।
নির্দেশযোগ্য নিয়মগুলো এবং পরিষ্কার বার্তা এইসবের বড় অংশ প্রতিরোধ করে। সংক্ষিপ্ত স্ট্যাটাস লাইন যেমন “Saved on this device” বনাম “Synced to your account” অনেক কাজ করে।
একটি ভালো অফলাইন-প্রথম ধরন একটি সহজ প্রতিশ্রুতি দিয়ে শুরু করে: আপনি যখন Save চাপেন, আপনার কাজ ঠিক তখনই সুরক্ষিত—ইন্টারনেট ছাড়াইও।
যখন কোনো ব্যবহারকারী কিছু এডিট করে, অ্যাপটা প্রথমে ডিভাইসে সেটি সেভ করা উচিত। সেটিই তারা সাথে সাথে দেখতে পাবে।
অপরদিকে, অ্যাপটি যখন সম্ভব হবে তখন সেই পরিবর্তন সার্ভারে পাঠানোর চেষ্টা করবে। যদি ফোন অফলাইনে থাকে, সেই এডিটগুলো “হারায়নি” বা “আधा সেভ” হয়নি। এগুলো কেবল পাঠানোর জন্য অপেক্ষা করছে।
UI-তে "queued" বা "pending writes" মতো প্রযুক্তিগত শব্দগুলো থেকে বিরত থাকুন। সাধারণ ভাষা ব্যবহার করুন: “আপনি অনলাইনে ফিরলে আমরা আপনার পরিবর্তন পাঠিয়ে দেব।”
মানুষ শান্ত বোধ করে যখন অ্যাপ স্পষ্টভাবে তাদের অবস্থান দেখায়। বেশিরভাগ পরিস্থিতি আপনি কয়েকটি স্টেট দিয়ে ঢেকতে পারেন:
তারপর একটি বিশেষ অবস্থা যোগ করুন যখন অ্যাপ সত্যিই ব্যবহারকারীর সিদ্ধান্ত ছাড়া শেষ করতে পারে না: Needs attention।
একটি সহজ ভিজুয়াল ব্যবস্থা ভাল কাজ করে: একটি ছোট আইকন এবং নির্দিষ্ট কাজ সংলগ্ন একটি সংক্ষিপ্ত স্ট্যাটাস লাইন (যেমন, এডিট স্ক্রিনের নীচে)।
উদাহরণ কপি:
সিঙ্ক কনফ্লিক্ট হয় যখন একই জিনিসের ওপর দুইটি এডিট হয় সার্ভারের সঙ্গে তুলনা করার আগে।
কনফ্লিক্ট সাধারণত স্বাভাবিক আচরণ থেকে আসে:
মানুষকে বিভ্রান্ত করে যে তারা কিছু ভুল করেনি। তাদের লোকালি এডিট সফল হয়েছে বলে তারা ধরে নেয় এটি চূড়ান্ত। পরে যখন অ্যাপ সিঙ্ক করে, সার্ভার সেটি প্রত্যাখ্যান করতে পারে, অনাকাঙ্খিতভাবে মিলিয়ে দিতে পারে, বা কাউরো সংস্করণ দ্বারা প্রতিস্থাপন করতে পারে।
সব ডেটার ঝুঁকি একই নয়। কিছু পরিবর্তন সহজে মিলানো যায় (লাইক, পড়া/অপঠিত, ক্যাশ করা ফিল্টার)। অন্যগুলো উচ্চ ঝুঁকির—শিপিং ঠিকানা, মূল্য, ইনভেন্টরি, পেমেন্ট।
সবচেয়ে বড় ট্রাস্ট-ভেঙে দেয়া হলো ম্লানভাবে ওভাররাইট হওয়া: অ্যাপ চুপচাপ ব্যবহারকারীর অফলাইন পরিবর্তনকে সার্ভারের নতুন মান দ্বারা বদলে দেয়। মানুষ পরে বিষয়ে লক্ষ্য করে, এবং সমর্থন টিকিট আসে।
আপনার নিয়মগুলোর একটাই পূর্বানুমানযোগ্য করা উচিত: তাদের পরিবর্তন জিতবে, মিলিত হবে, নাকি ব্যবহারকারীর সিদ্ধান্ত চাইবে?
অ্যাপ যখন অফলাইনে পরিবর্তন সেভ করে, এটি শেষে সিদ্ধান্ত নিতে হবে একই আইটেম অন্য কোথাও পরিবর্তিত হলে কী করা হবে। লক্ষ্য পরফেকশন নয়—দৃশ্যত ব্যবহারকারীরা যা আশা করবে তা নিশ্চিত করা।
Last-write-wins মানে সর্বশেষ সম্পাদনাই চূড়ান্ত সংস্করণ হবে। এটি দ্রুত এবং সহজ, কিন্তু কাউরো কাজ ওভাররাইট করতে পারে।
এটি ব্যবহার করুন যেখানে ভুল হওয়া সস্তা এবং সহজে ঠিক করা যায়, যেমন পড়া/অপঠিত অবস্থা, সাজানোর অর্ডার, বা “last viewed” টাইমস্ট্যাম্প। LWW ব্যবহার করলে ট্রেডঅফ লুকিয়ে রাখবেন না। স্পষ্ট কপি দিন: “Updated on this device. If a newer update exists, it may replace this one.”
Merge মানে অ্যাপ দুই সেট পরিবর্তনই রাখার চেষ্টা করে মিলিয়ে দিয়ে। এটি ভাল ফিট যেখানে মানুষ আশা করে পরিবর্তনগুলো জমা হবে, যেমন তালিকায় আইটেম যোগ করা, বার্তা যোগ করা, বা প্রোফাইলের বিভিন্ন ফিল্ড সম্পাদনা।
সফল হলে শান্ত ও নির্দিষ্ট বার্তা রাখুন:
যদি কিছু মেলানো না যায়, স্পষ্টভাবে বলুন কী হয়েছে:
যখন ডেটার ভুল হওয়ার খরচ উচ্চ—পেমেন্ট, পারমিশন, মেডিকেল বা আইনি টেক্সট—তখন জিজ্ঞাসা করা উপযুক্ত।
প্রায়োগিক নিয়মের কাঁচা ধারণা:
Last-write-wins (LWW) শোনতে সরল: একই ফিল্ড দুই জায়গায় এডিট হলে সর্বশেষ এডিটই সত্যি। বিভ্রান্তি আসে “সর্বশেষ” আসলে কী বোঝায় সেটা থেকে।
আপনার একটি একক সময় উৎস দরকার, না হলে LWW দ্রুত গোলমাল হয়ে যায়।
নিরাপদ অপশন হলো সার্ভার সময়: সার্ভার প্রতিটি পরিবর্তন গ্রহণ করার সময় একটি "updated at" নির্ধারণ করে, তারপর সর্বশেষ সার্ভার টাইমস্ট্যাম্প জিতবে। ডিভাইস সময়ে নির্ভর করলে, ভুল ঘড়িসহ ফোন ভালো ডেটাকে ওভাররাইট করতে পারে।
সার্ভার টাইম ব্যবহার করলেও LWW মানুষকে বিভ্রান্ত করতে পারে কারণ “সার্ভারে পৌঁছানোর সর্বশেষ পরিবর্তন” ব্যবহারকারীর কাছে করা “সর্বশেষ” মনে নাও হতে পারে। ধীর সংযোগ আগমনের ক্রম পরিবর্তন করতে পারে।
LWW ভাল কাজ করে যেখানে ওভাররাইট করা গ্রহণযোগ্য, বা যেখানে কেবল সর্বশেষ মানটি গুরুত্বপূর্ণ: প্রেজেন্স ফ্ল্যাগ, সেশন সেটিংস, মিউট/সোর্ট অর্ডার ইত্যাদি।
LWW ক্ষতিগ্রস্ত করে যেখানে তা মানে গুরুত্বপূর্ণ, যত্নসহকারে সম্পাদিত কন্টেন্ট: প্রোফাইল তথ্য, ঠিকানাগুলি, মূল্য, দীর্ঘ টেক্সট—যেগুলো ব্যবহারকারী ‘হারিয়ে গেছে’ মনে করবে।
বিভ্রান্তি কমাতে আউটকাম দৃশ্যমান এবং দায়মুক্ত রাখুন:
Merge সবচেয়ে ভালো কাজ করে যখন মানুষ ফলাফল অনুমান করতে পারে সাহায্য ছাড়া। সহজ নিয়ম: যা নিরাপদ তা মিলাও, কেবল তখনই ব্যবহারকারীকে বিরক্ত করো যখন আপনাকে বেছে নিতে হবে।
সম্পূর্ণ প্রোফাইলের একটি সংস্করণ বেছে নেওয়ার বদলে, ফিল্ড অনুযায়ী মিলাও। যদি এক ডিভাইসে ফোন নম্বর বদলায় এবং অন্য ডিভাইসে ঠিকানা বদলায়, উভয়ই রাখুন। এটি ন্যায্য মনে হয় কারণ ব্যবহারকারী সম্পর্কে অপ্রাসঙ্গিক এডিট হারায় না।
সফল হলে সহায়ক কপি:
যদি একটি ফিল্ড কনফ্লিকট করে, সরলভাবে বলুন:
কিছু ডেটা যোগকারী স্বভাবের: মন্তব্য, চ্যাট বার্তা, কার্যকলাপ লগ। যদি দুই ডিভাইস অফলাইনে আইটেম যোগ করে, সাধারণত সবকিছুই রাখা যায়। এটি কম বিভ্রান্তির প্যাটার্ন কারণ কিছুই ওভাররাইট হয় না।
স্পষ্ট স্ট্যাটাস মেসেজ:
তালিকা জটিল হয়ে উঠে যখন এক ডিভাইসে কোনো আইটেম ডিলিট করে এবং অন্য ডিভাইসে সেটি এডিট করা হয়। একটি সহজ নিয়ম বেছে নিন এবং তা স্পষ্টভাবে বলুন।
একটি সাধারণ পদ্ধতি: যোগ সবসময় সিঙ্ক হয়, এডিট সিঙ্ক হবে যদি আইটেম মুছে না যায়, এবং ডিলিট এডিটকে হারায় (কারণ আইটেমই নেই)।
কনফ্লিক্ট কপি যা প্যানিক রোধ করে:
যখন আপনি এসব পছন্দ সাধারণ ভাষায় ডকুমেন্ট করেন, মানুষ অনুমান করা বন্ধ করে দেয়। সাপোর্ট টিকিট কমে যায় কারণ অ্যাপের আচরণ স্ক্রিনে থাকা বার্তার সঙ্গে মিলে যায়।
অধিকাংশ কনফ্লিক্ট ডায়ালগ প্রয়োজন হয় না। শুধুমাত্র তখনি জিজ্ঞাসা করুন যখন অ্যাপ নিরাপদভাবে বিজয়ী নির্বাচন করতে না পারে — যেমন দুইজনেই একই ফিল্ড ভিন্নভাবে পরিবর্তন করলে।
বিরতি দিন এক স্পষ্ট মুহূর্তে: সিঙ্ক সম্পূর্ণ হওয়ার ঠিক পর এবং যখন কনফ্লিক্ট ধরা পড়ে। যদি ডায়ালগটি ব্যবহারকারী টাইপ করার সময় উঠে আসে, সেটি তাদের কাজ ভাঙার মতো মনে হবে।
সম্ভব হলে দুটি বোতামেই সীমাবদ্ধ রাখুন। “Keep mine” বনাম “Use theirs” বেশিরভাগ ক্ষেত্রে যথেষ্ট।
সাধারণ ভাষা ব্যবহার করুন যা ব্যবহারকারী মনে রাখে:
প্রযুক্তিগত ডিফ দেখানোর বদলে পার্থক্যটি ছোট গল্পের মতো বর্ণনা করুন: “You changed the phone number to 555-0142. Someone else changed it to 555-0199.”
ডায়ালগ শিরোনাম:
We found two versions
ডায়ালগ বডির উদাহরণ:
Your profile was edited on this phone while offline, and it was also updated on another device.
This phone: Phone number set to (555) 0142 Other update: Phone number set to (555) 0199
বাটন:
Keep mine
Use theirs
নির্বাচনের পর কনফার্মেশন:
Saved. We’ll sync your choice now.
অল্প বেশি আশ্বাস হলে বোতামের নিচে একটি শান্ত লাইন যোগ করুন:
You can change this again later in Profile.
প্রথমে সিদ্ধান্ত নিন ব্যবহারকারী কোন কাজ কানেকশন ছাড়াই করতে পারবে। যদি আপনি সবকিছুই অফলাইনে সম্পাদনা করতে দেন, আপনি পরে আরও কনফ্লিক্ট গ্রহণ করছেন।
সরল শুরু: ড্রাফট ও নোট সম্পাদনা করা যাবে; অ্যাকাউন্ট সেটিংস সীমাবদ্ধভাবে সম্পাদনাযোগ্য; সংবেদনশীল কাজ (পেমেন্ট, পাসওয়ার্ড পরিবর্তন) অনলাইনে না হওয়া পর্যন্ত শুধু দেখা যাবে।
এরপর প্রতিটি ডেটা টাইপের জন্য একটি কনফ্লিক্ট নিয়ম বেছে নিন, পুরো অ্যাপের জন্য এক নিয়ম নয়। নোটগুলো সাধারণত মেলানো যায়। প্রোফাইল ফিল্ড সাধারণত মেলে না। পেমেন্ট কনফ্লিক্ট হওয়া উচিত নয়। এখানে আপনি প্লেইন ভাষায় নিয়মগুলো নির্ধারণ করবেন।
তারপর ব্যবহারকারীরা কোন দৃশ্যগুলি দেখবে তা মানচিত্র করুন। সব স্ক্রিনে স্টেটগুলো একরকম রাখুন যাতে মানুষ পুনরায় শেখার প্রয়োজন না হয়। ব্যবহারকারী-উপযোগী টেক্সটে “Saved on this device” এবং “Waiting to sync” এর মত বাক্য ব্যবহার করুন—ইন্টারনাল টার্মস নয়।
কপিটি এমনভাবে লিখুন যেন আপনি এক বন্ধুকে ব্যাখ্যা করছেন। যদি আপনি “conflict” শব্দটি ব্যবহার করেন, সঙ্গে তাৎক্ষণিকভাবে বলে দিন: “দুইটি আলাদা এডিট ঘটেছে আপনার ফোন সিঙ্ক করার আগে।”
টেস্ট করুন অ-প্রযুক্তিগত ব্যবহারকারীদের সঙ্গে। প্রতিটি স্ক্রিনের পরে একটি প্রশ্ন জিজ্ঞাসা করুন: “আপনি ভাবছেন পরবর্তী কি হবে?” যদি তারা ভুল অনুমান করে, কপি কাজ করছে না।
শেষে একটি পলায়ন পথ রাখুন যাতে ভুল স্থায়ী না হয়: সাম্প্রতিক এডিটের জন্য Undo, গুরুত্বপূর্ণ রেকর্ডের জন্য ভার্সন ইতিহাস বা রিস্টোর পয়েন্ট। Koder.ai-র মত প্ল্যাটফর্ম স্ন্যাপশট এবং রোলব্যাক ব্যবহার করে—কারণ এজ কেস হলে পুনরুদ্ধার আস্থা তৈরি করে।
অধিকাংশ সিঙ্ক সাপোর্ট টিকিটের প্রধান-root সমস্যা: অ্যাপ জানে কী হচ্ছে, কিন্তু ব্যবহারকারী জানে না। স্টেট দৃশ্যমান করুন এবং পরবর্তী পদক্ষেপ স্পষ্ট রাখুন।
“Sync failed” একটি ডেড এন্ড। বলুন কী হয়েছে এবং ব্যবহারকারী কী করতে পারে।
ভাল: “Couldn’t sync right now. Your changes are saved on this device. We’ll try again when you’re online.” যদি কোনো বিকল্প থাকে, অফার করুন: “Try again” এবং “Review changes waiting to sync.”
যদি মানুষ তাদের আনসেন্ট আপডেট দেখতে না পায়, তারা ধরে নেবে কাজ হারিয়ে গেছে। তাদেরকে লোকালি কি সেভ আছে তা নিশ্চিত করার জায়গা দিন।
সরল উপায়: একটি ছোট স্ট্যাটাস লাইন “3 changes waiting to sync” যা একটি সংক্ষিপ্ত তালিকা খুলে যেখানে আইটেমের নাম ও আনুমানিক সময় আছে।
লো-স্টেক্স ফিল্ডের জন্য অটো-রিসলভ ঠিক আছে, কিন্তু যখন তা গুরুত্বপূর্ণ কিছু (ঠিকানা, মূল্য, অনুমোদন) অদৃশ্যভাবে ওভাররাইট করে, মানুষ রাগ করে।
কমপক্ষে, কার্যকলাপে একটি নোট রাখুন: “We kept the most recent version from this device” বা “We combined changes.” ভাল হলে পুনরায় সংযোগের পরে একটি এককালীন ব্যানার দেখান: “We updated 1 item during sync. Review.”
মানুষ সময় দিয়ে বিচার করে যে ন্যায়পরায়ণতা আছে কি না। যদি আপনার “Last updated” সার্ভার সময় বা ভিন্ন টাইমজোন ব্যবহার করে দেখায়, মনে হতে পারে অ্যাপ পিছন থেকে পরিবর্তন করেছে।
সময় ব্যবহারকারীর স্থানীয় টাইমজোনে দেখান, এবং “Updated 5 minutes ago” মত বন্ধুত্বপূর্ণ বাক্য বিবেচনা করুন।
অফলাইন স্বাভাবিক। দৈনন্দিন সংযোগ বিচ্ছেদের জন্য লাল/ভয় দেখানো স্টেট ব্যবহার করা থেকে বিরত থাকুন। শান্ত ভাষা ব্যবহার করুন: “Working offline” এবং “Saved on this device.”
যদি কেউ ট্রেনে প্রোফাইল এডিট করে এবং পরে ওয়াই-ফাইতে পুরোনো ডেটা দেখে, তারা সাধারণত সাপোর্টে যোগাযোগ করে না যদি অ্যাপ স্পষ্টভাবে দেখায় “Saved locally, will sync when online” এবং পরে “Synced” বা “Needs attention.” যদি কেবল “Sync failed” দেখায়, তারা করবে।
যদি মানুষ আপনার সিঙ্ক আচরণ ভবিষ্যদ্বাণী করতে না পারে, তারা অ্যাপের ওপর থেকে আস্থা হারায়। অফলাইন স্টেট চোখ থেকে হারাতে দেবেন না। একটি ছোট ব্যাজ হেডারে প্রায় যথেষ্ট, কিন্তু এটি তখনই দেখাতে হবে যখন তা গুরুত্বপূর্ণ (অ্যাপ্লেন মোড, সিগন্যাল নেই, বা সার্ভার পৌঁছানো যাচ্ছে না) এবং দ্রুত মুছে যেতে হবে যখন অ্যাপ অনলাইনে ফিরে আসে।
তারপর Save চাপার পরের মুহূর্ত পরীক্ষা করুন। তারা সাথে সাথে লোকালি সেভের নিশ্চয়তা দেখতে পাওয়া উচিত, যদিও সিঙ্ক এখনই হতে পারে না। “Saved on this device” প্যানিক কমায় এবং পুনরায় ট্যাপ করা থেকে বিরত রাখে।
একটি সংক্ষিপ্ত চেকলিস্ট আপনার ফ্লো স্যানিটি-চেক করার জন্য:
এছাড়াও পুনরুদ্ধারকে স্বাভাবিক করে তুলুন। যদি last-write-wins কিছু ওভাররাইট করে, “Undo” বা “Restore previous version” দিন। যদি সেটা না দিতে পারেন, স্পষ্ট পরবর্তী ধাপ দিন: “Try again when online,” এবং সাপোর্টের স্পষ্ট উপায় দিন।
একটি সহজ পরীক্ষা: একজন বন্ধুকে বলুন অফলাইনে যান, একটি ফিল্ড এডিট করুন, তারপর অন্য ডিভাইসে সেটি আবার এডিট করুন। যদি তারা ভবিষ্যদ্বাণী করতে পারে কি হবে কল্পনা না করেই, আপনার নিয়ম ঠিকমত কাজ করছে।
Maya ট্রেনে আছে, সিগন্যাল নেই। সে প্রোফাইল খুলে ডেলিভারি ঠিকানা পরিবর্তন করে:
“12 Oak St, Apt 4B” থেকে “12 Oak St, Apt 4C” এ।
স্ক্রীনের উপরে সে দেখে: “You’re offline. Changes will sync when you’re back online.” সে Save চাপে এবং চলে যায়।
একই সময়, তার সঙ্গী Alex বাড়িতে অনলাইন অবস্থায় একই ঠিকানা পরিবর্তন করে: “14 Pine St”. Alex সেভ করে এবং তা সঙ্গে সিঙ্ক হয়।
Maya যখন সিগন্যাল পায়, সে দেখে: “Back online. Syncing your changes…” তারপর একটি টোস্ট: “Synced.” এরপর কি হবে তা আপনার কনফ্লিক্ট নিয়মের উপর নির্ভর করে।
Last-write-wins: Maya-র এডিট পরে হওয়ায় ঠিকানা হয়ে যায় “12 Oak St, Apt 4C”. Alex বিস্মিত হন কারণ তাদের পরিবর্তন “গায়ব” হয়ে গেছে। ভালো ফলো-আপ মেসেজ: “Synced. Your version replaced a newer update from another device.”
Field-level merge: যদি Alex রাস্তা বদলে এবং Maya কেবল অ্যাপার্টমেন্ট নম্বর বদলে থাকে, আপনি উভয় মিলিয়ে দিতে পারেন: “14 Pine St, Apt 4C”. টোস্ট বলতে পারে: “Synced. We combined changes from another device.”
Ask the user: যদি উভয়েই একই ফিল্ড (রাস্তা) বদলে থাকে, একটি শান্ত প্রম্পট দেখান:
“Two updates to Delivery address”
“We found changes from another device. Nothing was lost. Choose which one to keep.”
বাটন: “Keep mine” এবং “Use other update”।
ব্যবহারকারী যা শিখে তা সরল: সিঙ্ক পূর্বানুমানযোগ্য, এবং যদি সংঘাত ঘটে, কিছুই হারায়নি—তারা বেছে নিতে পারে।
যদি আপনি এমন অফলাইন আচরণ চান যা ব্যবহারকারী ভবিষ্যদ্বাণী করতে পারে, প্রথমে আপনার নিয়মগুলো প্লেইন বাক্যে লিখে নিন। একটি সাহায্যকারী ডিফল্ট: লো-রিস্ক ফিল্ড (নোট, ট্যাগ, বর্ণনা) এর জন্য merge; উচ্চ-ঝুঁকি ডেটার (পেমেন্ট, ইনভেন্টরি, আইনি লেখা) জন্য Ask।
এই নিয়মগুলো ছোট একটি কপি কিটে রূপান্তর করুন যা আপনি সারাবখত পুনরায় ব্যবহার করবেন। শব্দগুলো সামঞ্জস্য রাখুন যাতে ব্যবহারকারী একবার শিখে নেয়।
পূর্ণ ফিচার নির্মাণের আগে, স্ক্রিন এবং কপি প্রোটোটাইপ করুন। পুরো গল্পটা দেখতে চান: অফলাইনে এডিট, রিকোনেক্ট, সিঙ্ক, এবং সংঘাত হলে কী হয়।
একটি হালকা ওজনের টেস্ট প্ল্যান যা বেশিরভাগ বিভ্রান্তি ধরবে:
আপনি যদি Koder.ai ব্যবহার করেন, প্ল্যানিং মোড আপনাকে অফলাইন স্টেট ম্যাপ করতে এবং সঠিক মেসেজ ড্রাফট করতে সাহায্য করবে, তারপর দ্রুত Flutter প্রোটোটাইপ তৈরি করে পুরো ফ্লো যাচাই করতে পারেন।
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.
