دراسة حالة - HTML5 في deviantART muro

Mike Dewey
Mike Dewey

مقدمة

في 7 آب (أغسطس) 2010، احتفلت منصة deviantART بعيد ميلادها العاشر. احتفلنا بعيد ميلادنا من خلال إطلاق أداة رسم HTML5 تُسمى deviantART muro. يمكن استخدام الأداة كتطبيق ويب مستقل بالإضافة إلى أداة رسم خفيفة الوزن لإضافة صور إلى تعليقات المنتدى.

استقبل منتدى deviantART أداة الرسم الجديدة هذه بحماس كبير، وتستقطب الأداة نفسها الآن عددًا من الزيارات يعادل عدد الزيارات التي تجذبها بعض المواقع الإلكترونية ذات الحجم المتوسط. منذ إطلاقه، يتم إرسال رسم جديد باستخدام deviantART muro مرة كل 5 ثوانٍ تقريبًا. هذه هي أعداد الرسومات المكتملة فقط، وقد تم بدء العديد من الرسومات الأخرى ولم يتم حفظها.

تقدّم المقالة التالية بعض المعلومات الأساسية عن كيفية استخدامنا لـ HTML5، وسبب اختيارنا استخدام التقنيات التي استخدمناها، والأشياء التي اكتشفتها أثناء كتابة أحد أوائل تطبيقات HTML5 الكاملة لموقع إلكتروني رئيسي.

معلوماتي الأساسية

في أواخر عام 2005، كنت أحد المطوّرين المسؤولين عن أداة الرسم المستخدَمة في Draw Here. كانت الأداة عبارة عن أداة "كتابة على الويب" يتم تشغيلها من خلال إشارة مرجعية صغيرة. وكان يُستخدَم لرسم الصور على أي صفحات ويب. تم إنشاء تطبيق Draw Here في البداية باستخدام SVG (كان الإصدار التجريبي من Firefox 1.5 قد صدر للتو، وكان من أوائل المتصفّحات التي تتيح استخدام SVG).

في Internet Explorer، كنا ننشئ ملفات SVG في الخلفية، ولكنّنا كنا نعرض الرسم باستخدام VML. لم يكن WebKit متوافقًا مع SVG في ذلك الوقت، لذا نقلت رمزنا لعرض SVG باستخدام canvas (التي كانت تقنية جديدة لم تظهر إلا في WebKit في ذلك الوقت). في مرحلة ما، أنشأتُ عملية نقل لكي يتم عرض رمز SVG على المتصفّحات القديمة باستخدام مجموعة من عناصر div التي تم لصقها معًا. (كان هذا الإجراء مجرد مزحة لإظهار أنّه يمكن تنفيذه، وكان بطيئًا جدًا).

في أوج استخدام تطبيق Draw Here، كان يتم إنشاء حوالي 100 رسم يوميًا. كان التطبيق مكتملًا بما يكفي ليُطلق عليه اسم أكثر من مجرد تجربة، على الرغم من أنّه لم يكن لديه اللمسة النهائية لتطبيق ويب رئيسي. في منتصف عام 2006، تم التخلي عن المشروع، على الرغم من أنّ الموقع الإلكتروني لا يزال يعمل حتى اليوم، إلا أنّه يُستخدَم في الغالب للضحك فقط.

التكنولوجيات المستخدَمة في deviantART muro

بسبب خبرتي في استخدام تقنيات HTML5 المختلفة في أيامها الأولى، طلب مني أن أكون المطوّر الرئيسي في deviantART muro. أي شخص يقرأ هذه المقالة يمكنه على الأرجح فهم سبب اختيارنا HTML5 بدلاً من تقنية مستندة إلى مكوّنات إضافية مثل Silverlight أو Flash. أردنا أن يكون لدينا نظام قوي يستخدم أيضًا معايير مفتوحة.

الاختيار بين Canvas وSVG

قرّرنا إنشاء طبقة الرسم باستخدام لوحة الرسم. قد يتساءل بعض المستخدمين عن الحالات التي يجب فيها استخدام canvas والحالات التي يجب فيها استخدام SVG. هناك تداخل كبير في الإجراءات التي يمكن تنفيذها باستخدام تكنولوجياتَي الالتقاط والرسم، كما أثبت تطبيق Draw Here، إذ يمكن استخدام كلتا التقنيتَين لإنشاء تطبيق للرسم.

لقد تبيّن لي أنّ ملفات SVG رائعة إذا كنت تريد الاحتفاظ بأسماء عناصرك التي رسمتها. على سبيل المثال، إذا أردت أن يتمكّن المستخدم من رسم خط، ثم سحب أجزاء من الخط لتغيير شكله، سيكون ذلك سهلاً باستخدام SVG. ولكن لا يمكن تنفيذ ذلك بسهولة باستخدام لوحة الصورة.

عند استخدام لوحة Canvas، يمكنك إضافة عناصر إليها، ثم نسيانها. تعمل لوحة فارغة ولوحة تم الرسم عليها لمدة ساعة بالطريقة نفسها تمامًا في الرمز البرمجي، وتستخدِم كلتا اللوحتَين مساحة الذاكرة نفسها تقريبًا. على الرغم من أنّ برنامج الرسم الممسوح ضوئيًا يعمل عادةً بشكل جيد جدًا مع التكنولوجيا، إلا أنّه يجعل بعض الأمور صعبة. على سبيل المثال، من الصعب جدًا إنشاء دالّة إلغاء سريع في "لوحة الرسم" مقارنةً بتنسيق SVG. في SVG، يمكنك الاحتفاظ باسم معرِّف لعدد من السطور الأخيرة التي وضعتها، ويمكنك التراجع عن الإجراء ببساطة عن طريق إزالة هذه العناصر. في اللوحة، بعد رسم خط، لا يمكنك معرفة ما كان تحته، لذلك تتطلّب إزالة الخط إعادة رسم المنطقة التي كان فيها.

بعد أن قرّرنا استخدام HTML5 للوحة، قررنا الاستفادة من بعض ميزات HTML5 الأخرى هنا وهناك. على سبيل المثال، الطريقة التي استخدمنا بها localStorage لتتبُّع إعدادات الفرشاة لدى المستخدم. بهذه الطريقة، بعد ضبط الفرش المختلفة بالطريقة التي يحبونها، يمكنهم الرجوع إلى هذه الإعدادات في المرة التالية التي يستخدمون فيها أداتنا. يعني localStorage أنّه ليس علينا استخدام ملف تعريف الارتباط أو إجراء أي عمليات اتصال بالخادم للحصول على هذه الإعدادات المفضّلة.

استخدام "لوحة الرسم"

شهدت ميزة "لوحة الصورة" تطورًا كبيرًا خلال السنوات الخمس الماضية. باستخدام ميزة "الرسم هنا"، لم ننشر إصدار لوحة الصورة لأنّ الأداء لم يكن جيدًا. أعتقد أنّه من الآمن الآن القول إنّه من المحتمل أن يحقّق أداءً أفضل مما تتوقّع. يمكن عادةً محو جزء كبير من اللوحة وإعادة رسم أشكال معقّدة بسرعة تفوق قدرة الإنسان على التمييز. إنّ الشيء الوحيد الذي تبيّن لي أنّه بطيء جدًا في بعض الأحيان هو استخدام getImageData() لتحليل عيّنات من البكسلات. تعتمد سرعة العملية بوضوح على حجم اللوحة، ولكن في اللوحة الكبيرة، يمكن أن يستغرق تنفيذ getImageData()() في الوقت الخطأ وقتًا طويلاً بما يكفي ليشعر المستخدم بأنّ التطبيق بطيء الاستجابة.

بعد قراءة دروس تعليمية مختلفة حول استخدام لوحات العرض، كان لديّ في البداية انطباع بأنّها عناصر ثقيلة يجب استخدامها بشكل مقتصد، ربما مرة أو مرتين في الصفحة. لا أعلم ما إذا كان الجميع يدرك ذلك، ولكنّني كنت أدرك ذلك، لذلك كنت أستخدمه بشكل مقتصد عندما بدأنا لأول مرة في ترميز deviantART muro. بعد فترة، اكتشفت أنّ هناك الكثير من الأماكن الصغيرة التي يمكن أن توفّر عليك الكثير من الجهد باستخدام لوحة. على سبيل المثال، حدّدت النماذج التوضيحية لتطبيقنا أنّه يجب أن يكون هناك أداة اختيار ألوان تتكون من مثلثَين متداخلَين يعرضان الألوان الأساسية والثانوية:

منتقي ألوان
أداة اختيار الألوان

كان شعوري الأول هو البدء في التفكير في طريقة لإنشاء هذا الجهاز الصغير لواجهة المستخدم باستخدام HTML وCSS التقليديَين. قد يشير الأشخاص المهرة في اختراق CSS إلى كيفية إجراء كل ذلك من خلال CSS، ولكن شكل المثلث للجزءَين اللذَين يتغيّر لونهما يجعل ذلك غير واضح.

عندما خطرت لي فكرة استخدام لوحة فقط، أنشأت التطبيق المصغّر باستخدام عنصر DOM واحد وبضعة أسطر من JavaScript. يستخدم deviantART muro عقد لوحات في كل مكان. كل طبقة هي لوحة، وتغيير ترتيب الطبقات هو مجرد تبديل فهرس z. لوحة "المستكشف" للتكبير/التصغير التي تعرض عرضًا مصغرًا لمنطقة الرسم هي مجرد لوحة أخرى تستدعي في بعض الأحيان drawImage() باستخدام لوحات الطبقات كصور مصدر. حتى مؤشر منطقة الرسم (دائرة ثنائية اللون يتم ضبط حجمها حسب حجم الفرشاة والتكبير/التصغير) هو لوحة تطفو أسفل الماوس.

السبب في أنّنا كنا أكثر تساهلاً مع استخدام عنصر Canvas مقارنةً بتكنولوجيات HTML5 الأخرى هو أنّ مكتبة ExplorerCanvas من Google تتيح محاكاة عنصر Canvas في Internet Explorer. يقودني ذلك إلى القسم التالي.

Internet Explorer

السبب الرئيسي لعدم استخدام المزيد من المواقع الإلكترونية الرئيسية لغة HTML5 حتى الآن هو عدم رغبتها في فقدان مستخدمي Internet Explorer. أعتقد أنّ السؤال الأول الذي يخطر ببال معظم المطوّرين عند سماعهم أنّ deviantART قد أنشأت تطبيق رسم باستخدام HTML5 هو: "ماذا تم بشأن Internet Explorer؟"

قرّرنا في البداية أن نبذل قصارى جهدنا في ما يتعلّق بمحاولة تشغيل العناصر في Internet Explorer، ولكنّنا قررنا عدم استخدام أسلوب تطوير الويب الأقل تكلفةً. ولأنّ منتدى الويب اتّبع المنهج الذي يقضي بأنّه لا يمكن إطلاق الموقع الإلكتروني إلا بعد أن يبدو بالشكل نفسه على كل متصفّح معروف، لا يمكن للمستخدمين معرفة متى يكون المتصفّح غير متوافق. بالنسبة إلى المستخدم العادي، يُحمّل اتّصال الإنترنت مسؤولية مشاكل السرعة، ويظهر كلّ صفحة بالسرعة نفسها تقريبًا. لذلك، يختارون المتصفّح المفضّل لديهم استنادًا إلى عناصر صغيرة عشوائية في واجهة المستخدم، مثل لون زر الرجوع.

قرّرنا إنشاء أي ميزة رائعة تخطر لنا باستخدام مواصفات HTML5، ومحاولة جعلها تعمل في Internet Explorer، وإذا تعذّر ذلك، سنعرض نافذة منبثقة توضّح أنّ الميزة غير متاحة لأنّ المتصفّح لم ينفِّذ بعد أحد معايير الويب.

حاولنا في البداية معالجة المشكلة باستخدام ExplorerCanvas (exCanvas) من Google. وهو بارع بشكل مدهش في تقليد لوحة الرسم لمعظم الأشياء. ومع ذلك، هناك جانب سلبي واحد. كلّ مرّة يتم فيها وضع لمسة على اللوحة، يتم إنشاء عنصر DOM في ترجمة VML الأساسية. بالنسبة إلى معظم الأشياء التي قد تحاول تنفيذها باستخدام اللوحة، هذا أمر جيد، ولكن بعض فرش deviantART muro تُنشئ أشكالًا من خلال وضع الكثير من الضربات معًا. عندما يواجه Internet Explorer ملف VML يحتوي على آلاف العقد، يتعذّر عليه التعامل معه حتى على الأجهزة السريعة. ولهذا السبب، في الكثير من طلبات الرسم، كان علينا استخدام لغة VML و تطبيق حيل لدمج العقد معًا واستخدام الأمر move لتحديد مواضع الفجوات. تستخدم الكثير من عناصر التحكّم الصغيرة وغيرها في الواجهة علامة canvas، لأنّ هذه الاستخدامات الصغيرة كانت تعمل بشكل جيد بشكل عام مع exCanvas.

بالإضافة إلى إتاحة بعض العناصر باستخدام exCanvas، اقترحنا على المستخدمين مواصلة استخدام إصدار Internet Explorer إذا ثبَّتوا مكوّن Google Chrome Frame الإضافي. Google Chrome Frame هو مكوّن إضافي يُدمج محرّك عرض Google Chrome في Internet Explorer. من وجهة نظر المستخدم، لا يزال يستخدم المتصفّح الذي يألفه، ولكن في الخلفية، يتم عرض صفحتنا باستخدام إمكانات HTML5 في Chrome وJavaScript الأسرع.

كنت أعلم أنّه من المفترض أن يكون من السهل نقل التطبيقات للعمل مع Chrome Frame، ولكن لم أتوقّع أن يكون الأمر بهذه البساطة. ما عليك سوى إدخال علامة وصفية إضافية، وبذلك تبدأ العناصر في العمل في IE.

ملخّص

يسعدنا العمل باستخدام التقنيات الجديدة في مواصفات HTML5، وأودّ القول إنّ كل ما استخدمناه جاهز تمامًا للعرض في أوقات الذروة. حتى إذا كنت بحاجة إلى أن تعمل الأشياء بسلاسة على IE، هناك عدد كبير من الإجراءات التي يمكنك تنفيذها من خلال دمج canvas وexCanvas. ومن المفاجئ أيضًا أنّه يمكن كتابة طبقة ترجمة بين SVG وVML. بعد بدء استخدام التكنولوجيا، ستشعر وكأنّك دخلت إلى عالم جديد تمامًا.

المراجع