02 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਸਧਾਰਣ ਸਥਾਨ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਲਈ ਮੋਬਾਇਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਇਕ ਪ੍ਰਾਇਗਟਿਕਲ ਗਾਈਡ ਜਿਸ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਮੋਬਾਇਲ ਐਪ ਬਣਾਈਏ ਜੋ ਸਥਾਨ ਦੇ ਆਧਾਰ 'ਤੇ ਸਧਾਰਣ ਪ੍ਰੌਂਪਟ ਟਰਿਗਰ ਕਰੇ—MVP ਯੋਜਨਾ, ਜੀਓਫੈਂਸ, ਪਰਮਿਸ਼ਨ, ਟੈਸਟਿੰਗ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ।
ਇਕ ਪ੍ਰਾਇਗਟਿਕਲ ਗਾਈਡ ਜਿਸ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਮੋਬਾਇਲ ਐਪ ਬਣਾਈਏ ਜੋ ਸਥਾਨ ਦੇ ਆਧਾਰ 'ਤੇ ਸਧਾਰਣ ਪ੍ਰੌਂਪਟ ਟਰਿਗਰ ਕਰੇ—MVP ਯੋਜਨਾ, ਜੀਓਫੈਂਸ, ਪਰਮਿਸ਼ਨ, ਟੈਸਟਿੰਗ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ।
ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ ਉਹ ਸੁਨੇਹਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਉਪਭੋਗਤਾ ਦੇ ਕਿਸੇ ਅਸਲ-ਜਗ੍ਹਾ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣ ਜਾਂ ਛੱਡਣ 'ਤੇ ਦਿਖਾਉਂਦੀ ਹੈ। ਇਸਨੂੰ ਸਮਝੋ ਕਿ ਇਹ ਕਿੱਥੇ ਹੋ ਦੇ ਆਧਾਰ 'ਤੇ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਕਦੋਂ ਹੈ ਦੇ ਆਧਾਰ 'ਤੇ।
ਮੂਲ ਤੌਰ 'ਤੇ, ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ ਵਿੱਚ ਤਿੰਨ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ:
ਉਦਾਹਰਨ: “ਜਦੋਂ ਮੈਂ ਫਾਰਮੇਸੀ ਪਹੁੰਚਾਂ, ਮੈਨੂੰ ਦਵਾਈ ਲੈਣ ਦੀ ਯਾਦ ਦਿਵਾਓ।”
ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ ਦਿਨਚਰਿਆ ਦੀਆਂ ਛੋਟੀਆਂ ਯਾਦਾਂ ਲਈ ਵਧੀਆ ਹਨ, ਜਿਹੜੀਆਂ ਸੰਦਰਭ ਤੋਂ ਲਾਭ ਉਠਾਉਂਦੀਆਂ ਹਨ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਪ੍ਰੌਂਪਟ ਉਸ ਵੇਲੇ ਆਵੇ ਜਦੋਂ ਕੰਮ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਹੋ—ਜਦ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਜਗ੍ਹਾ ਤੇ ਹੋਵੇ।
“ਸਧਾਰਣ” ਦਾ ਮਤਲਬ ਘੱਟ-ਗੁਣਵੱਤਾ ਨਹੀਂ — ਇਸਦਾ ਅਰਥ ਹੈ ਕੇਂਦਰਿਤ:
ਤੁਸੀਂ ਪੂਰੇ "if-this-then-that" ਸਿਸਟਮ ਦਾ ਨਿਰਮਾਣ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਯਾਦਦਿਹਾਨੀ ਉਪਕਰਣ ਬਣਾ ਰਹੇ ਹੋ।
ਇਹ ਗਾਈਡ ਵਿਚਾਰ ਤੋਂ ਰਿਲੀਜ਼ ਤੱਕ ਲੈ ਜਾਂਦੀ ਹੈ: MVP ਦੇ ਪਰਿਭਾਸ਼ਾ, ਆਰਕੀਟੈਕਚਰ ਚੋਣ, ਪਰਮਿਸ਼ਨ ਸੁਚੱਜਾ ਤਰੀਕਾ, ਸਥਾਨ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲ ਪਛਾਣ, ਚੰਗੀ UX ਨਾਲ ਪ੍ਰੌਂਪਟ ਡਿਲਿਵਰੀ, ਅਤੇ ਗੋਲੀ ਸਬੰਧੀ ਨਿੱਜੀਅਤ।
ਇਸ ਵਿੱਚ ਅਡਵਾਂਸਡ ਰੂਟਿੰਗ, ਟਰਨ-ਬਾਈ-ਟਰਨ ਨੈਵੀਗੇਸ਼ਨ, ਸੋਸ਼ਲ ਲੋਕੇਸ਼ਨ ਸ਼ੇਅਰਿੰਗ, ਜਾਂ ਫਿਟਨੈਸ ਐਨਾਲਿਟਿਕਸ ਲਈ ਹਾਈ-ਫ੍ਰਿਕਵੈਂਸੀ ਟਰੈਕਿੰਗ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ—ਇਹ ਸਾਰੇ ਕੰਪਲੈਕਸੀਟੀ, ਬੈਟਰੀ ਦੀ ਲੋੜ ਅਤੇ ਗੋਲੀ ਉਮੀਦਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟਾਂ ਲਈ ਇੱਕ MVP "ਪੂਰੇ ਐਪ ਦਾ ਛੋਟਾ ਸੰਸਕਰਣ" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਵਾਅਦਾ ਹੈ: ਜਦੋਂ ਕੋਈ ਕਿਸੇ ਜਗ੍ਹਾ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ, ਐਪ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਸਹਾਇਤਾ ਕਰੇ—ਬਿਨਾਂ ਬੇਕਾਰ ਬੈਟਰੀ ਖਰਚ ਕਰਨ ਜਾਂ ਸਪੈਮੀ ਅਲਾਰਟ ਭੇਜਣ ਦੇ।
ਤੀਨ ਚੀਜ਼ਾਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ: ਟਰਿਗਰ ਟਾਈਪ, ਪ੍ਰੌਂਪਟ ਫਾਰਮੈਟ, ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਅਨਭੂਤਿ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ।
ਪਹਿਲੇ ਰਿਲੀਜ਼ ਨੂੰ ਉਹ ਟਰਿਗਰ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਸੀਂ ਅਣਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ Enter + time window ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਜ਼ਿਆਦਾਤਰ ਰਿਮਾਇੰਡਰ ਮਾਮਲਿਆਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਐਜ ਕੇਸਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਆਸਾਨ ਰੱਖਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਡਿਲਿਵਰੀ ਤਰੀਕਾ ਅਤੇ ਇੱਕ fallback ਚੁਣੋ। ਹੋਰ ਫਾਰਮੈਟ ਦੀ ਲੋੜ ਬਾਅਦ ਵਿਚ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗੀ MVP ਸੰਯੋਗ ਹੈ notification + in-app card: ਨੋਟੀਫਿਕੇਸ਼ਨ ਧਿਆਨ ਖਿੱਚਦੀ ਹੈ; ਐਪ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਫਾਇਰ ਹੋਇਆ ਅਤੇ ਕਿਉਂ।
ਇੱਕ ਸਧਾਰਣ ਸਥਾਨ-ਆਧਾਰਿਤ ਰਿਮਾਇੰਡਰ ਐਪ ਨੂੰ ਵੀ guardrails ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਇਹ ਸੀਮਾਵਾਂ ਐਪ ਨੂੰ ਸੋਚਵਾਨ ਅਤੇ ਬੇ-ਸ਼ੋਰ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਫੀਚਰ ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ "ਚਲ ਰਿਹਾ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਪਹਿਲੇ ਵਰਜਨ ਲਈ ਕੁਝ ਮਾਪਯੋਗ ਸਿਗਨਲਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਜੇ ਇਹ ਨੰਬਰ ਸੁਧਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਅਗਲੇ ਟਰਿਗਰ ਟਾਈਪ, ਵਿਜੇਟ, ਅਤੇ ਹੋਰ ਸਮਾਰਟ ਸ਼ੈਡਿਊਲਿੰਗ ਜੋੜਨ ਦਾ ਹੱਕ ਕਮਾਈਦੇ ਹੋ।
ਤੁਹਾਡੇ ਟੈਕ ਚੋਣਾਂ ਦਾ ਇੱਕ ਪ੍ਰਸ਼ਨ ਵੱਲੋਂ ਨਿਰਣਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਐਪ ਕਿੰਨੀ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ ਠਿਕਾਣੇ-ਸਬੰਧੀ ਟਰਿਗਰ ਨੂੰ ਨੋਟਿਸ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦਿਖਾ ਸਕਦੀ ਹੈ—ਬਿਨਾਂ ਬੈਟਰੀ ਖਰਚੇ ਜਾਂ ਯੂਜ਼ਰ ਨੂੰ ਗੁੰਮਰਾਹ ਕੀਤੇ।
Native (iOS with Swift + Core Location, Android with Kotlin + Location APIs) ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਲੋਕੇਸ਼ਨ ਬਿਹੇਵियर, ਸਿਸਟਮ ਸੀਮਾਵਾਂ ਅਤੇ ਡਿਬੱਗਿੰਗ ਲਈ ਸਭ ਤੋਂ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦੇ ਹਨ। ਜੇ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਇਹ ਪਲੇਟਫਾਰਮ ਜਾਣਦੀ ਹੈ ਤਾਂ ਇਹ ਅਕਸਰ ਇਕ “ਸਭ ਥਾਂ ਚੱਲਦਾ” MVP ਲਈ ਤੇਜ਼ ਰਸਤਾ ਹੁੰਦਾ ਹੈ।
Cross-platform (Flutter, React Native) UI ਵਿਕਾਸ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕੋਡਬੇਸ ਰੱਖਦਾ ਹੈ, ਪਰ ਲੋਕੇਸ਼ਨ ਫੀਚਰ ਪਲੱਗਇਨਾਂ 'ਤੇ ਕਾਫੀ ਨਿਰਭਰ ਕਰਨਗੇ। ਇਹ ਸਧਾਰਣ ਐਪ ਲਈ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਬੈਕਗ੍ਰਾਊਂਡ ਸੀਮਾਵਾਂ, ਮੈਨੂਫੈਕਚਰਰ ਖਾਸ ਮਾਮਲੇ, ਜਾਂ OS ਅਪਡੇਟਾਂ ਨਾਲ ਮੁਸ਼ਕਲਾਂ ਭੇਟਦੇ ਹੋ ਤਾਂ timeline ਸੁੱਟ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਨੈਟਿਵ ਕੋਡ ਵਿੱਚ ਪੈਚਿੰਗ करनी ਪੈ ਸਕਦੀ ਹੈ।
ਪ੍ਰੈਗਟਿਕਲ ਨਿਯਮ: ਜੇ ਸਥਾਨ ਟਰਿਗਰ ਮੇਨ ਫੀਚਰ ਹਨ, ਤਾਂ ਨੈਟਿਵ ਨੂੰ ਡੀਫਾਲਟ ਮੰਨੋ, ਜੇ ਤੱਕ ਤੁਹਾਡੀ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਚੁਣੇ ਹੋਏ cross-platform ਸਟੈਕ ਵਿੱਚ ਸਥਾਨ-ਭਾਰ apps ਭੇਜ ਰਹੀ ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਪ੍ਰੋਟੋਟਾਇਪ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਜਾਂ ਪਹਿਲੀ ਵਰਜਨ ਛੇਤੀ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ), ਤਾਂ Koder.ai ਵਰਗਾ ਚੈਟ-ਆਧਾਰਿਤ ਪਲੇਟਫਾਰਮ ਤੁਸੀਂ ਦੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਅਕਸਰ Flutter ਲਈ ਵਰਕਿੰਗ ਐਪ ਜਨਰੇਟ ਕਰਦਾ, ਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ React ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਦਾ ਵਿਕਲਪ ਵੀ।
MVP ਲਈ, ਛੋਟਾ ਰੱਖੋ:
ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਆਫਲਾਈਨ ਵਰਤੋਂ ਨੈਚਰਲ ਤੌਰ 'ਤੇ ਸਹਾਇਕ ਬਣਾਉਂਦੀ ਹੈ: ਰਿਮਾਇੰਡਰ ਬਿਨਾਂ ਨੈੱਟ ਸਿਗਨਲ ਦੇ ਵੀ ਕੰਮ ਕਰਨਗੇ।
ਤੁਸੀਂ ਬੈਕਐਂਡ ਜੋੜੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਮਲਟੀ-ਡਿਵਾਈਸ ਸੁੰਕ, ਸ਼ੇਅਰਡ ਲਿਸਟਾਂ (ਪರਿਵਾਰ / ਟੀਮ), ਐਨਾਲਿਟਿਕਸ, ਜਾਂ ਸਰਵਰ-ਚਲਿਤ ਤਜਰਬੇ ਦੀ ਲੋੜ ਹੋਵੇ। ਨਹੀਂ ਤਾਂ, ਬੈਕਐਂਡ ਲਾਗਤ, ਪ੍ਰਾਈਵੇਸੀ ਸਰਫੇਸ, ਅਤੇ ਫੇਲਯੂਰ ਮੋਡ ਵਧਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬੈਕਐਂਡ ਜੋੜਦੇ ਹੋ, ਸੀਮਾ ਸਾਫ਼ ਰੱਖੋ: ਸਿਰਫ ਉਹੀ ਆਬਜੈਕਟ ਸੰਭਾਲੋ ਜੋ sync ਲਈ ਲੋੜੀਂਦੇ ਹਨ, ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਟਰਿਗਰ ਮੁਲਾਂਕਣ ਨੂੰ ਡਿਵਾਈਸ ਤੇ ਰੱਖੋ।
ਮੁੱਖ ਆਬਜੈਕਟ ਸਪਸ਼ਟ ਅਤੇ ਸਾਦੇ ਰੱਖੋ:
ਇਸ ਮਾਡਲ ਨਾਲ, ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਿਨਾਂ ਮੁੱਖ ਫਾਊਂਡੇਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ।
ਲੋਕੇਸ਼ਨ ਫੀਚਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਉਸ ਸਮੇਂ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਪਰਮਿਸ਼ਨ ਮੰਗਦੇ ਹੋ। ਲੋਕ "ਲੋਕੇਸ਼ਨ" ਨੂੰ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕਰ ਰਹੇ—ਉਹ ਅਣਿਛਿੱਤਤਾ ਨੂੰ ਨਾਂਹ ਕਰ ਰਹੇ। ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਲਕੁਲ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਓ ਕਿ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਕਦੋਂ।
OS ਡਾਇਲਾਗ ਨਾਲ ਸਿੱਧਾ ਅੱਗੇ ਨਾ ਜਾਓ। ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਣ, ਇੱਕ-ਸਕ੍ਰੀਨ ਵਿਆਖਿਆ ਦਿਖਾਓ:
ਇਸਨੂੰ ਸਾਦਾ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਛੋਟਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਸ਼ਾਇਦ ਫੀਚਰ ਬਹੁਤ ਵਿਸ਼ਾਲ ਹੈ।
iOS 'ਤੇ, ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰ When In Use ਅਤੇ Always ਵਿਚਕਾਰ ਚੁਣਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਐਪ ਬੰਦ ਹੋਣ 'ਤੇ ਵੀ ਪ੍ਰੌਂਪਟ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ Always ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਇਹ ਸਮਝਾਓ—ਅਤੇ ਇਹ ਬੇਨਤੀ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ ਉਪਭੋਗਤਾ ਨੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ location prompt ਬਣਾਇਆ ਹੋਵੇ।
Android 'ਤੇ, ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ foreground ਲੋਕੇਸ਼ਨ ਦੇਂਦੇ ਹਨ, ਫਿਰ ਤੁਸੀਂ ਅਲੱਗ ਤੌਰ 'ਤੇ background ਮੰਗਦੇ ਹੋ। ਇਸਨੂੰ ਦੋ-ਕਦਮ ਦਾ trust flow ਸਮਝੋ: foreground ਦੇ ਨਾਲ ਵਿਜ਼ੂਅਲ ਵੈਲਯੂ ਦਿਖਾਓ, ਫਿਰ background ਦੀ ਬੇਨਤੀ ਜਦੋਂ ਲਾਜ਼ਮੀ ਹੋਵੇ।
ਕਈ ਫੋਨਾਂ 'ਤੇ precise ਜਾਂ approximate ਚੋਣ ਹੁੰਦੀ ਹੈ। ਜੇ ਉਪਭੋਗਤਾ approximate ਪਸੰਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਨੁਭਵ ਨਾ ਟੁੱਟਣ ਦਿਓ। ਬਦਲੋ:
Fallback ਦਿਓ: ਸਮੇਂ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ, ਮੈਨੁਅਲ “I’m here” ਚੈਕ-ਇਨ, ਜਾਂ ਐਡਰੈੱਸ ਪਿਕਰ ਜੋ ਸਿਰਫ ਐਪ ਖੁਲ੍ਹਣ 'ਤੇ ਟਰਿਗਰ ਕਰੇ।
ਇੱਕ ਸਾਫ਼ ਰਸਤਾ ਵੀ ਜੋੜੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਮੁੜ-ਚਾਲੂ ਕੀਤੀ ਜਾ ਸਕੇ (ਉਦਾਹਰਨ: settings ਸਕ੍ਰੀਨ ਅਤੇ ਸਿਸਟਮ ਸੈਟਿੰਗ ਖੋਲ੍ਹਣ ਲਈ ਇੱਕ ਬਟਨ)।
ਤੁਹਾਡੇ ਐਪ ਦਾ ਇਹ ਜਾਣਨਾ ਕਿ "ਉਪਭੋਗਤਾ ਕਿੱਥੇ ਹੈ" ਬੈਟਰੀ ਲਾਈਫ ਅਤੇ ਭਰੋਸੇਯੋਗੀ ਲਈ ਸਭ ਤੋਂ ਵੱਡਾ ਫੈਸਲਾ ਹੈ। ਸਧਾਰਣ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟਾਂ ਲਈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਹਲਕਾ ਵਿਕਲਪ ਚਾਹੋਗੇ ਜੋ ਤੱਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਹੀ ਮਹਿਸੂਸ ਹੋਵੇ।
Geofencing ਤੁਹਾਨੂੰ ਜਗ੍ਹਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਵਰਚੁਅਲ ਸਰਹੱਦ ਢਾਂਚਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ (ਸਰਕਲ + ਰੇਡੀਅਸ)। OS "enter" ਅਤੇ "exit" ਘਟਨਾਵਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਜ਼ਰੂਰਤ 'ਤੇ ਹੀ ਐਪ ਨੂੰ ਜਗਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੇ ਪ੍ਰੌਂਪਟ ਜਗ੍ਹਾ-ਆਧਾਰਿਤ ਅਤੇ ਬਾਈਨਰੀ ਹੁੰਦੇ ਹਨ (ਆਉਣਾ/ਛੱਡਣਾ), ਇਹ ਆਈਡੀਅਲ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਵੀ ਆਸਾਨੀ ਨਾਲ ਸਮਝ ਆਉਂਦੀ ਹੈ: “ਅਸੀਂ ਇਸ ਜਗ੍ਹਾ ਨੂੰ ਨੇੜੇ ਆਉਣ 'ਤੇ ਸੂਚਿਤ ਕਰਾਂਗੇ।”
ਸਧਾਰਣ ਡਿਫਾਲਟ:
ਜੇ ਤੁਹਾਨੂੰ "ਮੈਂ ਕਰੀਬ-ਕਿੱਥੇ ਹਾਂ" ਅੱਪਡੇਟਾਂ ਦੀ ਲੋੜ ਹੈ (ਜਿਵੇਂ ਨੇੜੇ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰਨ ਲਈ), ਤਾਂ significant location change ਇੱਕ ਵਿਚਕਾਰਲਾ ਢੰਗ ਹੈ। ਡਿਵਾਈਸ ਅਪਡੇਟ ਸਿਰਫ਼ ਉਸ ਸਮੇਂ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਮਹੱਤਵਪੂਰਨ ਹਿਲਚਲ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ—ਇਹ ਲਗਾਤਾਰ GPS ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਾਫੀ ਘੱਟ ਬੈਟਰੀ ਖਪਤ ਕਰਦਾ ਹੈ।
Continuous GPS tracking ਸਿਰਫ ਉਹਨਾਂ ਦੇ ਲਈ ਰੱਖੋ ਜਿਹੜਿਆਂ ਨੂੰ ਰੀਅਲ-ਟਾਈਮ ਜਰੂਰਤ ਹੈ (ਫਿਟਨੈਸ ਟ੍ਰੈਕਿੰਗ, ਨੈਵੀਗੇਸ਼ਨ)। ਇਹ ਬੈਟਰੀ ਜ਼ਲਦੀ ਖਰਚ ਕਰ ਸਕਦਾ ਹੈ, ਪ੍ਰਾਈਵੇਸੀ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੀ ਰਿਮਾਇੰਡਰ-ਸਟਾਈਲ ਦੀਆਂ ਲੋੜਾਂ ਲਈ overkill ਹੈ।
ਪ੍ਰਯੋਗੀ ਦ੍ਰਿਸ਼ਟੀ: ਮੁੱਖ ਨਿਯਮਾਂ ਲਈ geofences ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਜੇ ਜ਼ਰੂਰਤ ਹੋਵੇ ਤਾਂ ਵਾਧੂ ਭਰੋਸੇਯੋਗੀ ਲਈ significant-change ਜੋੜੋ।
ਇੱਕ ਸਥਾਨ ਟਰਿਗਰ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਪ੍ਰੌਂਪਟ ਸਹੀ ਸਮੇਂ ਨਜ਼ਰ ਆਵੇ ਅਤੇ ਕਾਰਵਾਈ ਲਈ ਆਸਾਨ ਹੋਵੇ। ਡਿਲਿਵਰੀ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ: ਸਮਾਂ, ਸ਼ਬਦ, ਅਤੇ "ਅਗਲਾ ਟੈਪ" ਪਤਾ ਲਗਾਉਣ ਵਾਰਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਬਹੁਤ ਸਾਰੇ MVPs ਲਈ, local notifications ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਂਪਟਾਂ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹਨ। ਇਹ ਡਿਵਾਈਸ 'ਤੇ ਹੀ ਫਾਇਰ ਹੁੰਦੇ ਹਨ, ਸਰਵਰ ਬਿਨਾਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਧਾਰਨ ਰੱਖਦੇ ਹਨ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਾਕਈ ਸਰਵਰ-ਚਲਿਤ ਵਰਤੋਂ ਚਾਹੀਦੀ ਹੈ—ਜਿਵੇਂ ਕਿ ਡਿਵਾਈਸਾਂ ਵਿੱਚ sync, ਰਿਮੋਟ ਤਬਦੀਲੀਆਂ, ਜਾਂ ਟੀਮ-ਜੁੜੇ ਪ੍ਰੌਂਪਟ—ਤਦ ਹੀ push notifications ਵਰਤੋ।
ਇੱਕ ਸਹਾਇਕ ਯਾਦ ਵੀ ਜਦ ਵਾਰ-ਵਾਰ ਆਵੇ ਤਾਂ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ। ਸਧਾਰਨ ਨਿਯਮ ਜੋ ਤੁਸੀਂ ਆਸਾਨ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ:
ਇਹ ਨਿਯਮ ਤੁਹਾਡੇ ਐਪ ਦੀ ਸਹੀ-ਪਹਿਚਾਣ ਨੂੰ ਬਚਾਉਂਦੇ ਹਨ: ਘੱਟ ਨਾਰਾਜ਼ ਯੂਜ਼ਰ, ਘੱਟ ਅਣਇੰਸਟਾਲ।
ਇੱਕ ਚੰਗੀ ਪ੍ਰੌਂਪਟ ਇਹ ਜਵਾਬ ਦਿੰਦੀ: “ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?” ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਕੁਝ ਕਰੋ:
ਜਦੋਂ ਉਪਭੋਗਤਾ ਪ੍ਰੌਂਪਟ ਤੋਂ ਐਪ ਖੋਲ੍ਹਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਫੋਕਸਡ ਸਕ੍ਰੀਨ 'ਤੇ ਲੈਂਡ ਕਰੋ: ਰਿਮਾਇੰਡਰ ਟੈਕਸਟ, ਤੁਰੰਤ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਇੱਕ ਨਰਮ ਪੁਸ਼ਟੀਕਰਨ (“Done” ਸਥਿਤੀ)। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਭਰੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਨਾ ਸੁੱਟੋ—ਉਹ ਅਨੁਭਵ interrupt ਦੀ ਤੀਬਰਤਾ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ ਉਸ ਵੇਲੇ ਹੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਉਸਨੂੰ ਸੈਟ ਕਰ ਸਕੇ। ਲਕੜੀ ਹੈ ਕਿ “create prompt” ਫਲੋ ਮੋਹਣੀ, ਮਨਮਿੱਤ ਅਤੇ ਤੇਜ਼ ਹੋਵੇ—ਖ਼ਾਸ ਕਰਕੇ ਕਿਉਂਕਿ ਜਗ੍ਹਾ ਚੁਣਨਾ ਗੈਰ-ਟੈਕਨੀਕਲ ਯੂਜ਼ਰਾਂ ਲਈ ਸਭ ਤੋਂ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।
ਫਲੋ ਨੂੰ ਤਿੰਨ ਫੈਸਲਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ:
ਇੱਕ ਵਰਕਯੋਗ ਡਿਫਾਲਟ ਸੁਨੇਹਾ ਫੀਲਡ ਭਰ ਕੇ ਰੱਖਣਾ ਚੰਗਾ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ: “Remember to…”) ਅਤੇ ਇੱਕ ਸਮਝਦਾਰ ਰੇਡੀਅਸ ਪਹਿਲੋਂ ਹੀ ਚੁਣਿਆ ਹੋਵੇ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਮੀਟਰ/ਫੁੱਟ ਸਮਝਣ ਵਿੱਚ ਫਸਣ ਨਾ ਪਏ।
ਕਈ ਤਰੀਕੇ ਦਿਓ, ਪਰ ਸਾਰਾ ਕੁਝ ਇਕੱਠਾ ਨਾ ਦਿਖਾਓ।
Search first ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਵਿਕਲਪ ਹੈ: places autocomplete ਨਾਲ ਲੋਕ "Home", "Whole Foods", ਜਾਂ ਇਕ ਪਤਾ ਜ਼ਰੂਰ ਲੱਭ ਲੈਂਦੇ ਹਨ ਬਿਨਾਂ ਨਕਸ਼ੇ 'ਤੇ ਫਿਡਲ ਕਰਨ ਦੇ।
ਦੋ ਸਹਾਇਕ ਵਿਕਲਪ ਜੋੜੋ:
ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰ ਮੀਟਰਾਂ ਵਿੱਚ ਨਹੀਂ ਸੋਚਦੇ। ਇੱਕ ਸਲਾਈਡਰ ਵਰਤੋ plain-language ਲੇਬਲਾਂ ਨਾਲ (ਉਦਾਹਰਨ: “ਬਹੁਤ ਨੇੜੇ”, “ਨੇੜੇ”, “ਕੁਝ ਬਲਾਕ”) ਜਦੋਂ ਕਿ ਨੰਬਰ ਵੀ ਦਿੱਸਦਾ ਰਹੇ। ਇੱਕ ਛੋਟਾ preview ਜਿਵੇਂ “Triggers within ~200 m of this place” ਅਚਾਨਕੀ ਘਟਨਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਜਦ ਪ੍ਰੌਂਪਟ ਮੌਜੂਦ ਹਨ, ਲੋਕਾਂ ਨੂੰ ਜ਼ਰੂਰੀ ਕੰਟਰੋਲ ਚਾਹੀਦੇ ਹਨ ਬਿਨਾਂ ਡਿਲੀਟ ਕੀਤੇ:
ਲਿਸਟ ਨੂੰ ਸਕੈਨਬਲ ਰੱਖੋ: ਜਗ੍ਹਾ ਦਾ ਨਾਮ, ਇੱਕ-ਪੰਗਤੀ ਸੁਨੇਹਾ preview, ਅਤੇ ਇਕ ਨਰਮ ਸਥਿਤੀ (“Enabled”, “Paused”, “Archived”) ਦਿਖਾਓ।
ਸਥਾਨ UX ਅਕਸਰ ਛੋਟੇ ਨਕਸ਼ਾ ਕੰਟਰੋਲਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ—ਇਸ ਲਈ accessibility ਦਾ ਧਿਆਨ ਜ਼ਰੂਰੀ ਹੈ:
ਇਕ ਐਸਾ ਸੈਟਅਪ ਜੋ ਤੇਜ਼, ਸਪਸ਼ਟ ਅਤੇ ਵਾਪਸੀਯੋਗ ਹੋਵੇ, support issues ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰਾਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਸਥਾਨ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਬਣਾਉਣ ਜਾਰੀ ਰੱਖਣ।
ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ ਐਪ ਨੂੰ ਉਹਨਾਂ ਹਾਲਾਤਾਂ 'ਚ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦ ਉਪਭੋਗਤਾ ਕੋਲ ਕਦੇ-ਕਦੇ ਸਿਗਨਲ, ਘੱਟ ਬੈਟਰੀ, ਜਾਂ ਦਿਨਾਂ ਤੱਕ ਐਪ ਨਹੀਂ ਖੋਲ੍ਹੀ ਹੋਵੇ। ਇਨ੍ਹਾਂ ਸੀਮਾਵਾਂ ਲਈ ਪਹਿਲਾਂ ਹੀ ਡਿਜ਼ਾਇਨ ਕਰਨ ਨਾਲ ਤੁਹਾਡੀ "ਸਧਾਰਣ" ਐਪ ਅਣਭਰੋਸੇਯੋਗ ਬਣਨ ਤੋਂ ਬਚਦੀ ਹੈ।
ਡਿਵਾਈਸ ਨੂੰ ਸਚਾਈ ਦਾ ਸੋਰਸ ਮੰਨੋ। ਪ੍ਰੌਂਪਟ ਲੋਕਲ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ (ਉਦਾਹਰਨ: ਨਾਮ, latitude/longitude, radius, enabled state, last-edited timestamp)। ਜਦ ਯੂਜ਼ਰ ਪ੍ਰੌਂਪਟ ਸੋਧਦਾ ਹੈ, ਤੁਰੰਤ ਲੋਕਲ ਸਟੋਰੇਜ 'ਤੇ ਲਿਖੋ।
ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ account ਜਾਂ sync ਜੋੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ “outbox” ਟੇਬਲ ਵਿੱਚ ਬਦਲਾਵਾਂ ਦੀ ਕਤਾਰ ਰੱਖੋ: create/update/delete ਕਾਰਵਾਈਆਂ ਟਾਈਮਸਟੈਂਪਾਂ ਦੇ ਨਾਲ। ਜਦ ਨੈੱਟਵਰਕ ਉਪਲਬਧ ਹੋਵੇ, queued actions ਭੇਜੋ ਅਤੇ ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਬਾਅਦ ਹੀ ਉਹਨਾਂ ਨੂੰ completed ਨਿਸ਼ਾਨ ਲਗਾਓ।
iOS ਤੇ Android ਦੋਹਾਂ ਐਪਾਂ ਨੂੰ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੇ ਹਨ ਉੱਤੇ ਸੀਮਾਵਾਂ ਲਗਾਉਂਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜੇ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਬਾਰ-ਬਾਰ ਨਹੀਂ ਖੋਲ੍ਹਦੇ।
ਭਰੋਸੇਯੋਗ ਕੁਰੀਤੀ ਇਹ ਹੈ ਕਿ OS-managed ਟਰਿਗਰ (geofences / region monitoring) 'ਤੇ ਨਿਰਭਰ ਕਰੋ ਨਾ ਕਿ ਆਪਣਾ background loop ਚਲਾਓ। OS-managed ਟਰਿਗਰ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਸਹੀ ਸਮੇਂ ਜਗਾਉਣ ਲਈ ਬਣਾਏ ਗਏ ਹਨ ਬਿਨਾਂ ਇਹਦੇ ਕਿ ਐਪ ਸਾਰੇ ਦਿਨ active ਰਹੇ।
ਸਾਵਧਾਨ ਰਹੋ:
ਅਕਸਰ GPS polling ਬੈਟਰੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰਦਾ ਹੈ। ਇਹ ਨੂੰ ਪ੍ਰਤੀਗਿਆ ਕਰੋ:
ਜੇ ਪ੍ਰੌਂਪਟਾਂ ਨੂੰ ਕਈ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸੋਧਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ ਸਾਦਾ conflict ਨੀਤੀ ਫੈਸਲ ਕਰੋ। ਇੱਕ ਪ੍ਰਾਇਗਟਿਕੱਲ ਨਿਰਧਾਰਨ "last write wins" ਸਰਵਰ ਟਾਈਮਸਟੈਂਪ ਦੇ ਨਾਲ ਹੈ, ਜਦਕਿ ਲੌਕਲ edit timestamp ਟ੍ਰਾਂਸਪੈਰਨਸੀ ਅਤੇ ਡਿਬੱਗ ਲਈ ਰੱਖੋ। ਮਿਟਾਉਣ ਲਈ, tombstone ਰਿਕਾਰਡ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਤਾਂ ਕਿ ਪੁਰਾਣਾ ਡਿਵਾਈਸ sync ਕਰਨ 'ਤੇ ਮਿਟਾਇਆ ਗਿਆ ਪ੍ਰੌਂਪਟ ਮੁੜ ਨਾ ਆ ਜਾਵੇ।
ਸਥਾਨ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਨਿੱਜੀ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਯੂਜ਼ਰ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਇਸ ਗੱਲ 'ਤੇ ਅਨੁਸਾਰ ਮਾਪਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਡੇਟੇ ਨਾਲ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹੋ। ਚੰਗੀ ਪ੍ਰਾਈਵੇਸੀ ਕੇਵਲ ਇੱਕ ਨੀਤੀ ਨਹੀਂ—ਇਹ ਪ੍ਰੋਡਕਟ ਡਿਜ਼ਾਈਨ ਹੈ।
ਘੱਟੋ-ਘੱਟ ਡੇਟਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਇੱਕ ਰਿਮਾਇੰਡਰ ਸਿਰਫ ਇੱਕ ਜਗ੍ਹਾ 'ਤੇ ਆਉਣ 'ਤੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਚਾਲ-ਚਲਨ ਇਤਿਹਾਸ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ।
ਜੇ ਤੁਹਾਡੀ ਐਪ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਫੈਸਲਾ ਕਰ ਸਕਦੀ ਹੈ "trigger met, show prompt", ਤਾਂ ਐਸਾ ਕਰੋ। ਓਨ-ਡਿਵਾਈਸ ਪ੍ਰੋਸੈਸਿੰਗ ਇਕਸposure ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਪਾਲਣਾ ਸੌਖਾ ਬਣਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਘੱਟ ਡੇਟਾ ਫ਼ੋਨ ਤੋਂ ਬਾਹਰ ਜਾ ਰਹੀ ਹੈ।
ਕਾਨੂੰਨੀ ਲਿਖਤ ਦੇ ਪਿੱਛੇ ਪਰਾਈਵੇਸੀ ਨਾ ਛਪਾਓ। onboarding ਅਤੇ settings ਵਿੱਚ ਇੱਕ ਛੋਟੀ, ਸਾਦੀ ਭਾਸ਼ਾ ਵਾਲੀ ਸਕ੍ਰੀਨ ਜੋੜੋ।
ਸੇਵ ਕੀਤੀਆਂ ਜਗ੍ਹਾਂ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਡੇਟਾ ਵਰਤੋਂ ਨੂੰ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਇਕੱਤਰ ਕਰ ਰਹੇ ਹੋ।
ਲੋਕੇਸ਼ਨ ਫીਚਰ ਆਮ ਤੌਰ 'ਤੇ "ਤੁਹਾਡੇ ਫੋਨ 'ਤੇ ਚੱਲਦੇ ਹਨ" ਪਰ ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਅਸਫਲ ਕਿਉਂਕਿ ਹਾਲਾਤ ਗਡ਼ਬੜ ਹੁੰਦੀਆਂ ਹਨ: ਕਮਜ਼ੋਰ ਸਿਗਨਲ, ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸ, ਬੈਟਰੀ ਸੀਮਾਵਾਂ, ਅਤੇ ਅਣਪੇਸ਼ਕੀਲ ਚਲਣ। ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਯੋਜਨਾ ਇਹਨਾਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਜਲਦੀ ਹੀ ਦਰਸਾਉਂਦੀ ਹੈ।
ਘੱਟੋ-ਘੱਟ ਕੁਝ ਦਰਜਨ ਦੌੜ ਬਾਹਰ ਕਰੋ with a normal build (not a debug-only shortcut).
ਨੋਟ ਰੱਖੋ: ਉਮੀਦ ਕੀਤੀ ਟਰigger ਟਾਈਮ, ਅਸਲੀ ਟਰigger ਟਾਈਮ, ਅਤੇ ਕੀ ਐਪ ਖੁੱਲਾ ਸੀ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸੀ, ਜਾਂ force-closed ਸੀ।
ਅਸਲ-ਦੁਨੀਆ ਟੈਸਟ ਜ਼ਰੂਰੀ ਹਨ, ਪਰ ਉਹ ਹੌਲੇ ਹੁੰਦੇ ਹਨ। ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ:
Mocking ਤੁਹਾਨੂੰ ਦੀੜੇ ਕੰਮ ਨੂੰ ਦੁਹਰਾਉਂਣ ਅਤੇ ਬੱਗ ਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।
Location behavior Android vendors ਅਤੇ OS versions ਦੇ ਅਨੁਸਾਰ ਵਿੱਅਕ ਹੁੰਦੀ ਹੈ। ਸ਼ਾਮਿਲ ਕਰੋ:
ਲੌਗਾਂ ਨੂੰ ਡਿਬੱਗਿੰਗ ਟੂਲ ਵਜੋਂ ਵਰਤੋ, location ਡਾਇਰੀ ਵਜੋਂ ਨਹੀਂ। ਘਟਨਾਵਾਂ ਜਿਵੇਂ ਲਿਖੋ:
ਰਾਅ coordinates ਜਾਂ ਲੰਮੇ ਲੋਕੇਸ਼ਨ ਟਰੇਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇ ਡੀਬੱਗ ਲਈ location ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਵਿਕਲਪੀ, ਛੋਟਾ-ਸਮੇਂ ਲਈ, ਅਤੇ ਯੂਜ਼ਰ-ਨਿਯੰਤਰਿਤ ਰੱਖੋ।
ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਐਪ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਵਾਉਣਾ ਜ਼ਿਆਦਾਤਰ ਸਪਸ਼ਟੀਕਰਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ: ਤੁਹਾਨੂੰ ਲੋਕੇਸ਼ਨ ਕਿਉਂ ਐਕਸੈਸ ਕਰਦੇ ਹੋ, ਖ਼ਾਸ ਕਰਕੇ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ, ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦਿਖਾਉਣਾ ਕਿ ਤੁਸੀਂ ਡੇਟੇ ਨਾਲ ਸਤਿਕਾਰਪੂਵਕ ਵਿਵਹਾਰ ਕਰੋਗੇ।
iOS (App Store):
Apple ਤੁਹਾਡੇ ਪਰਮਿਸ਼ਨ ਟੈਕਸਟ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ location permission “purpose strings” ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ “Always” ਲੋਕੇਸ਼ਨ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਤਿਆਰ ਰਹੋ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕਿ “While Using” ਨਾਲ ਰਿਮਾਇੰਡਰ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ।
Android (Google Play):
Google background location ਲਈ ਕੜਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਦੀ ਬੇਨਤੀ ਕਰੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ Play Console 'ਚ ਇੱਕ declaration ਪੂਰੀ करनी ਪਵੇਗੀ ਜੋ ਫੀਚਰ ਅਤੇ foreground-only ਐਕਸੈਸ ਕਿਉਂ ਕਾਫੀ ਨਹੀਂ ਹੈ ਉਸ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਤੁਹਾਨੂੰ Data Safety ਵੇਰਵੇ ਵੀ ਪੂਰੇ ਕਰਨੇ ਪੈਣਗੇ (ਤੁਸੀਂ ਕੀ ਇਕੱਤਰ ਕਰਦੇ ਹੋ, ਇਹ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ, ਕੀ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ)।
App Store / Play Store listing ਵਿੱਚ, ਇੱਕ ਵਾਕ ਵਿੱਚ ਯੂਜ਼ਰ ਲਾਭ ਦੱਸੋ:
“Get reminders when you arrive at the grocery store, so you don’t forget your list.”
ਇਹ ਵੀ ਜ਼ਿਕਰ ਕਰੋ:
ਸਧਾਰਣ ਰੋਲਆਉਟ ਕ੍ਰਮ:
crash rates, permission opt-in rates, ਅਤੇ ਟਰਿਗਰਾਂ ਦੀ ਭਰੋਸੇਯੋਗੀ ਟਰੈਕ ਕਰੋ।
ਇੱਕ ਸਥਾਨ-ਅਧਾਰਤ ਪ੍ਰੌਂਪਟ MVP ਭੇਜਣਾ ਐੱਧਾ ਕੰਮ ਹੈ। ਬਾਕੀ ਕੰਮ ਇਹ ਸਾਬਤ ਕਰਨਾ ਹੈ ਕਿ ਇਹ ਅਸਲੀ ਲੋਕਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ ਤਕਨੀਕਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲਾ ਕਦਮ ਲਵੋ—ਅਨੁਮਾਨਾਂ 'ਤੇ ਨਹੀ।
ਕੁਝ ਇਵੈਂਟ ਸਬ ਤੋਂ ਪਹਿਲਾਂ ਟਰੈਕ ਕਰੋ:
ਇਹ ਤਿੰਨ ਹੀ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਯੂਜ਼ਰ ਪ੍ਰੌਂਪਟ ਸੈੱਟ ਕਰ ਰਹੇ ਹਨ, ਐਪ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਲੋਕੇਸ਼ਨ ਡਿਟੈਕਟ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਮੁੱਖ ਫੀਚਰ ਚੱਲਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬੈਕਐਂਡ ਨਾਲ ਬਣਾਓ, ਤਾਂ analytics privacy-first ਰੱਖੋ: ਜਿੱਥੇ ਸੰਭਵ ਹੋ aggregation ਕਰੋ, ਰਾ ਕੋਆਰਡੀਨੇਟਾਂ ਤੋਂ ਬਚੋ, ਅਤੇ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਰਿਕਾਰਡ ਕਰਦੇ ਹੋ।
ਉੱਚ ਟਰਿਗਰ ਗਿਣਤੀ ਵੀ ਖਰਾਬ ਅਨੁਭਵ ਦਿਖਾ ਸਕਦੀ ਹੈ। ਕੁਝ ਗੁਣਵੱਤਾ ਸੰਕੇਤ ਜੋੜੋ:
MVP ਲਈ ਇੱਕ عملي هدف ਹੈ false ਅਤੇ missed triggers ਨੂੰ ਹਫ਼ਤੇ ਦਰ ਹਫ਼ਤੇ ਘਟਾਉਣਾ।
ਪਹਿਲੀ ਬਣਤ ਦੇ ਬਾਅਦ ਚੱਲ ਰਹੇ ਕੰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਹ tooling ਵਿਚਾਰ ਕਰੋ ਜੋ boilerplate ਅਤੇ iteration ਸਮਾਂ ਘਟਾਉਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai snapshots ਅਤੇ rollback ਨਾਲ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ source code export ਵੀ ਦੇ ਸਕਦਾ ਹੈ—ਜੋ OS ਅਤੇ ਡਿਵਾਈਸ permutations ਟੈਸਟ ਕਰਨ ਵੇਲੇ ਉਪਯੋਗੀ ਹੈ।
ਉਹ ਫੀਚਰ ਪਹਿਲਾਂ ਰੱਖੋ ਜੋ ਦੁਬਾਰਾ ਵਰਤੋਂ ਵਧਾਉਂਦੇ ਹਨ:
ਇਕ ਸਥਾਨ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਉਹ ਯਾਦ ਦਿਵਾਉਣ ਵਾਲਾ ਸੁਨੇਹਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਦੇ "ਕਿੱਥੇ" ਹੋਣ 'ਤੇ ਟਰਿੱਗਰ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ "ਕਦੋਂ"।
ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਇੱਕ ਮਜ਼ਬੂਤ MVP ਭਰੋਸੇਯੋਗੀ ਅਤੇ ਸਪਸ਼ਟ ਰਿਹਾਇਸ਼ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਹੁੰਦਾ ਹੈ:
ਇਸ ਨਾਲ ਸੈਟਅਪ ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ ਅਤੇ “ਨੋਟੀਫਿਕੇਸ਼ਨ chaos” ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤ ਕਰੋ Enter + time windows ਨਾਲ।
ਜਦੋਂ ਤੁਸੀਂ ਭਰੋਸਾ ਅਤੇ UX ਸਾਬਤ ਕਰ ਲਓ, ਤਦ Exit ਜਾਂ Dwell ਜੋੜੋ।
ਸਹੀ ਅਤੇ ਭਰੋਸੇਯੋਗ ਛੇਤੀ ਲਈ ਡਿਫ਼ਾਲਟ ਵਰਤੋਂ:
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਤਿ-ਛੋਟੇ ਜਾਂ ਬਹੁਤ ਵੱਡੇ ਰੇਡੀਅਸ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ।
ਸੋਧਿਆ ਹੋਇਆ ਫ਼ਲੋ:
ਜੇ ਮਨਜ਼ੂਰੀ ਨਾਹ ਮਿਲੇ, ਤਾਂ fallback ਦਿਓ: ਸਮੇਂ-ਅਧਾਰਤ ਰਿਮਾਇੰਡਰ ਜਾਂ “ਐਪ ਖੁੱਲਾ ਹੋਣ 'ਤੇ ਚਲਾਓ” ਵਰਗੇ ਵਿਕਲਪ।
ਅਨੁਭਵ ਟੁੱਟਣ ਨਾ ਦਿਉ—ਇਸਨੂੰ ਢਾਲੋ:
ਐਪ ਐਸਾ ਡਿਜ਼ਾਇਨ ਕਰੋ ਕਿ ਉਹ ਘੱਟ ਨਿਰਦੇਸ਼ਤਾ ਨਾਲ ਵੀ ਕੰਮ ਕਰੇ।
ਸਧਾਰਣ arrive/leave ਰਿਮਾਇੰਡਰਾਂ ਲਈ, OS-managed geofencing/region monitoring ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਪਹਿਲਾਂ geofences, ਫਿਰ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ significant-change ਜੋੜੋ।
ਪ੍ਰਾਰੰਭ ਵਿੱਚ offline-first ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ sync ਜੋੜਦੇ ਹੋ, ਤਾਂ edits ਨੂੰ queue ਕਰੋ ਅਤੇ ਸਾਦਾ conflict ਨੀਤੀ ਵਰਤੋ (ਉਦਾਹਰਨ: last write wins + tombstones for deletes)।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਅਤੇ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਣਾਓ:
ਇਸ ਨਾਲ fatigue ਘਟਦੀ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਭਰੋਸਾ ਵੱਧਦਾ ਹੈ।
ਰਿਅਲ-ਵਰਲ্ড ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਟੈਸਟ ਦੋਹਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਲੌਗਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਇਤਿਹਾਸ ਨਾ ਸਟੋਰ ਕਰੋ (ਟਾਈਮਸਟੈਂਪ, ਟਰਿਗਰ ਟਾਈਪ, prompt ID ਆਦਿ ਲਿਖੋ)।