Ефективний або ефектний? Майстер-клас зі створення дизайну сайту. Частина I


 
Ефективний або ефектний?
 
Ясна річ, від будь-якого сайту хочеться і першого, і другого. Деяким вдається цього досягти, деяким ні. У форматі нема кого майстер-класу я постараюся пояснити як отримати і те саме перше, і друге, і навіть дещо на десерт для деякого усередненого проекту. У нашому випадку цим проектом стане редизайн nginx.org .
 
Який сайт можна назвати ефективним? Для мене це той, який вирішує поставлені завдання, сприяє досягненню поставлених цілей. Незважаючи на те, що звучить це вкрай шаблонно і бюрократично — застосовно це абсолютно до будь-якого проекту. Багато в чому, ефективність сайту закладається на етапі аналізу і прототипування. Про це я і розповім в першій частині.
 
 Огляд пацієнта
 Цілі і завдання
Відразу хочу попередити, я не знаю які цілі і завдання ставили автори nginx.org . Я придумав свої — наскільки вони близькі до реальності не настільки важливо, нам просто потрібно з чимось працювати.
 
Отже, завдання будуть цілком собі тривіальними:
 
 
     
  • Поширення та підтримка основного продукту.
  •  
  • Просування комерційного пакету.
  •  
Цілі не менш очевидні: більше інсталл першого, більше передплатників другого. І так, невеличкий відступ — забудемо про існування nginx.com (з ефективністю там все добре, питання може викликати тільки ефектність).
 
Після постановки цілей і завдань, варто поміркувати про те, що ми повинні розповісти і показати відвідувачеві. Тобто, почати думати про текстах. Так, це потрібно робити зараз, а не так, як роблять в 99% випадків — перед самим запуском. Зовсім необов'язково готувати фінальні тексти — досить визначити тези та приблизний обсяг.
 
У нашому випадку вже все готово, тому переходимо до наступного кроку.
 
 Структура сайту
Наступний крок — опрацювання структури сайту. Побуду капітаном: вона повинна бути максимально простою, зрозумілою і логічною.
 
Так як ми займаємося редизайном, завдання спрощується — у нас вже є готова структура, представлена ​​в головному меню (за винятком вкладеності в розділах "documentation" і "faq").
 Ð¡Ñ‚руктура сайта
 
Давайте згрупуємо посилання за змістом, щоб зменшити кількість розділів першого рівня:
 
 
     
  • По суті, група посилань ("faq", "links", "books", "support") допомагають в освоєнні продукту, їх можна об'єднати в загальну групу, назвемо її "Help". Крім того, об'єднаємо посилання, що ведуть на зовнішні ресурси ("trac", "wiki", "twitter", "nginx.com", "blog") з вищезазначеним розділом "links". Забігаючи вперед — посилання на зовнішні ресурси ми продублюємо в підвалі сторінки. Так що вони не загубляться, і доступ до них по раніше буде можливий з будь-якої сторінки сайту.
  •  
  • Згрупуємо розділи ("security advisories", "pgp keys") в один, назвемо його "Patches". Тут можу помилятися: об'єднуючи ці посилання, я розраховую на те, що ті самі ключі, окрім як для установки патчів, ніде не використовуються. Якщо це не так — тоді групувати розділи не варто.
  •  
  • Вибір мови замінимо на щось більш компактне, швидше за все на, що випадає.
  •  
 
У підсумку, структура набуває такого вигляду (без урахування вкладеності в розділах "Documentation" і "FAQ"):
 
 
     
  • Download
  •  
  • About
  •  
  • Documentation
  •  
  • Help
       
    • FAQ
    •  
    • Links

    •  
    • Books
    •  
    • Support
    •  
  •  
  • News
  •  
  • Patches
       
    • Security advisories
    •  
    • PGP keys

    •  
  •  
  • Donation
  •  
 
Розділи виставлені в порядку пріоритету. Перший рівень сформує головне меню сайту. Існує рекомендація — в головному меню має бути не більше семи пунктів. У нас вийшло якраз сім, що набагато краще, ніж пара десятків посилань, які були там спочатку.
 
Переходимо до аналізу поточного сайту.
 
 Головна сторінка
 Ð“лавная страница
 
Як ні яка інша, головна сторінка визначає наскільки ефективним і ефектним буде сайт. Вміст головної сторінки nginx.org — рекламний блок і новинна стрічка. Цього недостатньо, щоб дизайн сприяв досягненню поставлених цілей.
 
Найбільша проблема поточного сайту — головна сторінка не просувається продукт — дивлячись на неї, неможливо зрозуміти, що за софт перед вами! Щоб виправити це, досить розмістити ємний заголовок, короткий опис ключових особливостей продукту і помітну посилання на докладний опис.
 
На будь-якому сайті, що представляє якої-небудь софт, доступний для завантаження, просто життєво необхідна наявність великої і помітною кнопки скачування цього самого софта. Логічно?
 
Повернемося до поточного контенту головної сторінки. Рекламний блок в тому чи іншому вигляді ми залишимо, втім як і новини. Але кількість останніх однозначно варто скоротити і дати посилання на повну новинну стрічку.
 
Так як ми згрупували посилання в загальні розділи, в підвалі сторінки варто продублювати всю навігацію в розгорнутому вигляді. Там же додатково розмістимо кнопку "Donate" — користувачі звикли бачити її в підвалі. А слідувати звичкам користувачів — хороша практика.
 
 Сторінка завантаження (Download)
 Ð¡Ñ‚раница загрузки (Download)
 
Перед нами специфічний софт, тому сторінка завантаження зустрічає нас кількома десятками посилань. Але не всі посилання однаково корисні. Припускаю, що в 95% випадків посетітетей цікавить "Mainline version" і "Stable version" — на них і варто зробити основний акцент. Як мінімум, додамо помітні кнопки завантаження. А також вкажемо розмір і формат скачуваних файлів — це вважається правилом хорошого тону.
 
Через велику кількість посилань, блок "Legacy versions" бере на себе занадто багато уваги, хоча він тут найменш важливий. Перемістимо його в кінець сторінки, оформимо у вигляді таблиці і винесемо повторювані слова у вигляді заголовків колонок.
 
 Про продукт (About)
 Ðž продукте (About)
 
Винесемо зміст в «прікленную» до екрану колонку — набагато зручніше і наочніше бачити його постійно. Щоб було зрозуміло, що я маю на увазі — подивіться як реалізований Affix в Bootstrap.
 
 Affix
 
Чим він такий хороший?
 
 
     
  • Зміст винесено в ту саму «прікленную» до екрану колонку.
  •  
  • При прокручуванні сторінки виділяється соответвуют розділ у змісті.
  •  
  • При кліці на який-небудь пункт сторінка промотувати до відповідного заголовку.
  •  
  • Зміст може бути багаторівневим.
  •  
 
Все це дуже зручно у використанні, тому варто реалізувати щось подібне в нашому проекті.
 
 Документація (Documentation)
 Ð”окументация (Documentation)
 
Сформуємо зміст із заголовків "Introduction", "How-To", "Development" і "Modules reference". Винесемо його в окрему колонку в правій частині сторінки, аналогічну описаної вище для сторінки "About". Не забуваємо, що на внутрішніх сторінках також є зміст. Оформимо його таким же чином, але до всього іншого додамо посилання для повернення до основного змісту документації.
 
 Допомога (Help)
Нагадаю, що при формуванні нової структури ми об'єднали чотири розділи ("faq", "links", "books", "support") в один — "Help". Також в розділ "links" ми включили посилання на зовнішні ресурси.
 
 

Часті питання (FAQ)

 Ð§Ð°ÑÑ‚о задаваемые вопросы (FAQ)
 
Дуже часто для подібних розділів використовують так званий «акордеон» — при кліці на яке-небудь питання, тут же розкривається відповідь. На мій погляд, це допустимо, якщо відповідь на питання короткий, подгружается динамічно і на нього можна дати пряме посилання, тобто, існує окрема сторінка на сайті, де дана тільки цю відповідь.
 
Чому так багато вимог? У нашому випадку питань не багато, але уявімо, що їх буде більше. Пошукові системи проіндексують весь контент на сторінці (включаючи відповіді в прихованих блоках). Користувач, перейшовши з пошукової системи, потрапить на простирадло з кількома десятками питань, де він повинен знайти те, що шукав. І добре, якщо його запит буде в заголовку питання, якщо ж він буде в прихованому блоці — шансів його знайти практично немає. Тому, ми нічого міняти не будемо — кожен відповідь буде на окремій сторінці.
 
 

Посилання (Links)

 Ð¡ÑÑ‹Ð»ÐºÐ¸ (Links)
 
До поточного вмісту додамо підзаголовок "Resources" і розмістимо посилання на зовнішні ресурси ("trac", "wiki", "twitter", "nginx.com", "blog") з короткими поясненнями.
 
 

Книги (Books)

 ÐšÐ½Ð¸Ð³Ð¸ (Books)
 
Оформимо вміст більш щільно — по дві-три книги в ряд. На мій погляд, видавець і мова — зайва інформація, так як дані посилання на інтернет-магазини, де ці книги можна купити, а там вже в свою чергу, розміщено багато додаткової інформації про кожному виданні.
 
 

Підтримка (Support)

 ÐŸÐ¾Ð´Ð´ÐµÑ€Ð¶ÐºÐ° (Support)
 
Можливо варто додати акцент на блоці комерційної підтримки.
 
 Новини (News)
 ÐÐ¾Ð²Ð¾ÑÑ‚и (News)
 
Мені подобається те, як організована поточна новинна стрічка. Новин за рік небагато, вони лаконічні, тому розбивка на сторінки не використовується.
 
У стрічці поточних новин будуть виводиться останні десять новин незалежно від року. Якщо новин за поточний рік більше десяти — виводяться всі новини за поточний рік.
 
Висновок дат зробимо «для людей». Якщо новина опублікована сьогодні чи вчора — будемо виводити «Today» або «Yesterday» відповідно. Якщо новина опублікована в поточному році — будемо виводити місяць і число — «April 8». Якщо новина опублікована в минулих роках — до місяця і число будемо додавати рік — «December 17, 2013».
 
 Патчі (Patches)
 ÐŸÐ°Ñ‚чи (Patches)
 
Додамо акцент на заголовку, критичності, посиланні на сам патч і оформимо вміст більш щільно. Незважаючи на те, що місце для розміщення двох патчів в ряд доступно, цього робити не варто, так як є досить довгі заголовки — їх буде простіше зчитувати по одному в рядок.
 
 PGP ключи
 
PGP ключі згадуються тільки на сторінці "security advisories", тому я припускаю, що тільки тут вони і використовуються. Список з ключами перенесемо в праву колонку.
 
 Підтримати проект (Donation)
 ÐŸÐ¾Ð´Ð´ÐµÑ€Ð¶Ð°Ñ‚ÑŒ проект (Donation)
 
Очевидно, що розбивка на стовпці по роках має свої обмеження. Змінимо верстку цієї сторінки — року будемо розміщати не стовпцями, а рядками. Прохання і кнопку "Donate" Убірія в праву колонку.
 
 Що далі?
Ми закінчили аналіз поточного дизайну. Навіть для такого простого проекту він вийшов вельми об'ємним, що вже говорити про більш складні. Перетворимо цей текстовий аналіз в якусь візуальну альтернативу — прототип.
 
 Прототіпіровалі, прототіпіровалі, так не випрототіпіровалі
 Що таке прототипирование?
Згідно Вікіпедії , прототипування це «… швидка« чорнова »реалізація базової функціональності для аналізу роботи системи в цілому ...».
 
На практиці, в контексті веб-дизайну і веб-розробки, під прототипом я маю на увазі якийсь схематичний чорновий варіант сайту, що дозволяє оцінити зручність використання поточного концепту.
 
Прототипи можна робити у вигляді html-сторінок, хоч на тому ж бутстрапа, а можна використовувати спеціалізовані програми. На Хабре є відмінний огляд інструментів для прототипування .
 
Незалежно від того, який інструмент ви оберете, зверніть увагу на ці рекомендації:
 
 
     
  • Не починайте відразу з цифрового прототипу . Візьміть папір, ручку і накидайте все від руки. Упевнений, що на цьому етапі ви помітите якісь косяки і проблемні місця в початкових рішеннях.
  •  
  • Робіть все монохромним . Виключивши колір, при тестуванні прототипу вам, вашим клієнтам або колегам буде простіше сфокусуватися на функціоналі. Зрозуміло, там де колір допоможе донести функціональність, його можна використовувати (наприклад, сині посилання).
  •  
  • Не використовуйте картинки , якщо це не обумовлено функціональним рішенням.
  •  
  • Не вдаватися в деталі . Прототип передбачає досить швидке створення. Тому не потрібно намагатися отрісовать фінальний дизайн.
  •  
  • Коментуйте всі нестандартні рішення . Те, що вам може здаватися очевидним, не здаватиметься оним для все інших.
  •  
  • Використовуйте ітераційний підхід . Аналіз — прототипування — аналіз (тестування) прототипу — новий прототип — аналіз і так поки не набридне поки не отримаєте ефективний прототип.
  •  
  • Роздрукуйте фінальний прототип . Повісьте на стіну, уважно подивіться. Найімовірніше, знайдете якісь недоліки. Крім того, приємно бачити результати своєї роботи в матеріальному вопрощеніі (особливо, коли цих сторінок під сотню).
  •  
 
 Трохи про Axure
Для створення прототипів я використовую Axure . Причому, мені вистачає самого базового функціоналу: стандартні віджети, замітки для будь-яких елементів і проста інтерактивність у вигляді клікабельних посилань.
 
Не буду покроково описувати те, як я робив прототип — лише коротко опишу інтерфейс Axure (на скріншоті версія 6.5, актуальна 7-я версія практично нічим не відрізняється).
 
 image
 
 
     
  1. Sitemap . Як неважко здогадатися, це дерево сайту. Управління всіма сторінками зосереджено в цій галузі.
  2.  
  3. Widgets . Це елементи, з яких будується прототип. Стандартної бібліотеки "Wireframe" вам вистачить для будь-якого випадку. Однак, бажаючі можуть знайти в мережі безліч інших бібліотек (наприклад, для прототипування додатків під iOS). Або зробити свою.
  4.  
  5. Masters . Насправді це просто інша назва для згрупованих об'єктів. Відмінність від звичайних груп (зрозуміло, вони теж є) у тому, що оновивши вміст майстра, воно оновиться на всіх сторінках, де цей майстер використовується. Тобто, це якийсь аналог Smart Objects з Photoshop. Звичайно за допомогою майстрів реалізують шапки, підвали сторінки тощо.
  6.  
  7. Generate . Після того, як ви зробили протіп в Axure, ви можете експортувати його у вигляді картинок, html-прототипу або специфікації у форматі * doc. Також можете опублікувати в мережі, використовуючи сервіс AxShare.
  8.  
  9. Workspace . Робочий простір. Все найцікавіше відбувається в цій області.
  10.  
  11. Widget Properties . Налаштування віджетів. Якщо придивіться, побачите перемикач, що складається з трьох кнопок:
       
    • Annotations . Текстові поля, використовувані для опису елемента (назва, опис тощо).
    •  
    • Interactions . Налаштування інтерактивності. Обираєте подія, наприклад клік, і дія — відкрити сторінку з прототипу в поточній вкладці.
    •  
    • Formatting . Налаштування зовнішнього вигляду віджету. Вміст цієї вкладки дублюється в рядку над робочим простором.
    •  
  12.  
  13. Dynamic Panel Manager . Динамічні елементи, використовувані на поточній сторінці. Типовий випадок використання "Dynamic Panel" — відображення модального вікна.
  14.  
 
Як бачите все досить просто. Упевнений, що ви освоете Axure на базовому рівні за 20 хвилин.
 
А ось такий прототип вийшов у мене.
 
 Замість висновку
У статті я торкнувся ефективність в аспектах зручності використання і структури. Зрозуміло, вони одні з найважливіших, але не варто забувати і про інших — якісному контенті та доступності. Під доступністю я маю на увазі технічні аспекти: підтримка браузерів, швидкість завантаження і так далі. Але все це — тема для іншої статті.
 
А в наступній частині ми займемося отрисовкой дизайну. На цьому все, спасибі за увагу, до зустрічі!
 
 Що почитати і подивитися
 Книги
 
     
  • Якоб Нільсен «Веб-дизайн. Книга Якоба Нільсена »(не дивлячись на те що половина цієї книги безнадійно застаріла, інша половина буде актуальною завжди).
  •  
  • Влад В. Головач, «Дизайн користувальницького інтерфейсу II. Мистецтво мити слона »(безкоштовна електронна книга)
  •  
  • Джеф Раскін, «Інтерфейс: нові напрямки в проектуванні комп'ютерних систем».
  •  
  • Алан Купер, «Про інтерфейсі. Основи проектування взаємодії ».
  •  
  • Алан Купер, «Психбольница в руках пацієнтів».
  •  
 
 Статті
  
 Відеоуроки
 
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.