ਡਗਲਸ ਐਂਗਲਬਾਰਟ ਦੀ "Augmenting Human Intellect" ਸੋਚ ਨੇ ਅਜੋਕੇ ਉਤਪਾਦਕਤਾ ਟੂਲਾਂ—ਮਾਊਸ, ਹਾਈਪਰਟੈਕਸਟ, ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਰੀਅਲ-ਟਾਈਮ ਸਹਿਯੋਗ—ਦੀ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ।

ਅਸੀਂ ਵੱਧਤਰ ਆਪਣੇ ਦਿਨ ਵਿਚ ਵਿਚਾਰਾਂ ਨੂੰ ਇਕ ਜਗ੍ਹਾ ਤੋਂ ਦੂਜੇ ਜਗ੍ਹਾ ਲਿਜਾਂਦੇ ਹਾਂ: ਲਿਖਣਾ, ਸੋਧਣਾ, ਖੋਜਣਾ, ਸਾਂਝਾ ਕਰਨਾ, ਅਤੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸਹੀ ਸੰਦਰਭ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼। ਇਹ ਹੁਣ ਆਮ ਲੱਗਦਾ ਹੈ—ਪਰ “ਨੌਲੇਜ਼ ਕੰਮ” ਦਾ ਜੋ ਪੈਟਰਨ ਅਸੀਂ ਆਮ ਮੰਨਦੇ ਹਾਂ ਉਹ 1960ਆਂ ਵਿਚ ਹੀ ਬਣ ਰਿਹਾ ਸੀ।
ਡਗਲਸ ਐਂਗਲਬਾਰਟ ਕਿਸੇ ਗੈਜਿਟ ਬਣਾਉਣ ਲਈ ਨਹੀਂ ਨਿਕਲੇ। ਉਨ੍ਹਾਂ ਦਾ ਮੌਕਸਦ ਇਹ ਸੀ ਕਿ ਲੋਕ ਕਿਵੇਂ ਸੋਚਦੇ ਤੇ ਸਹਿ-ਰਚਨਾ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਸਮੱਸਿਆਆਂ ਜਟਿਲ ਹੋਣ। ਉਨ੍ਹਾਂ ਦੀ ਰਿਸਰਚ ਟੀਮ ਦਫ਼ਤਰੀ ਕੰਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਦੀ ਸੀ ਕਿ ਉਸਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਸਿਰਫ਼ ਤੇਜ਼ ਮਸ਼ੀਨਾਂ ਨਾਲ ਕੰਮ ਤੇਜ਼ ਕਰਨ ਤੋਂ ਬਿਲਕੁਲ ਵੱਖ।
ਐਂਗਲਬਾਰਟ ਨੇ ਸ਼ਬਦ augmenting human intellect ਇਸ ਮਤਲਬ ਲਈ ਵਰਤੇ: ਲੋਕਾਂ ਦੀ ਸੋਚ ਅਤੇ ਟੀਮਵਰਕ ਨੂੰ ਬੇਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨਾ—ਉਨ੍ਹਾਂ ਨੂੰ ਐਸੇ ਟੂਲ ਦੇ ਕੇ ਜੋ ਵਿਚਾਰ ਬਣਾਉਣਾ, ਜੋੜਨਾ ਅਤੇ ਕਾਰਵਾਈ ਕਰਨ ਨੂੰ ਆਸਾਨ ਕਰਦੇ ਹਨ. ਮਨੁੱਖਾਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਣਾ—ਉਨ੍ਹਾਂ ਨੂੰ ਵਧਾਉਣਾ।
ਆਧੁਨਿਕ ਉਤਪਾਦਕਤਾ ਸਾਫਟਵੇਅਰ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀ ਖ਼ਾਸੀਅਤਾਂ ਤਿੰਨ ਮੂਲ ਦਰਸ਼ਨਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਐਂਗਲਬਾਰਟ ਨੇ ਅੱਗੇ ਵਧਾਏ:
ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਐਂਗਲਬਾਰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬਣਾਇਆ (ਖ਼ਾਸ ਕਰਕੇ NLS oN-Line System) ਅਤੇ 1968 ਦੇ ਮਸ਼ਹੂਰ ਡੈਮੋ—“Mother of All Demos”—ਵਿੱਚ ਕੀ ਦਿਖਾਇਆ ਗਿਆ। ਫਿਰ ਅਸੀਂ ਉਹ ਵਿਚਾਰ ਉਹ ਟੂਲਾਂ ਨਾਲ ਜੋੜਾਂਗੇ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਹੋ—ਡੌਕਸ, ਵਿਕੀ, ਪ੍ਰੋਜੈਕਟ ਟ੍ਰੈਕਰ ਅਤੇ ਚੈਟ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਕੀ ਚੰਗਾ ਹੈ, ਕੀ ਘੱਟ ਹੈ, ਅਤੇ ਕਿਉਂ ਕੁਝ ਵਰਕਫਲੋ ਸੁਚੱਜੇ ਅਤੇ ਕੁਝ ਬੇਵਕੂਫ਼ੀ ਵਾਲੇ ਲੱਗਦੇ ਹਨ।
ਡਗਲਸ ਐਂਗਲਬਾਰਟ ਦਾ ਮੁੱਖ ਯੋਗਦਾਨ ਕਿਸੇ ਇੱਕ ਖ਼ਾਸ ਖੋਜ ਦਾ ਨਹੀਂ ਸੀ—ਇਹ ਇਕ ਲਕਸ਼ਯ ਸੀ। 1962 ਦੀ ਆਪਣੀ ਰਿਪੋਰਟ Augmenting Human Intellect: A Conceptual Framework ਵਿੱਚ ਉਸ ਨੇ ਦਲੀਲ ਦਿੱਤੀ ਕਿ ਕੰਪਿਊਟਰ ਲੋਕਾਂ ਦੀ ਸੋਚ, ਸਿੱਖਣ ਅਤੇ ਜਟਿਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੁਲਝਾਉਣ ਦੀ ਯੋਗਤਾ ਨੂੰ ਵਧਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨ; ਉਸ ਨੇ ਇਸਨੂੰ “ਆਗਮੈਂਟੇਸ਼ਨ” ਕਿਹਾ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਡਿਜ਼ਾਈਨ ਨਾਰਥ ਸਟਾਰ ਵਾਂਗੂ ਰੱਖਿਆ।
ਆਟੋਮੇਸ਼ਨ ਮਨੁੱਖੀ ਮਿਹਨਤ ਦੀ ਥਾਂ ਲੈਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ: ਕੰਮ ਤੁਹਾਡੇ ਲਈ ਕਰ ਦਿੰਦੀ ਹੈ, ਤੇਜ਼ ਤੇ ਸਸਤਾ। ਇਹ ਲਾਹੇਵੰਦ ਹੈ, ਪਰ ਜਦੋਂ ਕੰਮ ਅਸਪਸ਼ਟ, ਰਚਨਾਤਮਕ ਜਾਂ ਵਪਾਰ-ਆਧਾਰਿਤ ਹੋਵੇ ਤਾਂ ਇਹ ਤੁਹਾਡੇ ਚੋਣਾਂ ਨੂੰ ਸੀਮਿਤ ਵੀ ਕਰ ਸਕਦੀ ਹੈ।
ਆਗਮੈਂਟੇਸ਼ਨ ਵੱਖਰਾ ਹੈ। ਕੰਪਿਊਟਰ ਸੋਚ ਨੂੰ ਹਕਮ ਨਹੀਂ ਕਰਦਾ; ਉਹ ਉਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਵਿਚਾਰ ਬਾਹਰ ਕੱਢਣ, ਜਾਣਕਾਰੀ ਪਾਸ ਕਰਨ, ਆਸਾਨੀ ਨਾਲ ਸੰਬੰਧ ਵੇਖਣ ਅਤੇ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਸਮਝ ਨੂੰ ਦੁਬਾਰਾ ਸੋਧਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਲਕਸ਼ਯ ਮਨੁੱਖ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਨਹੀਂ—ਮਨੁੱਖੀ ਇਨਸਾਫ਼ ਨੂੰ ਵਧਾਉਣ ਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਮੰਨਦਾ ਸੀ ਕਿ ਸੁਧਾਰਾਂ ਨੂੰ ਇਕੱਠੇ ਹਲਕੀ ਚੀਜ਼ਾਂ ਤੋਂ ਬਣਦੇ ਹੋਏ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਵਧੀਆ ਟੂਲ ਤੁਹਾਨੂੰ ਹੋਰ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਯੋਗਤਾ ਹੋਰ ਬਿਹਤਰ ਟੂਲ, ਤਰੀਕੇ ਅਤੇ ਆਦਤਾਂ ਬਣਾਉਣ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ। ਇਹ ਲੂਪ—ਇਹ ਸਿਖਾਉਣਾ ਕਿ ਅਸੀਂ ਕਿਵੇਂ ਸੁਧਾਰ ਕਰਦੇ ਹਾਂ—ਉਸ ਦੀ ਸੋਚ ਦਾ ਕੇਂਦਰ ਸੀ।
ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਸੁਧਾਰਾਂ (ਨੋਟਸ ਬਣਾਉਣ ਦਾ ਵਧੀਆ ਤਰੀਕਾ, ਦਸਤਾਵੇਜ਼ ਨੈਵੀਗੇਸ਼ਨ, ਜਾਂ ਫੈਸਲੇ ਸਹਿਯੋਗ) ਦੇ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਵੱਡੇ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦੇ ਹਨ।
ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਐਂਗਲਬਾਰਟ ਨੇ ਗਰੁੱਪਾਂ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ। ਜਟਿਲ ਸਮੱਸਿਆਆਂ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਮਨ ਵਿੱਚ ਅਕਸਰ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਇਸ ਲਈ ਆਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਸਾਂਝੇ ਸੰਦਰਭ ਸ਼ਾਮਿਲ ਕਰਨਾ ਪੈਂਦਾ: ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼, ਸਾਂਝੀ ਭਾਸ਼ਾ ਅਤੇ ਉਹ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਕੰਮ ਕੋਆਰਡੀਨੇਟ ਕੀਤਾ ਜਾ ਸਕੇ ਬਿਨਾ ਫੈਸਲੇ ਦੇ ਪਿਛੋਕੜ ਨੂੰ ਖੋਇਆਂ।
ਇਹ ਟੀਮ-ਪਹਿਲਾਂ ਜ਼ੋਰ ਹੈ ਜੋ ਉਸਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਆਧੁਨਿਕ ਨੌਲੇਜ਼ ਕੰਮ ਨਾਲ ਬਹੁਤ ਸਾਫ਼ੇ ਨਾਲ ਜੋੜਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਦਾ NLS (oN-Line System) 1960ਆਂ ਦੇ ਰੂਹ ਵਿੱਚ “ਕੰਪਿਊਟਰ ਪ੍ਰੋਗਰਾਮ” ਨਹੀਂ ਸੀ। ਇਹ ਜ਼ਿਆਦਾ ਕਰਕੇ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਨੌਲੇਜ਼ ਵਰਕਸਪੇਸ ਸੀ: ਓਥੇ ਜਿੱਥੇ ਤੁਸੀਂ ਬਣਾਉਂਦੇ, ਨੈਵੀਗੇਟ ਕਰਦੇ, ਸੋਧਦੇ ਅਤੇ ਜਾਣਕਾਰੀ ਨੂੰ ਜੋੜਦੇ ਹੋ, ਹੁਣੇ-ਹੁਣੇ ਆਪਣੇ ਕੰਮ ਦੇ ਫਲੋਰ ਵਿੱਚ ਰਹਿ ਕੇ।
ਰਿਵੋਇਲੇਂਟ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਇੱਕ ਦੂਰ-ਕਲਕੂਲੇਟਰ ਵਜੋਂ ਦੇਖਣ ਦੀ ਥਾਂ, NLS ਨੇ ਯੂਜ਼ਰ ਨੂੰ ਐਸਾ ਸਾਥੀ ਸਮਝਿਆ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਹਰ ਪਲ ‘ਸਟੀਅਰ’ ਕਰ ਸਕਦੇ ਹੋ।
NLS ਉਹ ਯੋਗਤਾਵਾਂ ਇਕੱਠਾ ਕਰਦਾ ਸੀ ਜਿਹੜੀਆਂ ਅੱਜਕੱਲ੍ਹ ਅਲੱਗ-ਅਲੱਗ ਡੌਕਸ, ਵਿਕੀ ਅਤੇ ਕੋਲੈਬਰੇਸ਼ਨ ਐਪਾਂ ਵਿਚ ਮਿਲਦੀਆਂ ਹਨ:
NLS ਰਿਸਰਚ, ਯੋਜਨਾ ਅਤੇ ਸਹਿਯੋਗ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ: ਸੁਝਾਵਾਂ ਦਾ ਮਸੋਦਾ, ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਸੰਚਨਾ, ਨੋਲੇਜ਼ ਬੇਸ ਦਾ ਰੱਖ-ਰਖਾਵ ਅਤੇ ਫੈਸਲਿਆਂ ਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ।
ਮਕਸਦ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਦਿਖਾਉਣਾ ਨਹੀਂ ਸੀ, ਮਕਸਦ ਟੀਮਾਂ ਨੂੰ ਹੋਰ ਯੋਗ ਬਣਾਉਣਾ ਸੀ।
ਉਸ ਸਮੇਂ ਬਹੁਤ ਸੰਗਠਨਾਂ ਅਜੇ ਵੀ ਬੈਚ ਕੰਪਿਊਟਿੰਗ (ਜੌਬ ਭੇਜੋ, ਨਤੀਜਿਆਂ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰੋ) ਅਤੇ ਕਾਗਜ਼ੀ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਮੇਮੋ, ਬਾਈਂਡਰ, ਹੱਥ-ਵੱਲ ਵਰਜ਼ਨ ਕੰਟਰੋਲ) 'ਤੇ ਨਿਰਭਰ ਕਰ ਰਹੀਆਂ ਸਨ। NLS ਨੇ ਇੰਤਜ਼ਾਰ ਅਤੇ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਜਗ੍ਹਾ ਇੰਟਰਐਕਟਿਵ ਐਡੀਟਿੰਗ, ਨੈਵੀਗੇਬਲ ਸੰਰਚਨਾ ਅਤੇ ਜੁੜੀ ਜਾਣਕਾਰੀ ਲਿਆਂਦੀ—ਉਹੀ ਬਲੂਪ੍ਰਿੰਟ ਜੋ ਅਸੀਂ ਅੱਜ ਦੇ ਪ੍ਰੋਡਕਟੀਵਟੀ ਪਲੇਟਫਾਰਮਾਂ ਵਿਚ ਲੈਂਦੇ ਹਾਂ।
ਐਂਗਲਬਾਰਟ ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ ਕੰਪਿਊਟਿੰਗ ਇੰਟਰੈਕਸ਼ਨ ਟਾਈਪ ਕੀਤਾ ਹੁੰਦਾ ਸੀ: ਤੁਸੀਂ ਕਮਾਂਡ ਲਿਖਦੇ, ਕਰ ਦਿੰਦਿਆਂ ਅਤੇ ਮਸ਼ੀਨ ਦੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਦੇ। ਇਹ ਕੈਲਕੂਲੇਟਰਾਂ ਅਤੇ ਬੈਚ ਜੌਬਸ ਲਈ ਠੀਕ ਹੈ, ਪਰ ਜਦੋਂ ਜਾਣਕਾਰੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਵਸਤੂਆਂ ਵਾਂਗ ਹੋਵੇ—ਸ਼ਬਦ, ਸਿਰਲੇਖ, ਲਿੰਕ, ਫਾਈਲਾਂ—ਤਾਂ ਇਹ ਤਰੀਕਾ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਉਦੇਸ਼ ਨੌਲੇਜ਼ ਕੰਮ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ "ਉਸ ਚੀਜ਼ ਨੂੰ ਛੂਹਣ" ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ।
ਐਂਗਲਬਾਰਟ ਦੀ ਟੀਮ NLS ਨੂੰ ਇੱਕ ਐਸੇ ਮਾਹੌਲ ਲਈ ਬਣਾ ਰਹੀ ਸੀ ਜਿੱਥੇ ਲੋਕ ਜਟਿਲ ਦਸਤਾਵੇਜ਼ ਨੈਵੀਗੇਟ ਅਤੇ ਸੋਧ ਸਕਣ, ਸੰਬੰਧਤ ਵਿਚਾਰਾਂ ਦੇ ਵਿੱਚ ਚਲ-ਫਿਰ ਸਕਣ ਅਤੇ ਕਈ ਵੇਖਾਵਾਂ ਨੂੰ ਸੰਭਾਲ ਸਕਣ।
ਇਸ ਕਿਸਮ ਦੇ ਇੰਟਰਫੇਸ 'ਚ, "ਲਾਈਨ 237 'ਤੇ ਜਾਓ" ਕਹਿਣਾ ਕਾਫ਼ੀ ਹੌਲਾ ਅਤੇ ਗਲਤ-ਭਰ ਹੋ ਸਕਦਾ ਹੈ—ਉਸਨੂੰ ਸਿੱਧਾ ਪੌਇੰਟ ਕਰਨਾ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਅਤੇ ਵੱਧ ਸਹਾਇਕ ਹੈ।
ਪੌਇੰਟਿੰਗ ਡਿਵਾਈਸ ਇਰਾਦੇ ਨੂੰ ਘੱਟ ਤਰਜਮੇ ਨਾਲ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ: ਪੌਇੰਟ ਕਰੋ, ਚੁਣੋ, ਕਾਰਵਾਈ ਕਰੋ। ਇਸ ਮਾਨਸਿਕ ਖ਼ਰਚ ਨੂੰ ਘਟਾਉਣਾ ਹੀ ਉਸਦਾ ਹਿੱਸਾ ਹੈ ਜਿਹੜਾ ਸਕ੍ਰੀਨ-ਅਧਾਰਿਤ ਕੰਮ ਨੂੰ ਸਿੱਧੀ ਮੈਨਿਪੁਲੇਸ਼ਨ ਵਾਂਗ ਲਗਦਾ ਬਣਾਉਂਦਾ ਹੈ।
ਪਹਿਲਾ ਮਾਊਸ ਇੱਕ ਛੋਟਾ ਲੱਕੜੀ ਦਾ ਡਿਵਾਈਸ ਸੀ ਜਿਸ ਵਿੱਚ ਪਹੀਆ ਹੁੰਦੇ ਸਨ ਜੋ ਸਤਹ 'ਤੇ ਹਿਲਣ ਨਾਲ ਕਿਰਿਆਸ਼ੀਲ ਹੋ ਕੇ ਕਰਸਰ ਨੂੰ ਹਿਲਾਉਂਦੇ।
ਨਵਾਂਪਨ ਸਿਰਫ਼ ਹਾਰਡਵੇਅਰ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਸਥਿਰ ਸਕ੍ਰੀਨ ਪੌਇੰਟਰ ਨਾਲ ਤੇਜ਼ ਚੋਣ ਨੂੰ ਜੋੜਨ ਦਾ ਸੀ। ਇਸ ਨਾਲ ਯੂਜ਼ਰ ਟੈਕਸਟ ਬਲਾਕ ਚੁਣ ਸਕਦੇ, ਕਮਾਂਡ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਅਤੇ ਇੱਕ ਸੰਰਚਿਤ ਦਸਤਾਵੇਜ਼ 'ਚ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਕਮਾਂਡ ਭਾਸ਼ਾ ਵਿੱਚ ਆਉਣ ਦੇ ਕੰਮ ਕਰ ਸਕਦੇ।
ਲਗਭਗ ਹਰ ਪ੍ਰਚਲਿਤ ਨਮੂਨਾ ਇਹੀ ਆਧਾਰ ਲੈਂਦਾ ਹੈ: ਲਕੜੀ/ਪੌਇੰਟ ਕਰੋ, ਕਲਿੱਕ ਕਰੋ, ਡਰੈਗ ਕਰੋ, ਵਿੰਡੋਜ਼ ਦਾ ਆਕਾਰ ਬਦਲੋ ਅਤੇ ਬਹੁ-ਪੈਨ ਦ੍ਰਿਸ਼ਾਂ ਵਿਚ ਕੰਮ ਕਰੋ।
ਅੱਥੇ ਤੱਕ ਕਿ ਟੱਚ ਸਕ੍ਰੀਨ ਵੀ ਇੱਕੋ ਤਰ੍ਹਾਂ ਦਾ ਪ੍ਰਿੰਸੀਪਲ ਦੁਹਰਾਉਂਦੀ ਹੈ: ਡਿਜੀਟਲ ਵਸਤੂਆਂ ਨੂੰ ਹਿਲਾਓ—ਉਹਨਾਂ ਨੂੰ ਛੂਹਣਯੋਗ ਬਣਾਓ।
ਐਂਗਲਬਾਰਟ ਦੀ ਟੀਮ ਨੇ ਚੋਰਡਿੰਗ ਕੀਬੋਰਡ ਵਗੈਰਾ ਨੂੰ ਵੀ ਖੋਜਿਆ—ਜਿਥੇ ਇੱਕ ਹੱਥ ਨਾਲ ਕੁੰਜੀਆਂ ਦੇ ਕੰਬੀਨੇਸ਼ਨ ਦਬਾ ਕੇ ਤੇਜ਼ ਕਮਾਂਡ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਸੀ, ਜਦਕਿ ਦੂਜਾ ਹੱਥ ਪੌਇੰਟ ਕਰਦਾ।
ਇਹ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਮਾਊਸ ਟਾਈਪਿੰਗ ਦੀ ਥਾਂ ਨਹੀਂ ਸੀ, ਪਰ ਉਸਦਾ ਪੂਰਕ ਸੀ: ਇੱਕ ਹੱਥ ਨੈਵੀਗੇਸ਼ਨ ਲਈ ਤੇ ਦੂਜਾ ਤੇਜ਼ ਇਨਪੁੱਟ ਅਤੇ ਨਿਯੰਤਰਣ ਲਈ।
ਹਾਈਪਰਟੈਕਸਟ ਇੱਕ ਸਧਾਰਣ ਵਿਚਾਰ ਹੈ ਜਿਸਦਾ ਪ੍ਰਭਾਵ ਵੱਡਾ ਹੈ: ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਕ੍ਰਮ ਵਿੱਚ ਨਹੀਂ ਪੜ੍ਹਣਾ ਪੈਂਦਾ। ਤੁਸੀਂ ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸਿਆਂ—ਨੋਟ, ਪੈਰਾਗ੍ਰਾਫ, ਦਸਤਾਵੇਜ਼, ਵਿਅਕਤੀ, ਸ਼ਬਦ—ਨੂੰ ਜੋੜ ਸਕਦੇ ਹੋ ਅਤੇ ਜਰੂਰਤ ਮੁਤਾਬਕ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਜਾ ਸਕਦੇ ਹੋ।
ਰਵਾਇਤੀ ਦਸਤਾਵੇਜ਼ ਇੱਕ ਸੜਕ ਵਾਂਗ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਉੱਪਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਵਧਦੇ ਹੋ। ਹਾਈਪਰਟੈਕਸਟ ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਨਕਸ਼ੇ ਵਿਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਜੋ ਇਸ ਵੇਲੇ ਲੋੜੀਂਦਾ ਹੈ ਉਸ ਨੂੰ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਨਹੀਂ ਚਾਹੀਦਾ ਉਸ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ, ਅਤੇ ਮੁੱਖ ਧਾਰਾ 'ਤੇ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ।
ਇਹ ਬਦਲਾਅ ਜਾਣਕਾਰੀ ਆਯੋਜਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਕ "ਸਰਵੋਤਮ" ਆਊਟਲਾਈਨ ਫੋਰਸ ਨਾ ਕਰਕੇ, ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਨੂੰ ਉੱਥੇ ਰੱਖ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਉਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰਿਸ਼ਤੇ ਦਰਸਾਉਣ ਵਾਲੇ ਲਿੰਕ ਜੋੜ ਸਕਦੇ ਹੋ:
ਸਮੇਂ ਨਾਲ, ਇਹ ਕਨੈਕਸ਼ਨ ਇੱਕ ਦੂਜੇ ਪਰਤ ਦਾ ਸੰਰਚਨਾਤਮਕ ਢਾਂਚਾ ਬਣ ਜਾਂਦੇ ਹਨ—ਇਕ ਜੋ ਦਰਸਾਂਦਾ ਹੈ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕਿਸ ਤਰ੍ਹਾਂ ਸੋਚਦੇ ਅਤੇ ਕੰਮ ਕਰਦੇ ਹਨ।
ਤੁਸੀਂ ਹਰੇਕ ਵਾਰੀ ਜਦੋਂ ਵੈੱਬ 'ਤੇ ਹਾਇਪਰਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ ਤਾਂ ਹਾਈਪਰਟੈਕਸਟ ਵੇਖਦੇ ਹੋ, ਪਰ ਇਹ ਅੰਦਰੂਨੀ ਨੌਲੇਜ਼ ਟੂਲਾਂ ਵਿੱਚ ਵੀ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਲਿੰਕ ਸਿਰਫ਼ ਸੁਵਿਧਾ ਲਈ ਨਹੀਂ ਹਨ; ਉਹ ਗਲਤਫ਼ਹਮੀਆਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਇਕ ਪ੍ਰੋਜੈਕਟ ਬ੍ਰੀਫ ਫੈਸਲਾ ਲੌਗ, ਗਾਹਕ ਫੀਡਬੈਕ ਅਤੇ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨਾਲ ਲਿੰਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੀਮ ਇਕੋ ਸੰਦਰਭ ਸਾਂਝਾ ਕਰਦੀ ਹੈ—ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਵੀ ਬੜੀ ਤੇਜ਼ੀ ਨਾਲ ਕੈਚਅਪ ਹੋ ਸਕਦੇ ਹਨ।
ਅਮਲ ਵਿੱਚ, ਚੰਗੀ ਲਿੰਕਿੰਗ ਇਕ ਹਮਦਰਦੀ ਦੀ ਰੂਪ ਹੈ: ਇਹ ਅਗਲੇ ਸਵਾਲ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੀ ਹੈ ਅਤੇ ਉੱਤਰ ਤੱਕ ਇੱਕ ਸਪੱਸ਼ਟ ਰਾਹ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
ਐਂਗਲਬਾਰਟ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਨੂੰ "ਪੰਨਾ" ਵਜੋਂ ਨਹੀਂ ਦੇਖਦਾ ਸੀ ਬਲਕਿ ਇੱਕ ਸੰਰਚਿਤ ਸਿਸਟਮ ਵਜੋਂ। NLS ਵਿੱਚ, ਜਾਣਕਾਰੀ ਆਊਟਲਾਈਨ—ਨੇਸਟ ਕੀਤੀਆਂ ਹੈਡਿੰਗਾਂ ਅਤੇ ਉਪ-ਪੌਇੰਟਾਂ—ਵਜੋਂ ਠੀਕ ਕੀਤੀ ਜਾਂਦੀ ਸੀ, ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਧਾ ਜਾਂ ਘਟਾ ਸਕਦੇ, ਬਦਲ ਸਕਦੇ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ।
ਕੰਮ ਦਾ ਯੂਨਿਟ ਇੱਕ ਪੈਰਾ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਬਲਾਕ ਸੀ ਜਿਸਦੀ ਹieraਰਕੀ ਵਿਚ ਥਾਂ ਸੀ।
ਸੰਰਚਿਤ ਲਿਖਾਈ ਦਾ ਮਤਲਬ ਉਹ ਲਿਖਾਈ ਹੈ ਜਿਸਦੇ ਰੂਪ ਨਿਰਧਾਰਿਤ ਹਨ: ਹੈਡਿੰਗਜ਼, ਨੰਬਰਡ ਲੈਵਲਾਂ, ਅਤੇ ਰੀਯੂਜ਼ੇਬਲ ਬਲਾਕ (ਸੈਕਸ਼ਨ, ਬੁਲੇਟ, ਜਾ snippet) ਜੋ ਤੋੜ-ਮਰੋੜ ਬਿਨਾਂ ਟੁੱਟ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਸਮੱਗਰੀ ਮੋਡਿਊਲਰ ਹੁੰਦੀ ਹੈ, ਸੋਧ ਤੇਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ:
ਆਧੁਨਿਕ ਦਸਤਾਵੇਜ਼ ਏਡੀਟਰ ਅਤੇ ਨੋਲੇਜ਼ਬੇਸ ਇਹ ਵਿਚਾਰ ਚੁਪਚਾਪ ਦਰਸਾਉਂਦੇ ਹਨ। ਆਊਟਲਾਈਨਿੰਗ ਟੂਲ, ਹੈਡਿੰਗ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਬਲਾਕ-ਅਧਾਰਿਤ ਟੂਲ ਇਹਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਟਾਸਕ ਲਿਸਟ ਵੀ ਇਕੋ ਹੀ ਪੈਟਰਨ ਦਾ ਦੋਹਰਾਉਂ ਹਨ: ਹਰ ਟਾਸਕ ਇਕ ਬਲਾਕ ਹੈ ਜਿਸਨੂੰ ਪ੍ਰੋਜੈਕਟ ਹੇਠਾਂ ਨੇਸਟ ਕੀਤਾ, ਅਸਾਈਨ ਕੀਤਾ ਅਤੇ ਲਿੰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਕਾਰਗਿਰੀ ਨਤੀਜਾ ਸਿਰਫ ਸੁੰਦਰਤਾ ਨਹੀਂ—ਸੰਰਚਨਾ ਸਪੱਸ਼ਟਤਾ ਵਧਾਉਂਦੀ ਹੈ (ਲੋਕ ਸਕੈਨ ਕਰ ਸਕਦੇ), ਸੋਧ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ (ਤੁਸੀਂ ਹਿੱਸਿਆਂ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹੋ, ਸਾਰੇ ਨੂੰ ਨਹੀਂ), ਅਤੇ ਸਹਿਯੋਗ ਅਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ (ਟੀਮ ਮੈਂਬਰ ਖਾਸ ਸੈਕਸ਼ਨ 'ਤੇ ਟਿੱਪਣੀ ਜਾਂ ਮਾਲਕੀ ਰੱਖ ਸਕਦੇ)।
“Project Alpha” ਡੌਕ ਇਸ ਸਭ ਰਹੀ:
ਜਿਵੇਂ-jive ਤੁਹਾਨੂੰ ਹੋਰ ਪਤਾ ਚਲਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਮੁੜ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਕਰੋਗੇ। ਇੱਕ ਰਿਸਕ ਨੂੰ "ਨੋਟਸ" ਤੋਂ "ਸਕੋਪ" ਵਿੱਚ ਹਿਲਾਓ, ਟਾਸਕਾਂ ਨੂੰ ਮਾਈਲਸਟੋਨ ਹੇਠਾਂ ਨੈਸਟ ਕਰੋ, ਅਤੇ ਹਰ ਮਾਈਲਸਟੋਨ ਤੋਂ ਇੱਕ ਸਮਰਪਿਤ ਪੇਜ (ਮੀਟਿੰਗ ਨੋਟ, ਸਪੈਕ, ਜਾਂ ਚੈੱਕਲਿਸਟ) ਨੂੰ ਲਿੰਕ ਕਰੋ।
ਨਤੀਜਾ ਇੱਕ ਜ਼ਿੰਦਾ ਨਕਸ਼ਾ ਬਣਦਾ ਹੈ: ਇਕ ਜਗ੍ਹਾ ਜਿੱਥੇ ਸੰਦਰਭ ਨੈਵੀਗੇਬਲ ਹੈ, ਨਾ ਕਿ ਲੰਮੇ ਈ-ਮੇਲ ਜਾਂ ਚੇਟਰ ਦੀ ਲੜੀ।
ਐਂਗਲਬਾਰਟ "ਕੋਲੈਬੋਰੇਟ" ਨੂੰ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪਿੱਛੇ-ਅੱਗੇ ਭੇਜਣ ਵਜੋਂ ਨਹੀਂ ਦੇਖਦਾ ਸੀ। ਉਸਦਾ ਟੀਚਾ ਸਾਂਝੇ ਵਰਕਸਪੇਸਾਂ ਨੂੰ ਹੋਣਾ ਸੀ ਜਿੱਥੇ ਗਰੁੱਪ ਉਹੀ ਸਮੱਗਰੀ ਉਹੀ ਸਮੇਂ ਵੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਫੈਸਲੇ ਤੇਜ਼ੀ ਨਾਲ ਕਰ ਸਕਦਾ ਹੈ।
ਕੰਮ ਦਾ ਯੂਨਿਟ ਕਿਸੇ ਇਕ ਵਿਅਕਤੀ ਦੇ ਕੰਪਿਊਟਰ 'ਤੇ ਬੈਠੀ ਫਾਇਲ ਨਹੀਂ ਸੀ—ਇਹ ਉਹ ਇੱਕ ਜ਼ਿੰਦਾ, ਨੈਵੀਗੇਬਲ ਜਾਣਕਾਰੀ ਦਾ ਸੈੱਟ ਸੀ ਜਿਸਨੂੰ ਟੀਮ ਲਗਾਤਾਰ ਸੁਧਾਰ ਸਕਦੀ ਸੀ।
ਜਦੋਂ ਕੰਮ ਨਿੱਜੀ ਡ੍ਰਾਫਟਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਤਦ ਕੋਆਰਡੀਨੇਸ਼ਨ ਇੱਕ ਵੱਖਰਾ ਕੰਮ ਬਣ ਜਾਂਦੀ ਹੈ: ਵਰਜ਼ਨ ਇਕੱਠੇ ਕਰਨਾ, ਬਦਲਾਵਾਂ ਨੂੰ ਸਮਰਥ ਕਰਨਾ, ਅਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਕਿ ਕਿਹੜੀ ਕਾਪੀ ਮੌਜੂਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਦੀ ਦ੍ਰਿਸ਼ਟੀ ਇਸ ਓਵਰਹੈਡ ਨੂੰ ਘਟਾਉਂਦੀ ਸੀ—ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਿਸਟਮ ਵਿੱਚ ਰੱਖ ਕੇ ਜਿੱਥੇ ਅਪਡੇਟ ਤੁਰੰਤ ਦਿਖਦੇ ਹਨ ਅਤੇ ਲਿੰਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਇਹ “ਸਾਂਝਾ ਸੰਦਰਭ” ਉਤਰ-ਜਿਹੜਾ ਟੈਕਸਟ ਦੇ ਇਲਾਵਾ ਅੱਤ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਉਹ ਆਸਪਾਸੀ ਢਾਂਚਾ ਹੈ—ਕਿਹੜਾ ਸੈਕਸ਼ਨ ਕਿਹੜੇ ਨਾਲ ਜੁੜਿਆ ਹੈ, ਕਿਸ ਕਾਰਨ ਬਦਲਾਅ ਕੀਤਾ ਗਿਆ, ਕਿਹੜੇ ਫੈਸਲੇ ਦਾ ਸਮਰਥਨ—ਜੋ ਟੀਮ ਨੂੰ ਇੱਕੋ ਹੀ ਸੋਚ ਦੁਹਰਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
1968 ਦੀ ਮਸ਼ਹੂਰ ਡੈਮੋ ਵਿੱਚ, ਐਂਗਲਬਾਰਟ ਨੇ ਉਹ ਖ਼ੂਬੀਆਂ ਦਿਖਾਈਆਂ ਜੋ ਹੁਣ ਆਮ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਉਸ ਵੇਲੇ ਕਾਫੀ ਵਿਲੱਖਣ ਸਨ: ਰਿਮੋਟ ਇੰਟਰਐਕਸ਼ਨ, ਸਾਂਝੀ ਐਡੀਟਿੰਗ, ਅਤੇ ਤਰੀਕੇ ਜੋ ਲੋਕਾਂ ਨੂੰ ਇੱਕੋ ਜਾਣਕਾਰੀ ਵੇਖਣ ਦੇ ਨਾਲਨਾਲ ਕੋਆਰਡੀਨੇਟ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ।
ਮਕਸਦ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਦੋ ਲੋਕ ਇੱਕੋ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਟਾਈਪ ਕਰ ਸਕਦੇ—ਇਹ ਸੀ ਕਿ ਉੱਕਾ ਸਿਸਟਮ ਉਹ ਵਰਕਫਲੋ ਸਹਿਯੋਗ ਤੇਜ਼ੀ ਨਾਲ ਸਹਾਰ ਸਕਦਾ ਹੈ—ਸਮੀਖਿਆ, ਚਰਚਾ, ਅਪਡੇਟ ਅਤੇ ਅੱਗੇ ਵਧਣਾ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ।
ਅੱਜ ਦੇ ਸਹਿਯੋਗੀ ਸੌਫਟਵੇਅਰ ਅਕਸਰ ਇਹਨਾਂ ਵਿਚਾਰਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਇਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨਿੱਜੀ ਸੁਭਾਵ ਦੀਆਂ ਸ਼ੈਲੀਆਂ ਨਹੀਂ; ਜਦੋਂ ਕਈ ਲੋਕ ਇੱਕੋ ਕੰਮ 'ਤੇ ਹੋਣ, ਇਹ ਸਾਂਝਾ ਸੰਦਰਭ ਬਣਾਏ ਰੱਖਣ ਲਈ ਮਕੈਨੀਜ਼ਮ ਹਨ।
ਚੰਗਾ ਪਲੇਟਫਾਰਮ ਵੀ ਅਚਛੇ ਸਹਿਯੋਗ ਨੂੰ ਬਜਾਏ ਨਹੀਂ ਲਿਆ ਸਕਦਾ। ਟੀਮਾਂ ਨੂੰ ਅਜੇ ਵੀ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਹੈ: ਕਦੋਂ ਟਿੱਪਣੀ ਕਰਨੀ ਹੈ ਵర్సੁਦਾ ਸਿੱਧਾ ਸੋਧ ਕਰਨੀ ਹੈ, ਫੈਸਲੇ ਕਿਵੇਂ ਦਰਜ ਹੋਣਗੇ, "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਅੰਤਿਮ ਫ਼ੈਸਲਾ ਕਿਸਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਦੀ ਗਹਿਰੀ ਸੋਚ ਇਹ ਸੀ ਕਿ ਨੌਲੇਜ਼ ਕੰਮ ਵਿੱਚ ਸੁਧਾਰ ਲਈ ਟੂਲਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਆਦੀਕਾਰ ਦੋਹਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ—ਤਾਂ ਜੋ ਕੋਆਰਡੀਨੇਸ਼ਨ ਇੱਕ ਸਮਰਥ ਆਦਤ ਬਣ ਜਾਵੇ ਨਾ ਕਿ ਲਗਾਤਾਰ ਲੜੀ।
ਰੀਅਲ-ਟਾਈਮ ਕੋ-ਐਡੀਟਿੰਗ ਮਤਲਬ ਹੈ ਕਿ ਕਈ ਲੋਕ ਇੱਕੋ ਦਸਤਾਵੇਜ਼ 'ਤੇ ਇਕੋ ਸਮੇਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ—ਅਤੇ ਸਭ ਨੂੰ ਤੁਰੰਤ ਬਦਲਾਵ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
NLS ਨੇ ਇਸਨੂੰ ਇੱਕ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ ਲਿਆ, ਨ ਕਿ ਸਿਰਫ਼ ਇਕ ਨਵੀਂ ਚੀਜ਼ ਵਜੋਂ: ਮੁੱਲ ਸਿਰਫ਼ ਟਾਈਪ ਕਰਨ ਦੀ ਰਫ਼ਤਾਰ ਨਹੀਂ, ਮੁੱਲ ਫੈਸਲਾ ਕਰਨ ਦੀ ਰਫ਼ਤਾਰ ਹੈ।
ਜਦੋਂ ਸੋਧ ਲਾਈਵ ਹੁੰਦੀਆਂ ਹਨ, ਟੀਮ ਇਕ ਇਕ ਸਾਂਝਾ, ਮੌਜੂਦਾ "ਸਰੋਤ ਦਾ ਸੱਚ" ਸਾਂਝਾ ਕਰਦੀ ਹੈ। ਅਟੈਚਮੇੰਟਾਂ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਘਟਦੀ, ਚੈਟ ਵਿਚ ਅਪਡੇਟ ਕਾਪੀ-ਪੇਸਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ, ਅਤੇ ਗੁਣਾ ਤੁਰੰਤ ਮਿਲ ਕੇ ਇਹ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ, ਇਸਦਾ ਕੀ ਨਤੀਜਾ ਹੈ ਅਤੇ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ।
ਲਾਈਵ ਸਹਿਯੋਗ ਸਭ ਤੋਂ ਚੰਗਾ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੂਸਰੇ ਲੋਕਾਂ ਦੀ ਨੀਅਤ ਵੇਖ ਸਕਦੇ ਹੋ।
ਹਿਲਦਾ ਕਰਸਰ, ਚੁਣੀ ਹੋਈ ਹਾਈਲਾਈਟ ਜਾਂ ਛੋਟਾ ਕਿਰਿਆ-ਖ਼ਾਤਾ ਇਹ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਇਹ ਹਿੱਸਾ ਕਿਸ ਦਾ ਹੈ? ਕੀ ਉਹ ਇਸਨੂੰ ਪੁਨਰਲਿਖ ਰਹੇ ਹਨ, ਸੰਦਰਭ ਜੋੜ ਰਹੇ ਹਨ ਜਾਂ ਸਿਰਫ਼ ਸਕੈਨ ਕਰ ਰਹੇ ਹਨ?
ਇਹ ਵਿਜ਼ੀਬਿਲਟੀ ਦੁਹਰਾਈ ਕੰਮ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ("ਮੈਂ ਨਹੀਂ ਜਾਣਦਾ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਪੈਰਾ ਨੂੰ ਠੀਕ ਕਰ ਰਹੇ ਸੀ") ਅਤੇ ਹੈਂਡਓਵਰਾਂ ਨੂੰ ਸੁਗਮ ਬਣਾਉਂਦੀ ਹੈ ("ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਖਤਮ ਕਰੋ ਉਹਦਾ ਮੈਨੂੰ ਅੱਗੇ ਦਾ ਹਿੱਸਾ ਲੈ ਲਵਾਂਗਾ").
ਦੋ ਲੋਕਾਂ ਵੱਲੋਂ ਇੱਕੋ ਹਿੱਸੇ ਦੀ ਸੋਧ ਕਰਨ ਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਆਧੁਨਿਕ ਟੂਲ ਇਹਨਾਂ ਵਿਚਾਰਾਂ ਨਾਲ ਮਸਲੇ ਹੱਲ ਕਰਦੇ ਹਨ:
ਜਦੋਂ ਸੌਫਟਵੇਅਰ "ਆਟੋ-ਮਰਜ" ਕਰ ਰਿਹਾ ਹੋਵੇ, ਤਾਂ ਵੀ ਟੀਮ ਨੂੰ ਨੀਅਤ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਹੋਰ ਨਾ ਕੇਵਲ ਇਹ ਕਿ ਬਦਲਾਅ ਹੋਇਆ, ਬਲਕਿ ਕਿਉਂ ਹੋਇਆ।
ਰੀਅਲ-ਟਾਈਮ ਕੋ-ਐਡੀਟਿੰਗ ਸਹਿਯੋਗ ਨੂੰ ਇੱਕ ਰੇਲੇ ਤੋਂ ਸਾਂਝੇ ਵਰਕਸਪੇਸ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ—ਅਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਉਸ ਮੁੱਖ ਹੁਨਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਟੂਲ ਸਹਾਰਦਾ ਹੈ।
9 ਦਸੰਬਰ, 1968 ਨੂੰ ਡਗਲਸ ਐਂਗਲਬਾਰਟ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਟੀਮ ਨੇ ਸੈਨ ਫ਼ਰਾਂਸਿਸਕੋ ਵਿੱਚ ਸਟੇਜ਼ ਲਿਆ ਅਤੇ ਆਪਣੀ NLS (oN-Line System) ਦਾ ਲਾਈਵ, 90-ਮਿੰਟ ਦਾ ਡੈਮੋ ਕੀਤਾ।
ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ "Mother of All Demos" ਕਿਹਾ ਗਿਆ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਇੱਕ ਸੰਗਠਿਤ ਦ੍ਰਿਸ਼ਟੀ ਦਿਖਾਈ ਗਈ ਸੀ—ਇੰਟਰਐਕਟਿਵ, ਜੁੜੇ ਹੋਏ ਨੌਲੇਜ਼-ਕੰਮ ਦਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ—ਜੋ ਜੀਵੰਤ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਗਿਆ।
ਐਂਗਲਬਾਰਟ ਨੇ ਸਿਰਫ਼ ਤੇਜ਼ ਟਾਈਪ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਦਿਖਾਇਆ। ਉਸਨੂੰ ਇੱਕ ਪੂਰੇ ਵਰਕਇੰਵਾਇਰਨਮੈਂਟ ਨੂੰ ਦਿਖਾਇਆ:
ਗਹਿਰਾ ਨੁਕਤਾ ਕਿਸੇ ਇਕ ਗੈਜਿਟ ਦਾ ਨਹੀਂ ਸੀ। ਡੈਮੋ ਦਾ ਤਰਕ ਸੀ ਕਿ ਕੰਪਿਊਟਰ "ਨੌਲੇਜ਼-ਕੰਮ" ਲਈ ਸਾਥੀ ਹੋ ਸਕਦੇ ਹਨ: ਲੋਕਾਂ ਨੂੰ ਬਣਾਉਣ, ਐਕਠੇ ਕਰਨ ਅਤੇ ਜਾਣਕਾਰੀ ਨੂੰ ਕਾਗਜ਼ੀ ਤਰੀਕੇ ਤੋਂ ਤੇਜ਼ ਤਰੀਕੇ ਨਾਲ ਮੁੜ ਵੇਖਣ ਵਿੱਚ ਮਦਦ ਕਰਨ।
ਇਹ ਵੀ ਦਰਸਾਇਆ ਗਿਆ ਕਿ ਇਹ ਕੰਮ ਨੈਟਵਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸਾਂਝਾ ਸੰਦਰਭ ਹੋ ਸਕਦਾ ਹੈ—ਇੱਕੋ ਫਾਈਲਾਂ ਦੀ ਬਜਾਏ ਸਾਂਝਾ ਮੈਮੋਰੀ।
ਕੁਝ ਲੋਕਾਂ ਲਈ 1968 ਉਨ੍ਹਾਂ ਦੀਆਂ ਦ੍ਰਿਸ਼ਟੀਆਂ ਦੇ ਆਰੰਭਕ ਨਿਸ਼ਾਨ ਵਾਂਗ ਸੀ, ਪਰ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਸਾਰੇ ਤੁਰੰਤ ਆਧੁਨਿਕ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਆ ਗਏ।
NLS ਸਿੱਧਾ ਹਰ ਦਫ਼ਤਰ ਵਿੱਚ ਨਾਂਹ ਬਣਿਆ—ਕੁਝ ਹਿੱਸੇ ਮਹਿੰਗੇ ਜਾਂ ਜਟਿਲ ਸਨ। ਪਰ ਡੈਮੋ ਨੇ ਇਹ ਦਰਸਾਇਆ ਕਿ ਇਹ ਵਿਚਾਰ ਸੰਭਵ ਹਨ। ਬਾਅਦ ਦੇ ਸਿਸਟਮਾਂ—ਅਨੁਸੰਧਾਨ ਲੈਬਰਟਰੀਆਂ ਤੋਂ ਕਮੇਰਸ਼ੀਅਲ ਸਾਫਟਵੇਅਰ ਤੱਕ—ਉਸ ਦ੍ਰਿਸ਼ਟੀ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਲੈ ਕੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਅਪਨਾਉਂਦੇ ਰਹੇ।
ਐਂਗਲਬਾਰਟ ਨੇ ਕੇਵਲ ਮਾਊਸ ਜਾਂ ਲਿੰਕਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕੀਤੀ—ਉਸਨੇ ਇਸ ਗੱਲ ਦਾ ਰੂਪ ਰੇਖਾ ਦਿੱਤਾ ਕਿ ਨੌਲੇਜ਼-ਕੰਮ ਕਿਵੇਂ ਬਹਿੱਤਰ ਤਰੀਕੇ ਨਾਲ ਵਹੇ। ਆਧੁਨਿਕ ਟੂਲ ਬਾਹਰੋਂ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ "ਸਮਝਦਾਰ" ਪਲ ਬਹੁਤ ਵਾਰ ਉਸ ਦੀਆਂ ਮੂਲ ਧਾਰਨਾਵਾਂ ਦੇ ਪਰਛਾਵੇ ਹੁੰਦੇ ਹਨ।
ਸਭ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ, ਇਹੇ ਬੁਨਿਆਦ ਫਿਰ-ਫਿਰ ਆਉਂਦੀ ਹੈ: ਲਿੰਕਸ (ਵਿਚਾਰ ਜੋੜਨ ਲਈ), ਸੰਰਚਨਾ (ਆਊਟਲਾਈਨ, ਬਲਾਕ), ਸਰਚ (ਪੁਨਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ), ਅਧਿਕਾਰ (ਸਾਂਝੇ ਤਰੀਕੇ ਨਾਲ ਸੇਅਰ ਕਰਨ ਲਈ) ਅਤੇ ਇਤਿਹਾਸ (ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ)।
ਆਮ ਵਿਫਲਤਾ ਸਿਰਫ਼ ਫੀਚਰ ਦੀ ਘਾਟ ਨਹੀਂ—ਇਹ ਹੈ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ।
ਕਾਮ ਵੱਖ-ਹਥਿਆਰਾਂ ਵਿੱਚ ਵੰਡ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸੰਦਰਭ ਲੀਕ ਹੋ ਜਾਂਦਾ ਹੈ: ਚੈਟ ਵਿੱਚ ਫੈਸਲਾ, ਡੌਕ ਵਿਚ ਕਾਰਣ, ਟਾਸਕ ਵਿੱਚ ਕਾਰਵਾਈ, ਫਾਈਲ ਵਿੱਚ ਸਬੂਤ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਲਿੰਕ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਫਿਰ ਵੀ ਤੁਸੀਂ ਵਕਤ ਬਿਤਾਉਂਦੇ ਹੋ ਇਹ ਵਾਪਸ ਜੋੜਨ ਵਿੱਚ ਕਿ "ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ"।
ਚਾਰ ਕਿਰਿਆ-ਸ਼ਬਦ ਸੋਚੋ: capture → connect → coordinate → decide। ਜੇ ਤੁਹਾਡੇ ਟੂਲ ਇਹਨਾਂ ਚਾਰਾਂ ਨੂੰ ਘੱਟ ਕਾਂਟੈਕਸਟ-ਸਵਿੱਚ ਨਾਲ ਸਮਰਥਦੇ ਹਨ—ਅਤੇ ਰਾਹ ਵਿਚ ਲਿੰਕ, ਸੰਰਚਨਾ ਅਤੇ ਇਤਿਹਾਸ ਬਣਾਈ ਰੱਖਦੇ ਹਨ—ਤਾਂ ਤੁਸੀਂ ਐਂਗਲਬਾਰਟ ਦੀ ਅਸਲੀ ਯੋਗਦਾਨ ਦੇ ਨੇੜੇ ਹੋ।
ਇਹ ਨਵੀਨ ਲੇਖ-ਕੋਡਿੰਗ ਟੂਲਾਂ ਲਈ ਵੀ ਵਰਤਯੋਗ ਹੈ: ਜਦੋਂ AI ਤੁਹਾਡੇ ਲਈ ਕੋਡ ਬਣਾਉਂਦਾ ਹੈ, ਫਾਇਦਾ ਸਿਰਫ਼ ਕੋਡ ਤਿਆਰ ਕਰਨ ਦਾ ਨਹੀਂ—ਇਹ ਨੀਅਤ, ਫੈਸਲੇ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਜੁੜੇ ਰੱਖਣ ਵਿੱਚ ਵੀ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ Koder.ai ਇਸ ਧਾਰਨਾ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ — ਚੈਟ ਰਾਹੀਂ ਟੀਮਾਂ ਨੂੰ ਵੈੱਬ, ਬੈਕਅੈਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਲੋੜਾਂ ਤੋਂ ਲੈ ਕੇ ਕਾਰਜ੍ਯਨਵਿਤ ਤੱਕ ਰਾਹ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਕਿਸੇ ਖ਼ਾਸ ਐਪ ਦਾ ਨਹੀਂ ਸੀ—ਇਹ ਕੰਮ ਕਰਨ ਦਾ ਇੱਕ ਢੰਗ ਸੀ: ਜਾਣਕਾਰੀ ਨੂੰ ਸੰਰਚਿਤ ਕਰੋ, ਜੋੜੋ, ਅਤੇ ਸਹਿਯੋਗ ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਓ।
ਤੁਸੀਂ ਇਹ ਬਹੁਤ ਕੁਝ ਆਪਣੇ ਮੌਜੂਦਾ ਸੰਦਾਂ (Docs, Word, Notion, Confluence, Slack, email) ਵਿੱਚ ਹੀ ਅਪਣਾ ਸਕਦੇ ਹੋ।
ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪਰਫੈਕਟ ਕਹਾਣੀ ਵਜੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ—ਉਨ੍ਹਾਂ ਨੂੰ ਆਊਟਲਾਈਨ ਵਜੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਹੈਡਿੰਗ, ਬੁਲੇਟ ਅਤੇ ਛੋਟੇ ਬਲਾਕ ਵਰਤੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਪੂਨ:ਸੰਗਠਿਤ ਹੋ ਸਕਣ।
ਇਸ ਨਾਲ ਮੀਟਿੰਗ ਤੇਜ਼ ਹੋਂਦੀਆਂ ਹਨ (ਸਭ ਇੱਕੋ ਸੈਕਸ਼ਨ ਨੂੰ ਪਤਾ ਕਰ ਸਕਦੇ) ਅਤੇ ਸੋਧ ਘਬਰਾਹਟ ਘੱਟ ਹੁੰਦੀ ਹੈ (ਲੋਕ ਇੱਕ ਹੀ ਬਲਾਕ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਪੇਰੈਸ਼ਾਨ ਕੀਤੇ)।
ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਦਾਅਵਾ ਲਿਖੋ, ਉਸਦੇ ਨਾਲ ਸਰੋਤ ਦਾ ਲਿੰਕ ਜੋੜੋ। ਜਦੋਂ ਕੋਈ ਫੈਸਲਾ ਕਰੋ, ਕਿਉਂ ਦਰਜ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਚਰਚਾ ਜਾਂ ਸਬੂਤ ਨਾਲ ਜੁੜੋ।
ਛੋਟਾ ਫੈਸਲਾ ਲਾਗ ਬੇਹਿਸਾਬ ਮੁੜ-ਚਰਚਾ ਦੀ ਰੋਕਥਾਮ ਕਰਦਾ ਹੈ।
Decision note format: Decision → Reason → Owner → Date → Link to evidence
ਮੀਟਿੰਗ ਦੇ ਬਾਅਦ ਨਤੀਜੇ ਨੂੰ ਸਾਂਝਾ ਪੋਸਟ ਕਰੋ ਜਿਸ ਵਿਚ:
ਹਰ ਦਸਤਾਵੇਜ਼ ‘ਤੇ ਇੱਕ ਮਾਲਕ ਨਿਰਧਾਰਤ ਕਰੋ (DRI ਜਾਂ Editor) ਤਾਂ ਜੋ ਕੋਈ ਜਿੰਮੇਵਾਰ ਹੋਵੇ ਕਿ ਉਹ ਦਸਤਾਵੇਜ਼ ਸੰਗਠਿਤ ਰੱਖੇ।
ਜ਼ਬਰਦਸਤ ਸੋਧ ਕਰਨ ਉੱਤੇ ਇੱਕ ਛੋਟੀ-ਸੰਖੇਪ ਬਦਲਾਅ ਸਾਰ ਦਿਓ (ਕੀ ਬਦਲਿਆ + ਕਿਉਂ + ਹੋਰਾਂ ਤੋਂ ਕੀ ਲੋੜ)। ਇਹ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਦਾ ਮਨੁੱਖੀ ਰੂਪ ਹੈ।
Use consistent naming: TEAM — Project — Doc — YYYY-MM-DD.
Recurring ਕੰਮਾਂ ਲਈ ਟੈਮਪਲੇਟ ਵਰਤੋਂ: ਮੀਟਿੰਗ ਨੋਟ, ਪ੍ਰੋਜੈਕਟ ਬ੍ਰੀਫ, ਰੇਟਰੋ ਨੋਟ, ਫੈਸਲਾ ਲਾਗ।
ਐਂਗਲਬਾਰਟ ਨੇ ਕਿਸੇ ਇਕੱਲੇ ਵਿਅਕਤੀ ਵਾਂਗ ਸਭ ਕੁਝ ਨਹੀਂ ਬਣਾਇਆ—ਕਈ ਪਹਿਲਾਂ ਮੌਜੂਦ ਵਿਚਾਰ ਸਨ।
ਉਦਾਹਰਨ ਲਈ, Vannevar Bush ਨੇ “As We May Think” ਵਿੱਚ ਲਿੰਕ ਕੀਤੇ ਗਿਆਨ ਦਾ ਵਰਣਨ ਕੀਤਾ, ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਪੌਇੰਟਿੰਗ ਡਿਵਾਈਸਾਂ ਬਣਾਈਆਂ। ਜੋ ਐਂਗਲਬਾਰਟ ਨੇ ਅੱਗੇ ਵਧਾਇਆ ਉਹ ਸੀ ਸਿਸਟਮ-ਸਤਰ ਦਾ ਦਿਸ਼ਾ: ਪੌਇੰਟਿੰਗ, ਲਿੰਕ, ਸੰਰਚਿਤ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਟੀਮਵਰਕ ਨੂੰ ਇਕਠੇ ਕਰਕੇ ਇੱਕ ਸਪਸ਼ਟ ਲਕਸ਼ਯ—ਉਹਨਾਂ ਦੀ ਸੋਚ ਇਹ ਸੀ ਕਿ ਇਹ ਸਾਰੇ ਮਿਲ ਕੇ ਸਮੂਹਾਂ ਦੀ ਸੋਚ ਸੁਧਾਰ ਸਕਦੇ ਹਨ।
1960ਆਂ ਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਮਹਿੰਗੀਆਂ ਅਤੇ ਨਾਜ਼ੁਕ ਸਨ। ਇੰਟ2ਰਐਕਟਿਵ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਟਾਈਮ-ਸ਼ੇਅਰਿੰਗ ਮਸ਼ੀਨਾਂ, ਵਿਸ਼ੇਸ਼ ਡਿਸਪਲੇਅ ਅਤੇ ਕਸਟਮ ਇੰਪੁੱਟ ਹਾਰਡਵੇਅਰ ਦੀ ਲੋੜ ਸੀ।
ਨੈੱਟਵਰਕ ਸੀਮਤ ਸਨ, ਸਟੋਰੇਜ ਘੱਟ, ਅਤੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਤਿਆਰ ਕਰਨਾ ਪੈਂਦਾ ਸੀ।
ਇਹ ਵੀ ਸਚ ਹੈ ਕਿ ਬਹੁਤ ਸੰਗਠਨ ਤਿਆਰ ਨਹੀਂ ਸਨ—ਐਂਗਲਬਾਰਟ ਦਾ ਤਰੀਕਾ ਟੀਮਾਂ ਨੂੰ ਆਦਤਾਂ ਬਦਲਣ, ਸਾਂਝੇ ਧਾਰਤਾਂ ਅਪਣਾਉਣ ਅਤੇ ਟ੍ਰੇਨਿੰਗ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਮੰਗ ਕਰਦਾ ਸੀ—ਜਿਹੜੀਆਂ ਕਟੌਤੀ ਸਮੇਂ ਆਸਾਨੀ ਨਾਲ ਘਟਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਬਾਅਦ ਵਿੱਚ персонਲ ਕਮਪਿਊਟਰਾਂ ਦੀ ਉਭਾਰ ਨੇ ਸਧਾਰਨ, ਖੁਦ-ਨਿਰਭর ਐਪਸ ਨੂੰ ਪ੍ਰਫੁੱਲਿਤ ਕੀਤਾ—ਇੱਕੀਕੀਤ, ਗਹਿਰੀ ਸਾਂਝੇ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਥਾਂ।
NLS ਉਹਨਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਸੀ ਜੋ ਇਸ ਦੀ ਸੰਰਚਿਤ ਵਿਧੀ ਅਤੇ ਉन्नਤ ਇੰਪੁੱਟ ਤਕਨੀਕਾਂ ਸਿੱਖਦੇ ਸਨ। ਇਸ ਦਾ ਮਤਲਬ ਸੀ ਕਿ “ਕੰਪਿਊਟਰ ਲਿਟਰੇਸੀ” ਵਿਕਲਪ ਨਹੀਂ ਸੀ।
ਸਹਿਯੋਗ ਦਾ ਹਿੱਸਾ ਮਨੋਵਿਗਿਆਨਕ ਰਾਜੀਨਾਮਾ ਵੀ ਮੰਗਦਾ ਸੀ: ਸਾਂਝੇ ਸਪੇਸ 'ਚ ਕੰਮ ਕਰਨਾ, ਡ੍ਰਾਫਟ ਖੁਲ੍ਹੇ ਰੱਖਣਾ, ਅਤੇ ਖੁੱਲ੍ਹੇ ਤਰੀਕੇ ਨਾਲ ਫੈਸਲੇ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ—ਜੋ ਮੁਕਾਬਲਾਤੀ ਜਾਂ ਸਿਲੋ ਕਲਚਰਾਂ ਵਿੱਚ ਔਖਾ ਹੁੰਦਾ ਹੈ।
For more context on how these ideas echo in modern tools, see /blog/how-his-ideas-show-up-in-todays-productivity-software.
ਐਂਗਲਬਾਰਟ ਨੇ ਦਲੀਲ ਦਿੱਤੀ ਕਿ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਮਨੁੱਖੀ ਸੋਚ ਅਤੇ ਟੀਮਵਰਕ ਨੂੰ ਜ਼ਿਆਦਾ ਬਲਦਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਥਾਂ ਲੈਣੀ। “ਆਗਮੈਂਟੇਸ਼ਨ” ਦਾ ਮਤਲਬ ਹੈ:
ਜੇ ਕੋਈ ਟੂਲ ਤੁਹਾਨੂੰ ਸਮਝਣ, ਫੈਸਲਾ ਕਰਨ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮੱਦਦ ਕਰਦਾ ਹੈ (ਸਿਰਫ਼ ਕਰਵਾਉਂਦਾ ਨਹੀਂ), ਤਾਂ ਉਹ ਉਸਦੇ ਲੱਖਾਂ ਅਨੁਸਾਰ ਹੈ।
ਆਟੋਮੇਸ਼ਨ ਉਹ ਕੰਮ ਤੁਹਾਡੇ ਲਈ ਕਰਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਦੁਹਰਾਉਂਦੇ ਤੇ ਸਪਸ਼ਟ ਕਾਰਜ). ਆਗਮੈਂਟੇਸ਼ਨ ਤੁਹਾਡੇ ਸੋਚਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕੰਮ ਅਸਪਸ਼ਟ, ਰਚਨਾਤਮਕ ਜਾਂ ਮਿਆਦ-ਵਾਲਾ ਹੋਵੇ।
ਅਮਲ ਦੀ ਇੱਕ ਸਧਾਰਣ ਰਾਹਦਾਰੀ: ਜੇ ਟਾਸਕ ਵਿਵੇਚਨਾ ਜਾਂ ਮਰਯਾਦਾਵਾਂ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਤੇਜ਼ੀ ਨਹੀਂ, ਪਰ ਸਪੱਸ਼ਟਤਾ, ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਸਾਂਝੇ ਸਮਝਣ ਵਾਲੇ ਟੂਲ ਤਰਜੀਹ ਦਿਓ।
ਬੂਟਸਟਰੈਪਿੰਗ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸੁਧਾਰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਤਾਕਤ ਦੇਣ — ਬੇਹਤਰ ਟੂਲ ਤੁਹਾਨੂੰ ਹੋਰ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਇਹ ਯੋਗਤਾ ਤੁਹਾਨੂੰ ਹੋਰ ਬੇਹਤਰ ਟੂਲ ਅਤੇ ਤਰੀਕੇ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
ਇਸਨੂੰ ਆਪਣੀ ਟੀਮ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਲਈ:
ਛੋਟੇ-ਛੋਟੇ ਸੁਧਾਰ ਇੱਕ ਫਲਾਈਵ੍ਹੀਲ ਬਣਾਉਂਦੇ ਹਨ।
NLS (oN-Line System) ਇੱਕ ਪ੍ਰਾਰੰਭਿਕ ਇੰਟਰਐਕਟਿਵ ਨੌਲੇਜ਼ ਵਰਕਸਪੇਸ ਸੀ—ਜਿੱਥੇ ਤੁਸੀਂ ਕੰਮ ਕਰਦਿਆਂ ਜਾਣਕਾਰੀ ਬਣਾਉਂਦੇ, ਠੀਕ ਕਰਦੇ ਅਤੇ ਜੋੜਦੇ ਸੀ।
ਇਸ ਨੇ ਇਕੱਠੇ ਕੀਤੀਆਂ ਕਈ ਧਾਰਨਾਵਾਂ ਨੂੰ ਮਿਲਾਇਆ:
ਅਨੁਭਵ ਕਰਨ ਲਈ ਸੋਚੋ: “ਡੌਕਸ + ਵਿਕੀ + ਕੋਲੈਬਰੇਸ਼ਨ” ਇਕ ਹੀ ਮਾਹੌਲ ਵਿੱਚ।
ਜੇਕਰ ਕੰਮ ਸਕ੍ਰੀਨ-ਅਧਾਰਿਤ ਹੋਵੇ ਤਾਂ ਨੁਕਤਾ-ਦਰਸ਼ਕ (ਪੌਇੰਟਿੰਗ ਡਿਵਾਈਸ) ਮਨੁੱਖੀ ਮਨ ਦੀ ਨਿਸ਼ਾਨਬੰਦੀ ਘਟਾਉਂਦਾ ਹੈ।
ਹਕੀਕਤੀ ਨੁਕਤਾ: ਬਿਨਾਂ ਕਮਾਂਡ ਯਾਦ ਕਰਨ ਦੇ, ਤੁਸੀਂ ਜਿਸ ਚੀਜ਼ 'ਤੇ ਇਰਾਦਾ ਹੈ ਉਹਦੇ ਉੱਤੇ ਪੌਇੰਟ ਕਰਕੇ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਪ੍ਰਯੋਗਿਕ ਸਿਫਾਰਿਸ਼: ਅਜਿਹੇ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿਲੈਕਟ, ਦੁਬਾਰਾ ਬੰਦੋਬਸਤ ਅਤੇ ਨੈਵੀਗੇਟ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ (ਬਹੁ-ਪੈਨ ਵਿਊਜ਼, ਚੰਗੇ ਕੀਬੋਰਡ ਸੌਰਟਕੱਟਾਂ, ਨਿੱਖਰਦੀ ਚੋਣ)।
ਹਾਈਪਰਟੈਕਸਟ ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਰੈਖਿਕ ਪੰਨਾ ਬਣਨ ਦੀ ਬਜਾਏ ਇੱਕ ਨੈੱਟਵਰਕ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸਨੂੰ ਤੁਸੀਂ ਜਰੂਰਤ ਮੁਤਾਬਕ ਨੈਵੀਗੇਟ ਕਰ ਸਕਦੇ ਹੋ।
ਦਰਅਸਲ ਉਪਯੋਗ:
ਚੰਗੇ ਲਿੰਕ ਗਲਤ ਫ਼ੈਸਲਿਆਂ ਅਤੇ ਦੁਹਰਾਈ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਸੰਰਚਿਤ ਲਿਖਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਮੱਗਰੀ ਨੂੰ ਮੋਡਿਊਲਰ ਬਲਾਕਾਂ (ਹੈਡਿੰਗ, ਬੁਲੇਟ, ਨੇਸਟਿਡ ਹਿੱਸੇ) ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਲੰਬੇ ਪੰਨੇ ਵਜੋਂ।
ਸਰਲ ਵਰਕਫਲੋ:
ਇਸ ਨਾਲ ਸੋਧ ਤੇ ਸਹਿਯੋਗ ਤੇਜ਼ ਅਤੇ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਨੇ “ਕੋਲੈਬੋਰੇਸ਼ਨ” ਨੂੰ ਦਰਸਾਇਆ ਸੀ ਜਿਵੇਂ ਕਿ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਬੈਕ-ਐਂਡ ਵਿੱਚ ਭੇਜਣਾ ਨਹੀਂ — ਬਲਕਿ ਇੱਕ ਸਾਂਝਾ ਵਰਕਸਪੇਸ ਜਿੱਥੇ ਟੀਮ ਇਕੋ ਸਮੇਂ ਇੱਕੋ ਸਮੱਗਰੀ ਵੇਖ ਕੇ ਫੈਸਲੇ ਕਰ ਸਕੇ।
ਪ੍ਰਯੋਗਿਕ ਆਦਤਾਂ:
ਟੂਲਜ਼ ਸਹੂਲਤ ਦਿੰਦੀਆਂ ਹਨ; ਪਰ ਨਿਯਮ ਹੀ ਉਨ੍ਹਾਂ ਨੂੰ ਕਾਰਗਰ ਬਣਾਉਂਦੇ ਹਨ।
ਰियल-ਟਾਈਮ ਕੋ-ਐਡੀਟਿੰਗ ਦਾ ਮੁੱਲ ਸਿਰਫ਼ ਟਾਇਪਿੰਗ ਦੀ ਰਫ਼ਤਾਰ ਨਹੀਂ — ਇਹ ਸਹਿਮਤੀ ਦੀ ਰਫ਼ਤਾਰ ਹੈ।
ਚੰਗੀ ਕੋ-ਐਡੀਟਿੰਗ ਲਈ:
ਉਪਯੋਗ ਉਦਾਹਰਣ: ਇਨਸਿਡੈਂਟ ਰਿਸਪਾਂਸ, ਪਲੈਨਿੰਗ ਮੀਟਿੰਗਾਂ, ਸੰਪਾਦਕੀ ਸਮੀਖਿਆ—ਸਭ ਜਗ੍ਹਾ ਲਾਈਵ ਅਪਡੇਟ ਫੈਸਲਿਆਂ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ।
1968 ਦੀ ਡੈਮੋ (9 ਦਸੰਬਰ) ਵਿੱਚ Engelbart ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਟੀਮ ਨੇ NLS ਦਾ 90-ਮਿੰਟ ਦਾ ਲਾਈਵ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ।
ਉਸ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ:
ਮੂਲ ਨੁਕਤਾ: ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਸੀ ਕਿ ਕੰਪਿਊਟਰ ਸਿਰਫ਼ ਗਣਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਉਹ ਸਾਂਝੇ ਜਟਿਲ ਕੰਮਾਂ ਵਿੱਚ ਮਨੁੱਖਾਂ ਦੇ ਸਾਥੀ ਬਣ ਸਕਦੇ ਹਨ।
ਐਂਗਲਬਾਰਟ ਨੇ ਸਿਰਫ਼ ਕੁਝ ਗੈਜ਼ਿਟ ਨਹੀਂ ਬਣਾ ਕੇ ਦਿਖਾਏ—ਉਸਨੇ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਇਹ ਦਿਖਾਇਆ ਕਿ ਕੰਪਿਊਟਰ ਕਿਸ ਤਰ੍ਹਾਂ ਗਤੀਸ਼ੀਲ, ਜੁੜੇ ਹੋਏ ਅਤੇ ਸਾਂਝੇ ਗਿਆਨ-ਕਾਰਜ ਲਈ ਸਾਥੀ ਬਣ ਸਕਦੇ ਹਨ।
ਆਧੁਨਿਕ ਟੂਲਾਂ ਵਿੱਚ ਇਹ ਧਾਰਣਾਵਾਂ ਇਉਂ ਮਿਲਦੀਆਂ ਹਨ:
पर ਅਜਿਹਾ ਨਹੀਂ ਕਿ 1968 ਨਾਲ ਹੀ ਸਭ ਕੁਝ ਤੁਰੰਤ ਆ ਗਿਆ—ਇਹ ਇੱਕ ਕਾਰਗਰ ਦ੍ਰਿਸ਼ਟੀ ਦਿਖਾਉਂਦਾ ਸੀ ਜਿਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਨੇ ਅਪਣਾਇਆ।
ਐਂਗਲਬਾਰਟ ਨੇ ਸਿਰਫ਼ ਖਾਸ ਫੀਚਰਾਂ ਦੀ ਪੇਸ਼ਗੀ ਨਹੀਂ ਕੀਤੀ—ਉਸਨੇ ਕੰਮ ਦੇ ਇੱਕ ਪੈਟਰਨ ਦਾ ਨਕਸ਼ਾ ਖਿੱਚਿਆ। ਆਧੁਨਿਕ ਟੂਲਾਂ ਦੇ ਚੰਗੇ ਪਲੂਸ-ਮੋਮੈਂਟ ਇਸੇ ਜੀ੍ਨ ਤੋਂ ਆਉਂਦੇ ਹਨ।
ਸਧਾਰਨ ਫਰੇਮਵਰਕ: ਕੈਪਚਰ → ਕਨੈਕਟ → ਕੋਆਰਡੀਨੇਟ → ਡੀਸਾਈਡ
ਜੇ ਤੁਹਾਡੇ ਟੂਲ ਇਹਨਾਂ ਚਾਰ ਕੰਮਾਂ ਨੂੰ ਘੱਟ ਕਾਂਟੈਕਸਟ-ਸਵਿੱਚ ਦੇ ਨਾਲ ਸਹਾਰਦੇ ਹਨ (ਲਿੰਕ, ਸੰਰਚਨਾ ਅਤੇ ਇਤਿਹਾਸ ਸਾਥ ਹੋ), ਤਾਂ ਤੁਸੀਂ ਐਂਗਲਬਾਰਟ ਦੀ ਬੁਨਿਆਦੀ ਯੋਜਨਾ ਦੇ ਕਾਫ਼ੀ ਨੇੜੇ ਹੋ।
ਇਕ ਨਵਾਂ ਰੁਝਾਨ: ਜਦੋਂ AI ਤੁਹਾਨੂੰ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ ਤਾਂ ਫਾਇਦਾ ਕੇਵਲ ਕੋਡ ਉਤਪਾਦਨ ਨਹੀਂ—ਇਹ ਮਨੋਰਥ, ਫੈਸਲੇ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਜੋੜਨ ਵਿੱਚ ਵੀ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ Koder.ai ਉਹੀ ਵਿਚਾਰ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦਾ ਹੈ।
ਐਂਗਲਬਾਰਟ ਦੀ ਪ੍ਰਮੁੱਖ ਵਾਅਦਾ ਕਿਸੇ ਖ਼ਾਸ ਐਪ ਦਾ ਨਹੀਂ ਸੀ—ਇਹ ਕੰਮ ਕਰਨ ਦਾ ਇੱਕ ਢੰਗ ਸੀ: ਜਾਣਕਾਰੀ ਨੂੰ ਸੰਰਚਿਤ ਕਰੋ, ਜੋੜੋ ਅਤੇ ਸਹਿਯੋਗ ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਓ।
ਕੁਝ ਤੁਰੰਤ ਕਦਮ ਜੋ ਤੁਸੀਂ ਮੌਜੂਦਾ ਟੂਲਸ ਨਾਲ ਵੀ ਲੈ ਸਕਦੇ ਹੋ:
ਹਫ਼ਤੇ ਦੀ ਚੈਕਲਿਸਟ:
ਵਧੇਰੇ ਲੋਕ ਇਹ ਸੋਚਦੇ ਹਨ ਕਿ ਐਂਗਲਬਾਰਟ ਨੇ ”ਸਭ ਕੁਝ“ ਇਕੱਲੇ ਹੀ ਐਜਾਦ ਕੀਤਾ—ਪਰ ਇਹ ਸਚ ਨਹੀਂ।
ਅਸਲ ਵਿਚ ਉਸਨੇ ਕੀ ਕੀਤਾ:
ਕਿਉਂ ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਤੁਰੰਤ ਆਮ ਨਹੀਂ ਹੋਈ:
ਵਧੇਰੇ ਪੜ੍ਹਨ ਲਈ: Douglas Engelbart, “Augmenting Human Intellect: A Conceptual Framework” (1962) ਅਤੇ 1968 ਦੀ “Mother of All Demos” ਰਿਕਾਰਡਿੰਗ, ਅਤੇ ਕੁਝ ਇਤਿਹਾਸਕ ਪੁਸਤਕਾਂ. ਅਧਿਕ ਸੰਦਰਭ ਲਈ ਵੇਖੋ /blog/how-his-ideas-show-up-in-todays-productivity-software.