ਮਾਈਕ ਬੋਸਟੋਕ ਦੀ D3.js ਦਾ ਕਾਰਗਰ ਨਜ਼ਰ: ਇਹ ਕੀ ਹੈ, ਕਿਉਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਮੁੱਖ ਸੰਕਲਪ ਅਤੇ ਟੀਮਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਵੈੱਬ ਵਿਜ਼ੂਅਲ ਸਾਫ਼ ਬਣ ਸਕਣ।

Mike Bostock ਨੇ ਸਿਰਫ਼ ਇੱਕ ਲੋਕਪ੍ਰਿਯ JavaScript ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਲਿਖੀ—ਉਸਨੇ ਵੈੱਬ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਸੋਚ ਹੀ ਨਵੀਂ ਰੂਪ ਦਿੱਤੀ। ਉਸ ਦਾ ਮੁੱਖ ਖਿਆਲ, ਜੋ “data-driven documents” ਵਿੱਚ ਸੰਜੋਇਆ ਗਿਆ ਹੈ, ਸਾਦਾ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ: ਡਾਟਾ ਨੂੰ ਐਸਾ ਮੰਨੋ ਜੋ ਪੰਨੇ ਨੂੰ ਸਿੱਧਾ ਆਕਾਰ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਚਾਰਟ ਨੂੰ ਕਾਲੇ ਡੱਬੇ ਵਿੱਚ ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਡਾਟਾ ਨੂੰ DOM ਤੱਤਾਂ (ਜਿਵੇਂ SVG ਆਕਾਰ, HTML ਨੋਡ ਜਾਂ Canvas ਪਿਕਸਲ) ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਨਤੀਜਾ ਰੇਂਡਰ ਕਰਨ ਦਿੰਦੇ ਹੋ।
D3.js ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੇ ਚਾਰਟਿੰਗ ਟੂਲ ਤਿਆਰ-ਕੀਤੇ ਨਤੀਜਿਆਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਸਨ: ਚਾਰਟ ਕਿਸਮ ਚੁਣੋ, ਡਾਟਾ ਪਾਓ, ਵਿਕਲਪ ਠੀਕ ਕਰੋ, ਅਤੇ ਉміਦ ਕਰੋ ਕਿ ਡਿਜ਼ਾਈਨ ਤੁਹਾਡੀ ਕਹਾਣੀ ਨਾਲ ਮੇਲ ਖਾਏ। D3.js ਨੇ ਇਕ ਵੱਖਰਾ ਰੁਖ ਲਿਆ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ “ਇੱਕ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ” ਨਹੀਂ—ਇਹ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੂਲਕਿਟ ਹੈ।
ਇਹ ਫਰਕ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਅਸਲ-ਦੁਨੀਆ ਦਾ ਡਾਟਾ ਅਤੇ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਕਦੇ ਵੀ ਇੱਕ ਫਿਕਸਟ ਟੈਮਪਲੇਟ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੀਆਂ। D3 ਨਾਲ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ:
ਇਹ ਲੇਖ ਇੱਕ ਧਾਰਨਾਤਮਕ ਮਾਰਗਦਰਸ਼ਕ ਹੈ, ਕਿਸੇ ਹਦ-ਬੱਦੀ ਟਿਊਟੋਰਿਯਲ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਨਕਲ-ਚੇਪਿਆ ਚਾਰਟ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਪਰ ਤੁਸੀਂ D3 ਦੇ ਐਸਾ ਮਨੋ-ਦਿਸ਼ਾ-ਚਿੱਤਰ ਪੱਕਾ ਕਰੋਗੇ ਕਿ D3 ਡਾਟਾ, ਵਿਜ਼ੂਅਲ ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਬਾਰੇ ਕਿਵੇਂ ਸੋਚਦਾ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਸੋਝੀ ਨਾਲ ਚੁਣ ਸਕੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕੋ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਉਤਪਾਦ ਟੀਮ 'ਤੇ ਹੋ, ਇੱਕ ਐਨਾਲਿਸਟ ਜੋ ਨਤੀਜੇ ਸੰਚਾਰ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਡਿਜ਼ਾਈਨਰ ਜੋ ਡਾਟਾ ਦੀ ਮਹਿਸੂਸਾਈ ਨੂੰ ਗਠਿਤ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਇੱਕ ਡਿਵੈਲਪਰ ਜੋ ਇੰਟਰਐਕਟਿਵ UI ਬਣਾ ਰਿਹਾ ਹੈ, D3 ਦਾ ਪ੍ਰਭਾਵ ਸਮਝਣ ਲਾਇਕ ਹੈ—ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਕੋਡ ਵੀ ਨਾ ਲਿਖੋ।
D3.js ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ “ਵੈੱਬ ਚਾਰਟ” ਤਸਵੀਰਾਂ ਵਾਂਗ ਜ਼ਿਆਦਾ ਹੁੰਦੇ ਸਨ ਬਜਾਏ ਇੰਟਰਫੇਸ ਦੇ। ਟੀਮਾਂ Excel ਜਾਂ R ਤੋਂ ਗਰਾਫ ਨਿਰਯਾਤ ਕਰਕੇ PNG ਵਜੋਂ ਪੇਜ਼ ਵਿੱਚ ਪਾ ਦਿੰਦੀਆਂ ਸਨ ਅਤੇ ਕੰਮ ਖਤਮ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਸੀ। ਜਦੋਂ ਵੀ ਚਾਰਟ ਸਰਵਰ-ਪਾਸੋਂ ਬਣਾਏ ਜਾਂਦੇ, ਨਤੀਜਾ ਅਕਸਰ ਅਜੇ ਵੀ ਸਥਿਰ ਤਸਵੀਰ ਹੁੰਦੀ—ਪਬਲਿਸ਼ ਕਰਨ ਲਈ ਆਸਾਨ, ਖੋਜ ਲਈ ਮੁਸ਼ਕਲ।
ਲੋਕ ਚਾਹੁੰਦੇ ਸਨ ਕਿ ਚਾਰਟ ਵੈੱਬ ਵਾਂਗ ਵਰਤਣਯੋਗ ਹੋਣ: ਕਲਿੱਕयोग, ਰਿਸਪਾਂਸਿਵ, ਅਤੇ ਅਪਡੇਟਯੋਗ। ਪਰ ਆਮ ਵਿਕਲਪ ਕਈ ਤਰ੍ਹਾਂ ਘੱਟ ਰਹਿੰਦੇ ਸਨ:\n\n- ਸੀਮਿਤ ਅੰਤਰਕਿਰਿਆ: tooltips, ਫਿਲਟਰਿੰਗ ਅਤੇ ਡ੍ਰਿਲ-ਡਾਊਨ ਅਕਸਰ ਨਹੀਂ ਸੀ ਹੋਂਦ ਵਿੱਚ ਜਾਂ ਬਾਹਰੋਂ ਜੋੜੇ ਜਾਂਦੇ।\n- کمزور ਰਿਸਪਾਂਸਿਵਨੈੱਸ: ਚਾਰਟ ਦਾ ਆਕਾਰ ਬਦਲਣ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਚਿੱਤਰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਸੀ, ਨਾਂ ਕਿ ਫਲੋਅ ਕਰਨਾ।\n- ਕਮਜ਼ੋਰ ਕਹਾਣੀਕਾਰਤਾ: ਐਨੋਟੇਸ਼ਨ, ਕਦਮ-ਬਾਈ-ਕਦਮ ਖੁਲਾਸੇ, ਅਤੇ “scrollytelling” ਜਿਹੇ ਪੈਟਰਨ ਸੁਚੱਜੇ ਨਿਯੰਤਰਣ ਦੇ ਬਗੈਰ ਅਜੀਬ ਹੁੰਦੇ।
ਘਾਟ ਸਿਰਫ਼ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਨਹੀਂ ਸੀ—ਪਲੇਟਫਾਰਮ ਤਿਆਰ ਹੋ ਰਿਹਾ ਸੀ। ਬ੍ਰਾਊਜ਼ਰ ਮਿਆਰੀਆਂਿ ਤਕਨੀਕਾਂ ਵਿਕਸਿਤ ਹੋ ਰਹੀਆਂ ਸਨ:\n\n- DOM ਨੇ ਪੰਨੇ 'ਤੇ ਤੱਤਾਂ ਨੂੰ ਸਟਰੱਕਚਰਡ ਅਤੇ ਇੰਸਪੈਕਟ ਕਰਨਯੋਗ ਕੀਤਾ।\n- SVG ਨੇ ਸ਼ੇਪਾਂ ਅਤੇ ਲਿਖਤ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਬਣਾਇਆ, ਸਟਾਇਲ ਕਰਨਯੋਗ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਇਆ।\n- Canvas ਨੇ ਤੇਜ਼ ਪਿਕਸਲ-ਆਧਾਰਿਤ ਡਰਾਇੰਗ ਯੋਗ ਬਣਾਈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਤੱਤ ਕੰਟਰੋਲ ਤੋਂ ਤੇਜ਼ੀ ਚਾਹੀਦੀ।
ਇਹ ਤਕਨੀਕਾਂ ਗ੍ਰਾਫਿਕਸ ਨੂੰ ਮਨੁੱਖੀ UI ਕੰਪੋਨੈਂਟ ਵਾਂਗ ਇਲਾਜ਼ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀਆਂ—ਨਾ ਕਿ ਨਿਰਯਾਤ ਕੀਤੇ ਹੋਏ ਆਬਜੈਕਟ।
D3 “ਇੱਕ ਚਾਰਟ ਬਿਲਡਰ” ਵਜੋਂ ਨਹੀਂ ਆਇਆ। ਇਹ ਡਾਟਾ ਨੂੰ ਮੂਲ ਵੈੱਬ ਪ੍ਰਿਮਿਟਿਵਸ (DOM, SVG, Canvas) ਨਾਲ ਜੋੜਨ ਦਾ ਤਰੀਕਾ ਲੈ ਕੇ ਆਇਆ ਤਾ ਜੋ ਤੁਸੀਂ ਉਹ ਗ੍ਰਾਫਿਕ ਬਿਲਕੁਲ ਉਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ—ਫਿਰ ਉਸਨੂੰ ਇੰਟਰਐਕਟਿਵ ਅਤੇ ਅਨੁਕੂਲ ਬਣਾਉ। “ਚਾਰਟ ਤਸਵੀਰਾਂ” ਅਤੇ “ਡਾਟਾ-ਚਲਿਤ ਇੰਟਰਫੇਸ” ਵਿਚਕਾਰ ਜੋ ਫ਼ਰਕ ਸੀ, ਉਹ D3 ਨੇ ਪੂਰਾ ਕੀਤਾ।
D3 ਦਾ ਮੁੱਖ ਸਿਧਾਂਤ ਸਾਦਾ ਹੈ: ਚਾਰਟ ਨੂੰ “ਕਿਸੇ ਥਾਂ” ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਆਪਣਾ ਡਾਟਾ ਪੰਨੇ ਦੇ ਅਸਲ ਤੱਤਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਹਰ ਡਾਟਾ ਰੋ ਨੂੰ ਇੱਕ ਸਕ੍ਰੀਨ-ਉਤੇ ਤੱਤ (ਇੱਕ ਬਾਰ, ਇੱਕ ਡਾਟ, ਇੱਕ ਲੇਬਲ) ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਾਟਾ ਵਿੱਚ ਬਦਲਾਅ ਸਿੱਧਾ ਦਿੱਖ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।
ਇੱਕ ਵਰਤਣਯੋਗ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ: ਡਾਟਾ ਰੋ mark ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਡੇਟਾਸੇਟ ਵਿੱਚ 50 ਰੋ ਹਨ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ SVG ਵਿੱਚ 50 ਸਰਕਲ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਇਹ 60 ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ 60 ਦੇਖੋਣੇ ਚਾਹੀਦੇ ਹੋ। ਜੇ ਇਹ 40 ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ 10 ਸਰਕਲ ਗ਼ਾਇਬ ਹੋ ਜਾਣੇ ਚਾਹੀਦੇ। D3 ਇਸ ਰਿਸ਼ਤੇ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ।
“Selections” ਸਿਰਫ D3 ਦਾ ਤਰੀਕਾ ਹਨ ਤੱਤ ਲੱਭਣ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ।
ਇੱਕ selection ਬੁਨਿਆਦੀ ਤੌਰ ਤੇ ਹੈ: “ਇਸ ਚਾਰਟ ਵਿੱਚ ਸਾਰੇ ਡਾਟਾਂ ਨੂੰ ਲੱਭੋ, ਅਤੇ ਹਰ ਡਾਟ ਨੂੰ ਉਸਦੇ ਡਾਟਾ ਨਾਲ ਮਿਲਾਓ।”
D3 ਦਾ ਮਸ਼ਹੂਰ “update pattern” DOM ਤੱਤਾਂ ਨੂੰ ਡਾਟਾ ਨਾਲ ਸਿੰਕ ਰੱਖਣ ਦੀ ਵਰਕਫਲੋ ਹੈ:\n\n- Enter: ਨਵੇਂ ਡਾਟਾ ਰੋ ਲਈ ਨਵੇਂ ਤੱਤ ਬਣਾਓ।\n- Update: ਜਦ ਮੁੱਲ ਬਦਲਦੇ ਹਨ ਤਾਂ ਮੌਜੂਦਾ ਤੱਤਾਂ ਨੂੰ ਬਦਲੋ।\n- Exit: ਉਹ ਤੱਤ ਹਟਾਓ ਜਿਨ੍ਹਾਂ ਦਾ ਹੁਣ ਕੋਈ ਮਿਲਦੀ-ਜੁਲਦੀ ਡਾਟਾ ਨਹੀਂ। \nਇਸੀ ਕਾਰਨ D3 ਇੱਕ ਚਾਰਟ ਸੰਭਾਲਣ ਵਾਲਾ ਟੂਲ ਲੱਗਦਾ ਹੈ—ਇਹ ਇੱਕ ਜੀਵਤ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਬਦਲਦੇ ਡਾਟਾ ਦੇ ਨਾਲ ਸਹੀ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ D3 ਚਾਰਟ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਰੂਪਾਂਤਰ ਮਸ਼ੀਨ ਹੈ। ਤੁਹਾਡਾ ਡੇਟਾਸੇਟ ਮੁੱਲਾਂ (ਸੇਲਜ਼, ਤਾਪਮਾਨ, ਵੋਟ) ਦੇ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਕ੍ਰੀਨ ਸਿਰਫ਼ ਪਿਕਸਲਾਂ ਨੂੰ ਸਮਝਦਾ ਹੈ। D3 ਦੀ “data → scale → pixels” ਪਾਈਪਲਾਈਨ ਦੋਨਾਂ ਸੰਸਾਰਾਂ ਦਰਮਿਆਨ ਇੱਕ ਸਾਫ਼ ਪੁਲ ਹੈ।
ਇੱਕ scale ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਇੱਕ ਡਾਟਾ ਮੁੱਲ ਨੂੰ ਵਿਜ਼ੂਅਲ ਮੁੱਲ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਮਹੀਨਾਵਾਰ ਰੇਵਨਿਊ ਦੀ ਰੇਂਜ 0 ਤੋਂ 50,000 ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ 0 ਤੋਂ 300 ਪਿਕਸਲ ਬਾਰ ਉਚਾਈ 'ਚ ਨਕਸ਼ਾ ਕਰ ਸਕਦੇ ਹੋ। scale ਗਣਿਤ ਸੰਭਾਲਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ 'ਚ ਹਰ ਥਾਂ " / 50000 * 300" ਨਾ ਲਿਖੋ।
ਉਸ ਤੋਂ ਵੀ ਮਹੱਤਵਪੂਰਨ, scales inversion (ਪਿਕਸਲ → ਡਾਟਾ) ਨੂੰ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਇਹੀ precise interactions ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ—ਜਿਵੇਂ ਕਿ ਕਰਸਰ ਹੇਠਾਂ ਸਿੱਧਾ ਮੁੱਲ ਦਿਖਾਉਣਾ।
ਅਕਸ ਸਿਰਫ਼ ਸ਼ਿੰਗਾਰ ਨਹੀਂ: ਇਹ ਦਰਸ਼ਕ ਦਾ ਚਾਰਟ ਨਾਲ ਕਾਂਟਰੈਕਟ ਹੈ। ਚੰਗੇ ਟਿਕਾਂ ਗਲਤ-ਪੜ੍ਹਾਈ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਬਹੁਤ ਘੱਟ ਟਿਕਾਂ ਫਰਕ ਛੁਪਾ ਸਕਦੀਆਂ ਹਨ; ਬਹੁਤ ਜ਼ਿਆਦਾ ਦ੍ਰਿਸ਼ਤੀ ਸ਼ੋਰ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਲਗਾਤਾਰ ਟਿਕਸ ਸਪੇਸਿੰਗ ਅਤੇ ਸੋਚ-ਵਿਚਾਰ ਵਾਲੇ ਅੰਤੀਮ ਬਿੰਦੂ (ਖਾਸ ਕਰਕੇ ਬਾਰ ਚਾਰਟਾਂ ਲਈ ਜਿਰੋ ਸ਼ਾਮਲ ਕਰਨਾ) ਲੋਕਾਂ ਦੀ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ।
ਫਾਰਮੇਟਿੰਗ ਹੀ ਸਪਸ਼ਟਤਾ ਜਾਂ ਗਲਤਫਹਮੀ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ। ਤਾਰਿੱਖਾਂ ਸੰਦਰਭ ਅਨੁਸਾਰ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ (ਜਿਵੇਂ “Jan 2025” ਵਿਰੁੱਧ “2025-01-15”)। ਨੰਬਰਾਂ ਨੂੰ ਅਕਸਰ ਰਾਊਂਡਿੰਗ, ਸੇਪਰੇਟਰ ਅਤੇ ਯੂਨਿਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (“12,400” ਅਤੇ “$12.4k” ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ)। D3 ਦੀਆਂ ਫਾਰਮੈਟਿੰਗ ਯੂਟੀਲਿਟੀਆਂ ਲੇਬਲਾਂ ਨੂੰ ਇਕਸਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਚਾਰਟ ਨੂੰ ਅੰਦਾਜ਼ਾ-ਭਰਿਆ ਜਾਂ ਢੀਲਾ ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਣ ਦਿੰਦੀਆਂ।
D3 ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ ਰੇਂਡਰਿੰਗ ਟੈਕਨੋਲੋਜੀ ਵਿੱਚ ਫਸਾਉਂਦਾ ਨਹੀਂ। ਇਹ ਡਾਟਾ→ਤੱਤ ਲਾਜ਼ਿਕ (joins, scales, interaction) 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਮਾਰਕਾਂ ਕਿੱਥੇ ਰਹਿਣਗੀਆਂ: SVG, Canvas, ਜਾਂ ਸਧਾਰਨ HTML। ਸਹੀ ਚੋਣ ਅਕਸਰ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੀਆਂ ਚੀਜਾਂ ਡ੍ਰਾ ਕਰਨੀਆਂ ਹਨ ਅਤੇ ਸਟਾਇਲਿੰਗ ਤੇ ਪਹੁੰਚਯੋਗਤਾ ਕਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
SVG ਇੱਕ DOM-ਅਧਾਰਿਤ ਡ੍ਰਾਇੰਗ ਸਰਫੇਸ ਹੈ: ਹਰ circle, path ਅਤੇ label ਇੱਕ ਐਸਾ ਤੱਤ ਹੁੰਦਾ ਹੈ ਜੋ CSS ਨਾਲ ਸਟਾਇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਅਤੇ DevTools ਵਿੱਚ ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
SVG ਤਦ ਸ਼ਾਇਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ:
ਇਸਦਾ ਟਰੇਡ-ਆਫ਼: ਹਜ਼ਾਰਾਂ SVG ਤੱਤ ਭਾਰੀ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਹਰ ਇੱਕ ਨੂੰ DOM ਦਾ ਹਿੱਸਾ ਮੰਨ ਕੇ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ।
Canvas ਪਿਕਸਲ-ਅਧਾਰਿਤ ਹੈ: ਤੁਸੀਂ “ਪੇਂਟ” ਕਰਦੇ ਹੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਹਰ ਬਿੰਦੂ ਲਈ DOM ਨੋਡ ਨਹੀਂ ਰੱਖਦਾ। ਇਹ ਉਸ ਸਮੇਂ ਉਚਿਤ ਹੈ ਜਦ scatterplots ਵਿੱਚ ਦਸਾਂ ਹਜ਼ਾਰਾਂ ਪੋਇੰਟ, ਘਣ ਹੀਟਮੇਪ, ਜਾਂ ਰੀਅਲ-ਟਾਈਮ ਰੇਂਡਰਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇ।
ਟਰੇਡਆਫ਼ ਪ੍ਰਯੋਗਕ ਹੈ: ਸਟਾਇਲਿੰਗ ਮੈਨੁਅਲ ਹੁੰਦੀ ਹੈ, ਕ੍ਰਿਸਪ ਲਿਖਤ ਲਈ ਵੱਧ ਕੰਮ ਲੱਗ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਹੈਟ-ਟੈਸਟਿੰਗ ਲਾਜਿਕ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ (ਪਤਾ ਲਗਾਉਣਾ ਕਿ ਮਾਊਸ ਕਿਸ ਤੇ ਹੈ)।
HTML ਉਦਯੋਗਿਕ ਹੈ ਜਦੋਂ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਇੱਕ UI ਕੰਪੋਨੈਂਟ ਹੋ—ਸੋਚੋ sortable tables, tooltips, filters, ਜਾਂ card-based summaries। ਅਕਸਰ SVG ਜਾਂ Canvas ਚਾਰਟ ਨਾਲ HTML ਕੰਟਰੋਲ ਮਿਕਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
D3 ਡਾਟਾ ਨੂੰ SVG/HTML ਤੱਤਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਉਹ scale, layout ਅਤੇ interaction ਹਿਸਾਬ ਲਗਾ ਕੇ ਤੁਹਾਡੇ ਲਈ Canvas 'ਤੇ ਰੇਂਡਰ ਕਰਨ ਲਈ ਨੰਬਰ ਨਿਕਾਲ ਸਕਦਾ ਹੈ। ਇਹ ਲਚਕਦਾਰਤਾ D3 ਨੂੰ ਟੂਲਕਿਟ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ: ਡ੍ਰਾਇਿੰਗ ਸਰਫੇਸ ਇੱਕ ਫੈਸਲਾ ਹੈ, ਪਾਬੰਦੀ ਨਹੀਂ।
D3 ਵਿੱਚ, ਇੱਕ “layout” ਇੱਕ ਫੰਕਸ਼ਨ (ਜਾਂ ਛੋਟੀ ਫੰਕਸ਼ਨਾਂ ਦੀ ਸਿਸਟਮ) ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡਾਟਾ ਨੂੰ ਜਯੋਮੇਟਰੀ ਨਿਕਾਲ ਕੇ ਦਿੰਦੀ ਹੈ: x/y ਪੋਜ਼ਿਸ਼ਨ, ਕੋਣ, ਰੇਡੀਅਸ, ਪਾਥ, ਜਾਂ ਪੈਰੰਟ/ਚਾਇਲਡ ਰਿਸ਼ਤੇ ਜੋ ਤੁਸੀਂ ਡਰਾਅ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਤੁਹਾਡੇ ਲਈ ਪਿਕਸਲ ਨਹੀਂ ਖਿੱਚਦੀ—ਇਹ ਉਹ ਸੰਖਿਆਵਾਂ ਨਿਕਾਲਦੀ ਹੈ ਜੋ ਸ਼ੇਪਾਂ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, D3 ਨਾਲ ਨਾਮ-ਵਾਲੇ layouts (force, pack, tree, cluster, chord) ਆਏ। ਨਵੀਆਂ D3 ਵਰਜ਼ਨਾਂ ਨੇ ਕਈ ਵਿਚਾਰਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਮੋਡਿਊਲਾਂ ਵਜੋਂ ਉਤਾਰਿਆ—ਇਸ ਲਈ ਤੁਸੀਂ ਅਕਸਰ ਉਦਾਹਰਣਾਂ ਵਿੱਚ d3-force ਨੈਟਵਰਕ ਲਈ ਜਾਂ d3-geo ਨਕਸ਼ਿਆਂ ਲਈ ਸਿੱਧਾ ਵੇਖੋਗੇ।
ਜ਼ਿਆਦਾਤਰ ਦਿਲਚਸਪ ਚਾਰਟ "ਗਣਿਤੀ ਸਮੱਸਿਆਵਾਂ" ਹੁੰਦੇ ਹਨ। ਬਿਨਾਂ layouts ਦੇ ਤੁਸੀਂ ਹਿੰਡੀ-ਲਿਖੀ ਟਕਰਾਅ-ਰੋਕਥਾਮ, ਨੋਡ ਪੋਜ਼ਿਸ਼ਨਿੰਗ, ਟਾਇਲਿੰਗ ਰੈਕਟੈਂਗਲ, ਜਾਂ latitude/longitude ਪ੍ਰੋਜੈਕਸ਼ਨ ਖੁਦ ਲਿਖਣੀ ਪੈ ਸਕਦੀ ਹੈ। layouts ਇਸ ਕੰਮ ਨੂੰ ਕਨਫਿਗਰੇਸ਼ਨ ਤੱਕ ਘਟਾ ਦਿੰਦੇ ਹਨ:\n\n- ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਹਰ datum ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ (node, link, region, leaf)\n- ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ constraints (gravity, link distance, padding, projection)\n- layout ਨੂੰ coordinates ਗਣਨਾ ਕਰਨ ਦਿਓ ਜੋ ਤੁਸੀਂ SVG, Canvas, ਜਾਂ HTML ਨਾਲ ਬਾਈਂਡ ਕਰੋ
ਇਸਦਾ ਮਤਲਬ ਹੈ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ—ਰੰਗ, ਲੇਬਲਿੰਗ, ਇੰਟਰੈਕਸ਼ਨ—ਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਕਿਉਂਕਿ ਜਯੋਮੇਟਰੀ ਸਥਿਰ ਅਤੇ ਨਿਰੰਤਰ ਹੈ।
Network graphs: d3.forceSimulation() ਨੋਡਾਂ ਅਤੇ ਲਿੰਕਾਂ ਨੂੰ ਇਤਰੈਟਿਵ ਤੌਰ 'ਤੇ ਪੋਜ਼ਿਸ਼ਨ ਦਿੰਦਾ ਹੈ, ਹਰ ਨੋਡ ਨੂੰ x/y ਦੇ ਕੇ ਤੁਸੀਂ ਸਰਕਲਾਂ ਅਤੇ ਲਾਈਨਾਂ ਵਾਂਗ ਡ੍ਰਾਅ ਕਰ ਸਕਦੇ ਹੋ।
Treemaps: ਹਾਇਰਾਰਕੀ ਲੇਆਉਟ ਮੁੱਲ ਦੇ ਅਨੁਸਾਰ nested ਰੈਕਟੈਂਗਲ ਗਣਨਾ ਕਰਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਵਾਲੇ "ਹਿੱਸੇ-ਤੋਂ-ਪੂਰਾ" ਦਰਸ਼ਨਾਂ ਲਈ ਉੱਚਿਤ।
Maps: d3.geoPath() GeoJSON ਨੂੰ SVG ਪਾਥਸ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਪ੍ਰੋਜੈਕਸ਼ਨ (Mercator, Albers ਆਦਿ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਅਸਲ-ਦੁਨੀਆ ਕੋਆਰਡੀਨੇਟਸ ਨੂੰ ਸਕ੍ਰੀਨ ਕੋਆਰਡੀਨੇਟਸ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਖਿਆਲ ਇਹ ਹੈ: layouts ਕਚ੍ਹੇ ਨੰਬਰਾਂ ਨੂੰ ਡ੍ਰਾਇਅਬਲ ਜਯੋਮੇਟਰੀ ਵਿੱਚ ਬਦਲਦੇ ਹਨ, ਅਤੇ D3 ਦੀ ਡਾਟਾ ਬਾਈਂਡਿੰਗ ਉਹ ਜਯੋਮੇਟਰੀ ਨੂੰ ਪੰਨੇ 'ਤੇ ਮਾਰਕਾਂ ਬਣਾਉਣ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਇੰਟਰਐਕਸ਼ਨ ਸਿਰਫ਼ "ਸੌਖਾ ਜੋੜ" ਨਹੀਂ—ਅਕਸਰ ਇਹ ਹੈ ਜਿੱਥੇ ਲੋਕ ਆਪਣੇ ਵੇਖੇ ਹੋਏ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ। ਇੱਕ ਭਰਾ ਚਾਰਟ ਮਨ-ਭਰਾਵਾ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਠੀਕ ਸਮਝ ਨਾ ਆਵੇ। ਜਦ ਪਾਠਕ hover ਕਰ ਕੇ ਮੁੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ, filter ਕਰਕੇ ਇੱਕ ਸਿਗਮੈਂਟ ਅਲੱਗ ਕਰ ਸਕਦਾ, ਜਾਂ zoom ਕਰਕੇ ਘਣੇ ਕਲੱਸਟਰ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ, ਤਦ ਉਹ ਗ੍ਰਾਫਿਕ ਤਸਵੀਰ ਤੋਂ ਸੋਚਣ ਦਾ ਸਾਧਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਪਹਿਲੀਣ ਪਛਾਣਯੋਗ D3-ਸਟਾਇਲ interaction tooltip ਹੈ। ਚਾਰਟ ਅਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਨਿਰਧਾਰਤ ਮੁੱਲ ਹਰ ਵੇਲੇ ਮਿਲ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਲੋੜ ਮੰਗਦੇ ਹੋ। ਸਭ ਤੋਂ ਵਧੀਆ tooltips ਸਿਰਫ਼ ਅਕਸ ਲੇਬਲ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਨਹੀਂ—ਉਹ ਸੰਦਰਭ (ਯੂਨਿਟ, ਸਮਾਂ ਅਵਧੀ, ਸਰੋਤ, ਰੈਂਕ) ਜੋੜਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਥਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਉਹ ਜਿਹੜੇ ਮਾਰਕ ਤੁਸੀਂ ਵੇਖ ਰਹੇ ਹੋ ਉਸਨੂੰ ਛੁੱਡ ਕੇ ਰੱਖਣ।
Brushing—ਕਲਿੱਕ ਕਰਕੇ ਅਤੇ ਡਰੈਗ ਕਰਕੇ ਇੱਕ ਖੇਤਰ ਚੁਣਨਾ—ਸਿੱਧਾ ਤਰੀਕਾ ਹੈ ਇਹ ਪੁਛਣ ਲਈ ਕਿ “ਇਸ ਸਮਾਂ-ਵਿੰਡੋ ਵਿੱਚ ਕੀ ਹੋਇਆ?” ਜਾਂ “ਇਸ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਹੜੇ ਪੋਇੰਟ ਹਨ?” D3 ਨੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਵੈੱਬ ਤੇ ਵਰਤਣ ਯੋਗ ਬਣਾਇਆ, ਖ਼ਾਸ ਕਰ ਕੇ ਟਾਈਮ-ਸਿਰੀਜ਼ ਚਾਰਟਾਂ ਅਤੇ scatterplots ਲਈ।
ਚੁਣੇ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ filter ਕਰਨ (ਹਾਈਲਾਈਟ ਕਰਨਾ, ਹੋਰਾਂ ਨੂੰ dim ਕਰਨਾ, ਜਾਂ ਮੁੜ-ਡ੍ਰਾ ਕਰਨਾ) ਨਾਲ brushing ਇੱਕ ਸਥਿਰ ਦਰਸ਼ਨ ਨੂੰ ਖੋਜਯੋਗ ਬਣਾ ਦਿੰਦਾ ਹੈ।
D3 ਨੇ ਉਹ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰਸਿੱਧ ਕੀਤਾ ਜਿੱਥੇ ਇੰਟਰਐਕਸ਼ਨ ਇੱਕ ਚਾਰਟ ਤੋਂ ਦੂਜੇ ਚਾਰਟ ਤੱਕ ਵਿਆਪਕ ਹੁੰਦੀ ਹੈ। ਇਕ ਬਾਰ ਤੇ ਕਲਿੱਕ ਕਰੋ ਅਤੇ ਨਕਸ਼ਾ ਅਪਡੇਟ ਹੋ ਜਾਵੇ; timeline 'ਤੇ brush ਕਰੋ ਅਤੇ ਟੇਬਲ ਅਪਡੇਟ ਹੋ ਜਾਏ; ਇੱਕ ਪੋਇੰਟ 'ਤੇ hover ਕਰੋ ਅਤੇ ਮੂਲ ਰੋ ਰੇਖਾ ਹਾਈਲਾਈਟ ਹੋ ਜਾਵੇ। ਇਹ linked views ਸ਼੍ਰੋਤਾਂ ਨੂੰ ਵਰਗ, ਭੂਗੋਲ ਅਤੇ ਸਮਾਂ ਨੂੰ ਇਕੱਠੇ ਮਿਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਸਭ ਕੁਝ ਇੱਕ ਜ਼ਿਆਦਾ ਭਾਰੇ ਚਾਰਟ ਵਿੱਚ ਦਬਾਉਣ ਦੇ।
ਅਕਸਰ interactions ਕੁਝ ਢੁਕਵੇਂ ਇਵੈਂਟਾਂ ਤੱਕ ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ—click, mousemove, mouseenter/mouseleave, ਅਤੇ touch ਦੇ ਬਰਾਬਰ। D3 ਦਾ ਰੁਖ ਟੀਮਾਂ ਨੂੰ ਹਿੰਮਤ ਦਿੰਦਾ ਕਿ ਉਹ ਵਿਵਹਾਰ ਸਿੱਧਾ ਵਿਜ਼ੂਅਲ ਤੱਤਾਂ (bars, dots, labels) ਨਾਲ ਜੋੜਨ, ਜਿਸ ਨਾਲ interactions ਗ੍ਰਾਫਿਕ ਵਿੱਚ "ਮੂਲ" ਲੱਗਦੇ ਹਨ ਨਾ ਕਿ ਬਾਹਰੋਂ ਲਗਾਏ ਹੋਏ।
ਇੰਟਰਐਕਟਿਵ ਚਾਰਟਾਂ ਨੂੰ ਮਾਊਸ ਤੋਂ ਅਲਾਵਾ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਕੀਬੋਰਡ ਰਾਹੀਂ ਉਪਲਬਧ ਰੱਖੋ (ਫੋਕਸੇਬਲ ਤੱਤ, ਸਪਸ਼ਟ ਫੋਕਸ ਸਟੇਟ), ਸਕਰੀਨ-ਰੀਡਰ ਲਈ ਲੇਬਲ ਅਤੇ ਵਰਣਨ ਦਿਓ, ਅਤੇ ਰੰਗ ਨਾਲ ਹੀ ਅਰਥ ਨਹੀਂ ਦਰਸਾਉ। Reduced-motion ਪ੍ਰੈਫਰੰਸਜ਼ ਦਾ ਸਨਮਾਨ ਕਰੋ ਤਾਂ ਕਿ tooltips, highlights ਅਤੇ transitions ਰੁਕਾਵਟ ਨਾ ਬਣਣ।
D3 ਨੇ ਇੱਕ ਸਧਾਰਨ ਖਿਆਲ ਪ੍ਰਸਿੱਧ ਕੀਤਾ: ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਇੱਕ ਸਥਿਤੀ ਤੋਂ ਦੂਜੇ ਸਥਿਤੀ ਵਿਚਕਾਰ ਦਾ ਐਨੀਮੇਟਡ ਬਦਲਾਅ ਹੈ। ਚਾਰਟ ਨੂੰ ਮੁੜ-ਖਿੱਚਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਮਾਰਕਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਪੁਰਾਣੀ ਥਾਂ ਤੋਂ ਨਵੀਂ ਥਾਂ 'ਤੇ ਹਿਲਾਉਂਦੇ ਹੋ—ਬਾਰ ਵੱਧਦੇ ਹਨ, ਡਾਟ ਢਕਣ ਜਾਂ ਖਿਸਕਦੇ ਹਨ, ਲੇਬਲ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ। ਇਹ “ਵਿਚਕਾਰਲਾ” ਗਤੀ ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।
ਇਸਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਸਪਸ਼ਟਤਾ ਵਧਾਉਂਦੇ ਹਨ:\n\n- ਸਮਾਂ ਦੇ ਨਾਲ ਬਦਲਾਅ ਦਿਖਾਉਣ ਜਾਂ ਫਿਲਟਰ ਦੇ ਬਾਅਦ। ਜੇ ਇੱਕ ਬਾਰ ਉੱਪਰ ਜਾ ਰਹੀ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਅੰਞਾਣੇ ਤੌਰ 'ਤੇ ਫਾਲੋ ਕਰਦੇ ਹੋ।\n- ਪਹਚਾਨ ਬਣਾਈ ਰੱਖਣਾ। ਜਦ scatterplot ਦੇ ਪੁਆਇੰਟ ਕਿਸੇ ਸਕੇਲ ਬਦਲਣ ਜਾਂ brushing ਤੋਂ ਬਾਅਦ ਸਥਾਨ ਬਦਲਦੇ ਹਨ, ਨਰਮ ਗਤੀ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ "ਉਹੀ ਡਾਟਾ, ਨਵੀਂ ਨਜ਼ਰੀਆ"।\n- ਕਾਰਨ-ਅਸਰ ਸਮਝਾਉਣਾ। ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਜੋ ਨਰਮ re-sort ਟਰਿੱਗਰ ਕਰਦਾ ਹੈ, interaction ਨੂੰ ਨਤੀਜੇ ਨਾਲ ਜੁੜਿਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਐਨੀਮੇਸ਼ਨ ਉਸ ਵਕਤ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ ਜਦ ਇਹ ਡਾਟਾ ਨਾਲ ਮੁੱਕਾਬਲਾ ਕਰਦੀ ਹੈ:\n\n- ਲਗਾਤਾਰ ਗਤੀ (ਲੂਪ ਕਰਨਾ, ਭੰਕਣ, "ਸ਼ਿਮਰ" ਪ੍ਰਭਾਵ) ਪੜ੍ਹਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ।\n- ਲੰਬੇ, ਨਾਟਕੀ easing ਇਤਨਾ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਚਾਰਟ ਖਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹੋ।\n- ਬਹੁਤ ਸਾਰੇ ਘਟਕ ਇੱਕ ਵਾਰੀ ਹਿਲਣਾ ਇੱਕ ਸਾਫ਼ ਅਪਡੇਟ ਨੂੰ ਵਿਜ਼ੂਅਲ ਹੰਗਾਮੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜੇ ਦਰਸ਼ਕ ਬਿਨਾਂ ਗਤੀ ਦੇ ਅਪਡੇਟ ਤੁਰੰਤ ਸਮਝ ਲੈ ਲੈਂਦਾ, ਤਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਨੂੰ ਸੁਖਦ ਅਤੇ ਨਰਮ ਰੱਖੋ—ਜਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ।
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ। ਪ੍ਰਦਰਸ਼ਨ ਵਿਚ ਸੁਧਾਰ ਆਮ ਤੌਰ 'ਤੇ ਜਦ ਤੁਸੀਂ:\n\n- ਅਨੀਮੇਟ ਕੀਤੇ ਤੱਤਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਓ। ਹਜ਼ਾਰਾਂ ਪੁਆਇੰਟਾਂ ਦੀ ਬਜਾਏ ਸੁੰਨਦੀ ਰੇਖਾ ਜਾਂ ਕੁਝ ਬਾਰਾਂ ਨੂੰ ਅਨੀਮੇਟ ਕਰੋ।\n- ਮਹਿੰਗੇ ਵਿਜ਼ੂਅਲ ਪ੍ਰਭਾਵਾਂ ਤੋਂ ਬਚੋ। ਭਾਰੀ SVG filters, ਛਾਇਆ ਅਤੇ ਬਲਰ ਸਭ ਕੁਝ धीਮਾ ਕਰ ਸਕਦੇ ਹਨ।\n- ਸਧਾਰਨ ਗੁਣਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਸਥਿਤੀ ਅਤੇ opacity ਨੂੰ ਹਿਲਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਜਟਿਲ ਆਕਾਰ-ਰੂਪਾਂ ਨੂੰ ਮੋਰਫ ਕਰਨ ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ।
ਆਖ਼ਿਰ 'ਚ, ਯੂਜ਼ਰ ਆਰਾਮ ਨੂੰ ਯਾਦ ਰੱਖੋ। reduced-motion ਪਸੰਦਾਂ ਦਾ ਸਨਮਾਨ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, ਅਵਧੀ ਘਟਾਉ ਕੇ ਜਾਂ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਬੰਦ ਕਰਕੇ) ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਨਿਯੰਤਰਣ ਦਿਓ—ਜਿਵੇਂ "ਐਨੀਮੇਸ਼ਨ ਰੋਕੋ" ਟੌਗਲ ਜਾਂ ਇੱਕ ਸੈਟਿੰਗ ਜੋ ਐਨੀਮੇਟਡ ਅਪਡੇਟਾਂ ਨੂੰ ਤੁਰੰਤ ਅਪਡੇਟਾਂ 'ਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਡਾਟਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ ਮੋਸ਼ਨ ਸਮਝਣ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਧਿਆਨ ਖਿੱਚਣ ਲਈ ਨਹੀਂ।
D3 ਨੂੰ ਅਕਸਰ “ਇੱਕ ਚਾਰਟ ਲਾਇਬ੍ਰੇਰੀ” ਸਮਝਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ। D3 ਤੁਹਾਨੂੰ ਇੱਕ ਤਿਆਰ-ਕੀਤੇ ਬਾਰ ਚਾਰਟ ਕੰਪੋਨੇੰਟ ਨਹੀਂ ਦਿੰਦਾ ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿਕਲਪ ਹੁੰਦੇ। ਇਸਦੀ ਥਾਂ, ਇਹ ਤੁਹਾਨੂੰ ਨਿਮਨ-ਸਤਹ ਨਿਰਮਾਣ ਖੰਡ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਰਟ ਬਣਾਉਣ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ: scales, axes, shapes, layouts, selections, ਅਤੇ behaviors। ਇਸੀ ਲਈ D3 ਬਹੁਤ ਲਚਕੀਲਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਇਸੀ ਲਈ ਇਹ ਕਈ ਵਾਰ ਉਮੀਦ ਨਾਲੋਂ ਵੱਧ ਕੰਮ ਲੱਗ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ “ਚਾਰਟ ਪਾ ਕੇ ਤੁਰੰਤ ਜਮਨ੍ਹਾ” ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਓਰ ਰੁਖ ਕਰੋਗੇ ਜੋ ਤਿਆਰ-ਕੀਤੇ ਚਾਰਟ ਕਿਸਮਾਂ ਦਿੰਦੇ ਹਨ। D3 ਜ਼ਿਆਦਾ ਇੱਕ ਸੈੱਟ ਪ੍ਰੈਸੀਜ਼ਨ ਟੂਲਾਂ ਦੇ ਕੋਲ ਹੈ: ਤੁਸੀਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਚਾਰਟ ਕੀ ਹੈ, ਇਹ ਕਿਵੇਂ ਡਰਾਅ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਵਰਤਵੇ।
ਇਹ ਟਰੇਡਆਫ਼ ਇਰਾਦਤਨ ਹੈ। ਅਣਪੱਖਪਾਤੀ ਰਹਿ ਕੇ, D3 ਰਿਵਾਇਤੀ ਚਾਰਟਾਂ ਤੋਂ ਲੈ ਕੇ ਕਸਟਮ ਨਕਸ਼ੇ, ਨੈਟਵਰਕ ਡਾਇਗ੍ਰਾਮ ਅਤੇ ਵਿਲੱਖਣ ਐਡੀਟੋਰਿਅਲ ਗ੍ਰਾਫਿਕਸ ਤੱਕ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਹਾਰਦਾ ਹੈ।
ਅਧੁਨਿਕ ਟੀਮਾਂ ਵਿੱਚ, D3 ਅਕਸਰ ਇੱਕ UI ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ:\n\n- ਫਰੇਮਵਰਕ (React/Vue/Svelte) ਐਪ ਢਾਂਚਾ ਨੂੰ ਕਾਬੂ ਕਰਦਾ: ਪੰਨੇ, ਕੰਪੋਨੇੰਟ, UI ਸਟੇਟ, ਇਵੈਂਟ, ਪਹੁੰਚਯੋਗਤਾ ਅਤੇ ਰੇਂਡਰਿੰਗ ਲਾਈਫਸਾਈਕਲ।\n- D3 “ਡਾਟਾ ਮੈਥ” ਨੂੰ ਸੰਭਾਲਦਾ: scales, ticks, layout algorithms, path generation, ਅਤੇ ਕਈ ਵਾਰੀ zoom/drag ਲਾਜ਼ਿਕ।
ਇਹ ਹਾਈਬ੍ਰਿਡ ਰੁੱਖ D3 ਨੂੰ ਪੂਰੀ ਐਪ ਮੈਨੇਜ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਇਸ ਦੀਆਂ ਸਭ ਤੋਂ ਤਾਕਤਵਰ ਯੋਗਤਾਵਾਂ ਤੋਂ ਫਾਇਦਾ ਲੈਦਾ ਹੈ।
ਇੱਕ ਵਰਤਣਯੋਗ ਨਿਯਮ: ਫਰੇਮਵਰਕ ਨੂੰ DOM ਤੱਤ ਬਣਾਉਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਦਿਓ; D3 ਨੂੰ ਪੋਜ਼ਿਸ਼ਨ ਅਤੇ ਸ਼ੇਪਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਦਿਓ।
ਉਦਾਹਰਣ ਲਈ, D3 ਨੂੰ ਮੁੱਲਾਂ ਨੂੰ ਪਿਕਸਲਾਂ ਵਿੱਚ ਨਕਸ਼ਾ ਕਰਨ (scales) ਅਤੇ ਇੱਕ SVG path ਬਣਾਉਣ ਲਈ ਵਰਤੋ, ਪਰ ਤੁਹਾਡੇ ਕੰਪੋਨੇੰਟ \u003csvg\u003e ਦੇ ਢਾਂਚੇ ਨੂੰ ਰੇਂਡਰ ਅਤੇ ਯੂਜ਼ਰ ਇਨਪੁਟ ਦਾ ਜਵਾਬ ਦੇਣ ਦਿਓ।
ਦੋ ਗਲਤੀਆਂ ਮੁੜ-ਮੁੜ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:\n\n- DOM ਨਾਲ ਲੜਾਈ: ਫਰੇਮਵਰਕ ਰੇਂਡਰਿੰਗ ਨੂੰ D3 ਦੀ ਸਿੱਧੀ DOM ਮਿਊਟੇਸ਼ਨ ਨਾਲ ਮਿਲਾਉਣਾ flicker, duplicate nodes, ਜਾਂ "ਅਜੀਬ" ਅਪਡੇਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।\n- ਬੁਰੀ ਤਰ੍ਹਾਂ ਦਾ state tangled ਹੋਣਾ: ਇੱਕੋ state ਨੂੰ ਕਈ ਜਗ੍ਹਾ ਰੱਖਣਾ (ਫਰੇਮਵਰਕ state + D3 ਅੰਦਰੂਨੀ state) interactions ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਔਖਾ ਕਰ ਦਿੰਦਾ ਹੈ।
D3 ਨੂੰ ਇੱਕ ਟੂਲਕਿਟ ਸਮਝੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਖ਼ਾਸ ਕੰਮਾਂ ਲਈ ਬੁਲਾਉਂਦੇ ਹੋ, ਤੁਹਾਡਾ ਕੋਡ ਨਿਰਾਲਾ ਰਹੇਗਾ—ਅਤੇ ਤੁਹਾਡੇ ਚਾਰਟ ਨਿਭਾਉਣ ਯੋਗ ਰਹਿਣਗੇ।
D3 ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਵਿਰਾਸਤ ਕਿਸੇ ਇਕ ਚਾਰਟ ਕਿਸਮ ਵਿੱਚ ਨਹੀਂ—ਇਹ ਉਮੀਦ ਹੈ ਕਿ ਵੈੱਬ ਗ੍ਰਾਫਿਕਸ ਸੁਧਰੇ, ਅਭਿਵ੍ਯੰਜਕ ਅਤੇ ਡਾਟਾ ਨਾਲ ਗਠੇ ਹੋ ਸਕਦੇ ਹਨ। D3 ਦੇ ਵਿਸ਼ਾਲ ਪੈਂਡੇ ਤੋਂ ਬਾਅਦ, ਕਈ ਟੀਮਾਂ ਨੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਇੰਟਰਫੇਸ ਦਾ ਪਹਿਲਾ-ਸ਼੍ਰੇਣੀ ਹਿੱਸਾ ਮੰਨਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਨਾ ਕਿ ਪੇਜ਼ 'ਤੇ ਜੋੜਿਆ ਹੋਇਆ ਇਕ ਬਾਅਦ ਦਾ ਕੰਮ।
D3 ਪਹਿਲਾਂ ਹੀ ਡੇਟਾ ਜਰਨਲਿਜ਼ਮ ਵਿੱਚ ਦਿਖਿਆ ਕਿਉਂਕਿ ਇਹ ਵਰਕਫਲੋ ਨਾਲ ਭਲੀ-ਭਾਂਤ ਸੀ: ਰਿਪੋਰਟਰਾਂ ਅਤੇ ਡਿਜ਼ਾਈਨਰਾਂ ਨੇ ਅਨੁਕੂਲ ਵਿਜ਼ੂਅਲ ਬਣਾਉਣ ਲਈ ਤਿਆਰ-ਕੀਤੇ ਟੈਮਪਲੇਟ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿਣਾ ਪਿਆ। ਇੰਟਰਐਕਟਿਵ ਚੋਣ-ਮੈਪ, scroll-driven explainers, ਅਤੇ ਐਨੋਟੇਡ ਚਾਰਟ ਆਮ ਹੋ ਗਏ—ਨਾ ਕਿ ਇਸਲਈ ਕਿ D3 ਨੇ ਉਹਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ, ਪਰ ਇਸਲਈ ਕਿ ਇਹਨਾਂ ਨੂੰ ਵੈੱਬ-ਨੇਟਿਵ ਨਿਰਮਾਣ ਖੰਡਾਂ ਨਾਲ ਸੰਭਵ ਬਣਾਇਆ।
ਸਿਵਿਕ ਟੈਕ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਵੀ ਇਹੀ ਲਚਕ ਮਿਲੀ। ਸਰਵਜਨਿਕ ਡੇਟਾਏ ਗੁੰਝਲਦਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਜਿਹੜੇ ਪ੍ਰਸ਼ਨ ਪੁਛਦੇ ਹਨ ਉਹ ਸ਼ਹਿਰ, ਨੀਤੀ ਅਤੇ ਦਰਸ਼ਕ ਅਨੁਸਾਰ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। D3 ਦੇ ਰੁੱਖ ਨੇ ਉਹ ਪ੍ਰੋਜੈਕਟਾਂ ਉਤਪੰਨ ਕੀਤੇ ਜੋ ਡਾਟਾ ਦੇ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਹੋ ਸਕਦੇ—ਚਾਹੇ ਉਹ ਇਕ ਸਧਾਰਨ ਚਾਰਟ ਹੋਵੇ ਜਿਸ 'ਚ ਧਿਆਨ-ਪੂਰਨ ਲੇਬਲਿੰਗ ਹੋਵੇ ਜਾਂ ਇੱਕ ਹੋਰ ਖੋਜਯੋਗ ਇੰਟਰਫੇਸ।
ਭਾਵੇਂ ਟੀਮਾਂ ਜੋ ਸਿੱਧਾ D3 ਨਾ ਵਰਤੋਂ, ਬਹੁਤ ਪ੍ਰਥਾਵਾਂ ਜੋ ਇਸ ਨੇ ਲੋਕਪ੍ਰਿਯ ਕੀਤੀਆਂ ਉਹ ਸਾਂਝੀਆਂ ਮਿਆਰ ਬਣ ਗਈਆਂ: scales ਅਤੇ ਕੋਆਰਡੀਨੇਟ ਸਿਸਟਮ ਦੇ ਬਾਰੇ ਸੋਚਣਾ, ਡਾਟਾ ਰੂਪਾਂਤਰਣ ਨੂੰ ਰੇਂਡਰਿੰਗ ਤੋਂ ਅਲੱਗ ਰੱਖਣਾ, ਅਤੇ DOM (ਜਾਂ Canvas) ਨੂੰ ਪ੍ਰੋਗਰਾਮੇਬਲ ਗ੍ਰਾਫਿਕਸ ਸਰਫੇਸ ਵਜੋਂ ਵਰਤਣਾ।
D3 ਦਾ ਪ੍ਰਭਾਵ ਇਸ ਦੀ community ਰਾਹੀ ਵੀ ਫੈਲਿਆ। ਛੋਟੇ, ਕੇਂਦਰਿਤ ਉਦਾਹਰਣਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਆਦਤ—ਹਰ ਵਾਰ ਇਕ ਵਿਚਾਰ ਦਿਖਾਉਣਾ—ਨਵੀਂਆਂ ਲਈ remix ਕਰਕੇ ਸਿੱਖਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ। Observable notebooks ਨੇ ਇਸ ਰਿਵਾਜ ਨੂੰ ਹੋਰ ਇੰਟਰਐਕਟਿਵ ਮਾਧਿਅਮ ਨਾਲ ਵਧਾਇਆ: ਲਾਈਵ ਕੋਡ, ਤੁਰੰਤ ਪ੍ਰਤੀਕਿਰਿਆ, ਅਤੇ visualization ਵਿਚਾਰਾਂ ਲਈ ਸਾਂਝੇ ਕੀਤੇ “sketchbooks”。 ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਸਭਿਆਚਾਰ ਨੇ ਮਿਲ ਕੇ ਆਧੁਨਿਕ ਵੈੱਬ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਕੰਮ ਦਾ ਆਕਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ।
D3 ਉਹ ਵੇਲੇ ਆਸਾਨੀ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਡਿਜ਼ਾਈਨ ਟੂਲ ਸਮਝਦੇ ਹੋ, ਨਾਂ ਕਿ ਇੱਕ ਸ਼ਾਰਟ ਬਣਾਉਣ ਦਾ ਸ਼ੌਰਟਕਟ। ਇਹ ਤੁਹਾਨੂੰ ਡਾਟਾ ਨੂੰ ਮਾਰਕਾਂ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਬਾਰੀਕੀ ਨਿਯੰਤਰਣ ਦਿੰਦਾ (lines, bars, areas, nodes), ਕਿ ਉਹ ਕਿਵੇਂ ਇਨਪੁਟ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਸਭ ਕੁਝ ਸਮੇਂ ਦੇ ਨਾਲ ਅਪਡੇਟ ਹੋਵੇ। ਇਹ ਆਜ਼ਾਦੀ ਹੀ ਲਾਗਤ ਵੀ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਫੈਸਲੇ ਤੁਸੀਂ ਖੁਦ ਕਰਨ ਦੇ ਜ਼ਿੰਮੇਵਾਰ ਹੋ ਜੋ ਇੱਕ ਚਾਰਟਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਤੁਹਾਡੇ ਲਈ ਕਰ ਦੇਵੇਗੀ।
ਕਿਸੇ ਟੂਲ ਨੂੰ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਨ੍ਹਾਂ ਚਾਰ ਗੱਲਾਂ ਨੂੰ ਸਾਫ਼ ਕਰੋ:\n\n- Audience: ਇਹ ਕਿਸ ਲਈ ਹੈ—ਐਗਜ਼ਿਕਿਊਟਿਵ, ਵਿਸ਼ਲੇਸ਼ਕ, ਜਨਤਾ?\n- Questions: ਯੂਜ਼ਰ ਕੀ ਪੁੱਛ ਰਹੇ ਹਨ—ਮੁੱਲ ਤੁਲਨਾ, ਆਊਟਲਾਇਰ ਲੱਭਣਾ, “ਕਿਉਂ” ਖੋਜਨਾ, ਜਾਂ KPI ਮਾਨਿਟਰਿੰਗ?\n- Data quality & shape: ਕੀ ਇਹ ਸਾਫ਼ ਅਤੇ ਸਥਿਰ ਹੈ, ਜਾਂ ਗੁੰਝਲਦਾਰ, ਮਿਸਿੰਗ ਵਾਲਿਆਂ ਨਾਲ?\n- Chart type: ਕੀ ਇਹ ਇੱਕ ਮਿਆਰੀ ਚਾਰਟ ਹੈ (bar/line/area) ਜਾਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ (radial layouts, custom maps, network diagrams, dense small multiples)?
ਜੇ ਸਵਾਲ ਖੋਜ-ਮੁੱਖ ਹਨ ਅਤੇ ਚਾਰਟ ਕਿਸਮ “off the shelf” ਨਹੀਂ ਹੈ, ਤਾਂ D3 ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸੋਚਣਯੋਗ ਹੈ।
D3 ਨੂੰ ਚੁਣੋ ਜਦ ਤੁਹਾਨੂੰ ਕਸਟਮ ਇੰਟਰਐਕਸ਼ਨਾਂ (brushing, linked views, ਅਨੌਖੇ tooltips, progressive disclosure), ਵਿਉਂਤ-ਵੈਂਦ ਡਿਜ਼ਾਈਨ (ਗੈਰ-ਮਿਆਰੀ encoding, bespoke layout ਨਿਯਮ), ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਰੇਂਡਰਿੰਗ 'ਤੇ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋ (SVG+Canvas ਹਾਈਬ੍ਰਿਡ)। D3 ਉਸ ਸਮੇਂ ਵੀ ਚਮਕਦਾ ਹੈ ਜਦ visualization ਉਤਪਾਦ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੋ—ਜਿਹੜੇ ਉੱਤੇ ਤੁਹਾਡੀ ਟੀਮ ਇਟਰੇਟ ਅਤੇ ਸੁਧਾਰ ਕਰੇਗੀ।
ਜੇ ਤੁਹਾਡਾ ਲੱਕੜ ਇੱਕ ਸਧਾਰਨ ਡੈਸ਼ਬੋਰਡ ਹੈ ਜਿਸ ਵਿੱਚ ਆਮ ਚਾਰਟ, consistent theming ਅਤੇ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉੱਚ-ਪੱਧਰੀ ਪਰਗਟੈਂਸ (chart libraries) ਜਾਂ BI ਟੂਲ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਤੇ ਸੁਰੱਖਿਅਤ ਹਨ। ਤੁਹਾਨੂੰ axis, legends, responsiveness, ਅਤੇ accessibility ਪੈਟਰਨ ਬਿਨਾਂ ਨਵੇਂ ਤੋਂ ਲਿਖਣ ਦੇ ਮਿਲ ਜਾਣਗੇ।
ਜਦ ਟੀਮ ਇੱਕ ਵੱਡਾ ਪ੍ਰੋਜੈਕਟ ਯਾਾਇਡ (ਉਦਾਹਰਣ ਲਈ, ਉਤਪਾਦ-ਗਰੇਡ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ) ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ selections ਅਤੇ joins, scales, event handling, ਅਤੇ edge cases ਦੀ ਟੈਸਟਿੰਗ ਲਈ ਸਮਾਂ ਬਜਟ ਕਰੋ। ਸਭ ਤੋਂ ਵਧੀਆ D3 ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਇਟਰੇਸ਼ਨ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ਼ ਕੋਡ ਹੀ ਨਹੀਂ—ਇਸ ਲਈ ਦੋਨੋਂ ਲਈ ਸਮਾਂ ਰੱਖੋ।
D3 ਹੱਥ-ਨਾਲ ਸਿੱਖਣ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। “D3 ਮਨੋਵਿਰਤੀ” ਨੂੰ ਮਹਿਸੂਸ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਛੋਟੇ ਚਾਰਟ ਨੂੰ end-to-end ਬਣਾਉਣਾ ਹੈ, ਫਿਰ ਉਸਨੂੰ ਕਮਪੋਨੈਂਟਸ ਰੂਪ ਵਿੱਚ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸੁਧਾਰਨਾ।
ਇਕ ਛੋਟਾ ਡੇਟਾਸੇਟ (10–50 ਰੋ) ਚੁਣੋ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਬਾਰ ਚਾਰਟ ਜਾਂ ਲਾਈਨ ਚਾਰਟ ਬਣਾਓ। ਪਹਿਲਾ ਵਰਜਨ ਜਾਣ-ਬੁਝ ਕੇ ਬੋਰਿੰਗ ਰੱਖੋ: ਇੱਕ SVG, ਇੱਕ ਗਰੁੱਪ (\u003cg\u003e), ਇੱਕ ਸੀਰੀਜ਼। ਜਦ ਇਹ ਠੀਕ ਰੇਂਡਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸੁਧਾਰ ਜੋੜੋ—hover tooltips, ਇੱਕ ਹਾਈਲਾਈਟ ਸਟੇਟ, ਫਿਰ filtering ਜਾਂ sorting। ਇਹ ਕ੍ਰਮ ਤੁਹਾਨੂੰ ਦਿਖਾਏਗਾ ਕਿ ਅਪਡੇਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਬਗੈਰ ਬਹੁਤ ਸਾਰੀਆਂ ਫੀਚਰਾਂ ਵਿੱਚ ਘੁਸੇ।
ਜੇ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਵੇਲੇ ਇੱਕ ਰੈਫਰੈਂਸ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੀ ਟੀਮ ਵਿਖੇ ਇੱਕ ਨੋਟਸ ਪੇਜ਼ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਨੋਟ ਕਰੋ ਜੋ ਤੁਸੀਂ /blog ਤੋਂ ਪਸੰਦ ਕਰਦੇ ਹੋ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝਿਆ ਨਹੀਂ।
ਪਹਿਲੇ ਚਾਰਟ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਰੀਯੂਜ਼ੇਬਲ “ਚਾਰਟ ਪੈਟਰਨ” (ਸੰਰਚਨਾ, margins, update function, event handlers) ਦਸਤਾਵੇਜ਼ ਬਣਾਓ। ਇਸਨੂੰ ਇੱਕ ਛੋਟਾ ਅੰਦਰੂਨੀ ਕੰਪੋਨੇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਵਾਂਗ ਸੋਚੋ—ਭਾਵੇਂ ਤੁਸੀਂ ਕੋਈ ਫਰੇਮਵਰਕ ਵਰਤ ਨਹੀਂ ਰਹੇ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਸਾਂਝਾ ਸ਼ਬਦਾਵਲੀ ਅਤੇ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਬਣਾਉਂਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਐਨਾਲਿਟਿਕਸ ਟੂਲ (ਸਿਰਫ਼ ਇੱਕ-ਵਾਰ ਚਾਰਟ ਨਹੀਂ) ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਸਲੇ ਹੀ ਆਸਾਮਿੱਥ surrounding app—authentication, routing, tables, filters, API endpoints—ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੁਸੀਂ visualization ਵਿਸਥਾਰ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਹਤਰੀਨ ਤਰੀਕੇ ਨਾਲ ਪਰਖ ਸਕਦੇ ਹੋ। Platforms ਜਿਵੇਂ Koder.ai ਇਥੇ ਉਪਯੋਗੀ ਹਨ: ਤੁਸੀਂ chat ਰਾਹੀਂ React-ਅਧਾਰਤ web app ਨੂੰ vibe-code ਕਰ ਸਕਦੇ ਹੋ, planning ਮੋਡ ਵਿੱਚ iterate ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ hosting ਅਤੇ ਕਸਟਮ ਡੋਮੇਨਾਂ ਨਾਲ deploy ਕਰ ਸਕਦੇ ਹੋ। ਵੱਖ-ਵੱਖ interaction ਡਿਜ਼ਾਈਨ ਅਜ਼ਮਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, snapshots ਅਤੇ rollback ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਯੋਗਕ ਹਨ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਕ ਨਵਾਂ brushing/zoom flow ਟਰਾਈ ਕਰ ਸਕੋ ਬਿਨਾਂ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਵਰਜ਼ਨ ਨੂੰ ਗੁਆਉਣ ਦੇ।
ਗਹਿਰਾਈ ਲਈ, ਨਵੇਂ ਆਵਣ ਵਾਲਿਆਂ ਨੂੰ /docs ਦੀ طرف ਰਾਖੋ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਟੂਲਿੰਗ ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ /pricing 'ਤੇ ਇਕ ਤੁਲਨਾਤਮਕ ਪੰਨਾ ਰੱਖੋ।
Mike Bostock ਨੇ ਇੱਕ ਸਾਫ਼ ਮਾਨਸਿਕ ਮਾਡਲ ਦਿਖਾਇਆ: ਡਾਟਾ ਨੂੰ DOM ਨਾਲ ਬਾਈਂਡ ਕਰੋ ਤਾਂ ਜੋ ਹਰ ਡਾਟਾ ਆਈਟਮ ਇੱਕ ਸਕ੍ਰੀਨ-ਉਤੇ "ਮਾਰਕ" (ਇੱਕ ਬਾਰ, ਡਾਟ, ਲੇਬਲ, ਪਾਥ) ਨਾਲ ਮੇਲ ਖਾਏ। ਤਸਵੀਰ ਦੇ ਤੌਰ 'ਤੇ ਬੰਦ ਹੋਏ ਚਾਰਟ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਅਸਲ ਵੈੱਬ ਤੱਤ (SVG/HTML) ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਜਾਂ Canvas 'ਤੇ ਡਾਟਾ-ਚਲਿਤ ਲਾਜਿਕ ਨਾਲ ਡਰਾਇੰਗ ਕਰਦੇ ਹੋ।
ਰਵਾਇਤੀ ਟూలز ਅਕਸਰ ਇੱਕ ਚਾਰਟ ਟੈਮਪਲੇਟ (bar/line/pie) ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਵਿਕਲਪਾਂ ਚੇਨ੍ਹਣ ਦਿੰਦੇ ਹਨ। D3 Web primitives (DOM, SVG, Canvas) ਨੂੰ ਆਧਾਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਨਿਰਮાણ ਖੰਡਾਂ—scales, shapes, axes, layouts, behaviors—ਨੂੰ ਦਿੰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਿਹੜੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਉਹ ਡਿਜ਼ਾਇਨ ਕਰ ਸਕੋ, ਖ਼ਾਸ interactions ਅਤੇ ਗੈਰ-ਮਿਆਰੀ ਲੇਆਉਟ ਸਮੇਤ।
ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਮਜ਼ਬੂਤ, ਮਿਆਰੀ ਗ੍ਰਾਫਿਕ ਅਤੇ ਸਟ੍ਰਕਚਰ ਆ ਗਈ ਸੀ:
D3 ਇਸ ਮੋੜ 'ਤੇ ਫਿੱਟ ਬੈਠਿਆ ਕਿਉਂਕਿ ਇਹ ਡਾਟਾ ਨੂੰ ਇਨ੍ਹਾਂ ਨੈਟਿਵ ਯੋਗਤਾਵਾਂ ਨਾਲ ਜੋੜਦਾ ਸੀ, ਨਾ ਕਿ ਸਥਿਰ ਤਸਵੀਰਾਂ ਨਿਕਲਦਾ।
ਇੱਕ selection D3 ਦਾ ਤਰੀਕਾ ਹੈ ਕਿਸੇ ਤੱਤ ਨੂੰ ਟਾਰਗੇਟ ਕਰਕੇ ਉਸ 'ਤੇ ਬਦਲਾਅ ਲਾਉਣ ਦਾ। ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਹੈ: “ਇਨ੍ਹਾਂ ਨੋਡਾਂ ਨੂੰ ਲੱਭੋ, ਫਿਰ ਡਾਟਾ ਦੇ ਆਧਾਰ 'ਤੇ attributes/styles/events ਸੈੱਟ ਕਰੋ।” ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇੱਕ container ਚੁਣਦੇ ਹੋ, marks (ਜਿਵੇਂ circle) ਚੁਣਦੇ ਹੋ, ਡਾਟਾ ਬਾਈਂਡ ਕਰਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਹਰ datum ਤੋਂ x/y, r, fill, ਅਤੇ ਲਿਖਤ ਸੈੱਟ ਕਰਦੇ ਹੋ।
ਇਹ visuals ਨੂੰ ਬਦਲਦੇ ਡਾਟਾ ਨਾਲ ਸਿੰਕ ਵਿੱਚ ਰੱਖਣ ਦੀ ਵਰਕਫਲੋ ਹੈ:
ਇਸ ਕਾਰਨ D3 ਫਿਲਟਰਾਂ, ਲਾਈਵ ਅਪਡੇਟ ਅਤੇ ਇੰਟਰਐਕਟਿਵ re-sort ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਸਾਰਾ ਕੁਝ ਮੁੜ-ਬਣਾਉਣ ਦੇ।
D3 ਦਾ scale ਇੱਕ ਫੰਕਸ਼ਨ ਹੁੰਦਾ ਹੈ ਜੋ ਡਾਟਾ ਵੈਲਿਊ ਨੂੰ ਵਿਜ਼ੂਅਲ ਵੈਲਿਊ (ਅਕਸਰ ਪਿਕਸਲ) ਵਿੱਚ ਬਦਲਦਾ ਹੈ: data → scale → screen. ਇਹ mapping (domain/range) ਨੂੰ ਕੇਂਦਰੀ ਬਣਾਉਂਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਹੱਥੋਂ-ਹੱਥ ਗਣਿਤ ਨਾ ਫੈਲਾਉਣੋ, ਅਤੇ ਕਈ scales pixels ਨੂੰ ਵਾਪਸ ਡਾਟਾ ਵਿੱਚ invert ਵੀ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ hover readouts, brushing ਅਤੇ zoom ਜਿਹੇ interactions ਲਈ ਬਹੁਤ ਮਾਹਰ ਹੈ।
ਸੰਖੇਪ ਨਿਯਮ:
D3 ਵਿੱਚ ਇੱਕ layout ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾ ਤੋਂ ਜਯੋਮੇਟਰੀ (ਪੋਜ਼ਿਸ਼ਨ, ਕੋਣ, ਰੇਡੀਅਸ, ਪਾਥ, ਮਾਪ) ਨਿਕਾਲਦਾ ਹੈ; ਇਹ ਤੁਹਾਡੇ ਲਈ ਚਾਰਟ ਰੇਂਡਰ ਨਹੀਂ ਕਰਦਾ। ਉਦਾਹਰਣ:
d3-force ਨੈਟਵਰਕ ਨੋਡਾਂ ਲਈ x/y ਨਿਕਾਲਦਾ ਹੈ।d3-geo GeoJSON ਨੂੰ drawable paths ਵਿੱਚ ਬਦਲਦਾ ਹੈ।ਤੁਸੀਂ ਫਿਰ ਉਹ ਕੁੰਪਿਊਟ ਕੀਤੇ ਗਏ ਮੁੱਲ SVG/Canvas/HTML ਵਿੱਚ ਮਾਰਕਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰਦੇ ਹੋ।
D3 ਨੇ ਕੁਝ ਵੈੱਬ-ਨਿਵਾਸੀ interaction ਪੈਟਰਨ ਸਧਾਰਨ ਬਣਾਏ:
ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਇਹ ਹੈ ਕਿ interactions ਨੂੰ ਡਾਟਾ ਅਪਡੇਟ ਨਾਲ ਜੋੜੋ, ਫਿਰ ਦੁਬਾਰਾ ਰੇਂਡਰ ਕਰੋ ਤਾਂ ਕਿ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਸਥਿਰ ਅਤੇ ਸਮਝਣਯੋਗ ਰਹੇ।
ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਇੱਕ ਸਥਿਤੀਆਂ ਦੇ ਵਿਚਕਾਰ ਐਨੀਮੇਟਡ ਬਦਲਾਅ ਹੈ। ਅਜੇ-ਅਜੇ ਚਾਰਟ ਮੁੜ-ਢਾਂਚਾ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਮਾਰਕਾਂ ਨੂੰ ਪੁਰਾਣੀ ਥਾਂ ਤੋਂ ਨਵੀਂ ਥਾਂ ਤੱਕ ਹਿਲਾਉਂਦੇ ਹੋ—ਇਸ ਨਾਲ ਲੋਕਾਂ ਦੀ ਨਜ਼ਰ ਬਦਲਾਅ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਅਤੇ ਸਮਝ ਆਉਂਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।
ਪਰ ਧਿਆਨ ਰੱਖੋ: ਲਗਾਤਾਰ ਜਾਂ ਬਹੁਤ ਡਰਾਮੈਟਿਕ ਐਨੀਮੇਸ਼ਨ ਪਾਠਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੀ ਹੈ। ਯੂਜ਼ਰ ਦੀ ਆਰਾਮਦਾਇਤਾ ਲਈ reduced-motion ਪਸੰਦ ਨੂੰ ਸਨਮਾਨ ਕਰੋ।
ਸੰਖੇਪ ਚੈੱਕਲਿਸਟ:
ਜੇ ਤੁਸੀਂ ਖੋਜ-ਮੁਖੀ ਇੰਟਰੈਕਸ਼ਨ ਜਾਂ ਅਨੌਖਾ ਡਿਜ਼ਾਈਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ D3 ਸਹੀ ਚੋਣ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਮਿਆਰੀ ਡੈਸ਼ਬੋਰਡ ਚਾਹੀਦਾ ਹੈ ਤੇਜ਼ੀ ਨਾਲ, ਤਾਂ ਉੱਚ-ਪੱਧਰੀ ਲਾਇਬ੍ਰੇਰੀ ਬਿਹਤਰ ਹੋ ਸਕਦੀ ਹੈ।