تطوير موقع المكتبة للهواتف: تجربة في الإدارة الرشيقة

مقدمة:

تضم جامعة كاليفورنيا في سان دييغو ست كليات ونحو ثلاثين ألف طالب. ويعمل في مكتبات الحرم التسع أكثر من ثلاثمائة موظف موزعين على عشرات الأقسام. وفي هذه البيئة الأكاديمية الكبيرة والموزعة، اعتادت المشروعات المرور بفترات طويلة من التطوير والاختبار قبل إتاحة منتج قابل للاستخدام، مع إجراءات محددة للحصول على توجيه الإدارة وملاحظاتها. ويشبه ذلك نموذج الشلال (Waterfall) الذي يسعى إلى استكمال الأفكار واعتمادها قبل الانتقال إلى التنفيذ [1]. أما مشروع موقع الهواتف فكان تجربة لأسلوب يستجيب للتغيير ويعتمد التعاون والسرعة والتجريب، ويقبل إطلاق خدمة جيدة بما يكفي ثم تحسينها.

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

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

منهج العمل:

استند الأسلوب جزئيًا إلى مبادئ التطوير الرشيق (Agile)، ولا سيما دورات العمل القصيرة المتكررة والتواصل المباشر بين مطوري الويب وممثلي خدمات المستفيدين [2]. وقد قام على العناصر الآتية:

• جدول قصير ومحدد: يتطلب إنشاء خدمة جديدة من الصفر التزامًا بموعد قريب ومعالم واضحة حتى لا تعطل التفاصيل غير المتوقعة المشروع. بدأنا باجتماع يوضح الأدوار وحدود العمل. وفي الأسبوع الأول، من الاثنين إلى الجمعة، ينشئ فريق الويب قسمًا من الموقع ويوزع التغييرات. وفي الأسبوع الثاني، من الاثنين إلى الأربعاء، يختبر الأعضاء الأربعة الوظائف ودقة المحتوى ويسجلون التعديلات في ويكي المشروع. ويُدمج الرأي الراجع ويُطلق القسم يومي الخميس والجمعة. وفي الاثنين التالي يجتمع الفريقان لتحديد الدورة الجديدة وتوقعاتها وحدودها التقنية، ثم تتكرر العملية في الأسبوعين الثالث والرابع والخامس والسادس.
• تواصل مفتوح ومباشر: تكررت اللقاءات الشخصية بين ممثلي الخدمات وتقنية المعلومات أكثر مما هو معتاد في مشروعات المكتبات، مع إتاحة التواصل بالمحادثة والشبكات الاجتماعية خارج الاجتماعات.
• الاستجابة لسرعة انتشار الهواتف: قد يناسب التدرج الطويل بعض المشروعات، لكنه قد يؤخر الخدمة إلى ما بعد الفترة الأهم لاستخدامها. وأظهر تقرير بيو لعام 2010 أن تسعة من كل عشرة أشخاص بعمر 18–29 سنة يمتلكون هاتفًا خلويًا، وأن 65% منهم يدخلون الإنترنت بهذه الأجهزة [3].
• فريق صغير مفوض: قد يؤدي إشراك لجان عديدة في كل قرار إلى تصميم معقد وغير متماسك. وجمع الفريق خمسة ممثلين للخدمات، باحتساب المنسق، وموظفًا تقنيًا واحدًا. ومثّل أعضاؤه عدة لجان ومُنحوا صلاحية اتخاذ القرار باسم المكتبة.
• إطلاق مفيد ثم تحسين تدريجي: استهدفت النسخة الأولى تلبية الاحتياجات الأساسية لمعظم المستفيدين، دون محاولة تلبية كل احتياج. واستُبعدت الإضافات التي قد تؤخر الإطلاق، على أن تُضاف الخدمات تباعًا.

جمع المتطلبات:

بدأنا بمسح خدمات مواقع الهواتف في خمس وعشرين مكتبة أكاديمية، وحصرنا جميع الخدمات المتاحة فيها [4]. ثم توسع هذا الحصر ضمن مشروع بحث مستخدمي الأجهزة المحمولة بمكتبة كاليفورنيا الرقمية [5]. وراجعته المجموعة الاستشارية وفريق التقنية لتحديد أولويات النسخة الأولى. وشملت الخدمات المختارة ساعات العمل، والفهرس، واسأل أمين المكتبة، وأدوات البحث وقواعد البيانات، والخرائط والاتجاهات، وبيانات الاتصال، ورابط الموقع الكامل.

كانت الجامعة تستخدم نظام إدارة المحتوى (Cascade Server) من شركة هانون هيل منذ فبراير 2009 [6]، ويُدار به موقع المكتبات العام وشبكتها الداخلية. لذلك طُور موقع الهواتف ضمن النظام نفسه اتباعًا لمعايير الجامعة واستثمارًا للموارد القائمة. ولم تُدرس لهذا السبب أطر خارجية مثل إطار معهد ماساتشوستس للتقنية المفتوح المصدر [7]. واستهدفت البداية الأجهزة المتوسطة والمتقدمة واسعة الانتشار [8]، مع إعطاء الأولوية للوصول إلى أكبر عدد من المستفيدين عبر الويب بدل تطبيق مخصص لأجهزة بعينها.

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

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

التصميم والتنقل والأداء:

حرصنا منذ البداية على فهم سياق الهاتف: تختلف أهداف مستخدميه عن أهداف مستخدمي الحواسيب المكتبية والمحمولة. لذلك صممنا قوالب ومحتوى يتطلبان قدرًا محدودًا من التمرير، مع أحجام مناسبة للخطوط وعناصر الواجهة. واستُخدم دليل محتوى الويب لمتصفح سفاري في تصميم القوائم والأزرار والأيقونات [9]، ودليل ياهو في تنسيق المحتوى [10]، واستُخدمت أوراق الأنماط (CSS3) عند ملاءمتها للتحسين التدريجي للواجهة.

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

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

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

واستُخدم برنامج مفتوح المصدر لاكتشاف متصفح الهاتف من موقع (detectmobilebrowser.com)، لتوجيه الزائر من (libraries.ucsd.edu) إلى (libraries.ucsd.edu/m). ويظل للمستفيد اختيار الموقع الكامل من رابط واضح في الصفحة الرئيسية.

كان الأداء مهمًا لأن شبكات الهواتف أبطأ غالبًا من الاتصالات الثابتة، ولأن قدرة المعالجة والتخزين المؤقت أقل من الحواسيب المكتبية. ورغم تحسن الحد الأقصى لحجم ملف الأنماط أو البرنامج النصي القابل للتخزين المؤقت، كما ناقش ستيف سودرز ورايان غروف [11، 12]، ظلت هذه الحدود موضع دراسة. وضغطنا ملفات الأنماط والبرامج النصية [13]، وقللنا الصور وضغطناها، واستخدمنا ترويسات انتهاء صلاحية بعيدة في خادم أباتشي للمحتوى الملائم، مع متابعة التطورات في هذا المجال.

التحديات المقبلة:

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

خاتمة:

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

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

المراجع والهوامش:

• [1] http://www.editlib.org/p/12509.
• [2] Shore, James. The Art of Agile Development.
• [3] Pew Internet. Mobile Access 2010. Summary of Findings.
• [4] Library Success: A Best Practices Wiki. http://www.libsuccess.org.
• [5] CDL Mobile Device User Research Project. Comparative analysis resources.
• [6] Hannon Hill. Cascade Server. http://www.hannonhill.com/.
• [7] MIT Mobile Web Framework. SourceForge.
• [8] Admob Mobile Metrics. May 2010 country data; StatCounter Global Stats. Mobile browser statistics.
• [9] Apple. Safari Web Content Guide.
• [10] Yahoo. Yahoo Style Guide.
• [11] Souders, Steve. Mobile Cache File Sizes.
• [12] Grove, Ryan. Mobile Browser Cache Limits Revisited.
• [13] Yahoo Developer Network. YUI Compressor.