من النموذج الأولي إلى موقع أفضل: تجربة برينستون في تطوير البحث الأرشيفي

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

ما الغاية من الواجهة:

كثيرًا ما يُطلب من مطوري برمجيات المكتبات ومصممي واجهاتها تحسين قابلية استخدام المواقع، لكن تحسين الواجهة وحده قد لا يعالج التحديات الأوسع لتجربة المستخدم (Mathews, 2012). فالموقع يعكس أدوات المكتبة وممارساتها وأساليب عملها، وتغيير هذه الممارسات يتجاوز صلاحيات قسم التقنية. وفي المقابل، تتحفظ الإدارة العليا، لأسباب مفهومة، على المشروعات غير المنضبطة، وتحتاج إلى دليل على جدوى الأفكار الجديدة وإمكانية إدارة مخاطرها. ويزيد الأمر صعوبة بُعد المطورين والإدارة عن الاستخدام اليومي لدى معظم المستفيدين؛ فكيف نعرف ما يناسبهم ما لم نتفاعل معهم؟

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

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

الخلفية:

يعالج الالتزام بأعراف تصميم الويب الحديثة جانبًا كبيرًا من مشكلات قابلية الاستخدام (Alexandre et al., 2012)، بما في ذلك نظم الإتاحة الأرشيفية. فالمستخدم الذي اعتاد الوصول إلى المحتوى عبر الويب يشعر بالإحباط حين يجد البيانات الوصفية متاحة، ثم يواجه إجراءات مربكة لزيارة الأرشيف والتسجيل وطلب المواد والاطلاع عليها. [3] وتزيد الممارسات المحلية غير الموحدة، والمصطلحات المتخصصة، وأدلة البحث الطويلة والمعقدة صعوبة التجربة على الباحث المبتدئ. لذلك سعينا إلى نظام أقرب إلى توقعات مستخدمي الويب.

تقتني مكتبات جامعة برينستون نحو 2200 مجموعة أرشيفية ومخطوطة، وُصفت جميعها تقريبًا في أدوات بحث مرمّزة بمعيار الوصف الأرشيفي المرمّز (EAD). ومع أنها موصوفة أيضًا في صورة مختصرة على هيئة تسجيلات (MARC) على مستوى المجموعة ومتاحة في بيئة الفهرس الآلي المتاح للجمهور (OPAC)، فإن أدلة البحث على الإنترنت هي السياق الأساسي لوصول المستخدمين، والبحث على الويب هو القناة الأساسية للاكتشاف (discovery).

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

التجربة:

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

إن عرض مكوِّن واحد بوصفه تسجيلة تجربةٌ مختلفة جدًا عن الممارسة المعتادة المتمثلة في عرضه سطرًا واحدًا ضمن قائمة طويلة في أداة بحث تقليدية. غير أن نهج «المكوِّن بوصفه تسجيلة» مقبول تمامًا في إطار المعايير الأرشيفية. وقد هندسنا طريقة عرضنا لتسجيلات المكوِّنات بحيث تضم جميع حقول البيانات الوصفية اللازمة لاستيفاء الحد الأدنى من متطلبات الوصف أحادي المستوى كما يحددها معيار (DACS) (Describing Archives: A Content Standard)، ولكل تسجيلة مكوِّن معرّف فريد ومحدد موارد موحد (URL) ثابت. وبعبارة أخرى، لدينا عناوين (URL) تمثل كل مستوى من مستويات التسلسل الهرمي للمجموعة.

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

وثيقة الأهداف الموجزة:

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

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

وكان من المنطقي أيضًا الاستفادة من معيار الترميز (EAC-CPF) (Encoded Archival Context for Corporate Bodies, Persons, and Families) الخاص بملفات الاستناد الأرشيفية [7]. فتسجيلة (CPF) توفر مدخلًا آخر إلى المحتوى بطريقة قد تكون أكثر بداهة للمستخدم؛ إذ تبدأ من موضوع التساؤل البحثي لا من المواد التي قد تصف ذلك الموضوع. فمثلًا، بدلًا من البحث في المجموعات عن كل ما قد يكون لدينا عن وودرو ويلسون (Woodrow Wilson)، تقدّم تسجيلة (EAC-CPF) معلومات عن وودرو ويلسون، ثم تسرد المصادر المتاحة في المستودع المتصلة بويلسون، فتوفر «تجربة تصفح» بديلةً عن البحث.

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

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

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

النموذج الأولي قيد التطبيق:

التعاطف مع المستخدم يقود إلى تصميم أفضل:

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

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

الأدوات المناسبة للمهمة:

لكي نضع شاشات حقيقية وبيانات حقيقية أمام جميع مستخدمينا، كان على مطورينا أن يجدوا طريقة للانتقال من الأهداف إلى النموذج الأولي بأسرع ما يمكن، ثم جمع التغذية الراجعة والاستجابة لها بالسرعة نفسها. وكان من المهم ألا يكون النموذج الأولي مجرد مجسّم تصوري، بل أن يتفاعل المستخدمون مع بيانات حقيقية. ولمّا كانت لدينا خبرة سابقة في استخدام (eXist) (رابط المصدر) قاعدةَ بيانات لملفات (EAD) وإطارَ عمل (MVC) لموقع أدلة البحث القديم، فقد اقتضى إدخال بيانات حقيقية إلى نموذجنا الأولي تقديمَ مقتطفات سياقية من ملفات (EAD) بصيغ متعددة بناءً على طلبات (HTTP). وأضفنا (Solr) لتحسين أداء البحث وجودته عمومًا. وقد ساعدتنا أداتان جديدتان تبنيناهما مساعدة هائلة في اختبار قابلية الاستخدام: (Bootstrap) (رابط المصدر) لبناء النماذج الأولية، و(Trello) (رابط المصدر) لتتبع التغذية الراجعة وسير العمل.

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

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

لفتت (Trello) انتباهنا لإدارة التغذية الراجعة لأنها أداة مجانية لإدارة سير العمل تستلهم استخدام المنهجية الرشيقة للبطاقات المفهرسة [9] لنقل قصص المستخدمين من الفكرة إلى الخاصية المكتملة. ففي (Trello) نحاول أن نصوغ المشكلة في جملة واحدة، مع رابط عند الضرورة، فنحوّل التغذية الراجعة بسرعة إلى بطاقات. ويمكن أن تجري نقاشات وتفصيلات إضافية بسهولة عبر إشعارات (Trello). وتُـ«سحب» البطاقة عبر مسار عمل محدد خصيصًا إلى أن تستقر في عمود «(Done)» (منجز). ويكفي لتكليف شخص بالمهمة سحبُ صورته الرمزية إلى البطاقة. فضلًا عن ذلك، نتيح وصولًا عامًا للقراءة فقط إلى لوحتنا على (Trello) [10] ليتمكن أي شخص من معرفة موقع اقتراحاته في أولويات التطوير وسير العمل، فنبني الثقة بالشفافية والإشراك.

استراتيجية اختبار قابلية الاستخدام منخفض التكلفة:

ما إن بنينا نموذجنا الأولي وأصبحنا مستعدين لجمع التغذية الراجعة، حتى استرشدنا بفصل ستيف كروغ (Steve Krug) في كتاب (Don)’(t Make Me Think)، المعنون «(Usability Testing on 10 Cents a Day): (Keeping It Simple So You Test Enough)» (اختبار قابلية الاستخدام بعشرة سنتات يوميًا: البساطة لكي تختبر بما يكفي). يلاحظ كروغ أن الفريق، بعد أن يعمل على موقع ولو لبضعة أسابيع، لا يعود قادرًا على رؤيته بعين جديدة. والطريقة الوحيدة للتيقن من جودة عمله هي الاختبار (Krug, 2000).

قد يثير الحديث عن الاختبار قلق بعض المعنيين، لما يستحضرونه من أعباء الدراسات الأكاديمية السابقة، حتى الصغيرة منها. فمتطلبات البحوث الرسمية، ومنها الإجراءات الإدارية والتدريب المرتبط بمجلس المراجعة المؤسسية (IRB)، قد تجعل جمع الملاحظات البسيط أكثر تعقيدًا. ويقدم اختبار قابلية الاستخدام منخفض التكلفة نهجًا بديلًا، يقوم على ملاحظة عدد قليل من المستخدمين مباشرة لتحديد مشكلات الاستخدام (Nielsen, 2000).

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

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

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

منهج الاختبار وملاحظاتنا:

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

طلبنا من كل مختبَر أن يؤدي خمس مهام بحثية: بحثين عن مواد معروفة، وبحثين موضوعيين، وبحثًا واحدًا كنا نأمل أن يدفع إلى استخدام تسجيلة (EAC-CPF) لتحديد موقع المعلومات. وشُجّع المستخدمون على التحدث بصوت مسموع في أثناء عملهم، وشرح كيفية اختيارهم لمصطلحات البحث، والتعليق على نقراتهم. وفي أثناء أدائهم هذه المهام، دوّن ثلاثة منا من فريق التطوير ملاحظات عن طريقة عملهم. وسجّلنا مواضع السلاسة ومواضع التردد في التعامل مع النظام، وقاطعنا العملية دوريًا بأسئلة عن نوع الاستجابات التي يتوقعونها من النظام. كما طرحنا سلسلة من الأسئلة حاولنا بها أن نتبين لا مدى قدرة المستخدم على التفاعل مع النظام فحسب، بل شعوره في أثناء ذلك أيضًا.

وقد جسّد أحد الأسئلة البحثية تطوّر نظامنا تجسيدًا جيدًا على نحو خاص؛ إذ طرحنا على طلاب المرحلة الجامعية الأولى، وأرشيفيي الخدمات العامة، واختصاصيي الخدمات المرجعية، وباحث محترف مجال دراسته حقبة الحرب الباردة في الولايات المتحدة (مع تركيز خاص على جون فوستر دالاس (John Foster Dulles)) السؤال الآتي: «أكتب ورقة عن جون فوستر دالاس، وعن الكيفية التي ربما أثّرت بها قناعاته الدينية الشخصية في علاقته المتطورة بنغو دينه ديم (Ngo Dinh Diem). ماذا لديكم؟».

في موقع أدلة البحث السابق، كان البحث عن «(john dulles diem)» يُرجع معلومات على مستوى المجموعة، مثل عناوين أدلة البحث، والمستخلصات، والمنشئين، ومعلومات عن كيفية الاستشهاد بالمجموعة ومكانها. غير أنه لمّا كان التطابق قد يقع في أي موضع من دليل البحث، فإن مصطلحات البحث الفعلية لم تكن تظهر بالضرورة على شاشة النتائج، ولم تكن العلاقة الدقيقة بين مصطلحات البحث ونتائجه واضحة دائمًا. ففي هذا المثال، لا يرد أي ذكر لـ«(Diem)» على شاشة النتائج. وبالنقر للدخول، سيُضطر المستخدم الباحث عن معلومات حول المعتقدات الدينية لجون فوستر دالاس إلى البحث (أو استخدام (control+F)) في أداة بحث من خمسين ألف كلمة عن المادة ذات الصلة.

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

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

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

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

اخترنا أن نحترم هذا النوع من التفضيلات، مدركين أن الممارسات ستتغير حين يعتاد المستخدمون الأدوات الجديدة، واتخذنا قرارًا بعدم إزالة أي وظيفة قائمة. فأضفنا خيار العرض في «صفحة واحدة»، أي عرض دليل البحث كاملة بصيغتي (HTML) و(PDF)، للمستخدمين الذين يفضلون تلك التجربة.

استخدام التحليلات لاكتشاف أنماط الاستخدام:

ينبغي أن تُستكمل أي محاولة لتحسين تجربة المستخدم عبر اختبار قابلية الاستخدام ببيانات كمية عن سلوك المستخدمين. فقبل هذا المشروع، لم يكن ثمة سجل للاستخدام سوى سجلات (Apache)، التي كان من الصعب استخلاص معلومات يمكن الاستفادة منها عمليًا منها. وكان من أهدافنا أن نكوّن فكرة أفضل عن سلوكيات المستخدمين واستراتيجياتهم البحثية باستخدام (Google Analytics). وقد أتاح لنا عرض المكونات كوحدات مستقلة تتبّع اهتمام المستخدمين على مستوى أدق، لأن (Google Analytics) يجمع البيانات في إعداده الافتراضي بناءً على عناوين (URL) الفريدة. غير أن الإعدادات الافتراضية لـ(Google Analytics) لم تتح لنا تتبّع وظائف جديدة أخرى أضفناها، مثل التفاعلات داخل الصفحة القائمة على (JavaScript).

ولكي نفهم سلوكيات المستخدمين فهمًا حقيقيًا، ونعرف في نهاية المطاف مدى نجاح حلولنا، كنا بحاجة إلى تتبّع النقرات بطريقة أكثر استراتيجية لجمع بيانات أكثر فائدة لاتخاذ القرارات، وهو ما لم يكن بإمكاننا فعله قط ببرمجيات تسجيل الويب التقليدية. كم من المستخدمين كانوا يستخدمون تبويبات المعلومات على مستوى المجموعة؟ وكم منهم استخدم عارض الصور؟ وهل كانوا يطلبون عدة مواد في آن واحد أم مادة واحدة؟ وقد ساعدنا مقال كيرك هِس (Kirk Hess) في مجلة (Code4Lib Journal) بعنوان (Discovering Digital Library User Behavior with Google Analytics) على معرفة كيفية تطبيق «تتبّع الأحداث» وجمع البيانات التي نحتاج إليها (Hess K, 2012).

نماذج أولية على الموقع الفعلي:

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

كان جعل تفاعلات المستخدمين مع المواد طريقًا في اتجاهين هدفًا محوريًا لهذا المشروع. ولحسن الحظ، لم يتطلب حلّنا سوى جهد تطويري قليل، فأتاح لنا ترف اختباره على الموقع الفعلي في الغالب. وكان بناء نظام تعليقات خاص بنا خارج نطاق المشروع، ولم نكن نريد أن يضطر المستخدمون إلى إنشاء بيانات دخول جديدة لمجرد كتابة تعليق. فقد رأينا أن الأرجح أن تجري الحوارات في المساحات المألوفة لمستخدمينا، في الشبكات الاجتماعية التي يرتادها أقرانهم. وفي الوقت نفسه، أردنا الاحتفاظ بإحالة إلى موضوع النقاش لأغراض التتبع. ولهذا الغرض، تمكّنا من استخدام (Intense Debate) (رابط المصدر)، وهو نظام تعليقات بلغة (JavaScript) يُضاف بإضافة شفرته الجاهزة. ويتيح هذا النظام للمستخدمين استخدام بيانات اعتمادهم في تويتر (Twitter) أو فيسبوك (Facebook) أو (OpenID) أو جوجل (Google)، ثم مشاركة تعليقاتهم من دليل البحث عبر نظم أخرى، مما يزيد من ظهور الموقع. ومع أن الحكم لم يُحسم بعدُ بشأن حجم الأثر الذي ستحدثه خاصية التعليقات، فقد تلقّينا، في غضون أيام من إطلاق النسخة التجريبية من الموقع، تغذية راجعة عن أخطاء في وصف مكوِّنات ربما لم نكن لنكتشفها بغير ذلك.

الخاتمة:

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

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

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

المراجع:

• [1] يقوم ما نعدّه نموذجًا أوليًا على مفهوم إريك ريس (Eric Reis) للمنتج الأدنى القابل للحياة (minimum viable product, MVP)، وهو تلك النسخة من المنتج الجديد التي تتيح للفريق جمع أكبر قدر من التعلم المُتحقَّق منه عن العملاء بأقل جهد. http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
• [2] نشجع على تصفح الموقع النهائي في http://findingaids.princeton.edu استكمالًا للقطات الشاشة التي أدرجناها في المقال.
• [3] استرشد كثير من عملنا بالفكر الذي طوّره تقرير المتطلبات الوظيفية للتسجيلات الببليوغرافية (Functional Requirements for Bibliographic Records) الصادر عن الاتحاد الدولي لجمعيات ومؤسسات المكتبات (إفلا، IFLA).
• [6] استرشد تفكيرنا بدراسة مركز OCLC المتأنية لإمكانات المواد الممسوحة ضوئيًا في مكتبات المجموعات الخاصة. Schaffner, Jennifer, Francine Snyder, and Shannon Supple. 2011. “Scan and Deliver: Managing User-initiated Digitization in Special Collections and Archives.” Dublin, OH: OCLC Research. http://www.oclc.org/research/publications/library/2011/2011-05.pdf
• [8] تولّى دان سانتاماريا (Dan Santamaria) قيادة هذا المشروع بمهارة ومعرفة، وكان عضوًا في فريق اختبار المستخدمين لدينا. وقدّم جون ديلاني (John Delaney) وريجين هيبرلين (Regine Heberlein) ودون ثورنبري (Don Thornbury) معرفتهم بممارسات الوصف الأرشيفي واحتياجات المستخدمين؛ أما جون ستروب (Jon Stroop)، محلل البيانات الوصفية لدينا، فكان مسؤولًا عن بنية النظام.

• [4] Pitti, Daniel V. “Technology and the Transformation of Archival Description.” Journal of Archival Organization 3, no. 2–3 (2006): 9–22. (COinS)
• [5] Nimer, Cory. Applying Inheritance: Single-level Displays and Repurposable Metadata. Society of American Archivists 2010 Research Forum. http://www2.archivists.org/sites/all/files/CNFinal.pdf
• [7] http://eac.staatsbibliothek-berlin.de/
• [9] http://www.agilemodeling.com/artifacts/userStory.htm
• [10] https://trello.com/board/finding-aid-feedback/4fe4801276ca124c1029e650
• Alexandre N. Tuch, Eva Presslaber, Markus Stoecklin, Klaus Opwis, Javier Bargas-Avila. (2012). The role of visual complexity and prototypicality regarding first impression of websites: Working towards understanding aesthetic judgments. International Journal of Human-Computer Studies, vol. 70(11), pp. 794-811 Available at: http://research.google.com/pubs/pub38315.html
• Fried, J. (2008). Why we skip photoshop. 37Signals. Available from: http://37signals.com/svn/posts/1061-why-we-skip-photoshop/
• Hess, K. (2012). Discovering digital library user behavior with google analytics. Code4Lib Journal. Available from: http://journal.code4lib.org/articles/6942
• Hess, W. (2012). User experience is not enough. Available from: http://whitneyhess.com/blog/2012/04/21/user-experience-is-not-enough/
• Krug, S. (2000). Don’t Make Me Think! A Common Sense Approach to Web Usability. Indianapolis, Ind: Macmillan USA;. (COinS)
• Mathews, B. (2012). Think like a startup: a white paper to inspire library entrepreneurialism. VTechWorks, Virginia Tech University Library. Available from: http://vtechworks.lib.vt.edu/handle/10919/18649
• Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Jakob Nielsen’s Alertbox. Available from: http://www.useit.com/alertbox/20000319.html