Система управління проектами при розробці статичних сайтів

Хотілося б розповісти своє бачення про одну досить нової тенденції автоматизації розробки статичних сайтів. Це набір рішень, які спрощують розробку статичних сайтів та дозволяють клієнтам легко вносити коригування самостійно.



Статичні сайти
Статичні сайти, це досить велика частка ринку веб-розробки — в основному це landing page і сайти візитки. Ринок постійно прагне до здешевлення розробки таких сайтів пропонуючи:
  • SAAS-рішення (wix.com, unbounce.com і т. д.) як для кінцевих користувачів, так і для-вебстудий.
  • Дуже гнучкі і якісні шаблони для WordPress (звичайно є інші CMS з подібними шаблонами).
Чому всі клієнти не почнуть користуватися SAAS-рішеннями або WordPress-шаблонами і відмовляться від послуг веб-студій у цій галузі? На мій погляд основних причин дві:
  • Є багато клієнтів у яких в штаті немає відповідного фахівця і їм потрібен сервіс — вони платять гроші і відразу отримують результат.
  • SAAS-рішення і WordPress-шаблони мають обмеження дизайну. Чим більш гнучкіше шаблон тим більше потрібна кваліфікація користувача. Чим менш гнучкіша тим шаблон тим він менш унікальний — чого клієнт не хоче.




Кожна студія повинна мати своє SAAS-рішення для розробки статичних сайтів
Звичайно безліч студій мають великий набір гнучких і якісних WordPress-шаблонів і вони успішно можуть робити безліч статичних сайтів з дуже низькими витратами. Навіщо їм потрібно своє SAAS-рішення в даній області?

  • Веб-студії потрібен єдиний інтерфейс для управління проектами — PMS.
    Всі статичні сайти клієнтів можна розглянути як сторінки одного сайту для якого потрібна CMS, співробітники компанії це користувачі цієї CMS. Для кожного сайту можна прописати налаштування FTP доступу, що дозволить оновлювати зміни одним кліком.
  • Потрібно забезпечити можливість доступу клієнтів до даної PMS для самостійних коригувань.
    Це дозволить скоротити кількість звернень клієнта в студію на доопрацювання сайту.
  • Веб-студії не потрібен дуже наворочений візуальний інтерфейс налаштувань як це часто буває у WordPress-шаблонів.
    Іноді простіше написати HTML/JS/CSS код ніж вникати в інтерфейс налаштувань шаблону натикатися на баги і з'ясовувати, що те чи інше не можливо. Водночас важливо забезпечити клієнтам максимально простий інтерфейс для коригування тексту, картинок, посилань або стилів. Так потрібен чи не потрібен інтерфейс налаштувань? Існує компромісное рішення: можна зробити спрощений HTML редактор де в наявним HTML кліком миші змінюється текст, посилання, зображення, колір і т. д.
  • Як забезпечити повторне використання даного HTML/JS/CSS коду?
    Очевидно, що всередині даної PMS необхідно використовувати шаблони. Якщо робити шаблони для всього сайту то ефективність їх повторного використання різко падає, зате у випадку якщо користувач PMS недостатньо кваліфікований це значно полегшує розробку сайту. Якщо робити шаблони для окремих елементів (в WordPress зазвичай використовують механізм shortcode для цих цілей): повторне використання може бути частим, підвищуються вимоги до кваліфікації користувача і прискорення розробки сумнівно (так як іноді HTML/JS/CSS кодом зробити те ж саме простіше). Оптимальне рішення в таких умовах — робити шаблони для responsive-секцій (частина сайту повної ширини) як це зроблено у проекті Startup Framework. Секція може включати в себе всю атрибутику задуманого дизайну і весь необхідний JavaScript. При правильній розробці шаблонів секцій зіпсувати дизайн невдалими перестановками секцій досить складно, в той же час, кінцевий користувач отримає певну свободу для розробки унікального сайту.
  • Веб-студія може вести розробку своєї бібліотеки секцій.
    Як додатковий дохід може бути продаж доступу до PMS кінцевими клієнтам, що по суті виглядає як SAAS-рішення.
    І звичайно ж, очевидно: очікується ринок шаблонів-секцій.




Мій проект на github який може використовуватися для розробки подібної PMS.

Джерело: Хабрахабр

0 коментарів

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