ਉਹ ਆਫਲਾਈਨ-ਪਹਿਲਾਂ ਮੋਬਾਈਲ ਐਪ ਸਿੰਕ ਨਿਯਮ ਜੋ ਉਪਭੋਗਤਾ ਸਮਝ ਸਕਣ: ਸਾਫ਼ ਟਕਰਾਅ ਪੈਟਰਨ, ਸਧਾਰਨ ਸਟੇਟਸ ਸੁਨੇਹੇ, ਅਤੇ ਕਾਪੀ ਜੋ ਆਫਲਾਈਨ ਗੁੰਝਲ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਜ਼ਿਆਦਤਰ ਲੋਕ ਨੈੱਟਵਰਕ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ — ਉਹ ਉਸ ਕੰਮ ਬਾਰੇ ਸੋਚਦੇ ਹਨ ਜੋ ਸਾਹਮਣੇ ਹੈ। ਜੇ ਉਹ ਲਿਖ ਸਕਦੇ ਹਨ, Save ਧੱਕ ਸਕਦੇ ਹਨ, ਜਾਂ ਸਕਰੀਨ ਉੱਤੇ ਤਬਦੀਲੀ ਵੇਖਦੇ ਹਨ ਤਾਂ ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਇਹ ਹੋ ਗਿਆ।
ਉਨ੍ਹਾਂ ਦੀਆਂ ਉਮੀਦਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸਿਧੀਆਂ ਨੀਯਮਾਂ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ:
ਇਨ੍ਹਾਂ ਦੇ ਪਿੱਛੇ ਦੋ ਡਰ ਹਨ: ਖੋਇਆ ਹੋਇਆ ਕੰਮ ਅਤੇ ਅਚਾਨਕ ਤਬਦੀਲੀਆਂ।
ਖੋਇਆ ਹੋਇਆ ਕੰਮ ਧੋਖਾ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਐਪ ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਦੇਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਅਚਾਨਕ ਤਬਦੀਲੀਆਂ ਹੋਰ ਵੀ ਖਰਾਬ ਲੱਗ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਐਪ ਬਾਅਦ ਵਿੱਚ “ਆਪਣਾ ਮਨ ਬਦਲ ਲੈਂਦੀ” ਵਰਗੀ ਲੱਗਦੀ ਹੈ।
ਇਸ ਲਈ ਤੁਹਾਨੂੰ “ਸਿੰਕਡ” ਦੀ ਸਪੱਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਿੰਕਡ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਮੈਂ ਇਹ ਆਪਣੇ ਫੋਨ 'ਤੇ ਵੇਖ ਰਿਹਾ ਹਾਂ।” ਮਤਲਬ ਹੈ “ਇਹ ਤਬਦੀਲੀ ਸਰਵਰ ਨੂੰ ਅੱਪਲੋਡ ਹੋਈ ਅਤੇ ਅੰਗੀਕ੍ਰਿਤ ਹੋਈ, ਅਤੇ ਹੋਰ ਡਿਵਾਈਸਾਂ ਨੂੰ ਵੀ ਮਿਲੇਗੀ।” ਤੁਹਾਡੀ UI ਲੋਕਾਂ ਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇ ਕਿ ਉਹ ਕਿਸ ਹਾਲਤ ਵਿੱਚ ਹਨ।
ਇੱਕ ਆਮ ਨੁਕਸ: ਕੋਈ ਵਿਅਕਤੀ ਸੁਬਵੇ ਤੇ ਆਪਣਾ ਸ਼ਿਪਿੰਗ ਪਤਾ ਸੋਧਦਾ ਹੈ, ਵੇਖਦਾ ਹੈ ਕਿ ਅੱਪਡੇਟ ਹੋ ਗਿਆ, ਅਤੇ ਐਪ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਘਰ ਆ ਕੇ ਵੇਖਦਾ ਹੈ ਪੁਰਾਣਾ ਪਤਾ ਵਾਪਸ ਹੈ। ਭਾਵੇਂ ਸਿਸਟਮ ਨੇ ਲਾਜਿਕਲ ਕੰਮ ਕੀਤਾ ਹੋਵੇ, ਉਪਭੋਗਤਾ ਇਸ ਨੂੰ ਡਾਟਾ ਲਾਸ ਮੰਨਦਾ ਹੈ।
ਪੇਸ਼ਗੋਈਯੋਗ ਨਿਯਮ ਅਤੇ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। "Saved on this device" ਵਿਰੁੱਧ "Synced to your account" ਵਰਗੇ ਛੋਟੇ ਸਟੇਟਸ ਲਾਈਨਾਂ ਬਹੁਤ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਵਧੀਆ ਆਫਲਾਈਨ-ਪਹਿਲਾ ਦ੍ਰਿਸ਼ਟੀ ਇਕ ਸਧਾਰਨ ਵਾਅਦਾ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ Save ਦਬਾਉਂਦੇ ਹੋ, ਤੁਹਾਡਾ ਕੰਮ ਇਸ ਵੇਲੇ ਸੁਰੱਖਿਅਤ ਹੈ, ਚਾਹੇ ਇੰਟਰਨੈੱਟ ਨਾ ਹੋਵੇ।
ਜਦੋਂ ਉਪਭੋਗਤਾ ਕੁਝ ਸੋਧਦਾ ਹੈ, ਐਪ ਨੂੰ ਪਹਿਲਾਂ ਡਿਵਾਈਸ 'ਤੇ ਸੇਵ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਉਹ ਵਰਜਨ ਹੈ ਜੋ ਉਹ ਤੁਰੰਤ ਵੇਖਣ ਦੀ ਉਮੀਦ ਕਰਾਂਗੇ।
ਅਲੱਗ ਤੌਰ 'ਤੇ, ਐਪ ਉਹ ਤਬਦੀਲੀ ਸਰਵਰ ਨੂੰ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ। ਜੇ ਫੋਨ ਆਫਲਾਈਨ ਹੈ, ਤਾਂ ਉਹ ਸੋਧਾਂ “ਲੌਸਟ” ਜਾਂ “ਆਧੀ-ਸੇਵ” ਨਹੀਂ ਹਨ — ਉਹ صرف ਭੇਜਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀਆਂ ਹਨ।
UI ਵਿੱਚ ਤਕਨੀਕੀ ਸ਼ਬਦਾਂ ਜਿਵੇਂ “queued” ਜਾਂ “pending writes” ਵਰਤਣ ਤੋਂ ਬਚੋ। ਸਾਧੀ ਭਾਸ਼ਾ ਵਰਤੋ: “ਅਸੀਂ ਤੁਹਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਜਦੋਂ ਤੁਸੀਂ ਆਨਲਾਈਨ ਹੋਵੋਗੇ ਤਦ ਭੇਜਾਂਗੇ।”
ਲੋਕਾਂ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਜਦੋਂ ਐਪ ਸਪਸ਼ਟ ਦਿਖਾਉਂਦੀ ਹੈ ਤਾਂ ਜ਼ਿਆਦਾ ਸੌਖਾ ਲੱਗਦਾ ਹੈ। ਤੁਸੀਂ ਘੱਟੋ ਘੱਟ ਹਾਲਤਾਂ ਨਾਲ ਜ਼ਿਆਦਾਤਰ ਸਥিতੀਆਂ ਕਵਰ ਕਰ ਸਕਦੇ ਹੋ:
ਫਿਰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਹਾਲਤ ਜੋ ਸਿਰਫ਼ ਜ਼ਰੂਰਤ ਤੇ ਦਿਖਾਈ ਦੇ: Needs attention।
ਇੱਕ ਸਧਾਰਣ ਵਿਜ਼ੂਅਲ ਸਿਸਟਮ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕ ਛੋਟੀ ਆਈਕਨ ਨਾਲ ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਟੈਕਸਟ ਉਸ ਐਕਸ਼ਨ ਦੇ ਨੇੜੇ ਜਿਸ ਨੇ ਮਹੱਤਵ ਰੱਖਿਆ।
ਉਦਾਹਰਨ ਦੀ ਕਾਪੀ:
ਸਿੰਕ ਟਕਰਾਅ ਉਸ ਸਮੇਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕੋ ਹੀ ਚੀਜ਼ 'ਤੇ ਦੋ ਸੋਧਾਂ ਹੋ ਜਾਣ ਅਤੇ ਐਪ ਅਜੇ ਸਰਵਰ ਨਾਲ ਤੁਲਨਾ ਨਹੀਂ ਕਰ ਸਕੀ।
ਟਕਰਾਅ ਆਮ ਤੌਰ 'ਤੇ ਨਾਰਮਲ ਵਰਤੋਂ ਤੋਂ ਹੁੰਦੇ ਹਨ:
ਉਹ ਗੱਲ ਜੋ ਉਪਭੋਗਤਾਈਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦੀ ਹੈ: ਉਹਨਾਂ ਨੇ ਕੁਝ ਗਲਤ ਨਹੀਂ ਕੀਤਾ। ਉਹ ਆਪਣੇ ਸੋਧ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਫਲ ਵੇਖਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਇਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਇਹ ਅੰਤਿਮ ਹੈ। ਜਦੋਂ ਐਪ ਬਾਅਦ ਵਿੱਚ ਸਿੰਕ ਕਰਦੀ ਹੈ, ਤਦ ਸਰਵਰ ਇਸਨੂੰ ਰਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਮਿਲਾ ਸਕਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਹੋਰ ਦੇ ਵਰਜਨ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ।
ਸਾਰਾ ਡਾਟਾ ਇਕੋ ਜਿਹਾ ਖਤਰਾ ਨਹੀਂ ਰੱਖਦਾ। ਕੁਝ ਤਬਦੀਲੀਆਂ ਆਸਾਨੀ ਨਾਲ ਮਿਲਾ ਲਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (likes, read/unread, cached filters). ਹੋਰ ਉੱਚ-ਸਥਿਤੀ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ (ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ, ਕੀਮਤਾਂ, ਸਟੌਕ, ਭੁਗਤਾਨ)।
ਸਭ ਤੋਂ ਵੱਡਾ ਭਰੋਸਾ ਟੁੱਟਣ ਵਾਲਾ ਹਾਲਤ ਚੁਪਚਾਪ ਓਵਰਰਾਈਟ ਹੈ: ਐਪ ਬਿਨਾਂ ਕਿਸੇ ਸੁਨੇਹੇ ਦੇ ਉਪਭੋਗਤਾ ਦੀ ਆਫਲਾਈਨ ਸੋਧ ਨੂੰ ਸਰਵਰ ਦੀ ਨਵੀਂ ਵੈਲਯੂ ਨਾਲ ਬਦਲ ਦਿੰਦੀ ਹੈ (ਜਾਂ ਉਲਟ)। ਲੋਕ ਬਾਅਦ ਵਿੱਚ ਨੋਟਿਸ ਕਰਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਜਦੋਂ ਇਹ ਮਾਮਲਾ ਮਹੱਤਵ ਦਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ ਆਉਂਦੀਆਂ ਹਨ।
ਤੁਹਾਡੇ ਨਿਯਮ ਇੱਕ ਗੱਲ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਣ ਚਾਹੀਦੇ ਹਨ: ਕੀ ਉਨ੍ਹਾਂ ਦੀ ਸੋਧ ਜਿੱਤੇਗੀ, ਮਿਲਾਈ ਜਾਵੇਗੀ, ਜਾਂ ਵਿਕਲਪ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਪੁੱਛਿਆ ਜਾਵੇਗਾ?
ਜਦੋਂ ਐਪ ਆਫਲਾਈਨ ਸੇਵ ਕਰਦੀ ਹੈ, ਤਦ ਆਖ਼ਿਰਕਾਰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਜੇ ਇੱਕੋ ਹੀ ਚੀਜ਼ ਦੂਜੇ ਥਾਂ ਤੇ ਬਦਲੀ ਗਈ ਹੋਵੇ ਤਾਂ ਕੀ ਕੀਤਾ ਜਾਵੇ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ; ਇਹ ਵਰਤਾਰਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਪੇਸ਼ਗੋਈ ਕਰ ਸਕਣ।
Last-write-wins ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਭ ਤੋਂ ਹਾਲੀਆ ਸੋਧ ਅੰਤਿਮ ਵਰਜਨ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹ ਤੇਜ਼ ਅਤੇ ਸਧਾਰਣ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਹੋਰ ਦੇ ਕੰਮ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸਨੂੰ ਉਹ ਵੇਲੇ ਵਰਤੋਂ ਜਦੋਂ ਗਲਤ ਹੋਣਾ ਸਸਤਾ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਠੀਕ ਹੋ ਸਕਦਾ ਹੋਵੇ, ਜਿਵੇਂ read/unread ਸਥਿਤੀ, sort order, ਜਾਂ “last viewed” ਟਾਈਮਸਟੈਂਪ। ਜੇ ਤੁਸੀਂ LWW ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਹ ਟਰੇਡ-ਆਫ਼ ਲੁਕਾਓ ਨਹੀਂ। ਸਪਸ਼ਟ ਕਾਪੀ ਮਦਦ ਕਰਦੀ ਹੈ: “Updated on this device. If a newer update exists, it may replace this one.”
Merge ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪ ਦੋਨਾਂ ਸੋਧਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਓਹ ਜਗ੍ਹਾਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਇਡਿਟਾਂ ਇਕੱਠੇ ਹੋਣਗੀਆਂ, ਜਿਵੇਂ ਸੂਚੀਆਂ ਵਿੱਚ ਆਈਟਮਾਂ ਦੀ ਜੋੜ, ਮੈਸੇਜਜ਼ ਜੋੜਨਾ, ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਦੇ ਵੱਖ-ਵੱਖ ਫੀਲਡ ਸੋਧਣਾ।
ਜਦੋਂ ਇੰਝ ਸਫਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸ਼ਾਂਤ ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਸੁਨੇਹਾ ਰੱਖੋ:
ਜੇ ਕੁਝ ਮਿਲਾ ਨਹੀਂ ਸਕਿਆ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ:
ਪੁੱਛਣਾ ਉਹFallback ਹੈ ਜਦੋਂ ਡਾਟਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਆਪਣੇ-ਆਪ ਨੇ automatische ਨਿਰਨਾ ਲੈਣਾ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਭੁਗਤਾਨ, ਅਧਿਕਾਰ, ਮੈਡੀਕਲ ਜਾਣਕਾਰੀ, ਜਾਂ ਕਾਨੂੰਨੀ ਲਿਖਤ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਨਿਯਮ:
LWW ਸਿੱਧਾ ਲੱਗਦਾ ਹੈ: ਜਦੋਂ ਇੱਕੋ ਫੀਲਡ ਦੋ ਜਗ੍ਹਾਂ ਬਦਲੀ ਹੋਵੇ, ਸਭ ਤੋਂ ਨਵਾਂ ਸੰਸ਼ੋਧਨ ਅੰਤਿਮ ਸੱਚ ਹੋ ਜਾਂਦਾ ਹੈ। ਗਲਤੀ ਇਸ ਗੱਲ ਵਿੱਚ ਹੈ ਕਿ “ਆਖਰੀ” ਦਾ ਮਤਲਬ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ।
ਤੁਹਾਨੂੰ ਇੱਕ ਇਕਾਈ ਸਮਾਂ ਸਰੋਤ ਦੀ ਲੋੜ ਹੈ ਨਹੀਂ ਤਾਂ LWW ਜਲਦੀ ਗੜਬੜ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਸਰਵਰ ਸਮਾਂ ਹੈ: ਸਰਵਰ ਹਰ ਤਬਦੀਲੀ ਨੂੰ ਮਿਲਣ 'ਤੇ ਇੱਕ "updated at" ਦੇ ਦਿੰਦਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਨਵਾਂ ਸਰਵਰ ਟਾਈਮਸਟੈਂਪ ਜਿੱਤਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਡਿਵਾਈਸ ਟਾਇਮ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਗਲਤ ਘੜੀ ਵਾਲਾ ਫੋਨ ਸਹੀ ਡਾਟਾ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ।
ਸਰਵਰ ਸਮੇਂ ਦੇ ਨਾਲ ਵੀ, LWW ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ “ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੀ ਆਖਰੀ ਤਬਦੀਲੀ” ਉਹ ਨਹੀਂ ਜੋ ਉਪਭੋਗਤਾ ਅਨੇਹੀ ਤਾਂ ਤੌਰ ਤੇ ਸੋਚਦਾ ਹੈ। ਇੱਕ ਧੀਮੀ ਕਨੈਕਸ਼ਨ ਆਦੇਸ਼ ਦੇ ਆਗਮਨ ਦੇ ਕ੍ਰਮ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ।
LWW ਉਹਨਾਂ ਵੈਲਯੂਆਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿੱਥੇ ਓਵਰਰਾਈਟ ਸੰਵੀਕਾਰਯੋਗ ਹੈ ਜਾਂ ਸਿਰਫ ਨਵਾਂ ਮੁੱਲ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ: ਪ੍ਰੇਜ਼ੈਂਸ ਫਲੈਗ (online/offline), ਸੈਸ਼ਨ ਸੈਟਿੰਗਜ਼ (mute, sort order) ਅਤੇ ਹੋਰ ਘੱਟ-ਖ਼ਤਰਨਾਕ ਫੀਲਡ।
ਜਿੱਥੇ LWW ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ ਉਹ ਹੈ ਮਹੱਤਵਪੂਰਨ, ਧਿਆਨ ਨਾਲ ਸੋਧਿਆ ਸਮਗਰੀ: ਪ੍ਰੋਫਾਈਲ ਜਾਣਕਾਰੀ, ਐਡਰੈੱਸ, ਕੀਮਤਾਂ, ਲੰਮਾ ਟੈਕਸਟ, ਜਾਂ ਉਹ ਕੁਝ ਜੋ ਉਪਭੋਗਤਾ "ਗਾਇਬ ਹੋ ਗਿਆ" ਮਹਿਸੂਸ ਕਰੇਗਾ। ਇਕ ਖਾਮੋਸ਼ ਓਵਰਰਾਈਟ ਇੱਕ ਵੱਡਾ ਭਰੋਸਾ-ਤੋੜ ਹੋ ਸਕਦਾ ਹੈ।
ਗੁੰਝਲ ਘਟਾਉਣ ਲਈ, ਨਤੀਜਾ ਦਿੱਖਾਓ ਅਤੇ ਦੋਸ਼-ਮੁਕਤ ਬਨੀਏ:
Merge ਉਹ ਵੇਲੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਲੋਕ ਬਿਨਾ ਕਿਸੇ ਸਿਖਲਾਈ ਦੇ ਨਤੀਜੇ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹਨ। ਸਾਬਤ ਸਾਦਾ ਨਿਯਮ: ਜੋ ਸੁਰੱਖਿਅਤ ਹੈ ਉਹ ਜੋੜੋ, ਸਿਰਫ ਉੱਥੇ ਰੁਕੋ ਜਿੱਥੇ ਤੁਸੀਂ ਨਹੀਂ ਮਿਲਾ ਸਕਦੇ।
ਇੱਕ ਪੂਰੇ ਪ੍ਰੋਫਾਈਲ ਦੇ ਇੱਕ ਵਰਜਨ ਨੂੰ ਚੁਣਨ ਦੀ ਬਜਾਏ, ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਮਰਜ ਕਰੋ। ਜੇ ਇੱਕ ਡਿਵਾਈਸ ਨੰਬਰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਡਿਵਾਈਸ ਨੇ ਪਤਾ ਬਦਲਿਆ, ਤਾਂ ਦੋਨਾਂ ਰੱਖੋ। ਇਹ ਵਾਜਿਬ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਉਪਭੋਗਤਾਈਂ ਅਣਸੰਬੰਧਤ ਸੋਧਾਂ ਨੂੰ ਨਹੀਂ ਗੁਆਉਂਦੇ।
ਜਦੋਂ ਇਹ ਸਫਲ ਹੋਵੇ ਤਾਂ ਮਦਦਗਾਰ ਕਾਪੀ:
ਜੇ ਕਿਸੇ ਫੀਲਡ ਨੂੰ ਮਿਲਾਇਆ ਨਹੀਂ ਜਾ ਸਕਿਆ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ:
ਕੁਝ ਡਾਟਾ ਕਿਸਮ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਜੋੜਨਯੋਗ ਹੁੰਦੀਆਂ ਹਨ: ਟਿੱਪਣੀਆਂ, ਚੈਟ ਸੁਨੇਹੇ, ਐਕਟਿਵਿਟੀ ਲੌਗ। ਜੇ ਦੋ ਡਿਵਾਈਸਾਂ ਆਫਲਾਈਨ ਹੋ ਕੇ ਆਈਟਮ ਜੋੜਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਸਾਰਿਆਂ ਨੂੰ ਰੱਖ ਸਕਦੇ ਹੋ। ਇਹ ਸਭ ਤੋਂ ਘੱਟ-ਗੁੰਝਲ ਵਾਲਾ ਪੈਟਰਨ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਵੀ ਓਵਰਰਾਈਟ ਨਹੀਂ ਹੁੰਦਾ।
ਸਪਸ਼ਟ ਸਟੇਟਸ ਸੁਨੇਹਾ:
ਜਦੋਂ ਇੱਕ ਡਿਵਾਈਸ ਆਈਟਮ ਨੂੰ ਮਿਟਾਉਂਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਨੇ ਉਸਨੂੰ ਸੋਧਿਆ ਹੈ ਤਾਂ ਸੂਚੀਆਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਸਪਸ਼ਟ ਦੱਸੋ।
ਇੱਕ ਆਮ ਪਹੁੰਚ: ਜੋੜ ਹਮੇਸ਼ਾ ਸਿੰਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਸੋਧ ਸਿੰਕ ਹੁੰਦੀ ਹੈ ਜਦ ਤੱਕ ਆਈਟਮ ਮਿਟਾਇਆ ਨਾ ਗਿਆ ਹੋਵੇ, ਅਤੇ ਮਿਟਾਉਣਾ ਸੋਧਾਂ 'ਤੇ ਜਿੱਤਦਾ ਹੈ (ਕਿਉਂਕਿ ਆਈਟਮ ਹੋਰ ਨਹੀਂ ਹੈ)।
ਟਕਰਾਅ ਕਾਪੀ ਜੋ ਡਰ ਨਹੀਂ ਪੈਦਾ ਕਰਦੀ:
ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਚੋਣਾਂ ਨੂੰ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਲੋਕ ਅਣਦੇਖੇ ਅਨੁਮਾਨ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਸਪੋਰਟ ਟਿਕਟਾਂ ਘਟ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਐਪ ਦਾ ਵਰਤਾਰਾ ਸਕਰੀਨ ਤੇ ਦਿਖੇ ਸੁਨੇਹੇ ਨਾਲ ਮਿਲਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟਕਰਾਅ ਡਾਇਲਾਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੇ। ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪੁੱਛੋ ਜਿੱਥੇ ਐਪ ਸੁਰੱਖਿਅਤ ਜਿੱਤ ਨਿਰਣਾ ਨਹੀਂ ਲੈ ਸਕਦੀ ਬਿਨਾਂ ਹੈਰਾਨੀ ਦੇ, ਜਿਵੇਂ ਦੋ ਲੋਕ ਇੱਕੋ ਫੀਲਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਬਦਲ दें।
ਇੱਕ ਸਾਫ਼ ਪਲ 'ਤੇ ਰੁਕੋ: ਸਿੰਕ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਜਲਦੀ ਜੇ ਟਕਰਾਅ ਲੱਭਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਕ ਚੋਣ ਪੇਸ਼ ਕਰੋ। ਜੇ ਡਾਇਲਾਗ ਲਿਖਾਈ ਦੇ ਦੌਰਾਨ ਖੁਲਦਾ ਹੈ ਤਾਂ ਇਹ ਐਪ ਨੂੰ ਉਨਾਂ ਦੇ ਕੰਮ ਨੂੰ ਤੋੜਦਾ ਹੋਇਆ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਦੋ ਬਟਨਾਂ ਤੱਕ ਰੱਖੋ। “Keep mine” ਵਿਰੁੱਧ “Use theirs” ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ।
ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਰਤੋ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਯਾਦ ਹੋਏ ਹੋਏ ਕੰਮ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ:
ਇਕ ਤਕਨੀਕੀ diff ਦੀ ਥਾਂ, ਫਰਕ ਨੂੰ ਇਕ ਛੋਟੀ ਕਹਾਣੀ ਵਾਂਗ ਦੱਸੋ: “ਤੁਸੀਂ ਫੋਨ ਨੰਬਰ 555-0142 ਕਰ ਦਿੱਤਾ। ਕਿਸੇ ਹੋਰ ਨੇ ਇਸਨੂੰ 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 ਵਰਗੇ ਪਲੇਟਫਾਰਮ snapshot ਅਤੇ rollback ਵਰਤਦੇ ਹਨ ਇੱਕੋ ਹੀ ਕਾਰਨ ਲਈ: ਐਜ ਕੇਸ ਹੋਣ ਉੱਤੇ, ਰਿਕਵਰੀ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਸਿੰਕ ਸਪੋਰਟ ਟਿਕਟਾਂ ਇੱਕ ਮੁੱਲ ਬਿੰਦੂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ: ਐਪ ਜਾਣਦੀ ਹੈ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਪਰ ਉਪਭੋਗਤਾ ਨਹੀਂ। ਸਥਿਤੀ ਵਿਖਾਈ ਦਿਓ ਅਤੇ ਅਗਲਾ ਕਦਮ ਸਪਸ਼ਟ ਰੱਖੋ।
“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” ਸਰਵਰ ਸਮਾਂ ਜਾਂ ਵੱਖਰੇ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਐਪ ਨੇ ਪਿੱਠ ਪਿੱਠ ਬਦਲਾਅ ਕੀਤੇ।
ਸਮਾਂ ਉਪਭੋਗਤਾ ਦੇ ਸਥਾਨਕ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾਓ, ਅਤੇ ਸੌਖੀ phrasing ਵਰਤੋਂ ਜਿਵੇਂ “Updated 5 minutes ago.”
ਆਫਲਾਈਨ ਨਾਰਮਲ ਹੈ। ਰੋਸ ਭਰਿਆ ਲਾਲ ਸਟੇਟ ਹਟਾਓ। ਸ਼ਾਂਤ ਭਾਸ਼ਾ ਵਰਤੋ: “Working offline” ਅਤੇ “Saved on this device.”
ਜੇ ਕੋਈ ਵਿਅਕਤੀ ਟ੍ਰੇਨ 'ਤੇ ਪ੍ਰੋਫਾਈਲ ਸੋਧਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਾਈ-ਫਾਈ 'ਤੇ ਪੁਰਾਣਾ ਡਾਟਾ ਦੇਖਦਾ ਹੈ, ਉਹ ਅਕਸਰ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਕਰਦਾ ਜਦੋਂ ਐਪ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦੀ ਹੈ “Saved locally, will sync when online” ਅਤੇ ਫਿਰ “Synced” ਜਾਂ “Needs attention.” ਜੇ ਇਹ ਸਿਰਫ “Sync failed” ਦਿਖਾਉਂਦੀ ਹੈ ਤਾਂ ਉਹ ਸੰਪਰਕ ਕਰੇਗਾ।
ਜੇ ਲੋਕ ਤੁਹਾਡੇ ਸਿੰਕ ਵਿਹਾਰ ਦੀ ਪੇਸ਼ਗੋਈ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਹ ਐਪ ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦੇਣਗੇ।
ਆਫਲਾਈਨ ਸਥਿਤੀ ਨੂੰ ਪੂਰਾ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਓ। ਇੱਕ ਛੋਟਾ ਬੈਜ ਹੇਡਰ ਵਿੱਚ ਅਕਸਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਉਸ ਵੇਲੇ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਇਹ ਮਾਮਲਾ ਮਹੱਤਵਪੂਰਨ ਹੋ (ਪਲੇਨ ਮੋਡ, ਕੋਈ ਸਿਗਨਲ ਨਹੀਂ, ਜਾਂ ਸਰਵਰ ਪਹੁੰਚਯੋਗ ਨਹੀਂ)।
ਫਿਰ ਸੇਵ ਬਟਨ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਦੀ ਘੜੀ ਚੈੱਕ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਤੁਰੰਤ ਪੁਸ਼ਟੀ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਤਬਦੀਲੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੈ, ਭਾਵੇਂ ਸਿੰਕ ਹੁਣ ਨਹੀਂ ਹੋ ਸਕਦਾ। “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 ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ planning mode ਤੁਹਾਨੂੰ ਆਫਲਾਈਨ ਸਥਿਤੀਆਂ ਨਕਸ਼ੇਬੱਦੀ ਕਰਨ ਅਤੇ ਸਥਿਤੀ ਸੁਨੇਹਿਆਂ ਦੀ ਡਰਾਫਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਛੋਟੀ 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.
