23 ਜੂਨ 2025·8 ਮਿੰਟ
ਆਨਲਾਈਨ ਲਰਨਿੰਗ ਅਤੇ ਕੋਰਸਾਂ ਲਈ ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਇੱਕ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਣਾਉ: ਕੋਰਸ ਸਟ੍ਰਕਚਰ, ਵੀਡੀਓ, ਕੁਇਜ਼, ਭੁਗਤਾਨ, ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ iOS/Android ਲਈ ਲਾਂਚ ਕਦਮ।
ਇੱਕ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਣਾਉ: ਕੋਰਸ ਸਟ੍ਰਕਚਰ, ਵੀਡੀਓ, ਕੁਇਜ਼, ਭੁਗਤਾਨ, ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ iOS/Android ਲਈ ਲਾਂਚ ਕਦਮ।
ਇੱਕ ਲਰਨਿੰਗ ਐਪ "ਸਭ ਲਈ" ਨਹੀਂ ਹੋ ਸਕਦਾ ਅਤੇ ਫਿਰ ਵੀ ਵਧੀਆ ਮਹਿਸੂਸ ਕਰੇ। ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਫੀਚਰਾਂ 'ਤੇ ਸੋਚਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ ਬਣਾ ਰਹੇ ਹੋ, ਤੁਸੀਂ ਕਿਹੜਾ ਦਰਦ ਦੂਰ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਇੱਕ ਮੁੱਖ ਗਰੁੱਪ ਚੁਣੋ ਤਾਂ ਕਿ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲੇ ਆਸਾਨ ਹੋ ਜਾਣ:
ਇਸਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ: “ਇਹ ਐਪ ਵਿਆਸਤ ਕਾਰਜਕਾਰੀ ਬਾਲਗਾਂ ਲਈ ਹੈ ਜੋ ਆਪਣੇ ਕਮਿਊਟ ਵਿੱਚ 5–10 ਮਿੰਟ ਵਿੱਚ ਸਿੱਖਦੇ ਹਨ।”
ਨਤੀਜਾ-ਕੇਂਦ੍ਰਤ ਰਹੋ (ਫੀਚਰ ਨਹੀਂ)। ਉਦਾਹਰਨ:
ਜੇ ਕੋਈ ਫੀਚਰ ਐਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਉਹ ਸੰਭਵਤ: MVP ਲਈ ਨਹੀਂ।
ਇੱਕ “ਨਾਰਥ ਸਟਾਰ” ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਲਕੜੀ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ:
ਇਸ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਪਾਰिभਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: “% ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਦਾ ਜੋ 48 ਘੰਟਿਆਂ ਵਿੱਚ Lesson 1 ਮੁਕੰਮਲ ਕਰਦੇ ਹਨ”)।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ ਅਨੁਕੂਲ ਹੋ ਰਹੇ ਹੋ:
ਤੁਹਾਡਾ ਮਾਡਲ ਆਨਬੋਰਡਿੰਗ, ਪ੍ਰਾਈਸਿੰਗ ਸਕ੍ਰੀਨਾਂ, ਅਤੇ ਦਿਨ ਇੱਕ ਤੋਂ ਤੁਹਾਡੇ ਨਾਪ-ਜੋਖ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਏਗਾ।
ਫੀਚਰਾਂ ਜਾਂ ਸਕ੍ਰੀਨਾਂ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਐਪ ਵਿੱਚ "ਸਿੱਖਣਾ" ਕਿਸ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ ਲਰਨਿੰਗ ਅਨੁਭਵ ਤੁਹਾਡੇ ਲਈ ਸਹੀ ਕੋਰਸ ਸਟ੍ਰਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਅਤੇ ਯਾਦਗਾਰ ਵੀਡੀਓਜ਼ ਦਾ ਬੇਤਰਤੀਬਾ ਕਲੈਕਸ਼ਨ ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਗਿਆਦਾਤਮਕ ਲਰਨਿੰਗ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਪੇਚੀਦਾਂ ਫਲੋ ਫੋਲੋ ਕਰਦੇ ਹਨ। ਇੱਥੇ ਇੱਕ ਛੇਤੀ ਨਕਸ਼ਾ ਬਣਾ ਲਓ ਤਾਂ ਕਿ ਹਰ ਕਦਮ ਦਾ ਉਦੇਸ਼ ਹੋਵੇ:
Discover course → enroll → learn → test → earn certificate.
ਹਰ ਪੜਾਅ ਲਈ ਨੋਟ ਕਰੋ ਕਿ ਲਰਨਰ ਨੂੰ ਮੋਬਾਈਲ 'ਤੇ ਕੀ ਦੇਖਣ ਅਤੇ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, “discover” ਨੂੰ ਸਰਚ, ਫਿਲਟਰ ਅਤੇ ਪ੍ਰੀਵਿਊ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਜਦਕਿ “learn” ਨੂੰ ਭਰੋਸੇਯੋਗ ਪਲੇਬੈਕ ਅਤੇ ਸਪਸ਼ਟ “ਅਗਲਾ ਲੈਸਨ” ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੈ।
ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ ਫਾਰਮੈਟ ਚੁਣੋ, ਫਿਰ ਸਹਾਇਕ ਫਾਰਮੈਟ ਤਦ ਹੀ ਸ਼ਾਮਲ ਕਰੋ ਜੇ ਉਹ ਲਕੜੀ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹੋਣ।
ਸਾਫ਼ ਹਾਇਰਾਰਕੀ ਲਰਨਰਾਂ ਨੂੰ "ਉਹ ਕਿੱਥੇ ਹਨ" ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਸਮੱਗਰੀ ਨੂੰ ਵੱਡੀ ਪੱਧਰ 'ਤੇ ਸੰਗਠਿਤ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਆਮ ਮਾਡਲ:
Categories → courses → modules → lessons.
ਨਾਮਕਰਨ ਵਿੱਚ ਲਗਾਤਾਰ ਰਹੋ ("chapters," "units," ਅਤੇ "modules" ਨੂੰ ਮਿਲਾ-ਮਿਲਾ ਕੇ ਨਾ ਵਰਤੋ ਜਦ ਤੱਕ ਉਹ ਵੱਖਰੇ ਮਤਲਬ ਨਾ ਰੱਖਦੇ ਹੋਣ). ਮੋਬਾਈਲ 'ਤੇ, ਲਰਨਰਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਇਹ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਇੱਕ ਵਧੀਆ ਕੋਰਸ ਵੀ ਮੋਬਾਈਲ-ਫ੍ਰੈਂਡਲੀ ਡਿਲਿਵਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਨਿਰਾਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ:
ਇਹ ਚੋਣਾਂ ਤੁਹਾਡੇ ਕੋਰਸ ਸਟ੍ਰਕਚਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਆਫਲਾਈਨ ਮੋਡ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਲੈਸਨ ਵੱਖਰੇ ਯੂਨਿਟ ਹੋਣ, ਨਾ ਕਿ ਲੰਬੇ ਸਟਰੀਮਸ।
ਵਧੀਆ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਇਹ ਨਹੀਂ ਕਿ ਇਸ ਵਿੱਚ ਕਿੰਨੇ ਫੀਚਰ ਹਨ—ਇਹ ਇਸ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਹਰ ਰੋਲ ਆਪਣਾ ਕੰਮ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕੇ: ਸਿੱਖਣਾ, ਪੜ੍ਹਾਉਣਾ, ਜਾਂ ਕਾਰੋਬਾਰ ਚਲਾਉਣਾ। ਹੇਠਾਂ ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਫੀਚਰ ਚੈਕਲਿਸਟ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਆਨਲਾਈਨ ਕੋਰਸ ਐਪ ਜਾਂ LMS ਮੋਬਾਈਲ ਐਪ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸਮਾਰਟ ਆਨਬੋਰਡਿੰਗ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਸਾਈਨ ਅਪ (ਈਮੇਲ, Apple/Google), ਰੁਚੀਆਂ ਚੁਣੋ, ਅਤੇ ਇਕ ਛੋਟਾ "ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ" ਦਿਖਾਓ। ਇਸ ਦੇ ਬਾਅਦ, ਐਸੈੰਸ਼ਲ ਖੋਜ ਅਤੇ ਗਤੀਸ਼ੀਲਤਾ ਬਾਰੇ ਹਨ।
engagement ਕੋਈ ਗਿਮਿਕ ਨਹੀਂ—ਇਹ friction ਘਟਾਉਂਦਾ ਹੈ।
ਕੋਰਸ ਬਣਾਉਣ ਵਾਲੀ ਐਪ ਲਈ, ਕ੍ਰੀਏਟਰ ਵਰਕਫਲੋ ਲਰਨਰ ਅਨੁਭਵ ਜਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਤਨਾ ਹੀ ਅਹਮ ਹੈ।
ਭਰੋਸਾ ਫੀਚਰਾਂ ਨਾਲ ਤੁਰੰਤ ਰੂਪ ਤਬਦੀਲੀ ਅਤੇ ਰਿਟੇਸ਼ਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ MVP ਲਈ eLearning ਐਪ ਡਿਵੈਲਪਮੈਂਟ ਕਰ ਰਹੇ ਹੋ, ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ: ਕੈਟਾਲੋਗ → ਖਰੀਦ/ਦਾਖ਼ਲਾ → ਲੈਸਨ ਪਲੇਅਰ → ਪ੍ਰਗਤੀ → ਬੇਸਿਕ ਇੰਸਟ੍ਰਕਟਰ ਅਪਲੋਡਸ। ਬਾਕੀ ਸਭ ਕੁਝ ਕੋਰ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਬਾਅਦ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਉਸ ਵੇਲੇ ਸਫਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਐਪ ਅਸਾਨ ਮਹਿਸੂਸ ਹੋਵੇ: ਲਰਨਰ ਤੇਜ਼ੀ ਨਾਲ ਰੀਜ਼ਮ ਕਰ ਸਕੇ, ਅਗਲਾ ਲੈਸਨ ਸਕਿੰਟਾਂ ਵਿੱਚ ਮਿਲ ਜਾਵੇ, ਅਤੇ ਕਦੇ ਵੀ “ਮੈਂ ਕਿੱਥੇ ਹਾਂ?” ਨਾ ਸੋਚੇ। ਇੱਕ ਸਾਫ਼ ਸਟ੍ਰਕਚਰ ਅਤੇ ਕੁਝ ਲਗਾਤਾਰ ਪੈਟਰਨ ਫੈਂਸੀ ਸਕ੍ਰੀਨਾਂ ਨਾਲੋਂ ਵਧੀਆ ਹੁੰਦੇ ਹਨ।
ਚਾਰ ਮੁੱਖ ਖੇਤਰਾਂ ਨਾਲ ਬਾਟਮ ਨੈਵੀਗੇਸ਼ਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ: Home, Search, My Learning, ਅਤੇ Profile। ਇਹ ਆਮ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਕ ਟੈਪ 'ਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ “ਬੈਕ ਬਟਨ” ਥਕਾਵਟ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
My Learning ਵਿੱਚ, ਸਰਵਪ੍ਰਥਮ ਐਕਟਿਵ ਕੋਰਸ ਦਿਖਾਓ ਅਤੇ “Continue” ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਕਾਰਵਾਈ ਬਣਾਓ। ਲਰਨਰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ 3–5 ਮਿੰਟ ਦੇ ਸੈਸ਼ਨ ਲਈ ਐਪ ਖੋਲ੍ਹਦੇ ਹਨ—ਤੇਜ਼ ਰੀ-ਐਂਟਰੀ ਲਈ optimize ਕਰੋ।
ਦ੍ਰਿਸ਼ਯਤਾ ਤੇ ਪੌਲੀਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਕ੍ਰੀਨ ਵਾਇਰਫਰੇਮ ਕਰੋ ਜੋ ਲਰਨਿੰਗ ਨਤੀਜਿਆਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ:
ਇਹ ਸਕ੍ਰੀਨਾਂ ਤੁਹਾਡੇ LMS ਮੋਬਾਈਲ ਐਪ ਲਈ ਟੋਨ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਫੀਚਰ ਕ੍ਰੀਪ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ।
ਲੰਬੇ ਪੜ੍ਹਨ ਅਤੇ ਵੀਡੀਓ ਸਮੱਗਰੀ ਲਈ accessibility "ਅਚ্ছে ਹੋਣੀ" ਨਹੀਂ—ਲਾਜ਼ਮੀ ਹੈ।
ਪੜ੍ਹਨ ਯੋਗ ਟਾਈਪੋਗ੍ਰਾਫੀ ਵਰਤੋਂ (ਬਹੁਤ ਛੋਟੀ ਲਿਪੀ ਤੋਂ ਬਚੋ), ਮਜ਼ਬੂਤ ਕੰਟ੍ਰਾਸਟ, ਅਤੇ ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ। Dynamic Type (iOS) ਅਤੇ ਫੋਂਟ ਸਕੇਲਿੰਗ (Android) ਸਹਾਇਤਾ ਕਰੋ। ਬਟਨ ਅਤੇ ਫਾਰਮ ਫੀਲਡਾਂ ਨੂੰ ਸਕ੍ਰੀਨ ਰੀਡਰਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਓ, ਅਤੇ ਸਹੀ/ਗਲਤ ਜਵਾਬ ਦਰਸਾਉਣ ਲਈ ਕੇਵਲ ਰੰਗ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ।
ਛੋਟੇ ਫੋਨਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਟੈਬਲੇਟ 'ਤੇ ਸਕੇਲ ਕਰੋ। ਖਾਸ ਕਰਕੇ ਲੈਸਨ ਪਲੇਅਰ ਅਤੇ ਕੁਇਜ਼ ਵਿੱਚ ਦਿੱਖ-ਪੱਖ (orientation) ਪਰਖੋ। ਇੱਕ-ਹੱਥ ਵਰਤੋਂ, ਕਮਿਊਟ ਦਾ ਚਮਕ, ਅਤੇ ਵਿਚਕਾਰ-ਵਿਚ-ਧਿਆਨ ਹੋਣ ਦੀਆਂ ਹਾਲਤਾਂ ਲਈ ਕੰਟ੍ਰੋਲਜ਼ ਪਹੁੰਚਯੋਗ ਅਤੇ ਪ੍ਰਗਤੀ ਹਮੇਸ਼ਾ ਦਰਸ਼ਾਏ ਜਾਵੇ।
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਮੋਬਾਈਲ ਐਪ MVP ਲਈ ਹੋਰ ਡੀਪ UX ਚੈਕਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਆਪਣੇ ਪ੍ਰੋਡਕਟ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਿਯਮਾਂ ਦਾ ਰਨਿੰਗ ਸੈੱਟ ਰੱਖੋ ਅਤੇ ਹਰ ਡਿਜ਼ਾਈਨ ਰਿਵਿਊ ਦੌਰਾਨ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਵਧੀਆ ਲਰਨਿੰਗ ਐਪ “ਤੁਰੰਤ” ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਅਗਲਾ ਲੈਸਨ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਐਪ ਜਿੱਥੇ ਛੱਡਿਆ ਸੀ ਓਥੇ ਯਾਦ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਅਭਿਆਸ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੈਕਸ਼ਨ ਉਹ ਬਿਲਡਿੰਗ ਬਲਾਕ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ ਓਸ ਅਨੁਭਵ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ।
Adaptive streaming (HLS/DASH) ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਤਾਂ ਕਿ ਐਪ ਸਿੱਧਾ ਲਰਨਰ ਦੀ ਕਨੈਕਸ਼ਨ ਦੇ ਅਨੁਸਾਰ ਕੁਆਲਿਟੀ ਨੂੰ ਬਦਲ ਲਏ। resume playback (ਆਪਣੇ ਆਖਰੀ ਟਾਈਮਸਟੈਂਪ ਤੋਂ ਜਾਰੀ ਰੱਖਣਾ) ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ picture-in-picture ਉਸ ਵੇਲੇ ਸੋਚੋ ਜਦੋਂ ਤੁਹਾਡੇ ਲੈਸਨਾਂ ਨੂੰ ਮਲਟੀਟਾਸਕਿੰਗ ਤੋਂ ਫਾਇਦਾ ਹੋਵੇ।
ਇੱਕ ਛੋਟਾ ਪਰ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ: ਸਪਸ਼ਟ ਲੋਡਿੰਗ ਸਟੇਟਸ ਅਤੇ ਇੱਕ “ਅਗਲਾ ਲੈਸਨ” ਕਾਰਵਾਈ ਦਿਖਾਓ ਤਾਂ ਕਿ ਲਰਨਰ ਵੀਡੀਓ ਖਤਮ ਹੋਣ 'ਤੇ ਬਾਅਦ ਨਾ ਭੱਜੇ।
ਆਫਲਾਈਨ ਪਹੁੰਚ ਅਕਸਰ ਫਰਕ ਬਣਾਉਂਦੀ ਹੈ “ਮੈਂ ਬਾਅਦ ਵਿੱਚ ਸਿੱਖਾਂਗਾ” ਅਤੇ “ਮੈਂ ਟ੍ਰੇਨ 'ਤੇ ਸਿੱਖ ਲਿਆਂਦਾ” ਵਿੱਚ। ਪਹਿਲਾਂ ਨਿਯਮ ਤੈਅ ਕਰੋ:
ਕੁਇਜ਼ retention ਚਲਾਉਂਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਜੇ ਉਹ ਤੇਜ਼ ਅਤੇ ਆਸਾਨ ਹੋਣ। ਕੁਝ ਆਮ ਪ੍ਰਸ਼ਨ ਕਿਸਮਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰੋ (multiple choice, multi-select, true/false, short answer)। ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ, ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਟਾਈਮਰ, ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ, ਅਤੇ ਕੋਸ਼ਿਸ਼ ਸੀਮਾਵਾਂ ਸ਼ਾਮਲ ਕਰੋ।
ਫੀਡਬੈਕ ਨੂੰ ਮਨ-ਭਰਕ ਬਣਾਓ: ਅਭਿਆਸ ਕੁਇਜ਼ ਲਈ ਤੁਰੰਤ ਵਿਆਖਿਆਵਾਂ, ਜਾਂ ਗਰੇਡ ਕੀਤੇ ਟੈਸਟ ਲਈ ਦੇਰ ਨਾਲ ਨਤੀਜੇ।
ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਪਸ਼ਟ ਪੂਰਨ ਨਿਯਮ ਨਾਲ ਜੋੜੋ (ਉਦਾਹਰਨ: 90% ਵੀਡੀਓ ਦੇਖੋ + ਅੰਤਿਮ ਕੁਇਜ਼ ਪਾਸ ਕਰੋ)। ਡਾਊਨਲੋਡ/ਸ਼ੇਅਰ ਵਿਕਲਪ ਅਤੇ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਲਿੰਕ ਦਿਓ ਜੋ ਕੋਈ ਵੀ ਖੋਲ੍ਹ ਕੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਲਾਈਵ ਸੈਸ਼ਨ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਸ਼ੈਡਿਊਲਿੰਗ, ਰਿਮਾਈਂਡਰ, ਮੁਢਲੀ ਹਾਜ਼ਰੀ, ਅਤੇ ਕਲਾਸ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਰਿਕਾਰਡਿੰਗਾਂ ਦੀ ਆਟੋਮੈਟਿਕ ਪਹੁੰਚ।
ਮੋਨਟਾਈਜ਼ੇਸ਼ਨ صرف "ਤੁਸੀਂ ਕਿਵੇਂ ਚਾਰਜ ਕਰਦੇ ਹੋ" ਨਹੀਂ ਹੈ। ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਪੈਕ ਕਰੋ ਤਾਂ ਕਿ ਲਰਨਰ ਖਰੀਦ 'ਤੇ ਭਰੋਸਾ ਮਹਿਸੂਸ ਕਰੇ, ਅਤੇ ਸਪੋਰਟ ਬੀੜੀ ਬਾਅਦ ਵਿੱਚ ਧੱਕਾ ਨਾ ਖਾਏ।
ਸ਼ੁਰੂ ਕਰੋ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਕੇ ਕਿ ਖਰੀਦਣ ਤੋਂ ਫੌਰਨ ਬਾਅਦ ਲਰਨਰ ਨੂੰ ਕੀ ਮਿਲੇਗਾ—ਅਤੇ ਉਹ ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਖਰੀਦ ਤੋਂ ਪਹਿਲਾਂ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ।
ਕੁਝ ਪੈਟਰਨ ਜੋ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ:
ਪਹੁੰਚ ਦੀ ਮਿਆਦ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ: lifetime access, 12 months, ਜਾਂ "ਜਦ ਤੱਕ ਸਬਸਕ੍ਰਾਈਬ ਕੀਤਾ ਹੋਵੇ"। ਅਚਾਨਕ ਝਟਕਿਆਂ ਤੋਂ ਬਚੋ।
ਜ਼ਿਆਦਾਤਰ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ (ਜਾਂ ਮਿਸ਼ਰਣ) ਵਰਤਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕਾਰਪੋਰੇਟ ਜਾਂ ਗਰੁੱਪ ਪਹੁੰਚ ਦੇਣ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਆਪਣੀ ਕੀਮਤ ਮਾਡਲ ਨੂੰ ਫਲੈਕਸਿਬਲ ਰੱਖੋ ਤਾ ਕਿ "ਸੀਟਸ" ਸ਼ਾਮਲ ਕਰ ਸਕੋ ਬਿਨਾਂ ਸਿਸਟਮ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਰਾਹ ਹਨ:
ਆਪਣੇ ਦਰਸ਼ਕ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਲੋੜਾਂ ਦੇ ਅਨੁਸਾਰ ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਆਪਣਾ ਅਕਾਊਂਟ ਸਿਸਟਮ ਐਸਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਖਰੀਦ ਹਰ ਡਿਵਾਈਸ 'ਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਮੱਗਰੀ ਨੂੰ ਅਨਲੌਕ ਕਰੇ।
ਸ਼ੁਰੂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ:
ਇੱਕ ਸਧਾਰਨ MVP ਵੀ “ਬਿਲਿੰਗ” ਸਕ੍ਰੀਨ ਨਾਲ ਲਾਭ ਪਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਖਰੀਦ ਇਤਿਹਾਸ ਅਤੇ ਨਵੀਨੀਕਰਨ ਹਾਲਤ ਦਿਖਾਈ ਦੇਵੇ।
For packaging and pricing guidance, see pricing guidance. If you need help choosing a checkout approach, reach out to our team.
ਤੁਹਾਡੀ ਲਰਨਿੰਗ ਐਪ "ਬਰਿੰਗ" ਫ਼ਾਊਂਡੇਸ਼ਨ 'ਤੇ ਟਿਕੀ ਹੁੰਦੀ ਹੈ: ਯੂਜ਼ਰ ਕੌਣ ਹੈ, ਉਸ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ, ਅਤੇ ਐਪ ਉਹਨਾਂ ਬਾਰੇ ਕੀ ਯਾਦ ਰੱਖਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਸਹੀ ਸ਼ੁਰੂ ਵਿੱਚ ਕਰ ਲਿਆ, ਤਾਂ ਬਾਕੀ—ਕੋਰਸਾਂ, ਕੁਇਜ਼, ਸਰਟੀਫਿਕੇਟ, ਭੁਗਤਾਨ—ਸੌਖੇ ਹੋ ਜਾਉਣਗੇ।
ਅਧਿਕਤਮ ਐਪਾਂ ਇਮੈਲ + ਪਾਸਵਰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕਨਵੀਨੀਅੰਸ ਲੌਗਿਨ ਜੋੜਦੀਆਂ ਹਨ।
ਟਿੱਪ: ਆਪਣੇ ਅਕਾਊਂਟ ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਇੱਕ ਯੂਜ਼ਰ ਇਕ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਕਈ ਲੌਗਿਨ ਤਰੀਕਿਆਂ ਨੂੰ ਲਿੰਕ ਕਰ ਸਕੇ, ਤਾਂ ਕਿ ਡੁਪਲਿਕੇਟ ਅਕਾਊਂਟ ਨਾ ਬਣਨ।
ਸ਼ੁਰੂ ਤੋਂ ਰੋਲ ਸਪਸ਼ਟ ਰੱਖੋ:
ਹਰ ਥਾਂ ਹਾਰਡ-ਕੋਡ ਕਰਨ ਦੀ ਬਜਾਏ, ਐਕਸ਼ਨਾਂ ਨੂੰ ਪਰਮੀਸ਼ਨਾਂ ਨਾਲ ਮੈਪ ਕਰੋ (ਉਦਾਹਰਨ: “create course”, “publish lesson”, “issue certificate”)। ਇਹ ਐਪ ਵਧਣ 'ਤੇ ਗੰਦੇ ਲਾਜ਼ਿਕ ਤੋਂ ਬਚਾਓਂਦਾ ਹੈ।
ਘੱਟੋ-ਘੱਟ, ਇਹ ਇਕਾਈਆਂ ਯੋਜਨਾ ਕਰੋ:
ਪ੍ਰਗਤੀ ਡੇਟਾ ਨੂੰ ਇਵੈਂਟ-ਆਧਾਰਿਤ ਰੱਖੋ (ਉਦਾਹਰਨ: “completed lesson X at time Y”) ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸਾਰਾਂਸ਼ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉ ਸਕੋ।
ਰਿਮਾਈਂਡਰ ਅਤੇ ਕੋਰਸ ਅਪਡੇਟ ਲਈ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਰਤੋਂ; in-app ਐਨਾਊਨਸਮੈਂਟਸ ਉਹ ਸੁਨੇਹੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਮੁੜ ਦੇਖ ਸਕਦਾ ਹੈ। ਰਸੀਦਾਂ ਅਤੇ ਅਕਾਊਂਟ ਰਿਕਵਰੀ ਲਈ ਈਮੇਲ ਵਿਕਲਪਕ ਹਨ ਪਰ ਫਾਇਦੇਮੰਦ।
ਗੋਪਨੀਯਤਾ ਲਈ, ਕੇਵਲ ਜਿਹੜੀ ਜਾਣਕਾਰੀ ਲੋੜੀ ਹੈ ਉਹ ਇਕੱਠੀ ਕਰੋ, ਕਾਰਨ ਸਮਝਾਓ, ਅਤੇ ਮਾਰਕੇਟਿੰਗ ਲਈ ਸਪਸ਼ਟ ਸਮੀਤੀ ਪ੍ਰਾਪਤ ਕਰੋ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਪਸੰਦਾਂ ਨੂੰ ਪ੍ਰਬੰਧ ਕਰਨ ਅਤੇ ਲੋੜ 'ਤੇ ਅਕਾਊਂਟ ਮਿਟਾਉਣ ਦੇ ਆਸਾਨ ਤਰੀਕੇ ਦਿਓ।
ਟੈਕ ਫੈਸਲੇ ਪ੍ਰਾਜੈਕਟ ਨੂੰ ਰੋਕੇਂਦੇ ਹਨ। ਇੱਕ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਲਈ, ਆਪਣਾ ਸਮਾਂ-ਰੇਖਾ, ਬਜਟ, ਅਤੇ ਜੋ ਅਨੁਭਵ ਤੁਸੀਂ ਬਣਾ ਰਹੇ ਹੋ (ਵੀਡੀਓ-ਭਾਰ? ਆਫਲਾਈਨ? ਐਂਟਰਪਰਾਈਜ਼ ਯੂਜ਼ਰ?) ਦੇ ਅਨੁਸਾਰ ਸਧਾਰਨ ਵਿਕਲਪ ਚੁਣੋ।
Native (Swift iOS, Kotlin Android) ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਟਾਪ ਪਰਫਾਰਮੈਂਸ, ਡੀਪ ਡਿਵਾਈਸ ਫੀਚਰ, ਜਾਂ ਬਹੁਤ ਨਿੱਖਰੀ ਆਫਲਾਈਨ ਪਲੇਬੈਕ ਦੀ ਲੋੜ ਹੋਵੇ। ਟਰੇਡ-ਆਫ਼: ਦੋ ਕੋਡਬੇਸ ਹਨ ਇਸ ਲਈ ਲਾਗਤ ਵੱਧਦੀ ਹੈ।
Cross-platform (Flutter ਜਾਂ React Native) ਬਹੁਤ ਸਾਰੇ ਆਨਲਾਈਨ ਕੋਰਸ ਐਪ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਡੀਫਾਲਟ ਹੈ: ਇੱਕ ਸਾਂਝਾ ਕੋਡਬੇਸ, ਤੇਜ਼ iteration, ਅਤੇ ਵੀਡੀਓ, ਕੁਇਜ਼, ਅਤੇ ਡਾਊਨਲੋਡ ਲਈ ਚੰਗੀ ਪ੍ਰਦਰਸ਼ਨ।
PWA (Progressive Web App) ਮੰਗ ਵੈਧਤਾ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਹੈ। ਲਾਈਟਵੇਟ ਲਰਨਿੰਗ ਅਤੇ ਸਮੱਗਰੀ ਬ੍ਰਾਊਜ਼ਿੰਗ ਲਈ ਚੰਗੀ ਹੈ, ਪਰ ਐਪ ਸਟੋਰ ਵਿਤਰਣ ਅਤੇ ਕੁਝ ਬੈਕਗ੍ਰਾਊਂਡ/ਆਫਲਾਈਨ ਵਰਤਾਵਾਂ ਵਿੱਚ ਸੀਮਾਵਾਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਫੁਟਕਾ ਤੇਜ਼ੀ ਨਾਲ ਪਰਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ vibe-coding workflow ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਟੀਮਾਂ ਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਚੈਟ ਵਿੱਚ ਸਕ੍ਰੀਨ ਅਤੇ ਬੈਕਐਂਡ ਲੋੜਾਂ ਵੇਰਵਾ ਕਰਕੇ React ਵੈੱਬ ਐਪ ਜਾਂ Flutter ਮੋਬਾਈਲ ਐਪ ਨਾਲ Go + PostgreSQL ਬੈਕਐਂਡ ਜਨਰੇਟ ਕਰਨ ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਸੋర్స ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਸਮਰਥਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਸਟਮ ਉਤਪਾਦ ਅਤੇ ਮੋਨਟਾਈਜ਼ੇਸ਼ਨ ਮਾਡਲ ਚਾਹੁੰਦੇ ਹੋ, ਆਪਣਾ ਬੈਕਐਂਡ ਬਣਾਉਣਾ (API + ਡੇਟਾਬੇਜ਼) ਤੁਹਾਨੂੰ ਲਚੀਲਾਪਨ ਦਿੰਦਾ: ਯੂਜ਼ਰ ਅਕਾਊਂਟ, enrollments, progress tracking, certificates, ਅਤੇ admin ਟੂਲਸ।
ਜੇ ਤੇਜ਼ੀ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਕਿਸੇ LMS ਨੂੰ ਇੰਟਿਗ੍ਰੇਟ ਕਰਨਾ ਤੇ ਵਿਚਾਰ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਵਧਾਓ। ਤੁਸੀਂ ਕੋਰਸ ਮੈਨੇਜਮੈਂਟ, ਰੋਲ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ “ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ” ਰੱਖਦੇ ਹੋ, ਫਿਰ ਮੋਬਾਈਲ ਫਰੰਟਐਂਡ ਬਣਾਓ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਜੋ ਘੱਟ ਹੁੰਦਾ ਹੈ ਉਸਨੂੰ ਜੋੜੋ (ਕਸਟਮ UI, ਭੁਗਤਾਨ, ਕਮਿਊਨਿਟੀ ਫੀਚਰ)। ਇਹ ਤੁਹਾਡੇ ਪਹਿਲੇ ਰਿਲੀਜ਼ ਲਈ ਜੋਖਮ ਘਟਾ ਸਕਦਾ ਹੈ।
ਵੀਡੀਓ ਲਰਨਿੰਗ ਐਪ ਲਈ, ਮੁੱਖ ਸਰਵਰ ਤੋਂ ਵੀਡੀਓ ਸੇਵਾ ਕਰਨ ਤੋਂ ਬਚੋ। ਵੀਡੀਓ ਹੋਸਟਿੰਗ/ਸਟ੍ਰੀਮਿੰਗ (adaptive bitrate) ਵਰਤੋ, ਸਮੱਗਰੀ ਨੂੰ ਇੱਕ CDN ਦੇ ਪਿੱਛੇ ਰੱਖੋ, ਅਤੇ ਚਿੱਤਰਾਂ ਨੂੰ optimise ਕਰੋ (ਕਾਈ ਸਾਈਜ਼, ਆਧੁਨਿਕ ਫਾਰਮੈਟ)। ਆਫਲਾਈਨ ਮੋਡ ਲਈ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ: ਡਾਊਨਲੋਡ ਕੀਤੇ ਲੈਸਨ ਇੰਕ੍ਰਿਪਟ ਕੀਤੇ ਜਾਂ ਐਕਸੈਸ-ਕੰਟਰੋਲਡ ਹੋਣ ਚਾਹੀਦੇ ਹਨ, ਸਧਾਰਨ ਫਾਈਲਾਂ ਵਜੋਂ ਨਹੀਂ।
ਦਿਨ ਪਹਿਲਾਂ "AI recommendations" ਦੀ ਲੋੜ ਨਹੀਂ। ਸ਼੍ਰੇਣੀਆਂ, ਟੈਗ, ਅਤੇ ਫਿਲਟਰ, ਨਾਲ-ਨਾਲ ਕੋਰਸ ਟਾਈਟਲ ਅਤੇ ਲੈਸਨ ਨਾਂ 'ਤੇ ਬੇਸਿਕ ਸਰਚ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। “ਪ੍ਰਚਲਿਤ” ਅਤੇ “continue learning” ਸੈਕਸ਼ਨ ਜੋੜੋ ਤਾਂ ਕਿ ਐਪ ਸਮਾਰਟ ਮਹਿਸੂਸ ਹੋਵੇ ਬਿਨਾਂ ਭਾਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ।
ਸਭ ਥਾਂ HTTPS, ਟੋਕਨ-ਅਧਾਰਿਤ ਪਰਮਾਣੀਕਰਨ (ਛੋਟੇ-ਆਵਧੀ ਵਾਲੇ access tokens, refresh tokens), ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਐਕਸੈਸ (signed URLs ਜਾਂ authenticated streaming) ਵਰਤੋ। ਮਹੱਤਵਪੂਰਨ ਘਟਨਾਵਾਂ (ਲੌਗਿਨ, ਖਰੀਦ, ਡਾਊਨਲੋਡ) ਲੌਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਮੁੱਦਿਆਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕੋ।
ਵਧੀਆ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਹਰ ਫੀਚਰ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਇੱਕ ਪੂਰਾ, ਭਰੋਸੇਯੋਗ “ਲਰਨਿੰਗ ਲੂਪ” ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਯੂਜ਼ਰ ਮੁਕੰਮਲ ਕਰ ਸਕੇ। ਤੁਹਾਡਾ MVP ਕਿਸੇ ਨੂੰ ਕੋਰਸ ਖੋਜਣ, ਦਾਖ਼ਲਾ ਲੈਣ, ਸਿੱਖਣ, ਅਤੇ ਪ੍ਰਗਤੀ ਦੇਖਣ ਬਿਨਾਂ ਘੇਰਾਵੇ ਦੇ ਸਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪੋਛੋ: “ਇੱਕ ਲਰਨਰ ਨੂੰ ਦਿਨ ਇੱਕ 'ਤੇ ਮੁੱਲ ਦੇਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਸਕ੍ਰੀਨ ਅਤੇ ਫਲੋਜ਼ ਦਾ ਸੈੱਟ ਕੀ ਹੈ?” ਜੇ ਐਪ end-to-end ਪੂਰਾ ਅਨੁਭਵ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਤਾਂ ਤੁਸੀਂ ਜੋ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਉਸ ਬਾਰੇ ਸਿੱਖਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੋਵੇਗੀ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ MVP ਸਕੋਪ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਕਾਫੀ ਹੈ ਮੰਗ ਦੀ, ਕੀਮਤ, ਰਿਟੇਸ਼ਨ, ਅਤੇ ਸਮੱਗਰੀ ਗੁਣਵੱਤਾ ਨੂੰ ਪਰਖਣ ਲਈ—ਜੋ eLearning ਐਪ ਡਿਵੈਲਪਮੈਂਟ ਲਈ ਮੁੱਖ ਹਨ।
ਬਹੁਤ ਸਾਰੇ ਫੀਚਰ ਜ਼ਰੂਰੀ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਪਰ ਪ੍ਰਾਥਮਿਕ ਲੂਪ ਦੀ ਸੱਚੀ ਵੈਧਤਾ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੇ। ਬਾਅਦ ਵਿੱਚ ਦੇਖੋ:
ਤੁਸੀਂ ਆਪਣੇ UX ਨੂੰ ਇਨ੍ਹਾਂ ਲਈ ਥਾਂ ਛੱਡ ਕੇ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਜੋੜਨਾ ਆਸਾਨ ਹੋਵੇ।
ਇੱਕ ਐਸਾ ਬੈਕਲੌਗ ਬਣਾੋ ਜੋ ਅਮਲਯੋਗ ਹੋਵੇ:
ਇੱਕ ਸਪਸ਼ਟ ਰੋਡਮੈਪ ਤੁਹਾਡੇ mobile app MVP ਨੂੰ ਫੋਕਸ ਰੱਖਦਾ ਹੈ, ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਸਹਿਮਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਨੂੰ ਮੰਦ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
Analytics ਅਤੇ ਪ੍ਰਗਤੀ ਟ੍ਰੈਕਿੰਗ ਦੋ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ: ਕੀ ਲਰਨਰ ਸਫਲ ਹੋ ਰਹੇ ਹਨ? ਅਤੇ ਕੀ ਐਪ ਕਾਰੋਬਾਰ ਵਜੋਂ ਸਫਲ ਹੈ? ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਰੈਂਡਮ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਬਚੋਗੇ ਜੋ ਵਰਤੇ ਨਹੀਂ ਜਾਂਦਾ।
Analytics ਨੂੰ ਇੱਕ “ਮਿਨੀਮਮ ਵਾਇਬਲ ਲੈਂਗਵੇਜ” ਵਜੋਂ ਸਮਝੋ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਬੋਲਦਾ ਹੈ। ਆਮ ਸ਼ੁਰੂਆਤੀ ਇਵੈਂਟ ਸੈੱਟ:
ਇਵੈਂਟ ਨਾਂ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ course_id, lesson_id, ਅਤੇ device/OS ਵਰਜਨ ਵਰਗੀਆਂ ਪ੍ਰਾਪਰਟੀਆਂ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸੈਗਮੈਂਟ ਕਰ ਸਕੋ।
ਰੌਅ ਇਵੈਂਟ ਗਿਣਤੀਆਂ ਇਹ ਨਹੀਂ ਦੱਸਦੀਆਂ ਕਿ ਲਰਨਿੰਗ ਅਨੁਭਵ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਸਪਸ਼ਟ ਅਤੇ ਆਸਾਨ-ਸਮਝ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਜੇ ਇੱਕ ਲੈਸਨ 'ਤੇ ਤੇਜ਼ ਡ੍ਰੌਪ ਦਿਖਾਈ ਦੇਵੇ, ਪਹਿਲਾਂ ਉਸ ਵਿਸ਼ੇ ਦੀ ਸਮੀਖਿਆ ਕਰੋ (ਵੀਡੀਓ ਦੀ ਲੰਬਾਈ, ਸਪਸ਼ਟਤਾ, ਪ੍ਰੀ-ਰਿਕੁਇਜ਼ਿਟਸ) ਬਦਲਾਵਾਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਰੈਵੇਨਿਊ ਹੇਲਥ ਸਮਝਣ ਲਈ ਟਰੈਕ ਕਰੋ:
ਸੰਖਿਆਵਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕੀ ਹੋਇਆ; ਫੀਡਬੈਕ ਕਿਉਂ ਹੋਇਆ ਦੱਸਦਾ ਹੈ। ਹਲਕਾ-ਫੁਲਕਾ ਚੈਨਲ ਸ਼ਾਮਲ ਕਰੋ:
ਹਰ ਫੀਡਬੈਕ ਆਈਟਮ ਨੂੰ course/lesson IDs ਨਾਲ ਜੋੜਨਾ ਯਕੀਨੀ ਬਣਾਓ ਤਾਂ ਜੋ ਇਹ ਕਾਰਵਾਈਯੋਗ ਹੋਵੇ।
A/B ਟੈਸਟ ਨੂੰ ਧਿਆਨ ਨਾਲ ਯੋਜੋ ਅਤੇ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਚਲਾਓ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਾਫੀ ਯੂਜ਼ਰ ਹੋਣ। ਉੱਚ-ਪ੍ਰਭਾਵ, ਨੀਚ-ਖਤਰੇ ਟੈਸਟਾਂ (ਜਿਵੇਂ onboarding copy) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਇੱਕ-ਕਦਮ ਵਿੱਚ ਇੱਕ ਟੈਸਟ ਰਖੋ, ਅਤੇ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ “positive result ਖੋਜਣ” ਵਾਲੀ ਗਲਤੀ ਨਾ ਕਰੋ।
ਟੈਸਟਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਲਰਨਿੰਗ ਐਪ ਭਰੋਸਾ ਕਮਾਉਂਦੀ ਹੈ। ਜੇ ਲੈਸਨ ਲੋਡ ਨਹੀਂ ਹੁੰਦੇ, ਪ੍ਰਗਤੀ ਰੀਸੈਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਕੁਇਜ਼ ਗਲਤ ਜਵਾਬਾਂ ਨੂੰ ਗਲਤ ਮਾਰਕ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਲਰਨਰ ਵਾਪਸ ਨਹੀਂ ਆਉਣਗੇ—ਭਾਵੇਂ ਸਮੱਗਰੀ ਕਿੰਨੀ ਵੀ ਚੰਗੀ ਹੋਵੇ।
ਹਰ ਰੋਜ਼ ਦੀਆਂ ਫਲੋਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਵਿਭਿੰਨ ਡਿਵਾਈਸਾਂ (ਛੋਟੇ/ਵੱਡੇ ਸਕ੍ਰੀਨ, ਪੁਰਾਣੇ ਫੋਨ, ਟੈਬਲੇਟ) ਅਤੇ ਦੋਨੋ iOS ਅਤੇ Android ਲਈ ਮੁੱਖ OS ਵਰਜ਼ਨਾਂ 'ਤੇ ਟੈਸਟ ਕਰੋ। accessibility ਚੈੱਕਸ਼ਾਮਲ ਕਰੋ: ਸਕੇਲ ਕਰਨਯੋਗ ਲਿਪੀ, ਸਕ੍ਰੀਨ ਰੀਡਰ ਲੇਬਲ, ਯਥੇਚਿਤ ਕੰਟ੍ਰਾਸਟ, ਅਤੇ ਵਰਤਣਯੋਗ ਟੈਪ ਟਾਰਗੇਟ। ਇੱਕ ਕੋਰਸ ਐਪ ਟਿਕਾਊ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਲੰਬੇ ਸੈਸ਼ਨਾਂ ਲਈ, ਸਿਰਫ਼ “ਮੇਰੇ ਫੋਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ” ਨਹੀਂ।
ਮਾਪਯੋਗ ਟਾਰਗੇਟ ਸੈੱਟ ਕਰੋ ਅਤੇ ਜੇ ਉਹ ਪੂਰੇ ਨਾ ਹੋਣ ਤਾਂ ਬਿਲਡ ਫੇਲ ਕਰੋ:
ਪ੍ਰਵਾਨਗੀ ਦੀ ਆਖਰੀ ਸਮੀਖਿਆ ਕਰੋ: ਤੁਸੀਂ ਕੀ ਇਕੱਠਾ ਕਰਦੇ ਹੋ, ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। auth ਫਲੋਜ਼, session timeouts, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਨਿੱਜੀ ਕੋਰਸ ਸਮੱਗਰੀ ਗਲਤੀ ਨਾਲ ਸਾਂਝੀ ਲਿੰਕਾਂ ਜਾਂ cached ਫਾਈਲਾਂ ਰਾਹੀਂ ਖੁਲਾਸਾ ਨਹੀਂ ਹੁੰਦੀ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਟੈਸਟਿੰਗ ਤੋਂ ਥੱਕ ਚੁੱਕੇ ਹੋ, ਤਾਂ ਯੂਜ਼ਰ ਜਲਦੀ ਹੀ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰਨਗੇ।
ਇੱਕ ਵਧੀਆ ਲਰਨਿੰਗ ਐਪ ਫਿਰ ਵੀ ਲਾਂਚ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਯੂਜ਼ਰ ਸਮਝ ਨਾ ਪਾਵੇ ਕਿ ਇਹ ਕੀ ਕਰਦੀ ਹੈ, ਸਾਈਨ ਅਪ ਸਾਫ਼ ਨ ਹੋਵੇ, ਜਾਂ ਪਹਿਲੇ ਦਿਨ ਮੁੱਦੇ ਆਉਣ। ਲਾਂਚ ਨੂੰ ਇੱਕ ਯੋਜਨਾ ਸਮਝੋ: ਸਟੋਰ ਤਿਆਰੀ, ਆਨਬੋਰਡਿੰਗ, ਅਤੇ ਇੱਕ ਸਥਿਰ ਓਪਰੇਸ਼ਨ ਰੁਟੀਨ।
ਸਬਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੀਆਂ ਸਟੋਰ ਐਸੈਟਸ ਨੂੰ ਇੱਕ ਛੋਟੀ ਲੈਂਡਿੰਗ ਪੇਜ਼ ਵਾਂਗ ਤਿਆਰ ਕਰੋ।
ਸਟੋਰ ਰਿਵਿਊ ਸਮੇਂ, ਉਮਰ ਰੇਟਿੰਗ, ਗੋਪਨੀਯਤਾ ਖੁਲਾਸੇ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਜਾਂ ਟ੍ਰਾਇਲ ਦੇ ਸ਼ਬਦਾਵਲੀ ਦਾ ਧਿਆਨ ਰੱਖੋ। ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਸਟੋਰ ਟੈਕਸਟ ਇੰਸਟਾਲ ਤੋਂ ਬਾਅਦ ਦਿਖਣ ਵਾਲੇ ਵਸਤੂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਇੱਕ ਫੇਜ਼ਵਾਰ ਰੋਲਆਊਟ ਜੋਖਮ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਵਾਸਤਵਿਕ ਫੀਡਬੈਕ ਦਿੰਦਾ ਹੈ ਪਹਿਲਾਂ ਮਾਰਕੇਟਿੰਗ ਖਰਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
Closed beta → public release → first content expansion ਇੱਕ ਸਧਾਰਨ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕ੍ਰਮ ਹੈ।
ਆਪਣੀ ਆਨਬੋਰਡਿੰਗ ਨੂੰ ਯੂਜ਼ਰ ਨੂੰ ਕਈ ਮਿੰਟਾਂ ਵਿੱਚ ਪਹਿਲਾ ਲੈਸਨ ਮਿਲਣ ਲਈ ਦਿਸ਼ਾ ਦਿਓ।
ਇਸਨੂੰ ਕੋਚ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰੋ, ਫ਼ਾਰਮ ਨਹੀਂ:
ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਅਸਲ ਕੰਮ ਲਗਾਤਾਰਤਾ ਹੈ।
ਆਪਣੇ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਵਰਕਫਲੋ ਸੈੱਟ ਕਰੋ:
ਅਖੀਰ ਵਿੱਚ, ਸaptਾਹਿਕ ਐਪ ਹੇਲਥ ਸਮੀਖਿਆ ਨਿਰਧਾਰਤ ਕਰੋ: ਸਿਖਰ ਸ਼ਿਕਾਇਤਾਂ, ਸਿਖਰ ਲੋਪ-ਆਫ਼ ਕਦਮ, ਅਤੇ ਅਗਲੀ ਸੁਧਾਰ ਜੋ ਭੇਜਣਾ ਹੈ। ਓਪਰੇਸ਼ਨ ਹੀ ਤੁਹਾਡੇ ਲਾਂਚ ਨੂੰ ਰਿਟੇਸ਼ਨ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਹੋਰ ਇੱਕ-ਵਾਕ ਦਾ ਦਰਸ਼ਕ ਬਿਆਨ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ (ਉਦਾਹਰਨ: “ਆਜਾ-ਬਜੀ ਕਰਦੇ ਵੱਖਰੇ ਵ੍ਰਕਿੰਗ ਬਾਲਗ ਜੋ 5–10 ਮਿੰਟ ਦੀਆਂ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਸਿੱਖਦੇ ਹਨ”). ਫਿਰ ਓਹ 3 ਮੁੱਖ ਨਤੀਜੇ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਦੇਵੋਗੇ ਅਤੇ ਇੱਕ ਨਾਰਥ-ਸਟਾਰ ਮੈਟ੍ਰਿਕ (ਜਿਵੇਂ “ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਦਾ % ਜੋ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਪੈਠਕ 1 ਪੂਰਾ ਕਰਦੇ ਹਨ”).
ਜੇ ਕੋਈ ਫੀਚਰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਉਹ ਨਤੀਜੇ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਉਹ MVP ਲਈ ਸੰਭਵਤ: ਨਹੀਂ ਹੈ।
ਹਾਂ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਜਨਰਿਕ ਲੱਗਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਅਤੇ ਇੱਕ ਸਪੋਰਟ ਦਰਸ਼ਕ ਚੁਣੋ ਤਾਂ ਜੋ ਉਤਪਾਦ ਫ਼ੈਸਲੇ ਇਕਰੂਪ ਰਹਿਣ।
ਉਦਾਹਰਨ:
ਕੋਰ ਫਲੋ ਪ੍ਰਾਇਮਰੀ ਗਰੁੱਪ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਰੋਲ-ਨਿਰਧਾਰਿਤ ਫੀਚਰ ਬਾਅਦ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ, ਨਤੀਜਾ-ਕੇਂਦ੍ਰਤ ਸੈੱਟ:
ਇਹਨਾਂ ਨੂੰ ਸਿੱਖਿਆਰਥੀ ਨਤੀਜਿਆਂ ਵਜੋਂ ਰੱਖੋ ਨਾ ਕਿ ਫੀਚਰਾਂ ਵਜੋਂ, ਤਾਂ ਜੋ ਸਕੋਪ ਸਪੀਟ ਰਹੇ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਬਿਜ਼ਨਸ ਲਕੜੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ ਅਤੇ ਉਸ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
ਆਮ ਵਿਕਲਪ:
ਉਦਾਹਰਨ ਪਰਿਭਾਸ਼ਾ: “ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਜੋ ਸਾਈਨ-ਅਪ ਤੋਂ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਲੈਸਨ 1 ਪੂਰਾ ਕਰਦੇ ਹਨ।”
ਸਾਫ਼ ਹਾਇਰਾਰਕੀ ਨੈਵੀਗੇਸ਼ਨ, ਪ੍ਰਗਤੀ, ਅਤੇ ਸਕੇਲਿੰਗ ਨੂੰ ਸਹਿਯੋਗ ਦੇਂਦੀ ਹੈ। ਇੱਕ ਆਮ ਸਟ੍ਰਕਚਰ ਹੈ:
ਮੋਬਾਈਲ 'ਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਯੂਜ਼ਰ ਹਮੇਸ਼ਾ:
ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਫਾਰਮੈਟ ਚੁਣੋ ਅਤੇ ਫਿਰ ਕੇਵਲ ਓਹੀ ਦੂਜੇ ਫਾਰਮੈਟ ਜੋ ਲਕੜੀ ਦੇ ਹਿੱਤ ਵਿੱਚ ਹੋ, ਸ਼ਾਮਲ ਕਰੋ.
ਆਮ ਚੋਣਾਂ:
“Blended” ਉਸ ਵੇਲੇ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਟ੍ਰਕਚਰ ਹਰ ਲੈਸਨ 'ਚ ਲਗਾਤਾਰ ਰਹੇ।
ਸ਼ੁਰੂ ਤੋਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਸਮਗਰੀ ਦੀ ਰਚਨਾ, ਸਟੋਰੇਜ, ਅਤੇ DRM/ਸੁਰੱਖਿਆ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ ਤੈਅ ਕਰੋ:
ਆਫਲਾਈਨ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਲੈਸਨ ਸਪਸ਼ਟ ਅਤੇ ਅਲੱਗ-ਅਲੱਗ ਇਕਾਈਆਂ ਹੋਣ।
ਇੱਕ ਮਜ਼ਬੂਤ MVP ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
ਸਟ੍ਰੀਕਸ, ਕਮਿਊਨਿਟੀ ਅਤੇ ਉन्नਤ ਵਿਸ਼ਲੇਸ਼ਣ ਬਾਅਦ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ ਬਿਨਾਂ ਕੋਰ ਲੂਪ ਨੂੰ ਭੰਗ ਕੀਤੇ।
ਛੋਟੇ, ਸਥਿਰ ਇਵੈਂਟ ਸੈੱਟ ਨੂੰ ਟਰੈਕ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਕੋਰਸ/ਲੈਸਨ IDs ਨਾਲ ਜੋੜੋ.
ਇਵੇਂਟਾਂ ਜਿਵੇਂ:
ਫਿਰ ਕੰਪਲੀਸ਼ਨ ਰੇਟ, ਸਮਾਪਤੀ ਦਾ ਸਮਾਂ (median), ਅਤੇ ਲੈਸਨ ਦਰ ਲੋਪ-ਆਫ਼ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ।
ਇਹ ਤੁਹਾਡੇ ਸਮੇਂ, ਬਜਟ, ਅਤੇ ਲੋੜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.
ਉਸ ਅਨੁਸਾਰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਭੇਜ ਰਹੇ ਹੋ (ਵਿਡੀਓ-ਭਾਰ, ਆਫਲਾਈਨ, enterprise SSO ਆਦਿ)।