25 ਸਤੰ 2025·8 ਮਿੰਟ
ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਲਈ ਲੋਡਿੰਗ, ਗਲਤੀ ਅਤੇ ਖਾਲੀ ਅਵਸਥਾਵਾਂ ਵਿੱਚ ਇਕਸਾਰਤਾ
ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਲੋਡਿੰਗ, ਗਲਤੀ, ਅਤੇ ਖਾਲੀ ਅवਸਥਾਵਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣ ਲਈ ਇੱਕ ਸਧਾਰਣ ਸਿਸਟਮ ਸਿਖੋ, ਤਾਂ ਕਿ AI-ਜਨਰੇਟ ਕੀਤੀ UI ਸੁਚੱਜੀ ਰਹੇ ਅਤੇ ਆਖਰੀ ਪਾਲਿਸ਼ ਘੱਟ ਲੱਗੇ।
ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਲੋਡਿੰਗ, ਗਲਤੀ, ਅਤੇ ਖਾਲੀ ਅवਸਥਾਵਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣ ਲਈ ਇੱਕ ਸਧਾਰਣ ਸਿਸਟਮ ਸਿਖੋ, ਤਾਂ ਕਿ AI-ਜਨਰੇਟ ਕੀਤੀ UI ਸੁਚੱਜੀ ਰਹੇ ਅਤੇ ਆਖਰੀ ਪਾਲਿਸ਼ ਘੱਟ ਲੱਗੇ।
ਲੋਡਿੰਗ, ਗਲਤੀ, ਅਤੇ ਖਾਲੀ ਅਵਸਥਾਵਾਂ ਉਹ ਸਕ੍ਰੀਨ (ਜਾਂ ਛੋਟੇ UI ਬਲਾਕ) ਹਨ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਐਪ ਇੰਤਜ਼ਾਰ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਕੁਝ ਫੇਲ ਹੋ ਗਿਆ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਦਰਸਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਆਮ ਗੱਲਾਂ ਹਨ: ਨੈੱਟਵਰਕ ਧੀਮਾ ਹੋ ਸਕਦਾ ਹੈ, ਮਨਜ਼ੂਰੀਆਂ ਰੋਕੀ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਨਵੀਆਂ ਖਾਤਿਆਂ ਵਿੱਚ ਜ਼ੀਰੋ ਡੇਟਾ ਹੁੰਦਾ ਹੈ।
ਇਹ ਗੜਬੜ ਇਸ ਲਈ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਅਕਸਰ ਇਹ ਅਖੀਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜੇ ਜਾਂਦੇ ਹਨ। ਟੀਮ ਪਹਿਲਾਂ ਸੁਖਦਾਇਕ ਰਾਹ (happy path) ਬਣਾਉਂਦੀਆਂ ਹਨ, ਫਿਰ ਜਿੱਥੇ UI ਟੁੱਟਦਾ ਹੈ ਉੱਥੇ ਇੱਕ ਸਪਿਨਰ, ਲਾਲ ਸੁਨੇਹਾ, ਜਾਂ “ਕੋਈ ਆਇਟਮ ਨਹੀਂ” ਪਲੇਸਹੋਲਡਰ ਜੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਦੁਨੀਆਂ ਭਰ ਦੀਆਂ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਇਹ ਕਰਨ ਤੇ ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਇੱਕ-ਆਫ਼ ਵਰਜਨ ਆ ਜਾਂਦੇ ਹਨ।
ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਇਸਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰਦਾ ਹੈ। ਜਦੋਂ UI ਤੇਜ਼ੀ ਨਾਲ ਤਿਆਰ ਹੁੰਦੀ ਹੈ (ਇਸ ਵਿੱਚ AI-ਜਨਰੇਟ ਕੀਤੀ UI ਵੀ ਸ਼ਾਮਲ ਹੈ), ਮੁੱਖ ਲੇਆਊਟ ਮਿੰਟਾਂ ਵਿੱਚ ਦਿਖ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਵਸਥਾਵਾਂ ਆਸਾਨੀ ਨਾਲ ਛੱਡ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਸਪਿਨਰ ਸਟਾਈਲ, ਵੱਖਰਾ ਪੇਰਾਵਾ (“Try again” ਵਿਰੁੱਧ “Retry”), ਅਤੇ ਵੱਖਰੀ ਬਟਨ ਪਲੇਸਮੈਂਟ ਹੋ ਸਕਦੀ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਜੋ ਤੇਜ਼ੀ ਮਿਲੀ ਸੀ, ਉਹ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਪਾਲਿਸ਼ ਦੇ ਕੰਮ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਮਿਲਦੇ-ਜੁਲਦੇ ਸਟੇਟਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਟੀਮਾਂ ਦਾ ਸਮਾਂ ਲੈਂਦੀਆਂ ਹਨ। ਲੋਕ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ ਖਾਲੀ ਲਿਸਟ ਦਾ ਮਤਲਬ “ਕੋਈ ਨਤੀਜੇ ਨਹੀਂ”, “ਅਜੇ ਲੋਡ ਹੋਣ ਵਾਲਾ ਹੈ”, ਜਾਂ “ਤੁਹਾਡੇ ਕੋਲ ਐਕਸੈੱਸ ਨਹੀਂ” ਹੈ। QA ਨੂੰ ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਬਦਲਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਬੱਗ ਫਸਲ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ 'ਚ ਰਵੱਈਆ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
“ਗੜਬੜ” ਆਮ ਤੌਰ 'ਤੇ ਇੰਝ ਦਿਖਦੀ ਹੈ:
ਹ 목표 ਸਧਾਰਨ ਹੈ: ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਲਈ ਇਕ ਸਾਂਝਾ ਰਵੱਈਆ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਫੀਚਰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ), ਤਾਂ ਸਾਂਝਾ ਸਟੇਟ ਪੈਟਰਨ ਹੋਣਾ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਦੇ ਫੈਸਲੇ ਤੁਰੰਤ coherent ਰਹਿਣਗੇ।
ਜ਼ਿਆਦਾਤਰ ਐਪ ਇੱਕੋ ਹੀ ਪ੍ਰੈਸ਼ਰ ਪੁਆਇੰਟ ਦੁਹਰਾਉਂਦੇ ਹਨ: ਲਿਸਟਾਂ, ਡੀਟੇਲ ਪੇਜ, ਫਾਰਮ, ਡੈਸ਼ਬੋਰਡ। ਇੱਥੇ ਸਪਿਨਰ, ਬੈਨਰ, ਅਤੇ “ਕੁਝ ਨਹੀਂ” ਸੁਨੇਹੇ ਕਿੱਤੇ ਜਾਂਦੇ ਹਨ।
ਪਹਿਲਾਂ ਇਹ ਪੰਜ ਸਟੇਟ ਨਾਂ ਦੇ ਕੇ ਮਿਆਰੀਕਰਨ ਸ਼ੁਰੂ ਕਰੋ:
ਦੋ ਖਾਸ ਕੇਸ ਵੱਖਰੇ ਨਿਯਮ ਦੇ ਲਾਇਕ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵੱਖਰਾ ਵਿਹੇਵ ਕਰਦੇ ਹਨ:
ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਸਟ੍ਰਕਚਰ ਇਕਸਾਰ ਰੱਖੋ: ਸਟੇਟ ਕਿੱਥੇ ਦਿਖੇਗਾ, ਆਈਕਨ ਸਟਾਈਲ, ਟੋਨ, ਅਤੇ ਡਿਫਾਲਟ ਐਕਸ਼ਨ (Retry, Refresh, Clear filters, Create) ਇਕ ਜਿਹੇ ਹੋਣ। ਜੋ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ ਉਹ ਹੈ ਸੰਦਰਭ: ਸਕ੍ਰੀਨ ਦਾ ਨਾਮ ਅਤੇ ਇਕ ਵਾਕ ਜੋ ਯੂਜ਼ਰ ਦੀ ਭਾਸ਼ਾ ਵਰਤੇ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ “Projects” ਲਈ ਵੈੱਬ ਲਿਸਟ ਅਤੇ ਮੋਬਾਈਲ ਲਿਸਟ ਦੋਹਾਂ ਬਣਾਉਂਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ zero-results ਪੈਟਰਨ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਐਕਸ਼ਨ ਲੇਬਲ ਪਲੇਟਫਾਰਮ ਨਾਲ ਮੈਚ ਕਰ ਸਕਦਾ ਹੈ (“Clear filters” ਵਿਰੁੱਧ “Reset”)।
ਜੇ ਹਰ ਸਕ੍ਰੀਨ ਆਪਣਾ ਸਪਿਨਰ, ਐਰਰ ਕਾਰਡ, ਅਤੇ ਖਾਲੀ ਸੁਨੇਹਾ ਖੋਜਦਾ ਰਹੇਗਾ ਤਾਂ ਤੁਸੀਂ ਦਸਾਂ ਹੌਲੀ-ਹੌਲੀ ਵੱਖ-ਵੱਖ ਵਰਜਨਾਂ ਵਾਲਾ ਹਲਕਾ ਗੁਛਾ ਬਣਾਵੋਗੇ। ਸਭ ਤੋਂ ਤੇਜ਼ ਠੀਕ ਢੰਗ ਇੱਕ ਛੋਟੇ “state kit” ਦੀ ਰਚਨਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਫੀਚਰ ਵਿੱਚ ਰਖਿਆ ਜਾ ਸਕੇ।
ਹਰ ਥਾਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਤਿੰਨ ਰੀਯੂਜ਼ੇਬਲ ਕੋਮਪੋਨੈਂਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: Loading, Error, ਅਤੇ Empty. ਉਨ੍ਹਾਂ ਨੂੰ ਜ਼ਰੂਰਤਾਂ ਅਨੁਸਾਰ ਬੋਰੀਂਗ ਰੱਖੋ। ਉਹ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣਯੋਗ ਹੋਣ ਅਤੇ ਮੁੱਖ UI ਨਾਲ ਮੁਕਾਬਲਾ ਨਾ ਕਰਨੇ ਚਾਹੀਦੇ।
ਕੋਮਪੋਨੈਂਟਾਂ ਨੂੰ ਪ੍ਰੇਡੀਕਟੀਬਲ ਬਣਾਉਣ ਲਈ ਥੋੜ੍ਹੇ ਇਨਪੁਟ ਨਿਰਧਾਰਤ ਕਰੋ:
ਫਿਰ ਲੁੱਕ ਨੂੰ ਲੌਕ ਕਰੋ। spacing, ਟਾਇਪੋਗ੍ਰਾਫੀ, ਆਈਕਨ ਆਕਾਰ, ਅਤੇ ਬਟਨ ਸਟਾਈਲ ਇੱਕ ਵਾਰੀ ਫੈਸਲ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਨਿਯਮ ਸਮਝੋ। ਜਦੋਂ ਆਈਕਨ ਆਕਾਰ ਅਤੇ ਬਟਨ ਟਾਈਪ ਇੱਕੋ ਰਹਿਣਗੇ, ਯੂਜ਼ਰ ਸਟੇਟ UI ਨੂੰ ਨੋਟਿਸ ਕਰਨਾ ਛੱਡ ਦੇਣਗੇ ਅਤੇ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੇ।
ਵੈਰੀਅੰਟ ਨੂੰ ਸੀਮਤ ਰੱਖੋ ਤਾਂ ਕਿ ਕਿੱਟ ਦੂਜੇ ਡਿਜ਼ਾਇਨ ਸਿਸਟਮ ਵਿੱਚ ਨਾ ਬਦਲੇ। ਤਿੰਨ ਆਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ: small (inline), default (section), ਅਤੇ full-page (blocking)।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਸਕ੍ਰੀਨ ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਇੱਕ ਸਧਾਰਨ ਨਿਰਦੇਸ਼ ਜਿਵੇਂ “use the app StateKit for loading/error/empty with default variant” drift ਨੂੰ ਰੋਕਦਾ ਹੈ। ਇਹ React web ਅਤੇ Flutter mobile 'ਤੇ late-cycle ਸਾਫ-ਸੁਥਰਾ ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ।
ਕਾਪੀ ਵੀ ਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਹੈ, ਸਜਾਵਟ ਨਹੀਂ। ਭਾਵੇਂ ਲੇਆਊਟ ਇਕਸਾਰ ਹੋਵੇ, ਐਡ-ਹੌਕ ਫਰੇਜ਼ਿੰਗ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਵੱਖਰਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ।
ਇੱਕ ਸਾਂਝੀ آواز ਚੁਣੋ: ਛੋਟੀ, ਵਿਸ਼ੇਸ਼, ਅਤੇ ਸ਼ਾਂਤ। ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ ਕਿ ਕੀ ਵਾਪਰਿਆ, ਫਿਰ ਯੂਜ਼ਰ ਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ ਦਿਖਾਓ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਕੇਵਲ ਇਕ ਸਪਸ਼ਟ ਸਿਰਲੇਖ, ਇਕ ਛੋਟੀ ਵਿਆਖਿਆ, ਅਤੇ ਇਕ ਜਾਣੇ-ਪਛਾਣੇ ਐਕਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਸੁਨੇਹਾ ਪੈਟਰਨ ਜ਼ਿਆਦਾਤਰ ਸਥਿਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰ ਲੈਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਕਿ ਛੋਟੇ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਵੀ ਫਿੱਟ ਹੋ ਜਾਏ:
அਸਪਸ਼ਟ ਟੈਕਸਟ ਜਿਵੇਂ “Something went wrong” ਨੂੰ ਅਕੇਲਾ ਵਰਤਣ ਤੋਂ ਬਚੋ। ਜੇ ਤੁਹਾਨੂੰ ਵਾਕਈ ਕਾਰਣ ਦਾ ਪਤਾ ਨਹੀਂ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ ਉਹ ਦੱਸੋ ਅਤੇ ਹੁਣ ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਦੱਸੋ। “We couldn’t load your projects” “Error” ਨਾਲੋਂ ਵਧੀਆ ਹੈ।
ਇੱਕ ਨਿਯਮ ਰੱਖੋ: ਹਰ ਐਰਰ ਅਤੇ ਖਾਲੀ ਸਟੇਟ ਇੱਕ ਅਗਲਾ ਕਦਮ ਪੇਸ਼ ਕਰੇ।
AI-ਜਨਰੇਟ ਕੀਤੀ UI ਵਿੱਚ ਇਹ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਸਕ੍ਰੀਨ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਦੇ ਹਨ। ਟੈਮਪਲੇਟ ਕਾਪੀ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦਰਜਨਾਂ ਇਕ-ਆਫ਼ ਸੁਨੇਹਿਆਂ ਨੂੰ ਮੁੜ-ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਾਉਂਦੇ।
ਜਦੋਂ ਸਟੇਟ ਸਕ੍ਰੀਨਾਂ ਇੱਕ-ਪੇਜ਼ ਤੋਂ ਦੂਜੇ ਪੇਜ਼ ਤੱਕ ਵੱਖਰੇ ਐਕਸ਼ਨ ਦਿਖਾਉਂਦੀਆਂ ਹਨ, ਯੂਜ਼ਰ ਹੱਝਕਦੇ ਹਨ। ਟੀਮ ਫਿਰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਬਟਨ ਅਤੇ ਕਾਪੀ 'ਤੇ ਟਵੀਕਿੰਗ ਕਰਦੀ ਹੈ।
ਹਰ ਸਟੇਟ ਲਈ ਕਿਸ ਐਕਸ਼ਨ ਦਾ ਸਹੀ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰੋ, ਅਤੇ ਪਲੇਸਮੈਂਟ ਅਤੇ ਲੇਬਲ ਨੂੰ ਇਕਸਾਰ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਚਾਹੀਦਾ। ਜੇ ਤੁਸੀਂ ਦੂਜਾ ਜੋੜਦੇ ਹੋ, ਉਹ ਮੁੱਖ ਰਾਹ ਦੀ ਮਦਦ ਕਰੇ, ਮੁਕਾਬਲਾ ਨਾ।
ਆਪਣੇ ਐਕਸ਼ਨਾਂ ਨੂੰ ਤੰਗ ਰੱਖੋ:
ਬੋਰੀਂਗ ਬਟਨ ਇੱਕ ਫੀਚਰ ਹਨ। ਉਹ UI ਨੂੰ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ GENERATED ਸਕ੍ਰੀਨਾਂ ਨੂੰ coherent ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
“Retry” ਉਹੀ ਸਮੇਂ ਦਿਖਾਓ ਜਦੋਂ retry ਵਾਕਈ ਮਾਫ਼ੀ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ (timeouts, flaky network, 5xx)। ਬਾਰ-ਬਾਰ ਟੈਪਿੰਗ ਨੂੰ ਰੋਕਣ ਲਈ ਛੋਟੀ debounce ਲਗਾਓ, ਅਤੇ retry ਦੇ ਦੌਰਾਨ ਬਟਨ ਨੂੰ loading ਸਟੇਟ 'ਤੇ ਬਦਲ ਦਿਓ।
बार-बार ਫੇਲ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੱਕੋ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਰੱਖੋ ਅਤੇ ਸੈਕੰਡਰੀ ਮਦਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ “Check connection” ਟਿਪ ਜਾਂ “Try again later”)। ਸਿਰਫ਼ ਇਸ ਲਈ ਨਵਾਂ ਲੇਆਊਟ ਨਾ ਲਿਆਓ ਕਿ ਕੁਝ ਦੋ ਵਾਰੀ ਫੇਲ ਹੋ ਗਿਆ।
ਐਰਰ ਵੇਰਵੇ ਲਈ ਯੂਜ਼ਰ-ਯੋਗ ਕਾਰਨ ਦਿਖਾਓ (“Your session expired. Sign in again.”)। ਤਕਨੀਕੀ ਵੇਰਵੇ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਲੁਕਾਓ। ਜੇ ਲੋੜ ਹੈ, ਇੱਕ ਇਕਸਾਰ “Details” affordance ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਜਿਸਦੀ ਜਗ੍ਹਾ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਹੋਵੇ।
ਉਦਾਹਰਨ: “Projects” ਲਿਸਟ ਮੋਬਾਈਲ 'ਤੇ ਲੋਡ ਨਹੀਂ ਹੁੰਦੀ। ਦੋਹਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਪ੍ਰਾਇਮਰੀ “Retry” ਐਕਸ਼ਨ ਦਿਖੋ, retry ਦੌਰਾਨ disable ਕਰੋ, ਅਤੇ ਦੋ ਵਾਰੀ ਫੇਲ ਹੋਣ 'ਤੇ ਇੱਕ ਛੋਟੀ ਕਨੈਕਸ਼ਨ ਹਿੰਟ ਜੋੜੋ ਬਜਾਏ ਪੂਰੀ ਬਟਨ ਲੇਆਊਟ ਬਦਲਣ ਦੇ।
ਸਟੇਟ ਇਕਸਾਰਤਾ ਨੂੰ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਡਕਟ ਬਦਲਾਅ ਸਮਝੋ, ਨਾ ਕਿ redesign। ਇੰਕ੍ਰਿਮੈਂਟਲ ਦਾ ਰਸਤਾ ਲਵੋ ਅਤੇ ਅਪਨਾਉਣ ਨੂੰ ਆਸਾਨ ਬਣਾਓ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਉਸ ਦਾ ਇੱਕ ਛੋਟਾ ਨਕਸ਼ਾ ਬਣਾਓ। ਪੂਰਨਤਾ ਦਾ ਲਕਸ਼ ਨਾਂ ਰੱਖੋ। ਆਮ ਭਿੰਨਤਾ ਨੂੰ ਕੈਪਚਰ ਕਰੋ: ਸਪਿਨਰ ਵਿ। ਸਕੈਲੇਟਨ, ਪੂਰੀ-ਪੇਜ਼ ਐਰਰ ਵਿ। ਬੈਨਰ, “no results” ਸਕ੍ਰੀਨਾਂ ਵੱਖ-ਵੱਖ ਟੋਨ ਨਾਲ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਰੋਲਆਊਟ ਯੋਜਨਾ:
ਇੱਕ ਵਾਰੀ ਕੰਪੋਨੈਂਟ ਮੌਜੂਦ ਹੋਣ 'ਤੇ, ਸੱਚਾ ਸਮਾਂ-ਬਚਾਉਣ ਵਾਲਾ ਵਰਕ ਇੱਕ ਛੋਟਾ ਨਿਯਮ-ਸੈੱਟ ਹੈ ਜੋ بحث ਨੂੰ ਖਤਮ ਕਰ ਦੇਂਦਾ: ਕਦੋਂ ਸਟੇਟ ਪੂਰੀ ਪੇਜ਼ ਬਲੌਕ ਕਰੇ ਵਿਰੁੱਧ ਕੇਵਲ ਇੱਕ ਕਾਰਡ।
ਨਿਯਮ ਛੋਟੇ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ AI UI ਜਨਰੇਟਰ ਵਰਤਦੇ ਹੋ, ਇਹ ਨਿਯਮ ਤੇਜ਼ੀ ਨਾਲ ਲਾਭਪ੍ਰਦ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ prompt ਵਿਚ “use the state kit components” ਦੱਸ ਸਕਦੇ ਹੋ ਅਤੇ React web ਅਤੇ Flutter mobile 'ਤੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਕ੍ਰੀਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਜਿਸਨੂੰ ਫਿਰ ਘੱਟ ਸਾਫ-ਸੁਥਰਾ ਕੰਮ ਲੋੜੇਗਾ।
ਆਖਰੀ ਪਲ ਦਾ ਪਾਲਿਸ਼ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ state handling ਇੱਕ-ਆਫ਼ ਤਰੀਕੇ ਨਾਲ ਬਣਾਈ ਗਈ। ਇੱਕ ਸਕ੍ਰੀਨ “ਚਲਦੀ” ਹੈ, ਪਰ ਤਜਰਬਾ ਹਰ ਵਾਰੀ ਵੱਖਰਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਸਮਾਂ ਲੈਂਦਾ, ਫੇਲ ਹੁੰਦਾ, ਜਾਂ ਡੇਟਾ ਨਹੀਂ ਹੁੰਦਾ।
ਸਕੈਲੇਟਨ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਜੇ ਉਹ ਵੱਧ ਸਮਾਂ ਸਕ੍ਰੀਨ 'ਤੇ ਰਹਿ ਜਾਂਦੇ ਹਨ ਤਾਂ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਐਪ ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ। ਆਮ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਲੰਮੀ ਕਾਲ ਤੇ ਪੂਰਾ ਸਕੈਲੇਟਨ ਦਿਖਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਇਸ ਗੱਲ ਦੇ ਸੰਕੇਤ ਦੇ ਕਿ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ।
ਇਸਨੂੰ ਟਾਈਮ-ਬਾਕਸ ਕਰੋ: ਇੱਕ ਛੋਟੀ ਦੇਰ ਬਾਦ, ਹلਕਾ “Still loading…” ਸੁਨੇਹਾ ਦਿਖਾਓ ਜਾਂ ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਗ੍ਰੈਸ ਦਿਖਾਓ।
ਟੀਮਾਂ ਅਕਸਰ ਹਰ ਵਾਰੀ ਨਵਾਂ ਸੁਨੇਹਾ ਲਿਖਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਮਸਲਾ ਇੱਕੋ ਹੀ ਹੋਵੇ। “Something went wrong”, “Unable to fetch”, ਅਤੇ “Network error” ਇੱਕੋ ਕੇਸ ਨੂੰ ਦਰਸਾ ਸਕਦੇ ਹਨ, ਪਰ ਇਹਨਾਂ ਨਾਲ ਅਨੁਭਵ inconsistent ਲੱਗਦਾ ਹੈ।
ਹਰ ਐਰਰ ਕਿਸਮ ਲਈ ਇੱਕ ਲੇਬਲ ਚੁਣੋ ਅਤੇ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਦੁਹਰਾਓ, ਉਹੀ ਟੋਨ ਅਤੇ ਵੇਰਵਾ ਰੱਖੋ।
ਇੱਕ ਹੋਰ ਕਲਾਸਿਕ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਖਤਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਖਾਲੀ ਸਟੇਟ ਦਿਖਾਈ ਜਾ ਜਾਂਦੀ ਹੈ, ਜਾਂ “No items” ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦਕੀ ਅਸਲ ਸਮੱਸਿਆ ਰਿਕਵੈਸਟ ਫੇਲ ਹੋਣਾ ਹੈ। ਯੂਜ਼ਰ ਗਲਤ ਕਾਰਵਾਈ ਕਰ ਲੈਂਦਾ (ਜਿਵੇਂ ਸਮੱਗਰੀ ਜੋੜਨਾ ਜਦੋਂ ਉਹ retry ਕਰਨਾ ਚਾਹੀਦਾ)।
ਫੈਸਲਾ ਕ੍ਰਮ explicit ਬਣਾਓ: ਪਹਿਲਾਂ loading, ਫਿਰ error ਜੇ ਫੇਲ ਹੋਇਆ, ਅਤੇ ਖਾਲੀ ਸਿਰਫ਼ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਰਿਕਵੈਸਟ ਕਾਮਯਾਬ ਹੋ ਗਿਆ।
ایک ਐਰਰ ਜਿਸ ਵਿੱਚ ਕੋਈ ਰਿਕਵਰੀ ਐਕਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ dead end ਬਣਾਉਂਦਾ। ਉਲਟ, ਤਿੰਨ ਬਟਨ ਜੋ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ ਵੀ ਆਮ ਹੈ।
ਇਸਨੂੰ ਤੰਗ ਰੱਖੋ:
ਛੋਟੇ ਫਰਕ ਮਿਲਕੇ ਵੱਡੇ ਹੋ ਜਾਂਦੇ ਹਨ: ਆਈਕਨ ਸਟਾਈਲ, padding, ਬਟਨ ਆਕਾਰ। AI-ਜਨਰੇਟ ਕੀਤੀ UI ਵੀ ਉੱਥੇ drift ਕਰ ਸਕਦੀ ਹੈ ਜਦੋਂ prompts ਸਕ੍ਰੀਨ ਵਾਰੀ ਵੱਖਰੇ ਹੋਣ।
ਸਟੇਟ ਕੰਪੋਨੈਂਟਾਂ ਲਈ spacing, ਆਈਕਨ ਸੈੱਟ, ਅਤੇ ਲੇਆਊਟ ਲੌਕ ਕਰੋ ਤਾਂ ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਇੱਕੋ ਢਾਂਚਾ ਅਨੁਸਰਣ ਕਰੇ।
ਜੇ ਤੁਸੀਂ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਚ consistent state handling ਚਾਹੁੰਦੇ ਹੋ, ਉਹ “ਬੋਰੀਂ” ਨਿਯਮ explicit ਬਣਾਓ। ਜ਼ਿਆਦਾਤਰ ਆਖਰੀ ਪਲ ਦੀ ਪਾਲਿਸ਼ ਇਸ ਕਰਕੇ ਹੁੰਦੀ ਹੈ ਕਿ ਹਰ ਸਕ੍ਰੀਨ ਆਪਣਾ ਲੋਡਿੰਗ ਵਿਹਾਰ, ਟਾਈਮਆਉਟ, ਅਤੇ ਲੇਬਲ ਬਣਾਉਂਦੀ ਹੈ।
ਪੂਰੇ ਪੇਜ਼ ਲੋਡ ਲਈ ਇੱਕ ਡਿਫਾਲਟ ਚੁਣੋ: content-heavy ਸਕ੍ਰੀਨਾਂ (ਲਿਸਟ, ਕਾਰਡ, ਡੈਸ਼ਬੋਰਡ) ਲਈ skeletons ਅਤੇ ਛੋਟੇ ਇੰਤਜ਼ਾਰ ਲਈ spinner (ਜਿੱਥੇ ਲੇਆਊਟ ਅਣਜਾਣ) ਵਰਤੋਂ।
UI ਨੂੰ ਚੁੱਪ ਨਹੀਂ ਛੱਡਣ ਲਈ ਇੱਕ ਟਾਈਮਆਉਟ ਥਰੈਸ਼ਹੋਲਡ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਲੋਡਿੰਗ تقريباً 8-10 ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਅਤੇ ਇੱਕ ਵਿਜ਼ੀਬਲ ਐਕਸ਼ਨ ਜਿਵੇਂ “Retry” ਦਿਖਾਓ।
ਪਾਰਸ਼ਲ ਲੋਡ ਲਈ, ਸਕ੍ਰੀਨ ਨੂੰ ਖਾਲੀ ਨਾ ਕਰੋ। ਮੌਜੂਦਾ ਸਮੱਗਰੀ ਨੂੰ ਦਿੱਸਦੇ ਰੱਖੋ ਅਤੇ ਅੱਪਡੇਟ ਹੋ ਰਹੇ ਸੈਕਸ਼ਨ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਗ੍ਰੈਸ ਇੰਡਿਕੇਟਰ ਦਿਖਾਓ (ਜਿਵੇਂ header ਵਿੱਚ ਇੱਕ ਪਤਲਾ ਬਾਰ ਜਾਂ inline spinner)।
কੈਸ਼ਡ ਡੇਟਾ ਲਈ, “stale but usable” ਪਸੰਦ ਕਰੋ। ਸੇਵਡ ਸਮੱਗਰੀ ਤੁਰੰਤ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਨਰਮ “Refreshing…” ਇੰਡਿਕੇਟਰ ਜੋੜੋ ਤਾਂ ਲੋਕ ਸਮਝ ਸਕਣ ਕਿ ਡੇਟਾ ਬਦਲ ਸਕਦੀ ਹੈ।
ਆਫਲਾਈਨ ਆਪਣਾ ਇੱਕ ਸਟੇਟ ਹੈ। ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ, ਅਤੇ ਦੱਸੋ ਕਿ ਕੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਉਦਾਹਰਨ: “You’re offline. You can view saved projects, but syncing is paused.” ਇੱਕ ਇੱਕਲਅਗਲੇ ਕਦਮ ਜਿਵੇਂ “Try again” ਜਾਂ “Open saved items” ਦਿਓ।
ਇਹਨਾਂ ਨੂੰ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇਕਸਾਰ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਟੂਲ ਨਾਲ UI ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਇਹ ਨਿਯਮ shared state kit ਵਿੱਚ ਡਾਲਣ ਨਾਲ ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਡਿਫਾਲਟ ਤੋਂ coherent ਰਹਿੰਦੀ ਹੈ।
ਕੱਲਪਨਾ ਕਰੋ ਇਕ ਸੋਖਾ CRM ਜਿਸ ਵਿੱਚ Contacts ਲਿਸਟ ਸਕ੍ਰੀਨ ਅਤੇ Contact details ਸਕ੍ਰੀਨ ਹਨ। ਜੇ ਤੁਸੀਂ ਲੋਡਿੰਗ, ਐਰਰ, ਅਤੇ ਖਾਲੀ ਸਟੇਟਾਂ ਨੂੰ ਇੱਕ-ਆਫ਼ ਵਜੋਂ ਰੱਖਦੇ ਹੋ, ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਤੇ ਤੇਜ਼ੀ ਨਾਲ drift ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਛੋਟਾ ਸਿਸਟਮ ਇਹਨਾਂ ਨੂੰ aligned ਰੱਖਦਾ ਹੈ ਭਾਵੇਂ UI ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਈ ਜਾ ਰਹੀ ਹੋਵੇ।
First-time empty state (Contacts list): ਯੂਜ਼ਰ Contacts ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਅਜੇ ਕੁਝ ਨਹੀਂ ਹੈ। ਦੋਹਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਸਿਰਲੇਖ ਇੱਕੋ ਰਹਿੰਦਾ (“Contacts”), empty message ਵਜੋਂ ਸਪਸ਼ਟ ਵਜ੍ਹਾ ਹੋਵੇ (“No contacts yet”), ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਦਿਖਾਇਆ ਜਾਵੇ (“Add your first contact”). ਜੇ ਕੋਈ setup ਜਰੂਰੀ ਹੈ (ਜਿਵੇਂ inbox connect ਕਰਨਾ ਜਾਂ CSV import), empty state ਉਸ ਖਾਸ ਕਦਮ 'ਤੇ ਨਿਰਦੇਸ਼ ਕਰੇ।
Slow network loading: ਯੂਜ਼ਰ Contact details ਪੇਜ ਖੋਲ੍ਹਦਾ ਹੈ। ਦੋਹਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕ predictable skeleton layout ਦਿਖਾਓ ਜੋ final page structure (header, key fields, notes) ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ। back button ਕੰਮ ਕਰਦਾ ਰਹੇ, page title ਦਿਸੇ, ਅਤੇ ਅਲੱਗ-ਅਲੱਗ ਥਾਵਾਂ 'ਤੇ random spinners ਤੋਂ ਬਚੋ।
Server error: details request fail ਹੋ ਜਾਂਦਾ ਹੈ। ਦੋਹਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਪੈਟਰਨ ਹੋਵੇ: ਛੋਟਾ headline, ਇੱਕ ਵਾਕ, ਅਤੇ ਇੱਕ primary action (“Retry”). ਜੇ retry ਫੇਲ ਰਹਿੰਦੀ ਹੈ, ਦੂਜਾ ਵਿਕਲਪ ਦਿਓ ਜਿਵੇਂ “Go back to Contacts” ਤਾਂ ਯੂਜ਼ਰ stuck ਨਾ ਰਹੇ।
ਕੀ ਇਕਸਾਰ ਰਹਿੰਦਾ ਹੈ ਸਧਾਰਨ:
ਇੱਕ ਰਿਲੀਜ਼ “ਪੂਰਾ” ਲੱਗ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਕਿਸੇ ਨੂੰ slow connection, ਨਵਾਂ ਖਾਤਾ, ਜਾਂ flaky API ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਚੈੱਕਲਿਸਟ ਆਖਰੀ-ਮੌਕੇ ਦੀਆਂ ਖਾਮੀਆਂ ਬਿਨਾ QA ਨੂੰ ਸ਼ਿਕਾਰ ਬਣਾਏ ਪਕੜਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।
ਲਿਸਟ ਸਕ੍ਰੀਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਗੁਣਾ ਕਰਦੇ ਹਨ। ਤਿੰਨ ਆਮ ਲਿਸਟਾਂ (search results, saved items, recent activity) ਚੁਣੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਸਾਰੇ ਇੱਕੋ empty-state ਸਟ੍ਰਕਚਰ ਵਰਤਦੇ ਹਨ: ਸਪਸ਼ਟ ਸਿਰਲੇਖ, ਇਕ ਮਦਦਗਾਰ ਵਾਕ, ਅਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ।
ਪੱਕਾ ਕਰੋ ਕਿ ਖਾਲੀ ਸਟੇਟ ਕਦੇ ਵੀ ਡੇਟਾ ਲੋਡ ਹੋ ਰਹਿਣ ਦੌਰਾਨ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ। ਜੇ ਤੁਸੀਂ “Nothing here yet” ਅਲਪ ਸਮੇਂ ਲਈ ਫਲੈਸ਼ ਕਰ ਕੇ ਫਿਰ ਸਮੱਗਰੀ ਨਾਲ ਬਦਲ ਦਿੰਦੇ ਹੋ, ਭਰੋਸਾ ਘੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਲੋਡਿੰਗ ਇੰਡਿਕੇਟਰਾਂ ਦੀ ਇਕਸਾਰਤਾ ਚੈੱਕ ਕਰੋ: ਆਕਾਰ, ਪਲੇਸਮੈਂਟ, ਅਤੇ ਇਕ ਵਾਜਬ ਮਿੰਨੀਮਮ ਦਿਬੰਤੀ ਤਾਂ ਉਹ ਫਲਿੱਕਰ ਨਾ ਕਰਨ। ਜੇ ਵੈੱਬ ਉੱਪਰ top bar spinner ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਮੋਬਾਈਲ ਉੱਪਰ ਉਹੀ ਸਕ੍ਰੀਨ ਲਈ full-screen skeleton ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਦੋ ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਲੱਗਣਗੇ।
ਐਰਰ ਹਮੇਸ਼ਾ “ਹੁਣ ਕੀ?” ਦਾ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ। ਹਰ ਐਰਰ ਨੂੰ ਇਕ ਅਗਲਾ ਕਦਮ ਚਾਹੀਦਾ: retry, refresh, ਫਿਲਟਰ ਬਦਲੋ, ਮੁੜ ਸਾਈਨ ਇਨ, ਜਾਂ support ਨਾਲ ਸੰਪਰਕ।
ਇੱਕ ਛੋਟੀ ਤਜਵੀਜ਼ ਬਿਲਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ AI builder ਵਰਤਦੇ ਹੋ, ਇਹ ਚੈੱਕਜ਼ ਹੋਰ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਸਕ੍ਰੀਨ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ consistency ਫਿਰ ਵੀ shared kit ਅਤੇ shared copy rules 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
Consistency ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦਾ ਹਿੱਸਾ ਹੋਵੇ, ਨਾ ਕਿ ਇੱਕ ਵਾਰੀ ਦੀ ਸਫਾਈ। ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਨੂੰ ਇੱਕੋ ਪੈਟਰਨ ਆਪਣੇ-आप ਵਰਤਣੇ ਚਾਹੀਦੇ।
State ਵਿਹਾਰ ਨੂੰ ਤੁਹਾਡੇ definition of done ਦਾ ਹਿੱਸਾ ਬਣਾਇਆ ਕਰੋ। ਇੱਕ ਸਕ੍ਰੀਨ ਉਸ ਵੇਲੇ ਤੱਕ ਮੁਕੰਮਲ ਨਹੀਂ ਮੰਨੀ ਜਾਵੇਗੀ ਜਦ ਤੱਕ ਉਸ ਵਿੱਚ ਲੋਡਿੰਗ ਸਟੇਟ, ਖਾਲੀ ਸਟੇਟ (ਜੇ ਲਾਗੂ ਹੋਵੇ), ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਐਰਰ ਸਟੇਟ ਵਾਲਾ ਅਗਲਾ ਕਦਮ ਨਾ ਹੋਵੇ।
ਨਿਯਮ ਹਲਕੇ ਰੱਖੋ, ਪਰ ਲਿਖ ਕੇ ਰੱਖੋ। ਇੱਕ ਛੋਟੀ ਦਸਤਾਵੇਜ਼ ਜਿਸ ਵਿੱਚ ਕੁਝ ਸਕ੍ਰੀਨਸ਼ਾਟ ਅਤੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋਏ ਕਾਪੀ ਪੈਟਰਨ ਹੋਣ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਨਵੀਆਂ ਵੈਰੀਐਂਟਾਂ ਨੂੰ exceptional ਮੰਨੋ। ਜਦੋਂ ਕੋਈ ਨਵੀਂ state design ਦਾ ਪ੍ਰਸਤਾਵ ਆਏ, ਪੁੱਛੋ ਕਿ ਕੀ ਇਹ ਵਾਕਈ ਨਵਾਂ ਕੇਸ ਹੈ ਜਾਂ ਕੀ ਉਹ kit ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਈ ਸਕ੍ਰੀਨਾਂ ਨੂੰ refactor ਕਰ ਰਹੇ ਹੋ, ਖਤਰੇ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਕਾਬੂ ਵਾਲੇ ਕਦਮਾਂ ਵਿੱਚ ਕਰੋ: ਇੱਕ ਫਲੋ ਅੱਪਡੇਟ ਕਰੋ, web ਅਤੇ mobile 'ਤੇ verify ਕਰੋ, ਫਿਰ ਅਗਲਾ ਕਰੋ। Koder.ai ਵਿੱਚ snapshots ਅਤੇ rollback ਵੱਡੇ ਬਦਲਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ planning mode shared state kit ਨੂੰ paribhashit ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਨਵੀਂ ਜਨਰੇਟ ਕੀਤੀ ਸਕ੍ਰੀਨ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਹੀ ਤੁਹਾਡੇ defaults ਦੀ ਪਾਲਣਾ ਕਰਨ।
ਇਸ ਹਫ਼ਤੇ ਇੱਕ ਖੇਤਰ ਚੁਣੋ ਜਿੱਥੇ state ਮੁੱਦੇ ਆਖਰੀ ਫਿਕਸ ਬਣਾਉਂਦੇ ਹਨ (ਅਕਸਰ search results, onboarding, ਜਾਂ activity feed)। ਫਿਰ:
ਇਕਠ्ठਾ ਨਿਸ਼ਾਨ ਜੋ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ: “small” ਟਿਕਟਾਂ (ਜਿਵੇਂ “add retry”, “empty state looks weird”, ਜਾਂ “loading spinner blocks the page”) ਘੱਟ ਦਰਜ ਕੀਤੀਆਂ ਜਾਣ।
State standards ਲਈ ਇੱਕ ਇਕੱਲਾ ਮਾਲਕ ਨਿਰਧਾਰਤ ਕਰੋ (ਇਕ designer, tech lead, ਜਾਂ ਦੋਹੀਂ)। ਉਨ੍ਹਾਂ ਨੂੰ ਹਰ ਚੀਜ਼ ਮਨਜ਼ੂਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਉਨਾਂ ਦਾ ਕੰਮ kit ਨੂੰ slowly splitting ਵਿੱਚੋਂ ਬਚਾਉਣਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਧੀਰੇ-ਧੀਰੇ ਨਵੇਂ ਵਰਜਨਾਂ 'ਚ ਤਬਦੀਲ ਹੋ ਜਾਵੇ ਤੇ ਬਾਅਦ ਵਿੱਚ ਸਮਾਂ ਲਵੇ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਲਿਸਟ ਦੇ ਰਾਜ ਨਾਂ ਰੱਖੋ ਜੋ ਹਰ ਜਗ੍ਹਾ ਵਰਤੀ ਜਾਣ: initial loading (ਸ਼ੁਰੂਆਤੀ ਲੋਡ), refreshing, empty baseline, zero results, ਅਤੇ error. ਆਫਲਾਈਨ ਅਤੇ ਸਲੀ ਨੈਟਵਰਕ ਲਈ ਵੱਖਰੇ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਉਹ ਹੋਰ ਐਰਰ ਵਾਂਗ ਨਾ ਵਰਤੇ ਜਾਣ। ਟੀਮ ਇਕ ਵਾਰ ਨਾਮ ਅਤੇ ਟ੍ਰਿਗਰਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਣ ਤੇ UI ਹਰੇਕ ਸਕ੍ਰੀਨ ਤੇ ਪੇਸ਼ਾਨ ਹੋਣਾ ਅਸਾਨ ਹੋ ਜਾਵੇਗਾ।
ਇੱਕ ਛੋਟਾ StateKit ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਰੀਯੂਜ਼ੇਬਲ ਹਿੱਸੇ ਹੋਣ: Loading, Error, ਅਤੇ Empty. ਹਰ ਇੱਕ ਕੋਮਪੋਨੈਂਟ ਉਹੀ ਇਨਪੁਟ ਲਵੇ: ਸਿਰਲੇਖ, ਛੋਟੀ ਸੁਨੇਹਾ, ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ, ਅਤੇ ਵਿਕਲਪਿਕ ਵੇਰਵੇ। ਇਹਨਾਂ ਨੂੰ ਆਸਾਨ ਵਰਤਣ ਯੋਗ ਬਣਾਓ ਤਾਂ ਟੀਮਾਂ ਨਵੇਂ ਇੱਕ-ਅਫ਼ ਵਰਜਨਾਂ ਨੂੰ ਬਣਾਉਣ ਬੰਦ ਕਰਨ।
ਸਿੱਧਾ ਫੈਸਲਾ ਲੜੀ ਵਰਤੋਂ: ਰਿਕ੍ਵੈਸਟ ਖਤਮ ਹੋਣ ਤੱਕ ਲੋਡਿੰਗ ਦਿਖਾਓ, ਜੇ ਫੇਲ ਹੋਇਆ ਤਾਂ error ਦਿਖਾਓ, ਅਤੇ ਕੇਵਲ ਜਦੋਂ ਕਾਮਯਾਬ ਰਿਸਪਾਂਸ ਮਿਲਿਆ ਤੇ ਖਾਲੀ ਦਿਖਾਓ। ਇਹ ਉਸ ਆਮ ਬੱਗ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ “No items” ਥੋੜ੍ਹੀ ਦੇਰ ਲਈ ਫਲੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ।
ਹਰ ਸਟੇਟ ਲਈ ਇੱਕ ਡਿਫਾਲਟ ਐਕਸ਼ਨ ਚੁਣੋ ਅਤੇ ਉਹੀ ਲੇਬਲ ਅਤੇ ਪਲੇਸਮੈਂਟ ਦੁਹਰਾਓ। ਆਮ ਤੌਰ 'ਤੇ Errors ਲਈ “Retry”, empty baselines ਲਈ “Create” ਜਾਂ ਅਗਲਾ ਸੈਟਅਪ ਸਟੈਪ, ਅਤੇ zero results ਲਈ “Clear filters” ਵਰਤੋਂ। ਜਦੋਂ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਭਵਿੱਖਬਾਣੀਯੋਗ ਹੋਵੇ, ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਅਗਲਾ ਕਦਮ ਲੈਂਦੇ ਹਨ ਅਤੇ ਟੀਮਾਂ ਬਟਨ ਸ਼ਬਦਾਵਲੀ 'ਤੇ ਘੱਟ ਤਰਕ-ਵਿਵਾਦ ਕਰਦੀਆਂ ਹਨ।
ਸਾਂਝੇ ਟੈਂਪਲੇਟ ਬਣਾਓ: ਇੱਕ ਛੋਟਾ ਸਿਰਲੇਖ ਜੋ ਸਥਿਤੀ ਨਾਂਵੇ, ਇੱਕ ਵਾਕ ਜੋ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਏ, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਅਗਲਾ ਕਦਮ. ਅਸਪਸ਼ਟ ਟੈਕਸਟ ਜਿਵੇਂ “Something went wrong” ਦੀ ਥਾਂ ਐਸਾ ਕੁਝ ਲਿਖੋ: “We couldn’t load your projects”. ਟੋਨ ਸ਼ਾਂਤ ਅਤੇ ਇੱਕਜਿਹਾ ਰੱਖੋ ਤਾਂ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਇੱਕੋ ਉਤਪਾਦ ਲੱਗਣ।
ਆਫਲਾਈਨ ਨੂੰ ਇੱਕ ਅਲੱਗ ਸਟੇਟ ਸਮਝੋ, ਨਾ ਕਿ ਸਮਾਨ ਜਨਰਲ ਐਰਰ. ਜੇ ਸੇਵਡ ਡੇਟਾ ਹੈ ਤਾਂ ਉਹ ਦਿਖਾਓ, ਸਾਮਣੇ ਸਪੱਸ਼ਟ ਕਰੋ “You’re offline”, ਅਤੇ ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਅਜੇ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਅਗਲਾ ਕਦਮ ਦਿੱਸੋ ਜਿਵੇਂ “Try again”.
ਝਟਪਟ ਐਰਰ ਫਲੇਸ਼ ਤੋਂ ਬਚਣ ਲਈ ਥੋੜ੍ਹਾ ਇਨਤਜ਼ਾਰ ਕਰੋ. ਜੇ ਲੋਡਿੰਗ ਕਿਸੇ ਥਰੈਸ਼ਹੋਲਡ ਤੋਂ ਲੰਬਾ ਚੱਲ ਗਿਆ ਤਾਂ “Still loading…” ਜਿਹੀ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਵਿਜ਼ੀਬਲ ਐਕਸ਼ਨ ਜਿਵੇਂ “Retry” ਦਿਓ। ਇਸ ਨਾਲ ਐਪ ਨੈਟਵਰਕ ਜਦੋਂ ਧੀਮਾ ਹੋਵੇ ਤਬ ਵੀ ਜ਼ਿਆਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਲੱਗੇਗਾ।
ਤਿੰਨ ਸਾਈਜ਼ ਵਰਜੰਟ ਰੱਖੋ: ਛੋਟਾ inline (ਕਾਰਡ ਜਾਂ ਸੈਕਸ਼ਨ ਅੰਦਰ), default section, ਅਤੇ full-page blocking. ਹਰ ਵਰਜੰਟ ਕਦੋਂ ਵਰਤਣਾ ਹੈ ਇਹ ਨਿਯਮਿਤ ਕਰੋ ਤਾਂ ਟੀਮਾਂ ਹਰ ਸਕ੍ਰੀਨ ਲਈ ਨਵਾਂ ਫੈਸਲਾ ਨਾ ਕਰਨ। ਇਕੋ spacing, ਆਈਕਨ ਸਟਾਈਲ, ਅਤੇ ਬਟਨ ਸਟਾਈਲ ਵਰਤਣ ਨਾਲ ਤਜ਼ਰਬਾ ਇੱਕਸਾਰ ਬਣਦਾ ਹੈ।
ਕੁਝ ਮੁੱਢਲੇ ਨਿਯਮ ਜੋ ਹਰ ਜਗ੍ਹਾ ਲਾਗੂ ਕਰੋ: ਆਉਣ ਵੇਲੇ ਧਿਆਨ ਨੂੰ ਸਟੇਟ ਸੁਨੇਹੇ ਅਤੇ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਤੇ ਲਿਜਾਓ, ਲੋਡਿੰਗ ਅਤੇ ਐਰਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲੇਬਲ ਨਾਲ ਐਲਾਨ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬਟਨ ਮੋਬਾਈਲ ਤੇ ਅਸਾਨੀ ਨਾਲ ਟੈਪ ਹੋ ਸਕਦੇ ਹਨ। ਰੰਗ ਜਾਂ ਐਨੀਮੇਸ਼ਨ ਹੀ ਸਿੰਗਲ ਸਿਗਨਲ ਨਾ ਹੋਵੇ। ਜੇ ਇਹ StateKit ਵਿੱਚ ਹੋਵੇ ਤਾਂ ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਇਹ ਆਪਣੇ ਆਪ ਵਰਤ ਲਵੇਗੀ।
ਇਕ-ਇਲਾਕਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿੱਥੇ ਸਟੇਟ ਮੁੱਦੇ ਆਖਰੀ ਪਲ ਦੇ ਫਿਕਸ ਬਣਾਉਂਦੇ ਹਨ (ਅਕਸਰ search, onboarding, ਜਾਂ activity feed). ਫਿਰ: