У зв’язку з відсутністю опису сайту на основі публікацій, у нас не було іншого вибору як самим протестувати знайдені сайти та знайти в них спільні елементи, які і будуть вважатися рекомендованими до використання. Почнемо з головної сторінки. На кожному сайті, якщо характеризувати зверху вниз, була присутня спочатку картинка-заголовок сайту, що містила в собі URL-адресу та повну назву сайту. Далі сторінка розбивалася умовно на три поля, де ліворуч та праворуч містилася загальна інформація, а по центу йшло саме тематичне наповнення (текст та ілюстрації). Відрізняються наші два сайти тим, що на MyRobot.ru до загальної інформації відносилися навігація, меню, дружні сайти, голосування та реклама, а на http://www.rtc.ru відносилися короткі помітки про статті, що вже зістарилися настільки, щоб їх не тримати по центру, але ще залишаються відносно свіжими. Усі питання, пов’язані з інформацією про проект та ін., в них вирішує меню, яка йде одразу ж після картинки-заголовка. Недоліки, які одразу можна охарактеризувати, на http://www.rtc.ru це занадто мілкий шрифт, що значно погіршує читання, та одноманітні описання подій, що значно погіршує сприйняття прочитаного. Також одразу кидається в очі складні формулювання та словосполучення, що говорить про високу кваліфікацію авторів матеріалу, порівняно з простенькими викладеним матеріалом на MyRobot.ru, але з іншого боку цільова аудиторія легшого матеріалу потенціально більша, ніж складного. Розглядаючи та порівнюючи їх, ми зрозуміли, що не зможемо повноцінно відфільтрувати та проаналізувати матеріал, викладений там. Подальший розгляд дав також спільний елемент – меню нікуди не зникало і було присутнє на кожній сторінці. Як користувач мушу визнати це дуже зручно і значно економить час. Щодо інформаційного наповнення, то на обох сайтах переважав текст та ілюстрації, лише на MyRobot.ru було знайдено відео. Також спільним елементом можна вважати пошук, що був присутній на обох сайтах. Доцільність його використання визначити важко, адже неможливо прорахувати усі можливі варіанти його використання та ін. Посилання на головну сторінку в пункті меню MyRobot.ru виявилася напрочуд корисна, адже на головній сторінці знаходяться посилання на дружні сайти, голосування та ін. Голосування було присутнє лише на MyRobot.ru, але воно здалося нам перспективним для розробки, у зв’язку з тим, що його можна використовувати для моніторингу системи.
2. ІНФОРМАЦІЙНА МОДЕЛЬ ГІПЕРТЕКСТУ
Розглядаючи цей розділ, потрібно враховувати особливості та потреби нашої системи, а тому потрібний попередній її аналіз, тобто потрібно виявити найважливіші аспекти побудови інформаційної моделі гіпермедіа системи. Також потрібно урахувати пріоритет характеристик основної та побічної ідеї, тому що інколи потрібно вибирати щось одне із двох протилежних. Наведені нище базові характеристики вузлів та зв’язків містять в собі пояснення доцільності вибору, основані саме на аналізі відповідності можливих характеристик найважливішим аспектам:
говорячи про тип інформації, який буде зберігатися в вузлах, ми можемо сказати наступне: для виконання основного завдання(теоретичної частини) нам однозначно потрібен текст як основний наповнювач цієї частини сайту, але в зв’язку із складністю матеріалу, необізнаністю середньостатистичного користувача із тематикою сайту та можливістю неповноцінного сприйняття ми просто вимушені використовувати графіку. Відео для цієї частини недоречно, тому що воно в даному випадку може грати лише роль «обгортки цукерки» і ніякої практичної користі не дасть, але значно повищить складність розробки та буде перевантажувати систему, що недопустимо. Звук використовувати теж недоречно у зв’язку з повною відсутністю застосування. Для реалізації додаткової частини (практичної) нам потрібен також текст, але не як основний наповнювач, а як короткий опис до відеоматеріалів. Відео для цієї частини доречно, тому що еквівалентний йому за змістовністю обсяг графіки бути ускладнювати розуміння і зменшувати інтерес до системи, а використання все покращить та збільшить. В цьому випадку користі від нього більше ніж проблем, пов’язаних, з його використанням, тому воно застосовується. Звук тут теж використовується, як частина відео і ніяк більше. Тобто ми маємо в сумі текст, графіку, відео та звук (як частина відео);
говорячи про місткість вузлів, можна почати з основної частини, а саме з того, що складну інформацію краще засвоювати невеликими порціями, ретельно перемішуючи її з графікою, що не тільки утримає користувача, а й підніме його рівень засвоєння матеріалу. У цьому випадку можна додати, що навіть якщо нашою інформацією не зацікавляться, то є можливість затримати, а надалі і зацікавити викладеними гарними ілюстраціями та поясненнями до них(особливо якщо ми маємо справу із молодшим поколінням). Щодо практичної частини, то сам факт використання відео говорить про середню місткість вузлів. Чому не велику? Тому що практичні приклади будуть лише до окремих розділів і лише для кожного. Тобто ми маємо більшість вузлів малого об’єму та меншість середнього.
говорячи про потужність зв’язків, можна з упевненістю стверджувати, що на нашому сайті будуть переважати зв’язки потужністю один за винятком деяких випадків, де будуть присутні зв’язки потужністю два (наприклад, посилання на головну сторінку, де буде один пункт призначення, але багато пунктів відправки і т.п.). До цього можна дійти опираючись на той факт, що головне меню та меню структурного підрозділу, в якому ви знаходитися завжди будуть з вами, що виключає потрібність у декількох пунктах з будь-якої сторони: сторони призначення або сторони відправки, доречно повторитися і сказати, що так зроблено скрізь,тобто додаткові пояснення непотрібні;
говорячи про спрямованість зв’язків у основній частині, то доцільніше було б використовувати односпрямовані зв’язки, так як не потрібно забувати про можливості браузера, та те, що зв’язки подвійного спрямування майже не використовують (у стандартних випадках) - користувачу більш зручніше використовувати браузер для реверсу, ніж розбиратися з особливостями вашої системи та її можливостями. Звичайно можливі і інші варіанти - особливості системи, які проявляться пізніше, завдяки яким будуть внесені зміни в цей пункт, але про це вже буде сказано у висновках, а щодо практичної, то у нас немає сенсу використовувати зв’язки подвійного спрямування через простоту системи у цьому випадку, тобто однозначно односпрямовані.
говорячи про якірний механізм зв’язків, можна сказати таке: так як весь викладений матеріал – авторський, тобто користувач не може додати на сайт, щось своє, то потреби у динамічному якірному механізмі просто немає, як для основної так і для додаткової частини, тому загальний якірний механізм;.
говорячи про типи зв’язків можна однозначно сказати що будуть присутні усі з них: структурні, звичайні посилання між, наприклад, меню, посилкові, наприклад посилання на дружні сайти та звичайно асоціативні, тобто повний набір усіх типів зв’язків.
Отримавши базові характеристики, ми можемо приступати до аналізу. Що ж ми бачимо. Більшість характеристик мають початковий характер, тобто це вказує на клієнт-серверну модель. Але присутні деякі елементи, що говорять про несуттєве ускладнення системи, а це вже рівень абстрактної машини гіпертексту. То що обрати? Звернемося до формулювань. З формулювання правила АМГ ми можемо зробити висновок, що вона використовується для глибшої взаємодії зв’язків і вузлів. У нас є складні елементи, які могли б претендувати на детальнішу розробку, але потрібно вибирати оптимальнішу модель. Зважаючи на те, що ми маємо не велику групу складних елементів можна дійти висновку, що їх краще опрацювати на клієнт-серверному рівні, чим повністю перейти на рівень абстрактної машини гіпертексту. З усього вище перекисленого робимо висновок – Клієнт-серверна модель.
3. ПРОЕКТУВАННЯ ГІПЕРМЕДІА СИСТЕМИ
Розглядаючи цей розділ, слід не забувати про те що було описано в розділі «Огляд існуючих аналогів», адже багато інформації, про те що можна зробити, та обґрунтування знаходиться саме в цьому розділі. Також, в деяких випадках нам доведеться звертатися і до розділу «Інформаційна модель гіпертексту», щоб вибрати щось єдине із еквівалентних рішень. Почнемо з функціональних характеристик:
Подання (Presentation) – одна із головних характеристик, так як застосовується в будь-якій гіпермедіа системі. Тут можна цей пункт розділити на дві складові: на подання головної сторінки та інших сторінок. Головна сторінка буде суцільно вкрита графікою, а саме ілюстраціями, що характеризують певні статті, новини та іншу викладену інформацію, з короткими описаннями до неї. Ось тут потрібно звернутися до розділу «Інформаційна модель гіпертексту», тому що ми вибрали малі та середні вузли, тому ніякого відео на головній сторінці бути не може взагалі, так як це суперечить вибраній моделі системи. Інші сторінки будуть найрізноманітніші, але тут доцільно було б розподілити їх на складові частини для кращої систематизації та виявлення загальних рис. Ось тут потрібно звернутися до розділу «Огляд існуючих аналогів», так як там ми виявили загальні риси опрацьованих нами сайтів та вирішили доцільним використовувати їх у нашій системі. Загальною рисою усіх сторінок, незалежно від розділу чи функціональності є загальне меню, яке ніколи не зникає і було визначено як основний елемент навігації, про що ще буде мова далі. Основну частину (теоретичну) буде викладено поетапно, і спільною частиною для неї (для усіх сторінок крім головної) буде перехід на головну сторінку, знову ж таки пригадаємо висновки розділу «Огляд існуючих аналогів». Основна частина буде подаватися як текст з ілюстраціями для пояснення, загальна структура сторінки змінюватися не буде, лише заповнення. Практична частина буде подаватися як відео та описання до нього, якщо пригадати попередні обидва розділи, то він буде один на дану сторінку, при цьому дістатися до нього можна буде лише через теоретичну частину.