Ответы на вопросы. Вопросы к экзамену по Разработке корпоративных сайтов. Типы и классификации сайтов. Характеристики и особенности корпоративных сайтов
 Скачать 254.85 Kb.
|
|
Как написать use case? Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими: Определите, кто будет использовать сайт. Выберите одного из этих пользователей. Определите, что этот пользователь хочет делать на сайте. Все, что пользователь делает на сайте, становится юзкейсом. Для каждого use case определите нормальный ход событий. Опишите основной путь пользователя: что именно делает пользователь и каков ожидаемый ответ системы. Далее рассмотрите альтернативные варианты развития событий и добавьте их, чтобы «расширить» use case. Повторите шаги 2-6 для всех остальных пользователей. Зачем нужны use case? Заказчики В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков. Разработчики В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим. Тестировщики Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании. UX-проектирование сайта Что такое UX-дизайн? UX-дизайн (проектирование опыта взаимодействия) — методология проектирования цифровых продуктов для решения проблем пользователей. Когда команда использует этот ориентированный на человека подход, она принимает решения, основываясь на потребностях пользователей, а не на своих предположениях. В его основе лежит эмпатия. UX-дизайнеры должны понимать, чего пользователь хочет достичь с помощью цифрового продукта, и с какими болевыми точками он может столкнуться на этом пути. Что такое процесс UX-проектирования? Процесс UX-проектирования — это итеративная пошаговая методология, которую команды используют для завершения проектов. Хотя этот процесс варьируется в зависимости от продукта и организации, большинство компаний берут за основу процесс дизайн-мышления: Эмпатия Фокусировка Генерация идей Прототипирование Тестирование Этот итеративный процесс позволяет дизайнерам отрабатывать свои идеи и проверять, насколько они хороши, на протяжении всего процесса проектирования. Почему процесс UX-проектирования так важен? Компании уделяют много внимания процессу UX-проектирования, потому что он: Обеспечивает соответствие проектов стандартам качества и единообразия, Дает дизайнерам возможность разрабатывать решения без предвзятости и предположений, Позволяет дизайнерам тестировать и дорабатывать множество идей, чтобы найти лучшее решение, Способствует эффективному взаимодействию между командами и отделами, Снижает риск переделок благодаря соблюдению установленных протоколов, Позволяет заинтересованным сторонам отслеживать прогресс, Помогает выявлять скрытые риски и возможности. 8 этапов процесса UX-проектирования Этап 1 — Определение цели проекта и объема работ На первом этапе процесса UX-проектирования необходимо определить цель проекта и объем работ. В этом должны принимать участие члены команды и заинтересованные лица из различных отделов. Как правило, речь о специалистах, которые занимаются следующими вопросами: Бизнес Дизайн Продукт Техническая реализация Цель этого этапа проектирования — выявление проблемы, которую должен решить новый продукт или функция. Продуктовая команда также определяет объем работ, план, желаемые результаты и сроки выполнения. Этап 2 — Понимание проблемы Когда цель проекта и объем работ ясны, команда должна определить проблему с точки зрения пользователя. Дизайнеры используют различные UX-инструменты, чтобы понять, что он чувствует и с какими проблемами сталкивается. Некоторые инструменты: Персоны пользователей: собирательный образ группы ваших клиентов с похожими демографическими характеристиками. Карты путешествия пользователей: Пошаговая визуализация проблемы пользователя и того, как он может использовать цифровой продукт для ее решения. Карты эмпатии: Методология представления чувств и эмоций пользователя, которые он испытывает, когда сталкивается с болевыми точками при выполнении задач. Этап 3 — UX-исследование Затем UX-дизайнеры исследуют проблему, чтобы найти возможные решения. На этом этапе они проводят несколько типов исследований, включая: Исследование пользователей: Изучение целевого рынка для лучшего понимания потребителей. Исследование рынка: Анализ рынка для определения сегментации рынка и дифференциации продукта. Исследование конкурентов: Конкурентный анализ, который позволяет понять, как конкуренты решают схожие проблемы, и определить имеющиеся возможности. Исследование продукта: Анализ информации о существующем продукте для понимания поведения пользователей. Этап 4 — Генерация идей: наброски и низкодетализированные прототипы Имея четкое представление о своих пользователях, рынке и конкурентной среде, дизайнеры могут приступить к генерации идей. Чтобы быстро перебрать множество идей, на первом этапе они используют бумагу и ручку. В рамках этого шага дизайнеры создают: Наброски (скетчи): Нарисованные от руки схематичные изображения интерфейса. Бумажные прототипы: Макет продукта из бумаги. Вайрфреймы: Цифровые версии бумажных прототипов, которые содержат основные линии и формы. Низкодетализированные прототипы: Цифровые прототипы на основе вайрфреймов для тестирования пользовательских сценариев и информационной архитектуры. Команда также может проводить дизайн-спринты для быстрого решения конкретных проблем. Этап 5 — Высокодетализированные мокапы и прототипы Далее команда UI-дизайнеров преобразует вайрфреймы в мокапы для создания высокодетализированных прототипов, которые выглядят и функционируют как конечный продукт. Если у компании есть дизайн-система, дизайнеры используют библиотеку UI-компонентов. Этап 6 — Юзабилити-тестирование Основная цель создания высокодетализированных прототипов — тестирование юзабилити. UX-дизайнеры тестируют их с реальными пользователями, чтобы: Проверить идеи Выявить проблемы юзабилити Протестировать доступность Определить бизнес-возможности Этапы со 2 по 5 повторяются необходимое число раз. Используя результаты тестирования, дизайнеры возвращаются на второй или третий этап для новой генерации идей, пока не найдут решение, отвечающее критериям желанности, жизнеспособности и осуществимости. Важно отметить: несмотря на то, что тестирование пользователей — шестой шаг, команды дизайнеров проводят множество тестов на протяжении всего процесса UX-проектирования для проверки идей и гипотез. Это и внутреннее тестирование с членами команды, и обмен идеями / прототипами с заинтересованными сторонами для получения обратной связи. Этап 7 — Передача дизайна в разработку Предпоследний этап — передача дизайна в разработку, когда команда дизайнеров передает свои мокапы, прототипы и документацию команде разработчиков для дальнейшего проектирования. Несмотря на то, что передача дизайна происходит в конце UX-процесса, дизайнеры и разработчики начинают сотрудничать еще на этапе генерации идей, чтобы упростить переход от дизайна к разработке и обеспечить соответствие проекта техническим ограничениям. Этап 8 — Обеспечение качества или UX-аудит Заключительный этап процесса UX-проектирования — UX-аудит для проверки нового релиза. UX-аудит гарантирует, что новый релиз соответствует бизнес-целям проекта, опыту взаимодействия и требованиям доступности. Состав технического задания на разработку сайта. Техническое задание — документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше участники процесса понимают, что должны делать. А значит, вероятность, что все останутся довольны результатом, выше. Главная цель технического задания – убедиться, что клиент и исполнитель правильно поняли друг друга. Пользы от технического задания много. Для каждой стороны она своя. Польза для клиента Понять, за что заплачены деньги. Можно сразу увидеть структуру, узнать, что и как будет работать. Пересмотреть идеи еще до начала разработки, чтобы сэкономить время и деньги. Проверить компетентность исполнителя. Если техзадание понятное и четкое, доверие к разработчику повышается. Если написана каша, возможно, стоит бежать и не оглядываться. Подстраховаться. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор, можно даже получить компенсацию через суд. Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может затянуться. Подробное техзадание можно передать новой команде. Так она втянется в работу в разы быстрее. Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание. Польза для исполнителя Понять, чего хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей — ура, вы нашли контакт. Подстраховаться. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, подобное не пройдет: в случае чего даже суд будет на вашей стороне. Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются. Заработать. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу. Облегчить и ускорить разработку. В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Когда все требования уже перед глазами, дело остается за малым. Техзадание составляет исполнитель Техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли. Хорошее ТЗ всегда составляет исполнитель – проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец бизнеса, поэтому описывать проект придется ему. Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Отлично, одобряю». Он тоже должен участвовать в процессе: познакомить исполнителя с компанией, продуктами и целевой аудиторией; объяснить, зачем ему сайт; рассказать, чего хочет, поделиться идеями; показать примеры сайтов, которые можно взять за образец; ответить на любые вопросы исполнителя. Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку. Техзадание должно быть однозначным В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. Аналогично с непонятными формулировками, которые ничего сами по себе не значат: сайт должен понравиться заказчику – а если у него будет плохое настроение? сайт должен быть удобным – удобным для чего, для кого? сайт должен выдерживать большие нагрузки 10 тыс. посетителей? Или 10 млн? сайт должен содержать качественный экспертный контент – Ну, вы поняли. Проверяйте, нет ли в тексте неоднозначностей. Если есть — перепишите. Ваши формулировки должны быть четкими и точными: Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights. Большие нагрузки → 50 тысяч посетителей одновременно. На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей. Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*. С формулировками разобрались, давайте пробежимся по структуре. Техзадание должно содержать общую информацию Все члены команды должны правильно понимать, чем занимается компания, кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать. А еще стоит указать цель сайта и описать его задачи, чтобы не получить интернет-магазин вместо блога. В техзадании нет сложных терминов Техзадание должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка, условная владелица магазина детских игрушек, обязательно поясните их. Например: контент – это любой текст, изображения и видео на сайте; CMS – система управления сайтом, через которую можно добавлять и редактировать контент, не имея навыков веб-разработки; подвал – блок сайта, который отображается внизу каждой страницы. Техзадание описывает инструменты и требования к хостингу Представьте, что вы 2 месяца делали сайт. Каждый этап согласовывали с клиентом — он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс? ! Я думал, вы сделаете на “Вордпрессе”!» Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP, а у клиента сервер на .NET. Техзадание содержит требования к работе сайта Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы. Сюда же добавьте требования к скорости загрузки сайта, устойчивости к нагрузкам, защите от хакерских атак и подобным вещам. Техзадание показывает структуру сайта До отрисовки сайта и его верстки вам нужно согласовать с клиентом структуру. Соберите разработчиков, сеошников, маркетологов, главреда — и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти. Можно показать структуру списком, можно нарисовать блок-схему. Второе нагляднее. Это один из важнейших этапов работы с сайтом. Структура — это фундамент. Если она неудачная, сайт получится кривым. Техзадание касается каждой страницы Клиент должен понять, зачем нужна каждая страница сайта, какие элементы на ней будут. Есть два способа это показать. Прототип Более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс будущего сайта и говорит, что ему нравится, а что стоит изменить. Перечисление элементов Ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице и что они делают. В техзадании должны быть сценарии использования сайта Если вы создаете нестандартный интерфейс, показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого подходят сценарии. Схема сценария проста: действие пользователя – ответное действие сайта – … – результат Например, таким может быть сценарий оформления заказа. Пользователь нажимает на кнопку «Заказать» – сайт открывает форму заявки – пользователь вводит номер телефона и нажимает «Ок» – сайт принимает заявку и выводит сообщение «Заказ принят» – на e-mail менеджера приходит письмо с номером телефона клиента. Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут интерактивные сервисы, прописать сценарии необходимо – это поможет заметить «дыры» в работе ресурса. Техзадание утверждает обязанности Одни разработчики делают сайт сразу с контентом, другие ставят рыбу, третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить. Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «качественный, интересный и продающий, полезный целевой аудитории». Это мусор, он никому не нужен. Указать, что весь контент должен быть уникальным — это полезно. Причем в идеале нужно указать конкретные показатели уникальности в процентах, а также сервисы для проверки текста, которые исполнителю стоит использовать. Техзадание описывает дизайн Как и в случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме, опишите ее. Если у него есть брендбук, в котором прописаны шрифты, укажите и их. Вместо вывода: структура техзадания Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы: информация о компании и целевой аудитории, цели и задачи сайта; глоссарий терминов, которые могут быть непонятны клиенту; технические требования к верстке и работе сайта; описание используемых технологий и список требований к хостингу; подробная структура сайта; прототипы страниц или описания элементов, которые должны на них быть; сценарии использования нестандартного интерфейса (опционально); список контента, который делает разработчик; требования к дизайну (опционально). Параллельный и последовательный дизайн. Параллельный дизайн (parallel design) это метод, при котором создаются несколько альтернативных дизайнов (например, интерфейса) одновременно двумя-четырьмя группами разработчиков. Цель данного метода - оценить различные идеи до того, как будет принята единая концепция для реализации. Группы разработчиков должны работать независимо друг от друга, так как цель метода - создать как можно больше различных решений. Группы разработчиков не должны обсуждать друг с другом свои работы до тех пор, пока окончательные наброски не будут готовы для общего собрания. Задуманная система может опираться на один из этих дизайнов или на их сочетании, в котором взяты лучшие идеи из каждого варианта. Несмотря на то, что метод параллельного дизайна может показаться через чур дорогостоящим, это на самом деле не так: так как в данном случае разработчики генерируют множество идей не тратя время на их реализацию, этот метод позволяет дешево исследовать целый ряд возможных вариантов решения и выбрать наиболее оптимальный. Плюсы Позволяет дешево и быстро генерировать множество идей Параллельный подход позволяет одновременно исследовать несколько вариантов решения, благодаря чему сокращается время проекта Полученные решения часто можно совместить, так что окончательный вариант в любом случае выигрывает На "прощупывание" решений требуется минимум ресурсов и материалов Метод не требует знаний в области человеческой психологии Тем не менее параллельынй дизайн требует одновременного наличия нескольких команд разработчиков, а также на выполнение работы требуется выделить какое-то время. Кроме того необходимо предусмотрительно выделить время на сравнение полученных результатов. Метод Метод требует одновременного наличия нескольких команд разработчиков, которые будут работать параллельно. Перед этим необходимо подготовить документ с требованиям, который предоставляется каждой группе, так что обе группы начинают с одной и той же точки, владея одной и той же информацией. В качестве примера предлагаем следующий порядок действий: Четко определитье границы параллельного дизайна: цель системы, задачи, которые она должна выполнять, характеристики пользователей и т.д. Каждая из команд должна получить один и тот же набор требований. Каждая из команд может пользоваться любыми средствами для создания и представления дизайна. Рекомендуется использовать простейшие прототипы. За "навороченные" прототипы дополнительные очки не начилсяются. Команды разработчиков должны быть равны по силе. Заранее определите, сколько времени вы выделяете на разработку. 10 - 20 часов на группу - вполне достаточно. Определитесь, по каким критериям вы будете оценивать созданые работы. Выделите достаточно времени на справедливую оценку и сравнение полученных дизайнов. Очень часто эта работа выполняется на собрании, где присутствуют все группы. Обсудите каждый дизайн в отдельности и затем обсудите, как можно совместить различные аспекты различных вариантов. Цель - совместными усилиями сойтись на единственной концепции дизайна. Последовательный дизайн — это итеративный процесс, который помогает достичь желаемых результатов, при этом не требуя к себе излишнего внимания и гармонично встраиваясь в привычный ритм работы. За счет постоянного изучения и совершенствования он позволяет свести риск к минимуму, так как обращается только к проверенным на практике предположениям. А следование принципу постепенных изменений дает возможность запускать веб-ресурсы в короткие сроки, сокращая затраты на редизайн и общее время разработки. Основные методы тестирования дизайна сайта. Тестирование дизайна сайта — одно из ключевых составляющих успеха любого веб-проекта. Предполагать возможные пути следования пользователей по сайту и методы их взаимодействия с сайтом — дело хорошее, но это лишь предположения. Как в действительности пользователи будут пользоваться сайтом может показать только тестирование. Как же мы в Prozorro тестируем наш сайт или его доработки? Давайте разберем пошагово и посмотрим весь флоу. Перед тем как тестировать сайт, нужно сначала протестировать макеты сайта. Макет сайта — это эскиз, на котором изображена будущая страница. От того, насколько качественно проработан макет, зависит общее восприятие информации на сайте. При работе над макетом в графическом редакторе у дизайнера нет ограничений. Где может быть создан макет Есть множество ресурсов для создания макетов, но, пожалуй, самый популярный для дизайнера — это Figma. Если в рамках тестирования выяснится необходимость переделки, то значительно проще, дешевле, и быстрее переделать макеты, а не полностью сайт. К верстке и программированию стоит приступать, только убедившись в эффективности созданных дизайн-макетов. Зачем тестировать дизайн-макеты сайта Для владельца веб-ресурса тестирование макетов будущего сайта позволяет убедиться в том, что сайт будет выполнять возложенные на него коммерческие и коммуникативные задачи. Задачи сайта лучше предварительно четко описать в брифе по созданию сайта. Описание задач должно быть очень конкретным, так как потом они будут использованы в составлении вопросов для тестирования. Примеры коммуникативных задач нашего портала Prozorro: показать, что компания работает в сфере госзакупок; показать основные направления в сфере госзакупок; показать партнеров, с которыми мы сотрудничаем (тендерные площадки); показать прозрачность в сфере госзакупок. Этапы тестирования: тестирование функциональности; проверка юзабилити сайта (удобство использования); тест производительности; проверка на безопасность; тестинг интерфейса (UI  Testing). Понятно, что не все пункты проходит тестировщик, часть из них берут на себя другие члены команды, которые специализируются в нужном направлении. Давайте на примере посмотрим на блок функционального тестирования и составим чек-лист: Проверка правильности работы главных функций ресурса. Обнаружение ссылок, ведущих к одной странице. Корректность внутренних ссылок. Проверка пользовательских форм. Сюда входят: добавление комментарии в блог, обратная связь и прочее. Проверка полей и страниц «Авторизация», «Регистрация». Корректность работы «Поиск ресурса» (его открытие на странице и открытие всех его атрибутов). Проверка добавление, удаление и редактирование данных пользователей, товаров и заказов. Сверка контента, имеющегося на сайте с тем, что представил заказчик. Поговорим о юзабилити-тестировании Юзабилити-тестирование позволяет проверить, насколько удобен сайт для пользователя, насколько легко ему найти ту или иную информацию. Одним слово — комфортность выполнения желаемых действий. Основная цель юзабилити-тестирования: Определить, понятен ли ваш сайт для пользователя, удобен ли. Понять, насколько удобна навигация. Выяснить, какое впечатления создается у пользователя. Оценить, что может быть лишним на ресурсе. Чек-лист тестирования сайта на юзабилити: Навигационное тестирование. Здесь специалист проверяет, все ли страницы, кнопки и поля понятны пользователю. Есть ли доступ к главной странице и меню со всех остальных страниц. Тестирование контента. Специалист проверяет наличие грамматических ошибок, насколько контент информативный, имеют ли картинки и видео нужные размеры и качество, все ли заголовки проставлены корректно. Удобство пользования. Тестировщик оценивает, насколько понятна структура веб-приложения и есть ли лишние компоненты на ресурсе (проверяются все страницы). UI Testing: тест пользовательского интерфейса Не стоит путать тестирование интерфейса с проверкой юзабилити. Это два разных этапа общего теста. UI-тест проверяет соответствие графического интерфейса сайта. Чек-лист тестирования интерфейса: проверка на соответствие всем стандартам графических интерфейсов; тестирование с различными разрешениями экрана; проверка совместимости со всеми браузерами и их версиями (кроссбраузерность); тестирование интерфейса на смартфонах, кпп, планшетах; локализованное тестирование: точность перевода, проверка длины названий и прочее. Регрессионное тестирование Регрессионное тестирование позволяет удостовериться в том, что существующая функциональность не была затронута изменениями в коде. Для понимания приведем пример: ваша компания создала приложение «Фонарик». У него всего две функции: «включить» и «выключить». Ваши специалисты провели тестирование функциональности и убедились, все работает корректно. Можно не беспокоиться. Спустя время ваша команда добавляет еще одну функцию – «включение фонарика при встряхивании смартфоном». Тестировщику уже необходимо проверить не только новую функцию, но и предыдущие две (включение/выключение). Вдруг нововведение затронуло их? Это яркий и понятный пример регрессионного тестирования в процессе разработки ПО. Тестирование покажет, затронули новые фичи старый функционал или нет Чек-лист регрессионного тестирования: Провести анализ внесенных изменений, поиск областей, которые могли быть затронуты. Правильное составление набора текст-кейсов для тестирования. Проведение регрессионного тестирования. Составление отчета о дефектах, если таковые имеются. Устранение найденных дефектов и их верификация. Проведение второго круга регрессионного тестирования (проводится до момента полного исключения багов). Подводим итоги Тестирование сайта — это сложный процесс, от которого зависит качество работы ресурса, впечатление пользователей о компании. Этот этап создания сайта можно назвать гарантом спокойствия заказчика и исполнителя. Не стоит игнорировать тестирование, иначе в обратном случае это может привести к дополнительной трате времени и денег. Перед тем, как приступить к проверке, обсудите все важные детали с командой. Главное использовать обширный подход с применением различных техник, анализа и набора методик тест-дизайна. Принципы функционирования интернет-портала. Интернет объединяет в одно целое множество компьютерных сетей и отдельных ЭВМ, работающих по единым правилам. В основе функционирования Интернета заключаются три составляющие: техническая, технологическая, организационная. Техническая основа - составляет опорная сеть, структура которой образована узлами, соединенными между собой линиями связи с высокой помехозащищенностью. К узлам опорной сети подключены индивидуальные пользователи или локальные сети. Узел опорной сети составляют мощные компьютеры, называются хост-компьютерами, они работают в круглосуточном режиме, постоянно подключены к сети. Эти компьютеры должны обладать большим объемом памяти и быстродействием. На рисунке 1 представлена принципиальная схема сети Интернет.  Рисунок - 1 Принципиальная схема сети Интернет Технологическую основу составляют сетевые протоколы. Протокол - набор правил, позволяющий осуществлять соединение и обмен данных между включенными в сеть устройствами. Главные протоколы для обеспечения работы Интернет являются TCP/IP и HTTP. В протоколе TCP информация делится на пакеты, которые нумеруется для получения информации, которую можно правильно собрать. При помощи протокола IP все части собираются получателю, и при помощи TCP проверяется, все ли части получил пользователь, порядок частей может быть нарушен. При получении TCP проверяет, все ли части пришли, располагает в правильном порядке и собирает их. IP протокол добавляет служебную информацию, из которой можно узнать адреса отправителя и получателя информации. IP работает как обычная почта, на конверте пишется адресат и обеспечивает доставку. Правильно оформленные IP - пакеты доходят до получателя. Отличительной особенностью Интернета является высокая надежность. Если один из компьютеров вышел из строя, то линия связи сети будут продолжать функционировать. Сетевая структура Интернета всегда обеспечивает несколько путей передачи информации. HTTP - протокол передачи гиперссылок. Гиперссылка - это объект в документе, с которым связан указатель для перехода на другую страницу, в другой документ. Это позволило разместить в Интернете множество документов, связанных гиперссылками, которое образовало гипертекстовую информационную систему. На рисунке 2 представлена схема, поясняющая принцип работы гипертекстовой информационной системы.  Рисунок 2 - Схема, поясняющая принцип работы гипертекстовой информационной системы Организационную основу составляет система адресации. Символьные адреса или доменные имена предназначены для запоминания людьми. Их легко использовать как в небольших, так и крупных сетях. Числовые составные IP-адреса. Этот адрес имеет фиксированный и компактный формат и делится на старшую часть - номер сети и младшую - номер узла. URL - это адрес любого ресурса в Интернете, который указывает о месте нахождения этого ресурса. Формат URL включает: - схему адреса; - IP; - номер ТСР - порта; - адрес ресурса на сервере; - имя HTML-файла и метку; - критерии поиска данных. Запись такого адреса имеет вид: <протокол>://<логин>:<пароль>@<хост>:<порт>/ Значения: - протокол - набор правил, позволяющий осуществлять соединение и обмен данными между двумя включёнными в сеть устройствами; - логин - имя пользователя, используемое для доступа; - пароль - набор символов, идентифицирующий пользователя, при проверке его права доступа к данному ресурсу; - хост - IP-адрес хоста в форме четырёх десятичных чисел; - порт - порт хоста для подключения; - URL-путь - уточняющая информация о месте нахождения ресурса. Web-сервера, особенности их функционирования и применения. Web-сервер -- это программа, обрабатывающая сообщения, и работающая с протоколом HTTP. Именно этот протокол является основным для WWW. Он представляет собой набор правил для обмена данными и основан на принципе «запрос-ответ». Запрос идет от клиента к серверу и содержит служебную информацию о типе запроса. Ответ идет от сервера к клиенту. В нем находится служебный код (число), показывающий состояние обработки запроса, ответный заголовок и сами данные. В последнее время увеличилось количество Web-серверов, выпускаемых различными производителями. Естественно, любой Web-сервер поддерживает некоторый минимальный набор функций - поддержка протокола HTTP, настройка на разные порты, создание log-файлов, пользовательские директории, функции защиты. Планирование системы нужно начать с выбора ОС. Не всякий сервер реализован для конкретной операционной системы. Прежде чем установить сервер, необходимо понять, что он поддерживает, а что нет. Любой сервер поддерживает протокол HTTP, но не всякий сервер изначально поддерживает, например, работу с базами данных. Плюс к этому сейчас любой разработчик Web-серверов создает свой API для работы с сервером. Удобство средств разработки программ для сервера тоже играет немалую роль. Самый простой пример работы веб-сервера – интернет-магазин. Вы заходите на сайт, формируете запросы, получаете ответы на них в виде веб-страниц – всё это делает веб-сервер. Протоколы CMS-системы: общие принципы функционирования CMS –это система создания и управления сайтом. Это визуально удобный интересный интерфейс с помощью которго можно добавлять и релактировать содержимое сайта. Drupal – бесплатная, но полнофункциональная и достаточно тяжелая CMS, имеющая в составе все необходимое для создания полноценного сайта; 1С Битрикс – объемная, многопрофильная платная система, чересчур тяжеловесная для простых задач, но хорошо справляющаяся со сложными; Joomla – крайне простой в использовании бесплатный движок, который применяют начинающие сайтостроители и компании, не требующие от ресурса мощных вычислений; MODx – удобная для разработчиков бесплатная CMS, обладающая высокой степенью защищенности и достаточной гибкостью для решения большинства задач; WordPress – известный по всему миру движок, который изначально предназначался для создания блогов, однако на данный момент имеет куда более широкую функциональность; DLE – отчасти аналог предыдущей системы, простой в использовании и интуитивно понятный; движки для создания форумов: phpBB, vBulletin и другие; системы для организации интернет-магазинов: как бесплатные (OpenCart, PrestaShop), так и платные (Umi.CMS, Shop-Script и другие); прочие конструкторы с разными функциями, но, как правило, в простых и малоизвестных CMS принцип работы и возможности довольно ограничены. Сайты, составленные благодаря принципам CMS, не представляют собою разрозненные страницы. Многие задвижки меняются в зависимости от оформления сайта, хотя сама структура не меняется. Запрос пользователя формируется с учетом определенных параметров, например, авторизирован ли пользователь, какую информацию он искал перед этим и так далее. Допустим, ранее пользователь совершил покупку какого-то товара в интернет-магазине, поэтому на новых страницах у него будут высвечиваться аналогичные товары или изделия. CMS защищает любые действия сайта, препятствует накоплению спама и выполняет колоссальное количество дополнительной работы, которую не видит пользователь. Причем работа выполняется быстро, без задержек скорости получения информации, поэтому пользователь не уйдет на другой сайт в поисках решения своего вопроса. Сайт может обойтись без услуг CMS при условии, что он состоит из одной страницы. Но в случае расширения сайта могут возникнуть сложности. Если понадобиться изменить какую-либо информацию, то потребуется заходить на каждую страницу, вводить код и заменять данные, например, номер телефона, ссылка на определенный адрес. А вот владельцу системы CMS достаточно заглянуть в свою админку и изменить данные, основываясь на предоставленные инструкции. Особенности подготовки шаблонов дизайна для CMS-систем Шаблон для CMS (Template) — позволяет быстро, не обладая специальными знаниями программирования и навыками дизайна, задать внешний вид веб-сайта. Это набор файлов, которые представляют правила и стили интернет ресурса (цветовая гамма, оформление, расположение блоков и меню). В области разработки и создания сайтов наметилась устойчивая тенденция не привязывать дизайн и оформление представленной информации к содержанию интернет-ресурса. Такое разделение делает возможным использовать для структуризации документов и визуального оформления внешнего вида сайта готовые шаблоны. Эти заготовки сегодня становятся основой, которая отвечает за то, каким увидят сайт посетители. Сайты, использующие профессиональные(премиум) шаблоны, цена которых обычно составляет 40-60$, выглядят очень профессионально. CMS хостинг — тарифы хостинга для самых распространенных систем управления сайтами! Шаблон для CMS представляет собой набор файлов, которые связывают в единое целое дизайн, интерфейс и систему управления сайта. Он определяет: Оформление, размер и расположение блоков сайта; Навигацию; Описание стилей оформления текста, изображений; В шаблоне нередко присутствуют функции, выходящие за рамки систем управления контентом – изменение цветовой гаммы, фона, шрифта и т.д. Вместе с тем избыточный функционал служит источником определенных трудностей. В частности, такой сложнее настраивать под личные нужды и предпочтения. Недостатки шаблонов Наличие богатого функционала не гарантирует построение на основе шаблона сайта, который будет соответствовать индивидуальным требованиям пользователя. Кроме того, следует быть готовым к тому, что если сайт использует шаблон, в Интернете могут встречаться и другие сайты с похожим дизайном. Преимущества шаблонов Преимуществами использования шаблонов являются экономия времени и бюджета для проектов, которым не требуется индивидуальный дизайн. Выбор тематического шаблона из каталога значительно ускорит процесс запуска ресурса, чем заказ подобного функционала в студии веб-разработки. В денежном эквиваленте премиум-шаблон обойдется в 30-60 долларов, тогда как за уникальный дизайн придется заплатить в 5-15 раз дороже. В пользу шаблонов свидетельствует то, что ими пользуются тысячи вебмастеров. Однако найти два идентичных ресурса в сети практически невозможно. Еще один неоспоримый плюс шаблонов – они корректно отображаются в популярных браузерах. Платный или бесплатный шаблон? В Интернете представлен достаточно богатый выбор как платных, так и бесплатных шаблонов. Возникает резонный вопрос: зачем тратиться на то, что можно получить задаром? За деньги, как правило, пользователь получает не только качественный шаблон. В этом случае обеспечивается техническая поддержка, обновления, устранение возможных проблем, и доработки по просьбам покупателей. Особенности подготовки шаблонов работы с данными. HTML4 – основной язык разметки. Отличия от более ранних версий. Стандартизированный язык гипертекстовой разметки документов для просмотра веб-страниц в браузере. Веб-браузеры получают HTML документ от сервера по протоколам HTTP/HTTPS или открывают с локального диска, далее интерпретируют код в интерфейс, который будет отображаться на экране монитора. HTML 0.9 RFC 1866 — HTML 2.0, одобренный как стандарт 22 сентября 1995 года; HTML 3.2[1] — 14 января 1997 года; HTML 4.0[2] — 18 декабря 1997 года; HTML 4.01[3] (изменения, причём более значительные, чем кажется на первый взгляд) — 24 декабря 1999 года; ISO/IEC 15445:2000[4] (так называемый ISO HTML, основан на HTML 4.01 Strict) — 15 мая 2000 года. HTML 5[5] — 28 октября 2014 года HTML 5.1 начал разрабатываться примерно 19 декабря 2012 года HTML 1.0 Первая и базовая версия HTML была разработана для поддержки основных функций, таких как текстовые элементы управления или размещение изображений. Эта версия HTML не поддерживала широкий спектр элементов, как современные версии языка. В частности в этой версии HTML не было поддержки таблиц и шрифтов. В целом, можно сказать, что эта версия является самой ограниченной версией HTML. HTML 2.0 HTML 2.0 - это версия, имевшая все возможности HTML 1.0 с некоторыми новыми функциями для веб-дизайна. HTML 2.0 считался стандартной версией HTML до 1995 года. В этой версии были улучшены теги разметки, текстовых полей, кнопок и т. д. Браузеры, разработанные для этой версии HTML, также ввели концепцию наличия тегов и слоев. Был создан W3C (World Wide Web Consortium), который стандартизировал язык HTML. Данная версия HTML понимала шаблоны и визуализировала HTML-теги согласно стандарту W3C. HTML 3.0 Хотя выпуск HTML 2.0 был тепло принят, авторы HTML и веб-разработчики все еще нуждались в более целостной версии языка. И такой версией стала HTML 3.0. HTML 3.0 предоставила авторам HTML и веб-мастерам больший контроль и более широкий спектр способов разметки текста и повышения качества и внешнего вида веб-сайтов. Используя HTML 3.0, «Netscape», новый и ведущий браузер того времени, представил новые и более проработанные теги и атрибуты, которые получили название «Теги расширения Netscape». Разработки Netscape были благожелательно оценены программистами, однако эти теги и атрибуты не работали в других браузерах. Позже Дэйв Рэггетт, руководитель группы, работающей над HTML, представил новый проект HTML 3.0 со значительными улучшениями и доработками. HTML 3.2 HTML 3.2 (Wilbur) стал расширенной версией HTML, предлагавшей более широкий набор различных тегов. Это был новый стандарт, который тогда был крайне необходим. При этом все разработки предыдущей версии HTML 3.0 полностью вошли в эту версию языка. HTML 4.01 Новая версия началась с HTML 4.0, известной как Cougar. Но со временем некоторые улучшения были изменены и вошли в версию HTML 4.01. В 1999 году была представлена новая версия HTML 4.01, которая была значительно усовершенствована и предназначалась для достижения более масштабных целей. Расширенные версии HTML 4.01 поддерживали каскадные таблицы стилей (CSS). Представленная концепция таблиц стилей решила проблему наличия CSS на каждой веб-странице и убирала повторяющийся код. С выходом новой версии языка был запущен онлайн проект Cheatsheets in HTML с общими фрагментами кода и онлайн-инструментами, которые актуальны и по сей день. Также, HTML 4.01 дорабатывал старые теги и вводил ряд новых тегов HTML. XHTML 1.0 Большинство разработчиков ожидали, что после HTML 4.0 и HTML 4.01 следующим будет HTML 5.0. Но следующим в линейке стандартов стал XHTML. Новый XHTML сопровождался появлением улучшенных тегов и опций, которые очень понравились разработчикам. Аббревиатура XHTML расшифровывается как Расширяемый язык гипертекстовой разметки (англ. Extensible HyperText Markup Llanguage). При этом цель запуска XHTML заключалась вовсе не в улучшении тегов. Основная причина выхода этого стандарта состояла в том, чтобы улучшить взаимодействие с новыми браузерами, которые постоянно меняют динамику просмотра. Поскольку технологическая динамика постоянно меняется, было важно учитывать, что новые браузеры будут доступны на разнообразных современных гаджетах. Так что в этом отношении XHTML оказался шагом в нужном направлении. Данный браузерный язык был ориентирован на работу с этими новыми технологиями. Веб-страницы, написанные на XHTML, адекватно работали с самым широким спектром браузеров и интернет-платформ. В условиях, когда главным приоритетом было обеспечение хорошего качества веб-страниц, XHTML стал тем инструментом, который сумел удовлетворить все потребности разработчиков. В результате с 2000 по 2014 год, более десяти лет, XHTML был стандартизированным HTML следующего поколения. HTML 5 Самая последняя и современная версия - HTML 5. В ней поддерживаются все теги и другие элементы, такие как элементы ввода различных типов, теги поддержки, геолокацию и пр. Основная цель внедрения HTML 5 состояла в том, чтобы удовлетворить две вещи - улучшить язык и соответствовать новейшим разработкам в области мультимедиа. При этом в HTML 5 были введен ряд новых тегов, например: Тег электронной почты. Это совершенно новый тег, появившийся в HTML 5. Данный элемент ввода является тегом формы, который осуществляет проверку или аутентификацию введенного значения. Это дает уверенность в том, что введенные данные являются подлинным именем электронной почты. Тег пароля. Данный тег является элементом ввода и предназначен для ввода пароля пользователя. При использовании этого тега пароль будет виден во время ввода и показан специальными символами. Этот тег защищает пароль символическим экраном. Аудиотег. Данный тег был добавлен для вставки аудио на веб-страницы. Семантические теги. Еще одно название структурных тегов. С помощью семантических тегов вы можете распределять и разделять веб-страницу HTML на различные структуры. Эти структуры объединяются, чтобы сформировать веб-страницу HTML. Теги разделов. Эти теги позволяют разбивать HTML документ на разделы. Важными семантическими/структурными тегами являются пояснения к изображениям, шапка/заголовок и подвал. Существует множество причин использовать HTML 5. Некоторые из них практичны и философичны, другие альтруистичны, а многие эгоистичны. На HTML 5 удобнее писать, поддерживать, реструктурировать документ. Он лучше подходит для поисковой оптимизации (SEO), для агрегаторов контента и систем чтения каналов, легко доступен на мобильных устройствах, может работать даже для пользователей с более медленным подключением к Интернету и меньше уязвимы для слома дизайна, он обеспечивает безопасный и простой путь для добавления мультимедийных элементов. В настоящее время HTML 5 рассматривается как будущее этого языка программирования. СSS2. Особенности применения. CSS (Cascading Style Sheets) — язык таблиц стилей, который позволяет прикреплять стиль (например, шрифты и цвет) к структурированным документам (например, документам HTML и приложениям XML). Обычно CSS-стили используются для создания и изменения стиля элементов веб-страниц и пользовательских интерфейсов, написанных на языках HTML и XHTML, но также могут быть применены к любому виду XML-документа, в том числе XML, SVG и XUL. Отделяя стиль представления документов от содержимого документов, CSS упрощает создание веб-страниц и обслуживание сайтов. CSS поддерживает таблицы стилей для конкретных носителей, поэтому авторы могут адаптировать представление своих документов к визуальным браузерам, слуховым устройствам, принтерам, брайлевским устройствам, карманным устройствам и т.д. Каскадные таблицы стилей описывают правила форматирования элементов с помощью свойств и допустимых значений этих свойств. Для каждого элемента можно использовать ограниченный набор свойств, остальные свойства не будут оказывать на него никакого влияния. Объявление стиля состоит из двух частей: селектора и объявления. В HTML имена элементов нечувствительны к регистру, поэтому «h1» работает так же, как и «H1». Объявление состоит из двух частей: имя свойства (например, color) и значение свойства (grey). Селектор сообщает браузеру, какой именно элемент форматировать, а в блоке объявления (код в фигурных скобках) перечисляются форматирующие команды — свойства и их значения. Хотя приведенный пример пытается влиять только на пару свойств, необходимых для рендеринга HTML-документа, он сам по себе квалифицируется как таблица стилей. В сочетании с другими таблицами стилей (одна фундаментальная особенность CSS заключается в том, что таблицы стилей объединяются), правило будет определять окончательное представление документа. Блочная верстка сайта. Верстка типовых шаблонов. Блочная верстка заключается в использовании блоков при составлении страниц сайта. Иногда применяют термин верстка слоями. В наше время активно применяется блочная верстка, сайт состоит из блоков, к примеру : шапка - баннер, раздел меню, основной контент, боковая колонка, подвал. Сами эти блоки тоже могут состоять из элементов блоков. Тег может быть вложенным, к ним применяются разные классы, и этим классам даются определенные стили , оформления. Ранее сайты составляли часто табличной версткой, то есть применяли тег
|
