Проверка кроссбраузерность: ▷ Как проверить отображение сайта во всех браузерах: что такое кроссбраузерность?

alexxlab

Содержание

▷ Как проверить отображение сайта во всех браузерах: что такое кроссбраузерность?

77427 2 1

How-to – Читать 7 минут

Прочитать позже

ЧЕК-ЛИСТ: ТЕХНИЧЕСКАЯ ЧАСТЬ — КОД СТРАНИЦ

Инструкцию одобрил
SEO-специалист в Luxeo

Илья Беланенко

Посетители вашего сайта пользуются разными браузерами. В некоторых версиях сайт может работать некорректно или отображаться некрасиво, люди будут уходить. Тестируйте кроссбраузерность, чтобы понизить показатель отказов и увеличить конверсию.

Содержание:

  1. Что такое кроссбраузерность
  2. Проверка кроссбраузерности сайта
  3. Заключение

Что такое кроссбраузерность

Кроссбраузерность — это свойства сайта, которые позволяют ему одинаково отображаться в разных браузерах. Помните, что совместимость браузеров разная.

Не путайте кроссбраузерность с адаптивностью. Адаптивность означает, что ваш веб-сайт корректно выглядит на разных устройствах:

  • ПК;
  • мобильных устройствах;
  • планшетах и прочем.

В этом случае имеется в виду приспосабливаемость под тип устройства и разрешение экрана, но совсем не вид сайта в браузере ПК.

Влияние кроссбраузерности на SEO-продвижение связано с юзабилити для пользователя. Хорошее юзабилити положительно воздействует на поведенческие факторы, которые добавляют вес в SERP, а также повышают позиции сайта в поиске.

Проверка кроссбраузерности сайта

Чтобы узнать, корректно ли отображается ваш сайт в разных браузерах, воспользуйтесь ручными способами, проверив сайт с разных браузеров:

  • Google Chrome;
  • Safari;
  • Opera;
  • Mozilla Firefox;
  • Internet Explorer / Microsoft Edge.

Чтобы посмотреть, какими браузерами пользуется ваша аудитория и расширить данный список, воспользуйтесь любой системой аналитики.

Рассмотрим это на примере Google Analytics. В меню слева найдите раздел «Аудитория», промотав пункты которого нужно выбрать «Технологии». В раскрывшемся меню есть строчка «Браузеры и ОС», где находится необходимый отчет:

Однако при ручной проверке вы не увидите версии браузеров, которые еще не использовались при переходе на сайт. Данные считываются только по состоявшимся заходам.

Проверка вручную займет много времени. Поэтому лучше выполните тестирование с помощью одного из предложенных ниже инструментов. Это сэкономит ваше время и позволит сделать проверку максимально доступного количества браузеров.

Browsershots

Browsershots делает скриншоты вашего сайта в разных операционных системах и браузерах. Это бесплатный сервис с открытым исходным кодом, предлагающий разработчикам удобный способ проверить внешний вид дизайна для разных сегментов пользователей.

Когда вы отправляете свой веб-адрес, он добавляется в очередь заданий. Ряд распределенных компьютеров открывает ваш веб-сайт в своем браузере. Затем они делают скриншоты и загружают их на центральный выделенный сервер. В свою очередь вы получаете результат проверки по 65 разным браузерам и их версиям бесплатно.

Перейдите по ссылке, чтобы выполнить тест:

В активном поле следует указать гиперссылку на тестируемый веб-сайт, затем нажмите кнопку «Submit», как на скриншоте:

Когда система завершит проверку, вы узнаете кроссбраузерность сайта и увидите скриншоты:

Инструмент бесплатно проверяет сайт в порядке очереди, поэтому иногда возникают задержки из-за нагрузки на сервер. Платная версия предполагает проверку вне очереди и конфиденциальность итоговых скриншотов.

CrossBrowserTesting

CrossBrowserTesting — платный инструмент с триал-доступом на 7 дней. Для разовой проверки этого достаточно. Сервис совершает проверку через более чем 1500 десктопных и мобильных браузеров. Проверки могут происходить автоматически через заданный период.

Для начала теста зарегистрируйте бесплатный аккаунт и подтвердите свой почтовый адрес. Далее, авторизовавшись в личном кабинете, начните тест. Необходимые для работы вкладки выделены на скриншоте:

Укажите ссылку, нажмите «Run Test» и получите результат проверки.

Saucelabs

Saucelabs оценивает совместимость не только браузеров ПК, но и мобильных устройств. Сервис платный, но есть бесплатный доступ длительностью в 14 дней. После регистрации и подтверждения учетной записи зайдите в аккаунт.

Далее в пункте «Live Testing» из левого верхнего меню откроется страница, где необходимо вставить скопированный заранее URL-адрес сайта и нажать кнопку «Start Session» в правом нижнем углу.

NetRenderer

NetRenderer — бесплатный инструмент. Позволяет проверить отображение сайта в Internet Explorer 11, 10, 9, 8, 7, 6 или 5. 5 версиях.

Обычно снимок показывает самую верхнюю часть вашей веб-страницы. Если вы хотите посмотреть, как выглядит страница внизу, просто введите вертикальное смещение справа от поля URL и снова нажмите «Render».

Через несколько секунд вы получите снимок своей веб-страницы.

Browsera

Browsera уведомит о проблемных версиях браузеров для вашего сайта. Вместо того, чтобы самостоятельно проверять каждый скриншот, здесь вы получите отчет с подробным описанием страниц, которые имеют потенциальные проблемы.

Browsera работает на тестер и ищет визуальные расхождения между разными браузерами. Каждый раз, когда Browsera загружает страницу, сервис проверяет, не обнаружил ли браузер какие-либо ошибки сценария. К примеру, ошибки JavaScript могут привести к потере функциональности на сайте.

Инструмент платный, но с гарантией возврата средств в течение 30 дней.

Пример отчета с подсвеченными проблемными участками:

Чтобы быстро узнать какие проблемы есть у твоего сайта и получить рекомендации по их устранению, нажимай на Проверить свой сайт.

Хотите узнать, как с помощью Serpstat найти и исправить технические ошибки на сайте?

Оставьте заявку и наши специалисты проконсультируют вас по продвижению вашего проекта, поделятся учебными материалами и инсайтами рынка!

Заказать бесплатную консультацию

Заключение

Кроссбраузерность — это идентичность отображения веб-ресурса в разных браузерах и их версиях. Некорректный вид сайта отталкивает пользователей, что плохо для поведенческих факторов и SEO.

Проверить кроссбраузерность позволяет ряд автоматических сервисов, некоторые из них платные, но у большинства присутствует триал-доступ.

В данной статье мы рассмотрели несколько тестировщиков:

Browsershots.

CrossBrowserTesting.

Saucelabs.

NetRenderer.

Browsera.

Существует и ручной способ проверки. Для этого следует выяснить через Google Analytics, какими браузерами пользуются ваши посетители, и вручную открыть свой сайт во всех указанных браузерах.

Задавайте вопросы в комментариях или пишите в техподдержку.:) А также вступайте в чат любителей Серпстатить и подписывайтесь на наш канал в Telegram.

Сэкономьте время на изучении Serpstat

Хотите получить персональную демонстрацию сервиса, тестовый период или эффективные кейсы использования Serpstat?

Оставьте заявку и мы свяжемся с вами 😉

Оцените статью по 5-бальной шкале

3.68 из 5 на основе 28 оценок

Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Рекомендуемые статьи

How-to

Анастасия Сотула

Покупка трафика: как купить трафик на сайт и где это сделать

SEO +1

Ilkhom Chakkanbaev

Как задать в robots.txt директивы для роботов различных поисковых систем

How-to

Denys Kondak

Как настроить мониторинг упоминаний бренда в сети

Кейсы, лайфхаки, исследования и полезные статьи

Не успеваешь следить за новостями? Не беда! Наш любимый редактор подберет материалы, которые точно помогут в работе. Только полезные статьи, реальные кейсы и новости Serpstat раз в неделю. Присоединяйся к уютному комьюнити 🙂

Нажимая кнопку, ты соглашаешься с нашей политикой конфиденциальности.

Поделитесь статьей с вашими друзьями

Вы уверены?

Спасибо, мы сохранили ваши новые настройки рассылок.

Сообщить об ошибке

Отменить

Введение в кросс-браузерное тестирование — Изучение веб-разработки

  • Обзор: Cross browser testing
  • Далее (en-US)

Эта статья начинает модуль с обзора темы кросс-браузерного тестирования, отвечая на такие вопросы как «что такое кросс-браузерное тестирование?», «с какими распространёнными проблемами можно столкнуться?» и «какие основные подходы для тестирования, обнаружения и исправления проблем существуют?»

Необходимые условия:Знакомство с основами HTML, CSS, и JavaScript.
Цель:Улучшить понимание идей кроссбраузерного тестирования.

Кросс-браузерное тестирование — это практика обеспечения уверенности в том, что веб-сайты и веб-приложения, которые вы создаёте, работают в приемлемом количестве браузеров. Обязанность веб-разработчика быть уверенным, что проект работает не только у вас, а у всех ваших пользователей, независимо от браузера, устройства, или других вспомогательных инструментов, которые они используют. Вы должны думать о:

  • Других браузерах. Не тех нескольких, которые вы регулярно используете, а о довольно старых, которые некоторые люди могут использовать до сих пор, и которые не поддерживают современные возможности CSS и JavaScript.
  • Разных устройствах с разными возможностями, начиная от последних лучших планшетов, смартфонов и «умных» телевизоров, до дешёвых устройств и самых старых смартфонов, в которых браузеры могут работать с ограниченными возможностями.
  • Людях с инвалидностью, которые используют Web с помощью вспомогательных технологий, таких как скринридеры, или не используют мышь (некоторые используют только клавиатуру).

Поймите, что вы — не ваши пользователи — если ваш сайт работает на Macbook Pro или Galaxy Nexus, это не значит, что он будет работать так для всех пользователей — нужно сделать много тестов!

Примечание: Статья сделаем веб доступным для всех предоставляет более полезную информацию о различных браузерах, которые используют люди, их доле рынка и связанных с этим проблемах совместимости браузеров.

Мы должны поговорить немного о терминологии. Для начала, когда мы говорим о сайтах, «работающих кросс-браузерной», на самом деле мы говорим о том, что они должны обеспечивать приемлемое удобство использования в разных браузерах. Это нормально, если сайт выглядит немного по-разному в разных браузерах, главное он должен обеспечивать полную функциональность.В современных браузерах вы можете сделать что-то анимированным или использовать 3D, тогда как в старых браузерах вы можете лишь показать плоскую картинку, предоставляющую ту же информацию. Если владелец сайта доволен, вы сделали своё дело.

С другой стороны, плохо, когда сайт полноценно работает для обычных людей, но может быть совершенно недоступен для людей, имеющих проблемы со зрением, т.к. их приложения для чтения экрана не могут распознать информацию на сайте.

Когда мы говорим «приемлемое количество браузеров», мы не говорим, что это должно быть 100% всех браузеров в мире — это почти невозможно. Вы можете собрать информацию о том, какими браузеры и устройства используют ваши пользователи (это мы обсудим во второй статье — см. Gotta test ’em all?), но это ничего не гарантирует. Как веб-разработчик, вы должны определить для себя несколько браузеров и устройств, на которых код должен работать полностью, но кроме этого, вы должны писать код так, чтобы и другие браузеры были способны максимально использовать ваш сайт (defensive coding). Это одна из самых больших проблем веб-разработки.

Примечание: Мы разберём defensive coding позже в этом модуле.

Есть множество причин, почему возникают кросс-браузерные проблемы, и, заметьте, что сейчас мы говорим о проблемах, при которых некоторые вещи ведут себя по-разному в разных браузерах / устройствах / настройках просмотра. Прежде чем вы столкнётесь с проблемами браузера, вы должны исправить все ошибки в коде (см. Отладка HTML, Отладка CSS, and Что пошло не так? Устранение ошибок JavaScript из предыдущего раздела).

Кросс-браузерные проблемы возникают потому-что:

  • иногда браузеры содержат баги, или реализуют возможности по-разному. В настоящее время это не такая частая проблема, но когда IE4 и Netscape 4 конкурировали за право быть доминирующим браузером в 90-е, компании-разработчики браузеров умышленно реализовывали возможности по-своему в попытке получить конкурентное преимущество, что делало жизнь веб-разработчикам адом. Сейчас же браузеры гораздо жёстче соблюдают стандарты, но различия и баги всё же иногда возникают.
  • браузеры имеют разную степень поддержи современных технологий. Это неизбежно, когда вы имеете дело с новейшими функциями, которые браузеры только начинают осваивать, или если вы вынуждены поддерживать очень старые браузеры, которые более не дорабатываются или которые могли быть заморожены (то есть в них не добавляют новый функционал) задолго до того, как придумали новые возможности. Например, если вы хотите использовать передовые возможности JavaScript на вашем сайте, то они могут не работать в старых браузерах. Если вам нужна поддержка старых браузеров, вы можете конвертировать ваш код под старый синтаксис, используя специальные компиляторы.
  • некоторые устройства могут иметь ограничения, из-за которых сайт работает медленно или отображается неверно. Например, если сайт был спроектирован для просмотра на десктопных устройствах, он возможно будет выглядеть мелко и трудночитаемо на мобильных устройствах. Если ваш сайт содержит множество больших анимаций, это может быть хорошо на высокопроизводительных планшетах, но может быть вялым или резким на устройствах меньшей производительности.

а также другие причины.

В статьях далее, мы выясним основные проблемы кросс-браузерности и посмотрим на их решения.

Может показаться, что тестирование — это затратно и страшно, но это важно — вы должны спланировать и убедиться, что вы делаете тесты в нужных местах, чтобы не было неожиданных проблем. Если вы работаете над большим проектом, вы должны тестировать его регулярно, чтобы убеждаться, что новые возможности работают корректно для вашей целевой аудитории, и что новый код не ломает старый функционал.

Если вы будете тестировать в конце проекта, любые не обнаруженные баги будут гораздо более затратными по времени для исправления, если бы вы их тестировали и обнаруживали своевременно.

Рабочий процесс над тестированием и исправлением ошибок может быть разбит на следующие четыре фазы (очень грубое разделение — у разных людей этот процесс может очень сильно отличаться):

Начальное планирование > Разработка > Тестирование > Исправление ошибок

Шаги 2-4 будут повторяться до тех пор, пока не будут реализованы все возможности. Мы рассмотрим различные элементы процесса тестирования более детально в следующих статьях, но пока давайте соберём то, что может происходить на каждом этапе.

Начальное планирование

На этом этапе у вас, возможно, будет несколько встреч с владельцем/заказчиком сайта (это может быть ваш босс или кто-то из другой компании, для кого вы пишете сайт), чтобы точно определить, каким должен быть сайт — какой контент и функциональность должны быть на сайте, как сайт должен выглядеть и т. д. На этом этапе вы также хотите знать сколько времени у вас есть на разработку и цену работы. Не хочется углубляться в детали, но такое планирование оказывает большое влияние на кросс-браузерное тестирование.

Once you’ve got an idea of the required featureset, and what technologies you will likely build these features with, you should start exploring the target audience — what browsers, devices, etc. will the target audience for this site be using? The client might already have data about this from previous research they’ve done, e.g. from other web sites they own, or from previous versions of the web site you are now working on. If not, you will be able to get a good idea by looking at other sources, such as usage stats for competitors, or countries the site will be serving. You can also use a bit of intuition.

So for example, you might be building an e-commerce site that serves customers in North America. The site should work entirely in the last few versions of the most popular desktop and mobile (iOS, Android, Windows phone) browsers — this should include Chrome (and Opera as it is based on the same rendering engine as Chrome), Firefox, IE/Edge, and Safari. It should also provide an acceptable experience on IE 8 and 9, and be accessible with WCAG AA compliance.

Now you know your target testing platforms, you should go back and review the required featureset and what technologies you are going to use. For example, if the e-commerce site owner wants a WebGL-powered 3D tour of each product built into the product pages, they will need to accept that this just won’t work in IE versions before 11. You’d have to agree to provide a version of the site without this feature to users of older IE versions.

You should compile a list of the potential problem areas.

Note: You can find browser support information for technologies by looking up the different features on MDN — the site you’re on! You should also consult caniuse.com, for some further useful details.

Once you’ve agreed on these details, you can go ahead and start developing the site.

Development

Now on to the development of the site. You should split the different parts of the development into modules, for example you might split the different site areas up — home page, product page, shopping cart, payment workflow, etc. You might then further subdivide these — implement common site header and footer, implement product page detail view, implement persistent shopping cart widget, etc.

There are multiple general strategies to cross browser development, for example:

  • Get all the functionality working as closely as possible in all target browsers. This may involve writing different code paths that reproduce functionality in different ways aimed at different browsers, or using a Polyfill to mimic any missing support using JavaScript or other technologies, or using a library that allows you to write a single bit of code and then does different things in the background depending on what the browser supports.
  • Accept that some things aren’t going to work the same on all browsers, and provide different (acceptable) solutions in browsers that don’t support the full functionality. Sometimes this is inevitable due to device constraints — a cinema widescreen isn’t going to give the same visual experience as a 4″ mobile screen, regardless of how you program your site.
  • Accept that your site just isn’t going to work in some older browsers, and move on. This is OK, provided your client/userbase is OK with it.

Normally your development will involve a combination of the above three approaches. The most important thing is that you test each small part before committing it — don’t leave all the testing till the end!

Testing/discovery

After each implementation phase, you will need to test the new functionality. To start with, you should make sure there are no general issues with your code that are stopping your feature from working:

  1. Test it in a couple of stable browsers on your system, like Firefox, Safari, Chrome, or IE/Edge.
  2. Do some low fi accessibility testing, such as trying to use your site with only the keyboard, or using your site via a screen reader to see if it is navigable.
  3. Test on a mobile platform, such as Android or iOS.

At this point, fix any problems you find with your new code.

Next, you should try expanding your list of test browsers to a full list of target audience browsers and start concentrating on weeding out cross browser issues (see the next article for more information on determining your target browsers). For example:

  • Try to test the latest change on all the modern desktop browsers you can — including Firefox, Chrome, Opera, IE, Edge, and Safari on desktop (Mac, Windows, and Linux, ideally).
  • Test it in common phone and tablet browsers (e.g. iOS Safari on iPhone/iPad, Chrome and Firefox on iPhone/iPad/Android),
  • Also do tests in any other browsers you have included inside your target list.

The most low fi option is to just do all the testing you can by yourself (pulling in team mates to help out if you are working in a team). You should try to test it on real physical devices where possible.

If you haven’t got the means to test all those different browser, operating system, and device combinations on physical hardware, you can also make use of emulators (emulate a device using software on your desktop computer) and virtual machines (software that allows you to emulate multiple operating system/software combinations on your desktop computer). This is a very popular choice, especially in some circumstances — for example, Windows doesn’t let you have multiple versions of Windows installed simulataneously on the same machine, so using multiple virtual machines is often the only option here.

Another option is user groups — using a group of people outside your development team to test your site. This could be a group of friends or family, a group of other employees, a class at a local university, or a professional user testing setup, where people are paid to test out your site and provide results.

Finally, you can get smarter with your testing using auditing or automation tools; this is a sensible choice as your projects get bigger, as doing all this testing by hand can start to take a really long time. You can set up your own testing automation system (Selenium being the popular app of choice) that could for example load your site in a number of different browsers, and:

  • see if a button click causes something to happen successfully (like for example, a map displaying), displaying the results once the tests are completed
  • take a screenshot of each, allowing you to see if a layout is consistent across the different browsers.

You can also go further than this, if wished. There are commercial tools available such as Sauce Labs, Browser Stack, LambdaTest, TestingBot, and CrossBrowserTesting that do this kind of thing for you, without you having to worry about the setup, if you wish to invest some money in your testing. It is also possible to set up an environment that automatically runs tests for you, and then only lets you check in your changes to the central code repository if the tests still pass.

Testing on prerelease browsers

It is often a good idea to test on prerelease versions of browsers; see the following links:

  • Firefox Developer Edition
  • Edge Insider Preview
  • Safari Technology Preview
  • Chrome Canary
  • Opera Developer

This is especially prevalent if you are using very new technologies in your site, and you want to test against the latest implementations, or if you are coming across a bug in the latest release version of a browser, and you want to see if the browser’s developers have fixed the bug in a newer version.

Fixes/iteration

Once you’ve discovered a bug, you need to try to fix it.

The first thing to do is to narrow down where the bug occurs as much as possible. Get as much information as you can from the person reporting the bug — what platform(s), device(s), browser version(s), etc. Try it on similar configurations (e.g. the same browser version on different desktop platforms, or a few different versions of the same browser on the same platform) to see how widely the bug persists.

It might not be your fault — if a bug exists in a browser, then hopefully the vendor will rapidly fix it. It might have already been fixed — for example if a bug is present in Firefox release 49, but it is no longer there in Firefox Nightly (version 52), then they have fixed it. If it is not fixed, then you may want to file a bug (see Reporting bugs, below).

If it is your fault, you need to fix it! Finding out the cause of the bug involves the same strategy as any web development bug (again, see Debugging HTML, Debugging CSS, and What went wrong? Troubleshooting JavaScript). Once you’ve discovered what is causing your bug, you need to decide how to work around it in the particular browser it is causing problems in — you can’t just change the problem code outright, as this may break the code in other browsers. The general approach is usually to fork the code in some way, for example use JavaScript feature detection code to detect situations in which a problem feature doesn’t work, and run some different code in those cases that does work.

Once a fix has been made, you’ll want to repeat your testing process to make sure your fix is working OK, and hasn’t caused the site to break in other places or in other browsers.

Just to reiterate on what was said above, if you discover bugs in browsers, you should report them:

  • Firefox Bugzilla
  • EdgeHTML issue tracker
  • Safari
  • Chrome
  • Opera

This article should have given you a high-level understanding of the most important concepts you need to know about cross browser testing. Armed with this knowledge, you are now ready to move on and start learning about Cross browser testing strategies.

  • Обзор: Cross browser testing
  • Далее (en-US)
  • Introduction to cross browser testing
  • Strategies for carrying out testing
  • Handling common HTML and CSS problems
  • Handling common JavaScript problems
  • Handling common accessibility problems
  • Implementing feature detection
  • Introduction to automated testing
  • Setting up your own test automation environment

Last modified: , by MDN contributors

Проверка кроссбраузерности, кроссплатформенности и других ошибок

  • Главная
  • Повышение конверсии сайта
  • Технические ошибки и ошибки в структуре сайта

О технических ошибках много говорилось в пятой главе, посвященной оптимизации сайта. Ниже мы приведем основные примеры технических ошибок в разрезе юзабилити.

Кроссбраузерность — способность сайта отображаться и работать во всех популярных браузерах корректно и показывать материал с одинаковой степенью читабельности.

1. Ошибки кроссбраузерности, кроссплатформенности и ошибки тестирования. Часто бывает, что сайт делается без учета кроссбраузерности и тестируется только в одном браузере, а в остальных — один слой сайта наползает на другой. Если ресурс сделан в «резиновом» шаблоне, т.е. ширина сайта изменяется в зависимости от разрешения монитора, обязательно нужно проверить его в различных браузерах и разрешениях экрана. При низких разрешениях одни элементы могут наезжать на другие. Осуществить проверку кроссбраузерности можно с помощью специализированных сервисов, например, BrowserShots.org.

Кроссплатформенность — это способность сайта полноценно работать на всех устройствах и операционных системах, которые использует посетитель.

2. Динамическая навигация — это прием, при котором навигация по ресурсу, т.е. вертикальное и горизонтальное меню, изменяется в зависимости от страницы. Если навигация сложная, то пользователь, запутавшись, покинет ресурс, так и не отправив заявку. При работе с юзабилити сайта нужно помнить, что чем проще и привычнее организован ресурс, тем выше вероятность удачной транзакции. Меню, как вертикальное, так и горизонтальное, должно сохранять единообразие на всем сайте.

3. Ошибки в выпадающем меню. Распространенной ошибкой является всплывающее меню без задержки исчезновения. К примеру, пользователь навел курсор на один из пунктов бокового меню, и появился новый уровень меню; при попытке выбрать нужную ссылку из этого подменю оно исчезает. Пользователь, вероятно, повторит операцию несколько раз, но, не перейдя никуда в пределах сайта, уйдет с него. Другой технический момент, связанный с выпадающим меню, — большой список за пределами первого окна экрана. Это также усложняет выбор требуемого пункта и нарушает визуальную законченность сайта. Движение пользователя по ресурсу не должно быть затруднено, лишние действия и клики удаляют посетителя от совершения покупки.

4. Отсутствие основных пунктов меню в системе навигации. Например, отсутствие «хлебных крошек» затрудняет переход с нижнего уровня сайта на верхний. Пользователя также дезориентирует отсутствие указания на принадлежность страницы к определенному пункту меню.

5. Логотип не ведет на главную страницу. Логотип компании должен вести только на главную страницу. Этот нюанс построения сайта начинается с развития рунета и, в частности, поисковой системы Яндекс, где логотип всегда вел на главную страницу сайта. Если ссылка с логотипа ведет пользователя не на главную страницу, это может вызвать у него замешательство и даже раздражение. Также логотип, не являющийся ссылкой, создает для пользователей дополнительные трудности в навигации по сайту.

6. Наличие всплывающих окон. Всплывающее рекламное окно, которое внезапно появляется на сайте и блокирует дальнейшую работу, вызывает у пользователя желание как можно быстрее закрыть его, и часто он закрывает сразу весь сайт. Чтобы не терять посетителей, настройте на своем ресурсе открытие всплывающих окон только по клику пользователя.

7. Главная страница выбивается из стилистики сайта или несет очень низкую смысловую нагрузку. Прием со «страницей входа» (на которой пользователь, например, выбирает язык или город) оправдан только для крупных, широко известных компаний. Попадая на ресурс компании BMW пользователь не задается вопросом, чем занимается данная компания. Попадая же на малоинформативную входную страницу неизвестной фирмы, пользователь, не получив сведений о направлениях работы этой организации, покидает сайт. Главная страница должна содержать графический и текстовый контент, позволяющий посетителю сайта понять направление деятельности компании.

8. Неграмотное оформление страницы 404 ошибки. Если пользователь случайно переходит на страницу с несуществующим URL, он видит страницу 404 ошибки. При попадании на нее посетитель должен сразу понять, что он находится в несуществующей части сайта; чем быстрее произойдет данная идентификация, тем лучше. Яндекс рекомендует ограничиться информацией о том, что данная страница не существует, и предложить пользователю перейти на главную страницу, не размещая подробное меню и множество баннеров. Чтобы пользователь понимал, что он не покинул ресурс, рекомендуется на странице 404 ошибки также добавить логотип компании.

9. Слишком большое количество опций. Данная ошибка может относиться к таким функциональным элементам, как форма заявки, фильтр товаров, поиск по сайту и т.д. К примеру, форма отправки заявки должна содержать указание на основные пункты (услуга, которую заказывает клиент, и его контактные данные) и необязательные (индекс, описание заказа и т.д.). Количество полей в форме заказа должно быть необходимым и достаточным, чтобы вы могли доставить покупку, но пользователь при этом не был утомлен заполнением веб-формы. О том, как настроить веб-форму, читайте в книге «Введение в генерацию лидов».

10. Неуместное использование технических элементов или их неработоспособность. На сайте все должно вести пользователя к основной цели ресурса. Если на пути к этой цели расставлены препятствия в виде ненужной анимации, рекламных баннеров, всплывающих окон, неработающих кнопок и ссылок, то ожидать лояльности посетителя не стоит. Представьте, что пользователь уже готов оформить заказ, но кнопка «Купить» не нажимается! Все элементы сайта должны нормально функционировать, их использование должно быть продуманным. На примере ниже представлено меню с прокруткой, которое расположено поверх картинки, хотя в данном случае подошел бы просто выпадающий список на белом фоне.

Чтобы проверить сайт на предмет технических юзабилити-ошибок, обозначьте все возможные пути заказа товара или услуги и пройдите по ним сами, не забывая использовать сервисы для проверки кроссбраузерности и кроссплатформенности. Найденные ошибки исправьте как можно скорее, чтобы получить как можно больше клиентов с сайта.

Вернуться назад: Юзабилити сайтаЧитать далее: Ошибки в дизайне сайта

 

 

Как сделать проверку сайта на кроссбраузерность

13.10.2021 | Рубрика: Создание сайта |