في الواقع ، هناك عدد قليل جدًا من أنظمة النص التشعبي الحالية تتبع هذا النموذج في بنيتها الداخلية ؛ معظمها عبارة عن مزيج مشوش إلى حد ما من المميزات. ومع ذلك ، يُظهر النموذج اتجاهات مثيرة للاهتمام للمستقبل وهو مهم لعمل التقييس. تصف الأقسام التالية كل مستوى بمزيد من التفصيل ، بدءًا من الأسفل.
مستوى قاعدة البيانات
يقع مستوى قاعدة
البيانات في الجزء السفلي من النموذج ذي المستويات الثلاثة ويتعامل مع جميع
المشكلات التقليدية لتخزين المعلومات التي ليست لها علاقة خاصة بالنص التشعبي. من
الضروري تخزين كميات كبيرة من المعلومات على أجهزة تخزين الكمبيوتر المختلفة مثل
الأقراص الثابتة والأقراص الضوئية وما إلى ذلك ، وقد يكون من الضروري الاحتفاظ
ببعض المعلومات المخزنة على الخوادم البعيدة التي يتم الوصول إليها من خلال شبكة.
بغض النظر عن كيفية تخزين المعلومات ، يجب أن يكون من الممكن استرداد جزء صغير
محدد منها في وقت قصير جدًا. هذا يشبه إلى حد كبير مواصفات قاعدة البيانات .
علاوة على ذلك ،
يجب أن يتعامل مستوى قاعدة البيانات مع مشكلات قاعدة البيانات التقليدية الأخرى ،
مثل الوصول متعدد المستخدمين إلى المعلومات ، واعتبارات الأمان المختلفة ، بما في
ذلك النسخ الاحتياطي. في النهاية ، ستكون مسؤولية مستوى قاعدة البيانات هي فرض
ضوابط الوصول التي يمكن تحديدها في المستويات العليا من البنية.
وبقدر ما يتعلق
الأمر بمستوى قاعدة البيانات ، فإن عقد النص التشعبي والروابط هي مجرد كائنات
بيانات ليس لها معنى معين. يشكل كل واحد منها وحدة يمكن لمستخدم واحد فقط تعديلها
في نفس الوقت والتي تستهلك الكثير من مساحة التخزين. في الحياة الواقعية ، قد يكون
من المفيد لمستوى قاعدة البيانات معرفة المزيد قليلاً عن كائنات البيانات الخاصة
بها من أجل تمكينها من إدارة مساحة التخزين الخاصة بها بشكل أكثر كفاءة وتوفير
استجابة أسرع. ولكن على أي حال ، فإن مجال النص التشعبي سوف يعمل بشكل جيد في
الاستفادة من العمل المكثف والخبرة في مجال قاعدة البيانات التقليدية لتصميم
وتنفيذ مستواها.
مستوى آلة تجريد
النص التشعبي (HAM)
يقع HAM في منتصف الشطيرة بين قاعدة البيانات
ومستويات واجهة المستخدم. هذا المركز هو المكان الذي يحدد فيه نظام النص التشعبي
الطبيعة الأساسية لعقده وروابطه وحيث يحافظ على العلاقة فيما بينها. راجع المناقشة
أدناه حول مجموعة خيارات التصميم المتعلقة بالعقد والروابط. سيكون لدى HAM معرفة بشكل العقد والروابط وسيعرف
السمات المرتبطة بكل منها. على سبيل المثال ، قد تحتوي العقدة على سمة
"مالك" تحدد المستخدم الذي أنشأها والذي يتعين عليه تفويض التحديثات ،
أو قد يكون لها رقم إصدار. يمكن كتابة الروابط كما في بطاقات الملاحظات ، أو قد
تكون مؤشرات عادية كما في الدليل.
يعد HAM هو أفضل مرشح لتوحيد تنسيقات الاستيراد
والتصدير للنصوص التشعبية ، نظرًا لأن مستوى قاعدة البيانات يجب أن يعتمد بشكل
كبير على الجهاز في تنسيق التخزين الخاص به ومستوى واجهة المستخدم يختلف اختلافًا
كبيرًا من نظام نص تشعبي إلى آخر. هذا يترك فقط HAM ، وبما أننا بحاجة إلى القدرة على نقل
المعلومات من نظام نص تشعبي إلى آخر ، يتعين علينا التوصل إلى تنسيق تبادل في هذا
المستوى. أحد الأمثلة الحالية لمعيار مستوى HAM هو HyTime معيار ISO لهيكلة الوسائط الصحية / هيكلة
المستندات المستندة إلى الوقت Newcomb. 1991 ؛
ديروز ودوراند 1994].
يعد تبادل
النصوص التشعبية أكثر صعوبة من مجرد تبادل بيانات المكون في العقد ، على الرغم من
وجود مشاكل أيضًا مع تنسيقات البيانات الأقل توحيدًا للمعلومات غير ASCII مثل الرسومات ومقاطع الفيديو. تكمن
المشكلة في أن تبادل النص التشعبي يتطلب أيضًا نقل معلومات الربط. ينبغي أن يكون
من الممكن نقل الروابط الأساسية (أي
معلومات من النوع
"A Points to B") ،
ولكن قد يتم فقد أجزاء كبيرة من معلومات الربط.
على سبيل المثال
، تحتوي بعض أنظمة النص التشعبي مثل أنترميديا على روابط تشير إلى سلاسل نصية محددة
في العقدة الوجهة ، بينما تشير الأنظمة الأخرى مثل هايبرتي Hyperties فقط إلى العقدة الوجهة ككيان كامل.
وبالتالي ، فإن نقل نص تشعبي من أنترميديا إلى هايبرتي قد يفقد جوانب مهمة من معلومات الربط
ولكن يجب أن يظل ممكنًا من حيث المبدأ. إذا أردنا نقل بنية النص التشعبي من هايبرتي إلى أنترميديا ، فلن تكون هناك طريقة
للتوصل إلى سلسلة فرعية معقولة لمرساة الوجهة لأن مؤلف هايبرتي لم يكن قد أخذ هذا الخيار في الاعتبار
عند كتابة النص التشعبي. ربما يتعين علينا ابتكار مرساة وهمية في بداية عقدة
الوجهة فقط لإبقاء نظام أنترميديا سعيدًا. بالطبع إذا كان النقل من أنترميديا إلى دليل Guide (الذي يحتوي بالفعل على وجهات ارتباط مثبتة)
، فإننا نرغب في أن يحتفظ النقل بالمعلومات حول السلسلة الفرعية للوجهة بحيث يمكن
تمييزها عند الوصول. تكمن الصعوبة في أننا نود تحقيق هاتين النتيجتين بتنسيق تبادل
واحد.
تقرير كان ولانداو
عن تجربتهما في نقل شبكة ديكنز (نص تشعبي عن تشارلز ديكنز) من أنترميديا حيث تم تطويره في الأصل إلى نظامين
آخرين للنص التشعبي: Eastgate System's Storyspace و Interleaf's WorldView. كانت إحدى المشكلات الرئيسية هي أنه لا يمكن نقل
روابط واحد إلى متعدد "الدهون" في أنترميديا إلى ووردفيو WorldView نظرًا لأنها تحتوي فقط على روابط
تشعبية تقليدية فردية. كبديل ، توصل خان ولاندو إلى وثائق "مفترق الطرق"
مثل تلك الموضحة في الشكل .
تعمل مستندات
مفترق الطرق كمحطة طريق بين مرساة المغادرة الأصلية ومراسي الوجهة الأصلية. يتم
استبدال الرابط الأصلي برابط من مرساة المغادرة إلى مستند مفترق الطرق بالإضافة
إلى العديد من الروابط التي يتطلبها توصيل مستند مفترق الطرق بجميع نقاط ارتساء
الوجهة الأصلية. يوضح هذا المثال مدى صعوبة نقل النصوص التشعبية بين الأنظمة إذا
لم تشارك المفاهيم الأساسية فيما يتعلق ببنية النص التشعبي.
لقد بدأ العمل
على تعريف تنسيقات تبادل النص التشعبي في البداية من خلال اجتماعات غير رسمية لما
يسمى بمجموعة
Dexter ،
والتي تتألف من العديد من مصممي أنظمة النص التشعبي المبكرة. (تم تسمية مجموعة Dexter باسم النزل في نيو هامبشاير حيث عقدت
أول اجتماع لها. وقد تم تنظيم الاجتماعين اللذين أسفرا عن النموذج المرجعي بواسطة
جان والكر وجون
ليغيت
وتم تمويلهما
بشكل أساسي من قبل شركة Digital Equipment Corporation وجامعة Texas A&M. منذ ذلك الحين ورشة عمل التقييس للنص
التشعبي في يناير 1990 ، استمر العمل على نماذج مرجعية للنص التشعبي من خلال
المزيد من الأنشطة الرسمية في المعهد الوطني الأمريكي للمعايير والتكنولوجيا.
لقد نتج عن هذا
العمل نماذج معمارية أكثر تفصيلاً من النموذج البسيط ثلاثي المستويات الذي تمت
مناقشته هنا وأيضًا في بعض النجاحات الأولية في نقل معلومات النص التشعبي من نوت
كارد
NoteCards إلى هايبركارد HyperCard. تعد كل من بطاقات نوتكارد و هايبركارت محركات نص تشعبي قائمة على الإطارات ،
حيث يتم عرض المعلومات على بطاقات ثابتة. من المفترض أنه سيكون من الصعب التحويل
بين أنظمة النص التشعبي ذات البنى المختلفة ، مثل ، على سبيل المثال ، النقل من
نظام قائم على النوافذ مثل الدليل بنصوصه الطويلة للتمرير إلى نظام قائم على
الإطار. راجع مناقشة النص التشعبي المستند إلى الإطار مقابل النص التشعبي المستند
إلى النافذة في القسم التالي حول العقد. يوضح الشكل 5.2 العلاقة بين نموذج دكستر
والنموذج المستخدم في هذا الكتاب.
مستوى واجهة
المستخدم
تتعامل واجهة
المستخدم مع عرض المعلومات الموجودة، بما في ذلك المشكلات مثل ما يجب إتاحته من أوامر
للمستخدم، وكيفية إظهار العقد والروابط، وما إذا كان يجب تضمين مخططات نظرة عامة
أم لا.
دعونا نفترض أن المستوى
من النص التشعبي يعرف الروابط التي يتم كتابتها. قد يقرر مستوى واجهة المستخدم عدم
عرض هذه المعلومات على الإطلاق إلى بعض المستخدمين المبتدئين وإجراء كتابة
المعلومات المتاحة فقط في وضع التأليف. يميز التمييز بين القراءة والكتابة أحد
مشكلات واجهة المستخدم الأساسية.
دعونا الآن
نفترض أن مستوى واجهة المستخدم يرغب في عرض الرابط الكتابة للمستخدم. قد ترغب في
القيام بذلك عن طريق تغيير شكل المؤشر، كما يفعل الدليل (انظر الشكل 3.8)، أو من
خلال وجود تدوين خاص لأشكال مختلفة للمثبتين. يمكن أن تقرر أيضا عرض معلومات
الكتابة في مخطط نظرة عامة. إذا كان يحتوي على عرض ملون متاحا، فقد يختار إظهار كل
نوع ارتباطا بلون مختلف، بينما يتعين على عرض أحادي اللون، سيتعين عليه استخدام
تمثيلات مختلفة، مثل أنماط الخط المختلفة (مثل نوتكارد)،
أيقونات صغيرة
(مثل CM / 1، انظر الشكل 4.3)، أو باستخدام الكلمات
لتسمية الخطوط.
في الواقع، لا
يمكن إجراء هذا القرار على مستوى واجهة المستخدم بمعزل دون النظر في الشكل المحتمل
للبيانات. إذا كان لدى النص التشعبي فقط بعض أنواع الروابط ، فإن الألوان أو أنماط
الخط هي خيارات مناسبة، ولكن القدرة البشرية على فهم وتمييز مثل هذا الترميز يقتصر
على حوالي سبعة قيم مختلفة. يمكن أن تدعم الرموز النص التشعبي مع أنواع أخرى إلى
حد ما، ولكن من المحتمل أن يتطلب النص التشعبي مع مئات أنواع الرابط استخدام أسماء
الكتابة في الواجهة.
العقد
العقد هي الوحدة
الأساسية التشعبية، ولكن لا يوجد اتفاق فيما يتعلق بما يشكل حقا "عقدة".
التمييز الرئيسي بين الأنظمة القائمة على الإطار والنظم القائمة على النافذة.
تناول الإطارات
كمية محددة من المساحة على شاشة الكمبيوتر بغض النظر عن مقدار المعلومات التي
تحتوي عليها. أمثلة نموذجية هي إطارات KMS وبطاقات . غالبا ما يتم تعريف حجم الإطار على أنه
حجم شاشة الكمبيوتر، ولكن هذا التصميم قد لا يعقد في جميع الأنظمة. نظرا لأن
الإطار يحتوي على حجم ثابت، فقد يتعين على المستخدم تقسيم كمية معينة من المعلومات
عبر العديد من الإطارات إذا كان لا يمكن أن يصلح إلى واحد. ميزة الإطارات هي أن
جميع التنقل المستخدم يحدث باستخدام ما يتم توفير آليات التشعبي بواسطة النظام.
في المقابل،
تتطلب أنظمة النافذة المستندة إلى استخدام المستخدم من آلية التمرير بالإضافة إلى
آليات النص التشعبي للحصول على الجزء المطلوب من العقدة لإظهاره في النافذة. نظرا
لأن النظام يمكن أن يعرض فقط جزءا (صغير يحتمل) من العقدة من خلال النافذة في أي
وقت معين، فقد تكون العقدة كبيرة حسب الحاجة، والحاجة إلى التوزيع المحتمل غير
الطبيعي للنص على عدة عقد يتم إلغاؤها. دليل و أنترميديا هي أنظمة نموذجية قائمة على النافذة.
هناك عيب كبير
في النص التشعبي الذي يتخذ من النافذة هو أن مصمم النص التشعبي لا يحتوي على سيطرة
على كيفية ظهور العقدة عندما يقرأ المستخدم لأنه يمكن تمريره بعدة طرق. الميزة هي
أن النوافذ قد تكون بحجم مختلف حسب أهمية وطبيعة المعلومات التي يحملونها. يمكن
للمرء أن يتخيل نظاما يستند إلى النافذة التي قامت بالتمرير وبالتالي حافظت على
معظم مزايا تنسيقات العرض.
إن العالم
الحقيقي ليس بسيطا تماما مثل التمييز الواضح بين الإطارات والنوافذ. يعتمد هايبركارد في الغالب على الإطار ولكن يتضمن
إمكانية التمرير في حقول النص كجزء من البطاقة. يستخدم هايغبيرتي Highperties عرض ملء الشاشة دون
التمرير ولكن بدلا من ذلك، يتطلب المستخدم من المستخدم ذهابا وإيابا من خلال سلسلة
من الشاشات في حالة وجود العقدة كبيرة جدا لتناسب شاشة واحدة.
توفر معظم أنظمة
النص التشعبي الحالية معلومات ثابتة في العقد كما كتبها المؤلف الأصلي. في أنظمة
النص التشعبي الحسابية مثل KMS و هايبركارد (مع لغة برمجة مدمجة) أو نوتكارد (مع واجهة إلى لغة برمجة)
، من الممكن أن يكون لديك عقد محسوبة تم إنشاؤها للقارئ بواسطة النظام. مثال على
ذلك هو عقدة مع توقعات الطقس الحالية التي تم استردادها من خدمة عبر الإنترنت مثل American Prodigy أو French Minitel .
من الواضح أن
حساب عقدة أثناء التحليق عن طريق تنفيذ برنامج ينطوي على مخاطر تسبب أحصنة طروادة
في الإصابة بالفيروس أو مشاكل أخرى. يتم تقليل المشكلة عند تنفيذ البرنامج على
خادم بعيد يقتصر على إرسال البيانات الناتجة إلى كمبيوتر المستخدم. إذا كان يجب
تنفيذ الكود على جهاز الكمبيوتر الخاص بالمستخدم ، فسيلزم اتخاذ الاحتياطات في شكل
ماسحات ضوئية للفيروسات. هناك أيضًا جهود جارية لإنشاء لغات برمجة آمنة يمكن
تفسيرها داخل غلاف وقائي يضمن عدم حدوث أي ضرر دائم لنظام المستخدم.
إذا كان لدى
المرء قدر معين من المعلومات للتواصل ، فإن إحدى المشكلات هي ما إذا كان ينبغي
تقسيمها إلى العديد من العقد الصغيرة أو الاحتفاظ بها في عدد صغير نسبيًا من العقد
الأكبر. تقرير كريتزبيرغ Kreitzberg وشنايدرمان Shneiderman [1988] عن تجربة صغيرة للتحقيق في هذه المشكلة ، حيث
قاموا بتقسيم نفس النص إما إلى 46 مقالة من بين 4 و 83 سطراً أو 5 مقالات من 104
إلى 150 سطراً في هايبرتي وكانت النتيجة أن المستخدمين يمكن أن يجيبوا
على الأسئلة بشكل أسرع في قاعدة المعلومات مع العديد من العقد الصغيرة (125 ثانية
مقابل 178 ثانية لكل إجابة). ربما يكون أحد أسباب هذه النتيجة هو أن هايبرتي هو أحد أنظمة النص التشعبي التي ترتبط
ببداية المقالة وليس بالموقع الموجود داخل المقالة حيث توجد المعلومات التي تهم
نقطة المغادرة. بسبب هذه الميزة ، يتم تشغيل هايبرتي بسهولة مع عقد صغيرة مركزة تتعامل مع
مشكلة واحدة على وجه التحديد بحيث لا يكون هناك شك حول جزء العقدة الذي يشير إليه
الارتباط.
الروابط
إن الروابط هي
الوحدة الأساسية الأخرى للنص التشعبي إلى جانب العقد. يتم تثبيت الروابط دائمًا
تقريبًا في نقطة انطلاقها لتزويد المستخدم ببعض الكائنات الصريحة لتنشيطها من أجل
متابعة الرابط. إن نتيجة تنشيط المرساة هي اتباع الرابط إلى العقدة الوجهة الخاصة
به. في أغلب الأحيان ، يأخذ هذا الإرساء شكل "القوائم المضمنة" حيث يقوم
جزء من النص الأساسي أو الرسوم بواجب مزدوج باعتباره معلومات في حد ذاته وكونه
نقطة ارتساء الارتباط. من الممكن أيضًا أن يتم إدراج روابط النص التشعبي كقوائم
منفصلة ، ولكن يبدو أن هذا بطريقة ما يقلل من "إحساس النص التشعبي"
للتصميم ، ودراسة أجراها فورا Vora [1994] وجد أن أداء المستخدمين أسرع بنسبة 26٪ عندما كانت المراسي جزءًا من
النص الرئيسي.
معظم الروابط
صريحة بمعنى أنه تم تعريفها من قبل شخص ما على أنها تربط عقدة المغادرة بعقدة
الوجهة. توفر بعض الأنظمة أيضًا روابط ضمنية ، والتي لم يتم تعريفها على هذا النحو
ولكنها تتبع خصائص مختلفة للمعلومات. مثال كلاسيكي على الروابط الضمنية هو البحث
التلقائي عن قاموس المصطلحات الممكن في أنترميديا (انظر الشكل 4.15). يوفر خادم أنترليكس ارتباطًا من أي كلمة في أي مستند أنترميديا لتعريف هذه الكلمة في القاموس ، ولكن
من الواضح أنه سيكون من السخف تخزين كل هذه الروابط بشكل صريح. فقط عندما يطلب
المستخدم تعريف كلمة ما ، يحتاج النظام إلى العثور على وجهة الارتباط.
لقد قدم نظام StrathTutor [Kibby
and Mayes 1989] نوعًا
آخر من الارتباط الضمني. لم يكن من المتوقع أن يوفر مؤلف النص التشعبي روابط بين
العقد ولكن طُلب منه بدلاً من ذلك تحديد مجموعة من السمات ذات الصلة لكل عقدة
ولمجالات الاهتمام في العقدة. كانت هذه السمات كلمات رئيسية مأخوذة من مفردات
محدودة مسبقًا. كانت مجالات الاهتمام تسمى "النقاط الساخنة" وتخدم غرضًا
مشابهًا للمراسي في أنظمة النص التشعبي الأخرى. عندما يقوم المستخدم بتنشيط نقطة
فعالة ، سيعرض النظام اهتمامات المستخدم على أنها محددة من خلال مجموعة السمات
(الكلمات الرئيسية) من العقدة الحالية ونقطة الاتصال المحددة. لذلك تم ربط StrathTutor بعقدة جديدة بها أعلى تداخل بين سماتها
الخاصة ومجموعة السمات هذه. ادعى كيبي مايس أن هذا النموذج للمواصفات الموزعة
لوصلات النص التشعبي هو الطريقة الوحيدة التي يمكن بها إدارة تأليف النصوص
التشعبية الكبيرة حقًا.
كانت روابط
سترات تيتور مثالاً
للروابط المحسوبة التي يحددها النظام أثناء قراءة القارئ ، بدلاً من تحديدها بشكل
ثابت مسبقًا بواسطة المؤلف. مثال آخر على الروابط المحسوبة هو رابط من دليل سياحي
مثل جلاسكو على الإنترنت إلى جدول القطار ، حيث يمكن للنظام أن يرتبط بقائمة
القطار التالي خارج غلاسكو لكل وجهة.
تكون لرابط النص
التشعبي له نهايتان. حتى إذا لم يكن الارتباط ثنائي الاتجاه ، فقد تظل هناك حاجة
لربطه بشكل صريح في العقدة الوجهة. تحتوي معظم أنظمة النص التشعبي القائمة على
الإطارات على روابط تشير إلى عقدة بأكملها فقط ، ولكن عندما تكون الوجهة كبيرة ،
فمن المفيد للمستخدم أن يجعل النظام يشير إلى المعلومات ذات الصلة بشكل أكثر دقة.
بشكل عام ، يجب
أن يخبر تصميم النص التشعبي المستخدم عن سبب كون وجهة الرابط مكانًا مثيرًا
للاهتمام للانتقال إليه من خلال ربطه بنقطة الانطلاق واتباع مجموعة من الاصطلاحات
الخاصة بـ "خطاب الوصول" [لانداو 1989.
بالنظر إلى أن
النص التشعبي يعتمد على روابط صريحة ، فإن المشكلة التالية هي ما إذا كان يجب جعل
نقاط الارتساء بارزة بشكل خاص على الشاشة مقارنة ببقية العقدة أم لا. في نص تشعبي
متناثر ، حيث ربما يكون أقل من 10٪ من المعلومات بمثابة نقاط ارتساء ، ربما يكون
من الجيد التأكيد بصريًا على الارتساءات. هذه مجرد حالة خاصة من المبادئ التوجيهية
العامة لواجهة المستخدم للسماح له بمعرفة الخيارات المتاحة في الحوار. في النص
التشعبي الغني ، حيث يرتبط كل شيء تقريبًا بشيء آخر ، فإن أفضل نصيحة هي إزالة أي
تركيز خاص على المراسي. بعد كل شيء ، إذا تم تمييز كل شيء ، فلن يتم تمييز أي شيء
على أي حال.
من الممكن
استخدام طريقة الدليل لتوفير التغذية الراجعة عن طريق تغيير شكل المؤشر عندما يكون
فوق مرساة . ولكن لا يزال يتعين استكمال هذه الطريقة ببعض المؤشرات المرئية لموقع
المراسي حيث سيتم تحويل المستخدمين إلى لعب كاسحة ألغام بالماوس لاكتشاف المناطق
النشطة من الشاشة.
لسوء الحظ ،
يتعارض إبراز نقاط الارتساء مع استخدام التركيز في النص الجاري. استخدم الكتاب
تقليديًا تدوينًا مطبعيًا مثل الخط المائل أو الخط الغامق للإشارة إلى أشكال
مختلفة للتأكيد أو نص ذي غرض خاص مثل الاقتباسات ، ونود الاحتفاظ بهذه الإمكانيات
لمؤلفي النص التشعبي. لكن العديد من أنظمة النص التشعبي الحالية تستخدم نفس
الترميز أو ما شابه للإشارة إلى ارتساء النص التشعبي أيضًا. لسوء الحظ ، قد يكون
هذا مربكًا جدًا للمستخدمين ما لم يستخدم المؤلف دليل أسلوب لتوفير تدوين متسق
للمراسي والتشديد على التشغيل. قد يكون أحد الحلول لهذه المشكلة هو اختراع إشارات
مطبعية خاصة لوصلات النص التشعبي إيفونسون [1989] والظهور التدريجي لاتفاقيات تدوين النص
التشعبي.
تحتوي معظم
أنظمة النص التشعبي الحالية على روابط بسيطة ، وهي مجرد وصلات بين عقدتين (وربما
نقاط ارتساء). ميزة هذا النهج هي بالطبع بساطة التأليف والقراءة. لا علاقة للروابط
إلا بمتابعتها ، ويمكن تحقيق هذا الإجراء بنقرة على الفأرة.
بدلاً من ذلك ، يمكن تمييز الارتباط بكلمات أساسية أو سمات دلالية مثل اسم
المنشئ أو تاريخ إنشائه. إن هذه العلامات تتيح لأحدهم بتقليل تعقيد النص التشعبي
من خلال استعلامات التصفية مثل ، "إظهار جميع الروابط التي تم إنشاؤها بعد 23
آذار (مارس) 1995" أو "إخفاء جميع الروابط حسب شخص ما" (إذا
اعتقدنا أن مساهمات هذا الشخص هراء) .
يمكن
أيضًا كتابة الروابط للتمييز بين الأشكال المختلفة للعلاقة بين العقد. يقدم تريج [1983] تصنيفًا مفصلًا للغاية
لـ 75 نوعًا مختلفًا من الروابط ، بما في ذلك التجريد ، والمثال ، والصياغة ،
والتطبيق ، وإعادة الكتابة ، والتبسيط ، والتفنيد ، والدعم ، والبيانات.
بالإضافة إلى الروابط القياسية التي تربط عقدتين ، تحتوي بعض أنظمة النص
التشعبي أيضًا على "روابط فائقة" لتوصيل عدد أكبر من العقد. هناك عدة
احتمالات للتعامل مع وجود مرساة واحدة: وجهات متعددة ؛ مرساة متصلة بعدة وجهات.
أبسط خيارين هما إما إظهار قائمة الروابط أو الذهاب إلى جميع الوجهات في نفس
الوقت. تستخدم أنترميديا خيار القائمة وتسمح
للمستخدمين باختيار وجهة واحدة فقط. يتطلب هذا الأسلوب أسماء جيدة للروابط أو عقد
الوجهة حتى يتمكن المستخدمون من فهم خياراتهم. لقد قام بعض مستخدمي بطاقات
الملاحظات بتطبيق نوع "رابط الدهون" الذي يفتح النوافذ على الشاشة لجميع
العقد الوجهة.
تتمثل الطريقة البديلة للتعامل مع وجهات متعددة في جعل النظام يختار للمستخدم
بطريقة ما. يمكن أن يعتمد الاختيار على نموذج النظام لاحتياجات المستخدم أو تقدير
آخر لأفضل وجهة ، أو يمكن ببساطة أن يكون عشوائيًا ، كما في المثال الذي تمت
مناقشته في نهاية الفصل 2.
الشكل 5.3. يُنشئ نظام Kon-Tiki حاشية سفلية للفيديو عن طريق تكبير صورة
الفيديو الكبيرة إلى رمز.
تمثل ارتساءات الروابط مشكلات خاصة لمعماريات النص التشعبي متعدد الطبقات مثل
النموذج المقدم في بداية هذا الفصل. من حيث المبدأ ، تنتمي الروابط إلى مستوى
الجهاز المجرد للنص التشعبي ، لكن موقع المرساة في العقدة يعتمد على بنية التخزين
لوسائط العقدة. في العقدة النصية فقط ، يمكن وصف موضع الارتساء على أنه سلسلة
فرعية ("الأحرف 25-37") ، بينما يحتاج الرابط في مقطع الفيلم إلى
معلومات السلسلة الفرعية ("إطارات الفيلم 517-724") وموقع رسومي (
"المستطيل [(10 ، 10) ؛ (20 ، 20)]"). قد يكون من الصعب تحديد بعض أدوات التثبيت الديناميكية:
لقد حاول ترميز المراسي في مقطع فيديو لمباراة كرة قدم للسماح للمستخدم بالنقر فوق
لاعب في أي وقت لربط اسم اللاعب وإحصائياته. لذلك لا يمكن معالجة الربط الفعلي
للرابط بواسطة آلة تجريد النص التشعبي. الحل في نموذج دكستر [Halasz and Schwartz
1990] هو تحديد واجهة صريحة بين آلة تجريد النص التشعبي (تسمى "طبقة
التخزين" في نموذجهم) ومستوى قاعدة البيانات (تسمى "الطبقة داخل
المكون" في نموذجهم أيضا ) هو مبين في الشكل 5.2. تصبح المراسي مؤشرات غير
مباشرة وتوفر واجهة الإرساء ترجمة بين معرفات الارتساء في آلة تجريد النص التشعبي
وقيم الارتساء الفعلية في بيانات العقدة.
لقد صمم كل من Gunnar Liestøl و Per Siljubergsåsen واجهة مستخدم لمتحف Kon-Tiki في النرويج تستخدم
طريقة شيقة لتوضيح الروابط في مواد الفيديو .يحتوي المتحف على كميات كبيرة من
الأفلام المسجلة فيما يتعلق ببعثات Thor Heyerdahl ، وكان تحدي التصميم هو كيفية
تمثيل الروابط بين مقاطع الفيديو والمعلومات الأخرى مثل النصوص والخرائط والصور.
للحصول على جهاز يشير إلى تسلسل فيديو ، استعار المصممون اصطلاحًا من إرشادات
واجهة مستخدم ماكنتوش (يستخدم مايكل أوانت 1990 المصطلح "عامية
الواجهة" لهذا المنهج لاستعارة عناصر من مفردات تفاعلية ثابتة للاستخدامات
الأخرى ، على الرغم من ارتباطها.): عند فتح المستندات أو إغلاقها على نظام
التشغيل ماك Mac ، يتم تصور العلاقة بين المستند والأيقونة التي تمثلها من خلال
مستطيل متحرك يقوم بالتكبير بين الموضعين. وبالمثل ، فإن منطقة الفيديو الرئيسية
في نظام Kon-Tiki "تزيل" الصور المصغرة التي يتم
تصغيرها من الفيديو لتستقر على الشاشة كـ "حواشي فيديو" يمكن النقر
فوقها للحصول على مزيد من المعلومات حول هذا الجزء من الفيديو.
شروح
نوع الرابط الخاص
هو رابط التعليق التوضيحي لكمية صغيرة إضافية من المعلومات. عادة ما تأخذ قراءة
التعليق التوضيحي شكل رحلة مؤقتة من المادة الأولية التي يعود إليها القارئ بعد
الانتهاء من التعليق التوضيحي. تشبه التعليقات التوضيحية إلى حد كبير الحواشي
السفلية في النص التقليدي ويمكن تنفيذها ، على سبيل المثال ، كنافذة منبثقة للدليل
تختفي بمجرد أن يحرر المستخدم زر الماوس. بدلاً من ذلك ، كما هو موضح في الشكل 5.4
، يمكن أن تكون التعليقات التوضيحية "مثبتة" عائمة (تظهر دائمًا في أشكال النوافذ الصفراء في تكريم
ملاحظات أو يمكن الوصول إليها من خلال رمز.
الشكل 5.4.
استخدام الملاحظات اللاصقة لتمثيل التعليقات التوضيحية. لإضافة تعليق توضيحي ،
يمزق المستخدم ملاحظة لاصقة من الكومة إلى اليمين ويضعها على الكائن الذي يحتاج
إلى تعليق. في كل مرة يتم فيها عرض هذا الكائن في المستقبل ، ستكون الملاحظة
اللاصقة موجودة (حتى يزيلها المستخدم).
يمكن لكتّاب
النص التشعبي استخدام التعليقات التوضيحية بنفس الطريقة التي يستخدمون بها الحواشي
السفلية في النص التقليدي باستثناء أن التعليقات التوضيحية للنص التشعبي أقل
تدخلاً لأنها لا تظهر إلا إذا طلبها القارئ. وبالتالي، فإن الاستخدام الأكثر إثارة
للاهتمام للتعليقات التوضيحية في النص التشعبي هو للقراء. تسمح العديد من أنظمة
النص التشعبي للقراء بإضافة روابط جديدة إلى المادة الأولية حتى لو لم تسمح دائمًا
للقارئ بتغيير العقد والروابط الأصلية ، ويمكن للقراء استخدام هذه التسهيلات
لتخصيص مساحة المعلومات وفقًا لاحتياجاتهم الخاصة. على سبيل المثال ، قد يرغب قراء
الكتيب الطبي للنص التشعبي [Frisse 1988a] في استكمال الوصف العام لعقار ما في الكتيب بتعليق يوضح اسم العلامة
التجارية الموصوف عادة في مستشفياتهم.
توفر خدمة InterNote داخل IRIS أنترميديا وسيلة سريعة للتعليق على المستندات من
أي نوع. يحتوي الإطار العلوي لنافذة الملاحظة (على اليمين) على اقتراح المعلق
بتغيير الصياغة. يوضح الإطار السفلي سبب الاقتراح. قد يختار مؤلف مستند
"مقدمة الأنابيب الدقيقة" الآن دمج التغيير عن طريق تحديد العلامة في أي
من طرفي الرابط الذي يربط الملاحظة بالمستند واختيار أمر "دمج التعليقات
التوضيحية". من قبل جامعة براون ، أعيد طبعها بإذن.
أحد الأنظمة
التي توفر إمكانية التعليق التوضيحي هو أنترميديا ، كما هو موضح في الشكل 5.5. لا تسمح الأنظمة
الأخرى مثل هايبرتي للقراء بالتعليق عليها ولكنها تحتفظ
بجميع الخيارات لتغيير مساحة المعلومات للمؤلفين. في هذه الحالة ، فإن أحد أسباب رفض حق
القراء في إضافة المعلومات هو أن النظام قد تم تصميمه في الأصل لأنظمة معلومات
المتاحف حيث قد لا يرغب المرء في الواقع في قيام مستخدمين عشوائيين بتغيير محتوى
النص التشعبي. سبب آخر هو الرغبة في واجهة مستخدم بسيطة للغاية لـ هايبرتي: وجود عدد أقل من الخيارات المتاحة
للمستخدم يعني أن هناك القليل لتعلمه.
أخيرًا ، يمكن
للمستخدمين إضافة تعليق توضيحي للنص التشعبي بإضافة أشكال مختلفة من التمييز مثل استخدام ألوان مختلفة للتأكيد على
نص ذي أهمية خاصة لمستخدم معين أحد المنتجات التي تدعم التمييز هو فوليو. على الرغم من أن التمييز الفردي لا
يشكل حقًا شكلاً من أشكال الرابط ، يمكن استخدام المعلومات التي تم جمعها من
التمييز (ربما من عدة مستخدمين) في تصفية النص التشعبي لإظهار المعلومات المهمة
فقط أو للبحث في النص التشعبي عن العقد التي تم تمييزها مسبقًا.
محركات النص
الفائق
العديد من أنظمة
النص التشعبي هي في الحقيقة محركات نص تشعبي يمكنها عرض العديد من مستندات النص
التشعبي المختلفة. لقد تم تصميم أنظمة النص التشعبي الأخرى خصيصًا لعرض مستند واحد
، وبالتالي يمكن أن توفر تفاعلًا أكثر ثراءً فيما يتعلق بمحتوى ذلك المستند المحدد.
إلى جانب الميزة
الواضحة المتمثلة في عدم الاضطرار إلى برمجة تطبيق جديد ، فإن استخدام محركات النص
التشعبي له أيضًا ميزة أنها توفر واجهة مستخدم مشتركة للعديد من المستندات. يمكن
للمستخدمين الذين يعرفون بالفعل كيفية استخدام الدليل ، على سبيل المثال ، البدء
فورًا في قراءة مستند الدليل التالي دون أي تدريب.
بعض أنظمة النص
التشعبي مثل
Guide و Hyperties هي محركات بسيطة حقًا. يقوم المؤلف فقط
بإفراغ النص فيها وسيهتم بكل شيء آخر. على سبيل المثال ، تظهر دائمًا نافذة منبثقة
في "الدليل" في الزاوية اليمنى العلوية من الشاشة. لا يتعين على المؤلف
اتخاذ أي قرارات لواجهة المستخدم باستثناء بعض تفاصيل التنسيق ذات المستوى المنخفض
مثل مكان فصل الفقرات. بالنظر إلى أن معظم الناس هم من مصممي واجهة المستخدم ، فقد
يكون هذا ميزة جيدة.
تسمح محركات
النص التشعبي الأخرى لمصمم النص التشعبي بتخصيص واجهة المستخدم لمستند ضمن إطار
عمل معين.
هايبركارد هو
مثال رئيسي لمثل هذا النظام لأنه يسمح للمصمم بتحريك الحقول وإضافة جميع أنواع
رسومات الخلفية. وبالتالي فإن المصمم مقيد بإطار هايبركارد الأساسي لكونه نظامًا قائمًا على إطار
مع بطاقة أحادية اللون ذات حجم ثابت. تتوفر بعض تسهيلات واجهة المستخدم في نوع من
مجموعة أدوات البناء للمصمم ، ولكن لا يمكن إضافة تقنيات تفاعل جديدة.
في الواقع ، من
الممكن توسيع إطار عمل هايبركارد ، ولكن فقط من خلال ترك لغة البرمجة
هايبرتالك
HyperTalk المضمنة خلفها وبرمجة ما يسمى بالأوامر الخارجية (XCMDs) بلغة برمجة تقليدية مثل C. ، ولكنه يوفر أيضًا
العديد من الاحتمالات الأبسط لمصممي النص التشعبي لتخصيص واجهاتهم وفقًا لاحتياجات
مستنداتهم الفردية.
لا تسمح هايبركارد لمؤلفي النص التشعبي فقط بتخصيص واجهة
المستخدم لوثائق النص التشعبي الخاصة بهم ، بل تتطلب منهم القيام بذلك. وهو لا
يحتوي
على تصميم مستند
افتراضي ولكن من حيث المبدأ يقدم للمؤلف شاشة فارغة حيث يكون من الضروري تحديد
موضع الحقول النصية قبل كتابة أي شيء.
أخيرًا ، يتم
تنفيذ بعض مستندات النص التشعبي كتطبيقات متخصصة. وتشمل هذه أقراص دريكسيل (انظر
الشكل 1.3) و بالينكو (انظر الفصل 4). يمكن لهذه التطبيقات المتخصصة تحقيق تطابق
تام بين نظام النص التشعبي واحتياجات المستند. على سبيل المثال ، بالنسبة للأطفال
الذين يستكشفون الغابة المكسيكية ، تتمتع بالانك Palenque بميزات خاصة في شكل شخصية تلفزيونية
مصورة تنبثق من وقت لآخر لتقديم اكتشافات جديدة. لقد أضاف مصممو بالانك هذه الشخصية الإرشادية إلى الواجهة بعد
إجراء مقابلات مع الأطفال حول كيف يرغبون في استكشاف أطلال مايا في الغابة المكسيكية.
وهم بالتأكيد لا يريدون فعل ذلك بمفردهم.
فتح النص
التشعبي
يعمل معظم
الباحثين التشعبيين مع أنظمة مصممة خصيصا لأنظمة النص التشعبي. معظم المستخدمين،
من ناحية أخرى، يعملون مع الأنظمة التي تساعدهم في أداء جميع أنواع المهام، من
حسابات جدول البيانات البسيطة إلى العمل المعقد خاص بالمجال مثل تحليل البيانات
الزلزالية من مواقع استكشاف النفط. من المؤكد أن الصراع بين هذين النظريين على
العالم سيحلون بالتأكيد من خلال الحصول على غالبية المستخدمين الذين يحولون إلى
استخدام أداة التشعبية والتخلي عن أدوات البرامج الأخرى الخاصة بهم. يسمى منهج
أكثر وعدا النص التشعبي المفتوح وهو AIME في دمج قدرات النص التشعبي مع بقية بيئة برامج المستخدم. يتمثل
المفهوم الرئيسي في السماح لكل تطبيق بالعمل مع البيانات التي يتم تحسينها ولديها
طريقة للتواصل مع آلية تشطيبية مشتركة تعالج الروابط عبر التطبيقات (وربما حتى
داخل التطبيقات).
يحدد أنجلبرت [1990] ثلاثة مستويات من قابلية التشغيل
البيني من أجل النصاب النصائي المفتوح: قابلية التشغيل البيني في مساحة المعلومات
الفردية (على سبيل المثال، الرتبية من قائمة الهاتف إلى مجموعة من الملاحظات)،
قابلية التشغيل البيني في مساحة معلومات المجموعة (على سبيل المثال، من مساحة ملف
شخص واحد إلى الزميل)، وقابلية التشغيل البيني عبر المجموعات (على سبيل المثال،
يربط من منظمة التسويق إلى منظمات التصنيع أو تطوير المنتجات). الحالة اللاحقة
مثال على قابلية التشغيل البيني عبر مجال المعرفة لأن المجموعات المختلفة من
المرجح أن تستخدم تطبيقات مختلفة للغاية لعملها المتخصص.
هذا القسم سيقلق
في الغالب من المستوى الأول من التشغيل البيني: القدرة على الارتباط بين كائنات
المعلومات في تطبيقات مختلفة. مساحة المستويات المتبقية في طبيعة العمل التعاوني
الذي يدعمه الكمبيوتر وإشراك برامج الشبكات والمجموعات إلى حد كبير مما تنطوي على
النص التشعبي على هذا النحو. يمكن دعم التشغيل البيني عبر المجموعة والشركات جزئيا
من قبل الويب العالمية وآليات الإنترنت الأخرى التي نوقشت في الفصل.
الطريقة
النموذجية لتزويد النص التشعبي المفتوح هي إزالة مستوى النص التشعبي من التطبيقات
وتوفير خدمة نصية واحدة لكل شيء على كمبيوتر المستخدم. ستحتاج خدمة النص التشعبي
إلى تتبع المعلومات التي يتم نقلها حيث يتم نقل المعلومات، ويمكنها بعد ذلك
التواصل مع التطبيقات باستخدام رسالة تمر بالإشارة، على سبيل المثال، يجب أن تفتح
لها وثيقة معينة وانتقل إليها للحصول على بعض الإيجار. يتم تخزين معلومات الارتباط
عادة في قاعدة بيانات منفصلة عن المستندات الأساسية ويتم صيانتها بواسطة خدمة النص
التشعبي بدلا من تطبيقات المستخدم. أسباب الفصل هذا هو أن معلومات الارتباط قد
توجد في صيغ غير متوافقة مع بعض التطبيقات وأن المرء لا يريد المستخدم أن يرى
هياكل البيانات الداخلية هذه.
مشروع ميكروكوسم microcosm ديفيس وآخرون. 1992، 1994؛ حدد ثلاث
درجات من الدعم للتطبيقات النصية المفتوحة النص التشعبي: تدرك تماما، وإدراكها جزئي،
وتطبيقات غير مدركة، حيث يشير مصطلح "علم" إلى المدى الذي يعرف التطبيق
عن النص التشعبي وإمكانية الروابط بينه البيانات والتطبيقات الأخرى. يوضح الشكل
5.6 تطبيقات طباعة مصغرة بالكامل والطريقة التي تدعم ميكروكوسم الروابط بينها، على سبيل المثال، تطبيق
الرسومات ومعالج النصوص. عندما يفتح تطبيق يدرك بالكامل وثيقة، يقوم بإرسال رسالة
لمعرفة ما إذا كان المستند يحتوي على أي روابط، وإذا كان الأمر كذلك، فيمكنه عرض
المراسين كأزرار وجعل واجهة المستخدم أكثر جاذبية مع استخدامها. عندما يقوم
المستخدم بتنشيط مرساة، سيعرف التطبيق المعرف بالكامل أنه يجب اتباع ارتباط
التشعبي، ويمكنه أن يسأل خدمة ميكروكوسم للقيام به. نظرا لأن المستخدم يقوم
بتحرير المعلومات الموجودة في المستند المصدر، فيمكن للتطبيق المعرف بالكامل إبلاغ ميكروكوسم إذا تمت إضافة مراسيات الارتباط،
وانتقلت، ويمكن حذف الذهب، ويمكن الحصول على ميكروكوسم المعلومات اللازمة للحفاظ على قاعدة
بيانات الارتباط.
الشكل 5.6.
مشاهدي العالم المصغر يدركون تمامًا. يُظهر عارض الصور جزءًا من خريطة المدينة مع "أزرار"
مفروضة بشكل كبير أعلى بيانات الصورة النقطية لأغراض العرض. يعتمد عارض النص على RTF (تنسيق نص منسق). تم
إطلاق هؤلاء المشاهدين كنتيجة لاختيار المستخدم للعناصر من مربع الروابط المتاحة ،
والذي يعرض الروابط المتاحة من مرساة المصدر .
تكمن المشكلة
الرئيسية في التطبيقات المدركة تمامًا في أنه يجب تخصيصها لتناسب نموذج النص
التشعبي المفتوح المعين الذي يستخدمه المستخدم. في هذه الحالة ، تم استخدام ميكروكوسم ، ولكن توجد العديد من
أنظمة النص التشعبي المفتوحة الأخرى (ويمكن توقع المزيد في المستقبل) ، لذلك ليس
من الواقعي توقع تعديل جميع التطبيقات للعمل مع جميع خدمات النص التشعبي.
الشكل 5.7. يعمل Microcosm
Universal Viewer أعلى
برنامج تقويم ميكروسوفت وهو غير مدرك تمامًا للعالم المصغر.
يعمل
Universal Viewer كقطعة
بين تطبيقات ميكروكوسم والتطبيقات غير المدركة ، ويعرض القوائم
وأي أزرار ذات صلة على شريط عنوان التطبيق ، ويسمح للمستخدم بإجراء التحديدات داخل
التطبيق لإنشاء الروابط أو متابعتها.
المشاهدون
المدركون جزئيًا هم أولئك الذين لديهم نوع من قابلية البرمجة التي تسمح لهم
بالتوسع بقائمة إجراءات مع الأوامر اللازمة للتفاعل مع خدمة النص التشعبي. تأتي
العديد من التطبيقات الشائعة ، بما في ذلك ميكروسوفت
وورد ومعظم
حزم جداول البيانات ، مزودة بميزة البرمجة النصية مثل
Visual Basic التي يمكن استخدامها لهذا الغرض. لا
يسمح المشاهدون المدركون جزئيًا عادةً بوضع علامات على الروابط كأزرار نظرًا لأنها
تتحكم في واجهة المستخدم الخاصة بهم والطريقة التي يريدون بها إظهار بياناتهم على
الشاشة. وبالتالي ، يتم إهمال المستخدمين لاختيار الكائنات في التطبيق باستخدام
آلية التحديد العادية الخاصة به ثم إصدار أوامر النص التشعبي مثل "Follow
Link" من ميكروكوسم.
في تطبيق غير
مدرك ، لا يمكن حتى تمثيل أوامر النص التشعبي كأوامر قائمة ولكن يجب توفيرها من
خلال تعديل نظام النافذة أو مستوى آخر من نظام التشغيل الأساسي. يوضح الشكل 5.7
كيف يمكن لـ
Microcosm Universal Viewer إرفاق نفسه بشريط عنوان النافذة وبالتالي يمكن
الوصول إليه في سياق التطبيق الذي يتم تشغيله في تلك النافذة على الرغم من أن
التطبيق لا يعرف شيئًا عن ميكروكوسم . عندما يتم تنشيط هذه الخدمة من خلال القائمة الموجودة على شريط
العنوان ، فإنها تقرأ التحديد الحالي في النافذة وتقارنها بقاعدة بيانات الارتساء
أو كائنات النص التشعبي الأخرى الخاصة بها ، وبعد ذلك يمكن لـ
ميكروكوسم اتخاذ
الإجراء المناسب (على سبيل المثال ، فتح نافذة أخرى باستخدام وجهة ارتباط ، حتى لو
كانت تلك الوجهة في تطبيق آخر).
لن تعرف
التطبيقات التي تدرك خدمة النص التشعبي جزئيًا أو لا تعلم بها إبلاغ خدمة النص
التشعبي حيث يقوم المستخدم بتحرير المعلومات التي قد تحتوي على روابط نص تشعبي.
لذلك ، ستحتاج خدمة النص التشعبي إلى آلية أخرى لتحديث قاعدة بيانات الارتباط
الخاصة بها لضمان تكامل الارتباط. لا يمكن حل هذه المشكلة بالكامل في جميع الحالات
نظرًا لأن المستخدمين ربما قاموا بتعديل المستند كثيرًا للسماح بتحديد مواقع
ارتساء النص التشعبي. تذكر أنه لا يُسمح عادةً للمستند نفسه باحتواء أي علامات
ارتساء من أجل الحفاظ على توافقه مع هياكل بيانات التطبيق الأصلية. الحل النموذجي
لمشكلة المراسي المتحركة هو تذكر موقع الارتساء قبل تحرير المستند ثم البحث عن
موقع أقرب ما يمكن باستخدام نفس النص (أو البيانات الأخرى) مثل المرساة. بالطبع ،
إذا قام المستخدم بتحرير المرساة نفسها أو إذا تم نقلها كثيرًا ، فسيفشل هذا النهج.
دمج أفكار النص
التشعبي في بيئات أخرى
الملاحظة
المعمارية النهائية هي أن النص التشعبي لا يحتاج حقًا إلى تضمين مجموعة كاملة من
المميزات. من الممكن استخدام عدد أقل من الأفكار من النص التشعبي ودمجها في أنظمة
الكمبيوتر الأخرى دون جعلها أنظمة نص تشعبي كاملة .
الشكل 5.8. قائمة
هايبرفيو
HyperView المنبثقة
من برنامج الإحصاء Data Desk Professional. ينظر المستخدم إلى جدول يحتوي على
تحليل التباين وقد أشار إلى اهتمام خاص بأحد المتغيرات. تسمح القائمة المنبثقة
الآن للمستخدم بفتح النوافذ مع تحليلات ورسوم بيانية إحصائية إضافية ذات صلة خاصة
في ظل هذا السياق.
على سبيل المثال
، تحتوي حزمة الإحصائيات Data Desk Professional من Odesta على مرفق يسمى هايبرفيو والذي يظهر في الشكل 5.8. تسمح هذا
الأخير للمستخدم
بالوصول المباشر من تحليل إحصائي واحد إلى عدد صغير من التحليلات الأخرى ذات الصلة
بالنظر إلى السياق الحالي للمستخدم. استنادًا إلى معرفته بالإحصاءات ،
"يعرف" البرنامج ما هي التحليلات الإحصائية الأخرى التي يريدها الأشخاص
عادةً إذا كان لديهم اهتمام بالمتغير المحدد في السياق المحدد في الجدول الحالي.
نتيجة الاختيار
من القائمة في الشكل 5.8 هي الانتقال إلى نافذة جديدة تحتوي على التحليل المطلوب
أو الرسم البياني. بالطبع يجب على النظام حساب محتوى تلك النافذة أولاً ، لذا فإن
النتيجة الحقيقية هي فقط تنشيط حزمة الإحصائيات بأمر معين ومجموعة معينة من
المعلمات. ولكن بالنسبة للمستخدم ، يبدو الأمر وكأنه تنقل يشبه النص التشعبي بين
النوافذ المتصلة. إنها أيضًا ميزة عملية رائعة لمنشأة هايبرفيو أنها تقلل من حاجة المستخدم للعثور
على الأمر الصحيح بين مجموعة كبيرة من التحليلات الإحصائية المتاحة في البرنامج
وأنه يحدد تلقائيًا المعلمات الصحيحة.
0 التعليقات:
إرسال تعليق