جولة تفصيلية حول تطوير أجهزة متعددة
في مقالتنا الأولى حول تطوير تجربة Chrome A Journey Through Middle-earth، ركّزنا على تطوير WebGL للأجهزة الجوّالة. في هذه المقالة، نناقش التحديات والمشكلات والحلول التي واجهناها عند إنشاء بقية واجهة HTML5 الأمامية.
ثلاث نُسخ من الموقع الإلكتروني نفسه
لنبدأ بالحديث قليلاً عن تكييف هذه التجربة للعمل على كل من أجهزة الكمبيوتر المكتبية والأجهزة المحمولة من منظور حجم الشاشة وإمكانات الجهاز.
يعتمد المشروع بأكمله على أسلوب "سينمامي" للغاية، حيث أردنا الحفاظ على التجربة داخل إطار ثابت مهيأ للمنظر لمنع السحر من الفيلم. نظرًا لأن جزءًا كبيرًا من المشروع يتكون من "ألعاب" مصغّرة تفاعلية، فلن يكون من المنطقي السماح لها بتجاوز الإطار أيضًا.
يمكننا أن نأخذ الصفحة المنتقل إليها كمثال لكيفية تكييف التصميم مع الأحجام المختلفة.
يحتوي الموقع على ثلاثة أوضاع مختلفة: سطح المكتب والجهاز اللوحي والهاتف الجوّال. لن يقتصر الأمر على التعامل مع التخطيط فحسب، ولكن لأنّنا نحتاج إلى التعامل مع مواد العرض المحمَّلة في وقت التشغيل وإضافة تحسينات متنوعة للأداء. ليس من السهل تحديد مجموعة القواعد النهائية، وذلك لأنّ الأجهزة ذات الدقة العالية مقارنةً بأجهزة الكمبيوتر المكتبية والمحمولة ولكن أداءها سيئ مقارنةً بالهواتف.
نستخدم بيانات وكيل المستخدم لاكتشاف الأجهزة الجوّالة وإجراء اختبار بحجم إطار العرض لاستهداف الأجهزة اللوحية (645 بكسل أو أعلى). كل وضع مختلف يمكنه أن يعرض جميع درجات الدقة في الواقع، نظرًا لأن التنسيق يعتمد على الاستعلامات عن الوسائط أو تحديد الموضع النسبي/النسبة المئوية باستخدام JavaScript.
نظرًا لأن التصميمات في هذه الحالة لا تستند إلى شبكات أو قواعد وهي فريدة تمامًا بين الأقسام المختلفة، فإن ذلك يعتمد حقًا على العنصر المحدد والسيناريو فيما يتعلق بنقاط التوقف أو الأنماط التي يجب استخدامها. وقد حدث ذلك أكثر من مرة عندما أنشأنا التنسيق المثالي باستخدام عبارات sass-mixin اللطيفة واستعلامات الوسائط، ثم احتجنا إلى إضافة تأثير بناءً على موضع الماوس أو الكائنات الديناميكية، وانتهى بنا الأمر إلى إعادة كتابة كل شيء في JavaScript.
نضيف أيضًا فئة بالوضع الحالي في علامة العنوان حتى نتمكن من استخدام هذه المعلومات في أنماطنا، كما في هذا المثال (في SCSS):
.loc-hobbit-logo {
// Default values here.
.desktop & {
// Applies only in desktop mode.
}
.tablet &, .mobile & {
// Different asset for mobile and tablets perhaps.
@media screen and (max-height: 760px), (max-width: 760px) {
// Breakpoint-specific styles.
}
@media screen and (max-height: 570px), (max-width: 400px) {
// Breakpoint-specific styles.
}
}
}
نحن نتيح استخدام جميع الأحجام حتى 360×320 تقريبًا، ما يشكّل تحديًا كبيرًا عند تقديم تجربة ويب غامرة. على سطح المكتب، لدينا حد أدنى للحجم قبل أن نعرض أشرطة التمرير لأننا نريدك أن تعرض الموقع في إطار عرض أكبر إن أمكن. على الأجهزة الجوّالة، قرّرنا السماح بالوضع الأفقي والرأسي وصولاً إلى التجارب التفاعلية التي نطلب منك فيها تحويل الجهاز إلى الوضع الأفقي. وكان الحجج ضد ذلك هو أن الموقع ليس غامرًا في الوضع العمودي كما هو الحال في الوضع الأفقي، ولكن حجم الموقع كان جيدًا، لذلك احتفظنا به.
تجدر الإشارة إلى أنّه يجب عدم الخلط بين التصميم ورصد الميزات، مثل نوع الإدخال واتجاه الجهاز وأدوات الاستشعار وما إلى ذلك، إذ يمكن أن تتوفّر هذه الميزات في جميع هذه الأوضاع ويجب أن تمتد على كل هذه الأوضاع. يعد دعم الماوس واللمس في نفس الوقت أحد الأمثلة. يتم تعويض Retina للحصول على الجودة، ولكن الأهم من ذلك كله هو أداء آخر، وأحيانًا تكون جودة أقل من حيث الجودة أفضل. وكمثال على ذلك، تُمثل اللوحة نصف درجة الدقة في تجارب WebGL على شاشات Retina، والتي من المفترض أن تعرض أربعة أضعاف عدد وحدات البكسل.
كثيرًا ما استخدمنا أداة المحاكي في "أدوات مطوري البرامج" أثناء عملية التطوير، لا سيّما في Chrome Canary الذي يتضمّن ميزات جديدة ومحسّنة والكثير من الإعدادات المسبقة. وهي طريقة جيدة للتحقق من صحة التصميم بسرعة. كنّا لا نزال بحاجة إلى إجراء اختبارات على الأجهزة الحقيقية بانتظام. وكان أحد الأسباب هو تكيف الموقع مع وضع ملء الشاشة. تُخفي الصفحات التي تحتوي على تمرير عمودي واجهة مستخدم المتصفح عند التمرير في معظم الحالات (يواجه متصفح Safari على نظام التشغيل iOS7 مشاكل مع هذه الميزة حاليًا) ولكن كان علينا ملاءمة كل شيء بشكل مستقل عن ذلك. استخدمنا أيضًا إعدادًا مسبقًا في المحاكي وغيّرنا إعداد حجم الشاشة لمحاكاة فقدان المساحة المتاحة. إجراء الاختبارات على الأجهزة الحقيقية مهم أيضًا لرصد استهلاك الذاكرة والأداء.
التعامل مع الولاية
بعد الصفحة المقصودة، وصلنا إلى خريطة ميدل ايرث. هل لاحظت أنّ عنوان URL يتغيّر؟ الموقع الإلكتروني هو تطبيق من صفحة واحدة يستخدم History API لمعالجة التوجيه.
ويمثل كل قسم من الموقع الإلكتروني الكائن الخاص به الذي يكتسب نصًا نموذجيًا من الوظائف، مثل عناصر DOM، والانتقالات، وتحميل مواد العرض، والتخلص من الإعلان، وغير ذلك. وعندما تستكشف أجزاءً مختلفة من الموقع الإلكتروني، يتم بدء الأقسام، وتتم إضافة العناصر إلى DOM وإزالتها منه ويتم تحميل مواد العرض للقسم الحالي.
نظرًا لأن المستخدم يمكن أن يضغط على زر الرجوع في المتصفح أو التنقل عبر القائمة في أي وقت، فيجب التخلص من كل ما تم إنشاؤه في مرحلة ما. يجب إيقاف المهلات والرسوم المتحركة وتجاهلها، وإلا ستؤدي إلى سلوك غير مرغوب فيه أو أخطاء أو تسرُّب في الذاكرة. هذه ليست مهمة سهلة دائمًا، خاصة عند اقتراب المواعيد النهائية وتحتاج إلى إنجاز كل شيء في أسرع وقت ممكن.
عرض المواقع الجغرافية
لإظهار الإعدادات الرائعة وشخصيات ميدل ايرث، صممنا نظامًا معياريًا لمكوّنات الصور والنصوص التي يمكنك سحبها أو تمريرها سريعًا أفقيًا. لم نفعّل شريط تمرير هنا لأنّنا نريد استخدام سرعات مختلفة في نطاقات مختلفة، كما هو الحال في تسلسلات الصور حيث توقف الحركة بشكل جانبي إلى أن يتم تشغيل المقطع.
الجدول الزمني
عندما بدأ التطوير، لم نكن نعرف محتوى الوحدات الخاصة بكل موقع. ما كنا نعرفه هو أننا أردنا طريقة نموذجية لعرض أنواع مختلفة من الوسائط والمعلومات في جدول زمني أفقي من شأنه أن يمنحنا الحرية في إنشاء ستة عروض تقديمية مختلفة للموقع دون الحاجة إلى إعادة بناء كل شيء ست مرات. ولإدارة ذلك، أنشأنا وحدة تحكّم في المخطط الزمني تتولى العرض الشامل لوحداته استنادًا إلى الإعدادات وسلوكيات الوحدات.
الوحدات ومكونات السلوك
تتمثل الوحدات المختلفة التي أضفنا إليها الدعم في تسلسل الصور، والصور الثابتة، ومشهد اختلاف المنظر، ومشهد تحويل التركيز، والنص.
تتمتع وحدة مشهد المنظر بخلفية معتمة تحتوي على عدد مخصص من الطبقات التي تستمع إلى تقدم إطار العرض للحصول على مواضع محددة.
مشهد تغيير التركيز هو أحد أشكال مجموعة اختلاف المنظر، بالإضافة إلى أننا نستخدم صورتين لكل طبقة تتلاشى للداخل والخارج لمحاكاة تغيير التركيز. لقد حاولنا استخدام فلتر التمويه، ولكنه لا يزال مكلفًا، لذا سننتظر استخدام أدوات تظليل CSS.
المحتوى في الوحدة النصية مفعَّل مع السحب باستخدام المكوّن الإضافي TweenMax السحب. يمكنك أيضًا استخدام عجلة التمرير أو التمرير سريعًا بإصبعين للانتقال رأسيًا. لاحِظ throw-props-plugin الذي يضيف توقُّعات الحركة عند التمرير السريع وإفلاتها.
ويمكن أن تتضمّن الوحدات أيضًا سلوكيات مختلفة تتم إضافتها كمجموعة من المكوّنات. وتشتمل كل هذه الأدوات على أدوات اختيار وإعدادات مستهدفة خاصة بها. الترجمة لنقل عنصر، والمقياس للتكبير/التصغير، ونقاط الاتصال لتراكب المعلومات، ومقاييس تصحيح الأخطاء للاختبار مرئيًا، وتراكب عنوان البداية، وطبقة مضيئة، وغير ذلك. سيتم إلحاق هذه العناصر بنموذج العناصر في المستند (DOM) أو التحكّم في العنصر المستهدف داخل الوحدة.
عند تنفيذ ذلك، يمكننا إنشاء مواقع مختلفة باستخدام ملف إعداد فقط يحدّد مواد العرض المطلوب تحميلها وإعداد الأنواع المختلفة للوحدات والمكوّنات.
تسلسلات الصور
إنّ تسلسل الصور هو أصعب الوحدات من حيث الأداء وحجم التنزيل. هناك أخبار كثيرة يمكنك قراءتها عن هذا الموضوع. نستبدله بصورة ثابتة على الأجهزة الجوّالة والأجهزة اللوحية. يتطلب الأمر قدرًا كبيرًا من البيانات لفك ترميزها وتخزينها في الذاكرة إذا أردنا الحصول على جودة ملائمة على الجوّال. لقد جربنا عدة حلول بديلة؛ مثل استخدام صورة خلفية وورقة الرموز المتحركة أولاً، لكن هذا أدى إلى حدوث مشاكل في الذاكرة وتأخير عندما احتاجت وحدة معالجة الرسومات إلى التبديل بين أوراق الرموز المتحركة. ثم حاولنا تبديل عناصر الصور، لكنها كانت أيضًا بطيئة جدًا. كان رسم إطار من ورقة الرموز المتحركة إلى لوحة رسم هو الأكثر فعالية، لذلك بدأنا في تحسين ذلك. لتوفير وقت الحساب لكل إطار، تتم معالجة بيانات الصورة المراد كتابتها في لوحة الرسم مسبقًا عبر لوحة رسم مؤقتة وحفظها باستخدام (putImageData()) في مصفوفة، ويتم فك ترميزها وجعلها جاهزة للاستخدام. يمكن بعد ذلك تجميع ورقة الرموز المتحركة الأصلية، ولا نخزن سوى الحد الأدنى من البيانات اللازمة في الذاكرة. ربما لا يكون تخزين الصور غير المرمّزة أمرًا أقل في الواقع، ولكنّنا نحقّق أداءً أفضل أثناء مراجعة التسلسل بهذه الطريقة. الإطارات صغيرة جدًا، 640x400 فقط، لكنها ستكون مرئية فقط أثناء التقديم والترجيع. عند التوقف، يتم تحميل صورة عالية الدقة وتتلاشى بسرعة.
var canvas = document.createElement('canvas');
canvas.width = imageWidth;
canvas.height = imageHeight;
var ctx = canvas.getContext('2d');
ctx.drawImage(sheet, 0, 0);
var tilesX = imageWidth / tileWidth;
var tilesY = imageHeight / tileHeight;
var canvasPaste = canvas.cloneNode(false);
canvasPaste.width = tileWidth;
canvasPaste.height = tileHeight;
var i, j, canvasPasteTemp, imgData,
var currentIndex = 0;
var startIndex = index * 16;
for (i = 0; i < tilesY; i++) {
for (j = 0; j < tilesX; j++) {
// Store the image data of each tile in the array.
canvasPasteTemp = canvasPaste.cloneNode(false);
imgData = ctx.getImageData(j * tileWidth, i * tileHeight, tileWidth, tileHeight);
canvasPasteTemp.getContext('2d').putImageData(imgData, 0, 0);
list[ startIndex + currentIndex ] = imgData;
currentIndex++;
}
}
يتم إنشاء أوراق الرموز المتحركة باستخدام Imagemagick. في ما يلي مثال بسيط على GitHub يوضّح كيفية إنشاء ورقة رموز متحركة لجميع الصور داخل مجلد.
تحريك الوحدات
لوضع الوحدات على المخطط الزمني، يؤدي تمثيل مخفي للمخطط الزمني، المعروض خارج الشاشة، إلى تتبع "رأس التشغيل" وعرض المخطط الزمني. يمكن القيام بذلك باستخدام التعليمات البرمجية فقط، ولكنه كان جيدًا مع التمثيل المرئي عند التطوير وتصحيح الأخطاء. عند تشغيل المحتوى بشكلٍ حقيقي، يتم تحديثه فقط بشأن تغيير الحجم لضبط الأبعاد. بعض الوحدات تملأ إطار العرض، وبعضها يحتوي على نسبة خاصة بها، لذلك كان من الصعب قليلاً تغيير حجم كل شيء وتحديد موضعه في كل درجات الدقة حتى يظهر كل شيء ولا يتم اقتصاصه كثيرًا. كل وحدة بها مؤشران للتقدم، أحدهما للموضع المرئي على الشاشة والآخر لمدة الوحدة نفسها. عند إنشاء حركة المنظر، يكون من الصعب غالبًا حساب موضع بداية ونهاية الكائنات لمزامنتها مع الموضع المتوقع عندما يكون العنصر في العرض. من المفيد أن تعرف بالضبط متى تدخل وحدة العرض، وتشغِّل مخططها الزمني الداخلي وعندما تتحرك خارج العرض مرة أخرى.
تحتوي كل وحدة على طبقة سوداء رقيقة على سطحها تعمل على ضبط مستوى التعتيم حتى تصبح شفافة تمامًا عندما تكون في الموضع الأوسط. يساعدك هذا في التركيز على وحدة واحدة في كل مرة، مما يعزز التجربة.
أداء الصفحة
إن الانتقال من نموذج أولي فعال إلى إصدار إصدار خالٍ من البيانات يعني الانتقال من التخمين إلى معرفة ما يحدث في المتصفح. هذا هو المكان الذي تكون فيه "أدوات مطوري البرامج في Chrome" أفضل صديق لك.
لقد أمضينا وقتًا طويلاً في تحسين الموقع. يعد فرض تسريع الأجهزة أحد أهم الأدوات بالطبع للحصول على رسوم متحركة سلسة. بالإضافة إلى البحث عن الأعمدة الملونة والمستطيلات الحمراء في "أدوات مطوري البرامج في Chrome". هناك العديد من المقالات الجيدة حول المواضيع، وعليك قراءتها جميعًا. إنّ مكافأة إزالة لقطات تخطّي اللقطات تكون فورية، ولكن يمكن أن يشعر ذلك بالإحباط عند عودة تلك اللقطات مرة أخرى. وسيفعلون ذلك. إنها عملية مستمرة تحتاج إلى تكرارات.
أحب استخدام TweenMax من Greensock لخصائص tweenMax وتحويلات وCSS. فكر في الحاويات، وتصور هيكلك أثناء إضافة طبقات جديدة. يُرجى العِلم أنّه يمكن استبدال التحويلات الحالية بتحويلات جديدة. يتم استبدال translateZ(0) التي فرضت تسريع الأجهزة في فئة CSS بمصفوفة ثنائية الأبعاد إذا كنت تفوق القيم ثنائية الأبعاد فقط. للحفاظ على الطبقة في وضع التسريع في تلك الحالات، استخدم خاصية "force3D:true" في مرحلة ما قبل المراهقة لإنشاء مصفوفة ثلاثية الأبعاد بدلاً من مصفوفة ثنائية الأبعاد. من السهل أن تنسى عند الجمع بين ملفات CSS وJavaScript لتعيين الأنماط.
لا تفرض تسريع الأجهزة عند عدم الحاجة إليها. يمكن أن تمتلئ ذاكرة وحدة معالجة الرسومات بسرعة وتتسبب في ظهور نتائج غير مرغوب فيها عندما تريد تسريع الأجهزة في العديد من الحاويات، وخاصةً على نظام التشغيل iOS حيث توجد قيود أكبر على الذاكرة. وقد أدى تحميل مواد عرض أصغر حجمًا وتوسيع نطاقها باستخدام css وإيقاف بعض التأثيرات في وضع الجوّال إلى تحسينات كبيرة.
كان تسرُّب الذاكرة مجالاً آخر نحتاج إلى تحسين مهاراتنا فيه. عند التنقل بين تقنيات WebGL المختلفة، يتم إنشاء الكثير من الكائنات والمواد والقوام والأشكال الهندسية. وإذا لم تكن هذه الملفات جاهزة لجمع البيانات المهملة عند الخروج من الصفحة وإزالة هذا القسم، من المحتمل أن يؤدي ذلك إلى تعطُّل الجهاز بعد فترة من عدم اكتمال الذاكرة.
للعثور على المعلومات المجهولة المصدر، كانت العملية واضحة ومباشرة في "أدوات مطوري البرامج"، مع تسجيل المخطط الزمني والتقاط لقطات متعدّدة. من الأسهل أن تكون هناك كائنات معيّنة يمكنك فلترتها، مثل الهندسة الثلاثية الأبعاد أو مكتبة معيّنة. في المثال أعلاه، اتضح أن المشهد الثلاثي الأبعاد لا يزال موجودًا وأيضًا لم يتم محو الصفيف الذي خزنت الأشكال الهندسية. إذا وجدت صعوبة في تحديد مكان وجود الكائن، فهناك ميزة رائعة تتيح لك عرض هذا المسمّى مسارات الاحتفاظ. ما عليك سوى النقر على العنصر الذي تريد فحصه في اللقطة المجمّعة وستظهر المعلومات المطلوبة في اللوحة أدناه. يساعد استخدام بنية جيدة مع كائنات أصغر عند تحديد موقع المراجع.
بشكل عام، من المفيد التفكير جيدًا قبل استخدام DOM. عندما تفعل ذلك، فكر في الكفاءة. لا تعالج نموذج كائن المستند (DOM) داخل حلقة الألعاب إذا أمكنك ذلك. تخزين المراجع في المتغيّرات لإعادة استخدامها إذا كنت بحاجة إلى البحث عن عنصر، استخدِم أقصر طريق من خلال تخزين المراجع إلى الحاويات الاستراتيجية والبحث داخل أقرب عنصر أصل.
يمكنك تأخير قراءة أبعاد العناصر المضافة حديثًا أو عند إزالة/إضافة فئات إذا واجهت أخطاءً في التخطيط. أو تأكَّد من تشغيل التنسيق. في بعض الأحيان، يتم تغيير دُفعة المتصفّح إلى أنماط، ولا يتم تحديثها بعد مشغّل التنسيق التالي. يمكن أن تكون هذه مشكلة كبيرة في بعض الأحيان، ولكنها موجودة لسبب ما، لذا حاول معرفة كيف يعمل وراء الكواليس وستحقق الكثير.
ملء الشاشة
يتوفر لك خيار وضع الموقع في وضع ملء الشاشة في القائمة عبر واجهة برمجة التطبيقات بملء الشاشة، عند توفرها. ولكن على الأجهزة، يمكن للمتصفّحات أيضًا اختيار وضع البطاقة في وضع ملء الشاشة. كان متصفّح Safari على أجهزة iOS تعرّض للاختراق في السابق للسماح لك بالتحكم في ذلك، إلا أنّ ذلك لم يعد متاحًا، لذا عليك إعداد تصميمك للعمل بدونه عند إنشاء صفحة لا تسمح بالتمرير. ومن المتوقّع أن نتوقّع تحديثات عن هذا الأمر في التحديثات المستقبلية لأنّه أدّى إلى تعطّل الكثير من تطبيقات الويب.
مواد العرض
لدينا الكثير من أنواع مواد العرض المختلفة في الموقع الإلكتروني، ونستخدم الصور (PNG وJPEG) وSVG (مضمّن وخلفية) وأوراق الرموز المتحركة (PNG) وخطوط الرموز المخصّصة والرسوم المتحركة في Adobe Edge. نستخدم ملفات PNG لمواد العرض والرسوم المتحركة (أوراق الرموز المتحركة) حيث لا يمكن أن يكون العنصر متجهًا، وإلا نحاول استخدام ملفات SVG قدر الإمكان.
ولا يعني تنسيق الخط المتجه أي فقدان للجودة، حتى إذا قمنا بقياسه. ملف واحد لكل الأجهزة
- حجم الملف صغير.
- يمكننا تحريك كل جزء على حدة (وهو مثالي للصور المتحركة المتقدمة). وكمثال على ذلك، نخفي "العنوان الفرعي" لشعار الهوبيت (ويحل محله سموغ) عند تصغيره.
- ويمكن تضمينه كعلامة SVG HTML أو استخدامه كصورة خلفية بدون تحميل إضافي (يتم تحميلها في نفس وقت تحميل صفحة html).
تتمتع الخطوط الطباعية للأيقونات بنفس مزايا الرسومات الموجّهة التي يمكن تغيير حجمها (SVG) عندما يتعلق الأمر بقابلية التوسّع، ويتم استخدامها بدلاً من SVG للعناصر الصغيرة مثل الرموز التي نحتاج فقط إلى أن نتمكّن من تغيير لونها (التمرير، والحركة، وما إلى ذلك). من السهل جدًا أيضًا إعادة استخدام الرموز، وما عليك سوى تعيين خاصية "content" في CSS لأحد العناصر.
الصور المتحركة
في بعض الحالات، قد تستغرق الصور المتحركة لعناصر SVG باستخدام التعليمات البرمجية وقتًا طويلاً، خاصة عندما يلزم تغيير الرسوم المتحركة كثيرًا أثناء عملية التصميم. لتحسين سير العمل بين المصممين والمطورين، نستخدم Adobe Edge لبعض الرسوم المتحركة (التعليمات قبل الألعاب). إنّ سير عمل الرسوم المتحركة قريب جدًا من برنامج Flash وهذا ساعد الفريق ولكن هناك بعض العيوب، خاصةً في ما يتعلّق بدمج رسوم Edge المتحركة في عملية تحميل مواد العرض لأنّها تأتي مع أدوات تحميل خاصة بها ومنطق تطبيق.
ما زال أمامنا طريق طويل قبل أن نوفّر سير عمل مثاليًا للتعامل مع مواد العرض والصور المتحركة المصنوعة يدويًا على الويب. نتطلع إلى معرفة كيف سيتم تطوير أدوات مثل Edge. لا تتردد في إضافة اقتراحات حول أدوات الرسوم المتحركة الأخرى وسير العمل في التعليقات.
الخلاصة
والآن، عندما يتم إصدار جميع أجزاء المشروع ونلقي نظرة على النتيجة النهائية، لابد أن أقول إننا قد أعجبنا جدًا بحالة المتصفحات الحديثة على الأجهزة الجوّالة. عندما بدأنا هذا المشروع، كانت توقعاتنا أقل بكثير حول مدى السلاسة والتكامل والأداء الذي سنتمكن من تحقيقه. لقد كانت تجربة تعليمية رائعة بالنسبة إلينا وقد أدى طول الوقت الذي قضيناه في التكرار والاختبار (كثيرًا) إلى تحسين فهمنا لكيفية عمل المتصفحات الحديثة. وهذا ما سيتطلبه الأمر إذا أردنا تقصير وقت الإنتاج لهذه الأنواع من المشاريع، بدءًا من التخمين وحتى المعرفة.