Адаптация таблиц под мобильные устройства
Почти все дизайнеры сталкиваются с проблемой адаптации при отрисовке таблиц в интерфейсах — а именно адаптации таблиц под мобильные устройства. Справедливо также будет отметить полезность статьи для Frontend разработчиков, которые эти самые таблицы верстают.
Проблема
Проблема у дизайнера начинается в тот момент, когда таблица из десктопной версии интерфейса адаптируется под мобильные устройства. Как мы знаем — таблицы могут иметь много столбцов, что влечёт за собой вылеты таблицы за ширину экрана на мобильном устройстве.
Данная проблема встречается повсеместно, и усугубить ее может пожалуй лишь контент ячейки, который не переносится построчно, увеличивая тем самым ширину колонки.
Подопытный набор данных
Для того чтобы понимать лучше суть проблемы, мы придумаем себе таблицу, и будем ее адаптировать.
Результатом станет довольно обширная таблица, которая имеет все нужные нам виды колонок. Признаться даже список сверху вызывает у меня вопросы — справа тратится слишком много места.
С фиксированной шириной и переносом строк
С шириной по контенту
Анонс следующей статьи “О списках в интерфейсах и как их применять по феншую”.
Десктоп
В окне браузера наша таблица будет довольно комфортно себя чувствовать. Мы можем контролировать отображение контента так, как нам нужно. Даже если таблица перестанет помещаться по ширине — то мы всегда можем либо скрыть пару колонок с самым низким приоритетом, либо в крайнем случае сделать скроллинг по горизонтали.
Варианты адаптации
Проблема — наша таблица по ширине не влезает в телефон.
Делать растровую картинку с таблицей и вставлять ее в макет
Возможные верные решения по убыванию
Каждую строку таблицы делать блоком
Первый вариант адаптации — сделать каждую строку таблицу отдельным блоком, и вывести ее на экране телефона.
Проблема с данным методом: Удлиняется вертикальный скроллинг, данные повторяются. (частично решается добавлением фильтров для поиска)
Возьмём за пример таблицу, которая отображена сверху. В таком виде она не поместится по ширине в мобильный экран. Для решения этой проблемы мы будем каждую строку таблицы преобразовывать в блок.
Таким образом мы добьемся максимальной читаемости таблицы, без потери данных. Мы видим в строке все столбцы, при необходимости можем сделать функцию поиска, а так же добавить сортировки для блоков. Проблемой при данном подходе является длинный скроллинг.
Второй вариант — горизонтальный скроллинг таблицы
Для реализации данного подхода — нам нужно взять таблицу из десктопной версии сайта, и поместить ее в мобильный экран, а весь тот контент, который не помещается по ширине вынести за границы экрана, добавив при этом горизонтальную прокрутку к скрытым столбцам.
Субъективно для меня — это наименее подходящий вариант отображения таблиц в мобильных устройствах — так, как он скрывает большую часть контента за пределами окна устройства — что нарушает визуальную целостность данных контекста каждой строки таблицы (мы не видим строку целиком).
Вывод
Теперь адаптация таблиц не должна нам казаться невыполнимой задачей, мы научились делать так, чтобы таблицы были удобоваримыми не только на десктопной версии сайтов, но и в мобильной (что применимо и к мобильным приложениям).
Если вы заметили ошибки, или вам есть что дополнить — дайте мне знать, я обязательно это сделаю. Спасибо за внимание!
Opencart: Мобильная версия, правка шаблона «по умолчанию»
При всех ворчаниях, которые у меня происходят при работе с новыми CMS, кое, что меня всё же привлекло в Opencart, а именно то, что шаблоны (по умолчанию) уже настроены под мобильную версию (по крайней мере, версия Opencart 2.3 точно) сайта. Таким образом, небольшие правки цветовой гаммы и, по крайней мере, вопросом дизайна (а в особенности вёрстки) можно не задаваться.
Однако и в этом вопросе меня ждали сюрпризы и «подводные камни». Поскольку за время эксплуатации магазина стали появляться те или иные вопросы, так например «цена по акции», заказчику захотелось, чтобы «перечёркнутая» линия была красного цвета (а цвет текста при этом был чёрным). Таблица стилей CSS спасла меня в этой ситуации, следующим кодом:
text-decoration: line-through #f00;
Но ввиду того, что айфоны эту строку игнорируют, пришлось её немного дополнить:
text-decoration: line-through;
text-decoration: line-through #f00;
Следующие правки касались уже непосредственно самого шаблона и именно мобильной версии. Первое, что следует отметить, что все нужные настройки прописаны в следующем файле:
ROOT:\\catalog\view\javascript\bootstrap\css\bootstrap.min.css
Так, например, передо мной была поставлена задача «вернуть» кнопку «КУПИТЬ» (которая шаблоном скрывается в мобильной версии), когда я открыл файл таблицы стилей, был удивлён и совсем неприятно. Причина тому – всё записано в одну строку и это жутко неудобно, правда меня спас Adobe Dreamweaver.
Собственно надо было только вот эту строку:
Заменить на эту:
Все остальные настройки касательно мобильной версии Opencart так же прописывал в этой строке.
Советы по оптимизации OpenCart, о которых стоит знать каждому
В данном обзоре речь пойдет конкретно об оптимизации загрузки и открытия страниц сайта.
Зачем это нужно?
Во-первых, поисковые системы, такие как Яндекс и Google. Для них скорость это фактор ранжирования сайта. Простыми словами, если сайт медленный, то и рассчитывать на поисковой трафик сложно.
Во-вторых, если сайт тормозит, то вашим же посетителям будет неудобно им пользоваться и они банально уйдут к конкурентам.
Так же важно понимать, что оптимизация это не одно какое-то единичное действие — это набор отдельных шагов, позволяющих в сумме добиться высокой скорости сайта с OpenCart . Утрируя, на 1 рубль ничего не купишь, но если у вас 100 раз по 1 рублю, то это как минимум вкусняшка или две.
Перейдем от слов к практике.
1. Убедитесь, что вы сжали картинки.
Хотя интернет в нынешнее время быстрый, все же стоит следить за количеством и размером картинок.
Например, нередкая ситуация, когда в баннере главной страницы 5-7 картинок с размером по 400-500 Кб. А это 2,0-3,5 Мб для клиента.
Конечно, картинки обычно кэшируются браузером, но для клиента, который впервые открыл ваш сайт, это медленная скорость.
Плюс большой размер страницы не очень нравится поисковым системам, таким как Яндекс и Google.
2. Сожмите и скомпонуйте JS и CSS .
По поводу сжатия. Ничего неожиданного — оно позволяет добиться меньшего веса страниц.
По поводу компоновки. Обычно сам контент ( JS и CSS) скачивается быстро, потому что он небольшой (с Gzip, о котором чуть дальше, это обычно сродни одной картинке, размером до 100-150кб). Другое дело, что когда каждый файл необходимо скачивать отдельно, то это вызывает простои и лишний раз нагружает сайт.
Поясню в самом упрощенном примере (без учета CDN, типа веб-серверов и прочих вещей).
Допустим, у вас 20 JS файлов и 15 CSS файлов. Как обычно поступает браузер? Запрашивает их параллельно у сайта. Звучит вроде как: это должно быть быстрее. Однако, в реальности это вместо 2-х HTTP -запросов (скомпонованных JS и CSS), целых 35 HTTP- запросов. В свою очередь, это вызывает много моментов, таких как одновременное обращение к жесткому диску. Но, чаше же всего вопрос в том, что у веб-сервера попросту ограничено количество соединений. Например, 3000 соединений, при 100 HTTP -запросах от одной страницы без компоновки JS и CSS, позволяют загружать в единицу времени 30 страниц (3000/100), а при 67 HTTP -запросах это примерно 44 страниц (3000/67). Не говоря уже о том, что с параллельностью тоже существуют моменты, но это уже за рамками обзора.
Тем не менее, стоит понимать, что бывают разные ситуации и иногда объединение не нужно. Например, если у вас несколько JS и CSS, то от такой оптимизации может не быть особого толка. Иногда стоит объединять только часть файлов. И так далее.
3. Включите Gzip.
Зачем нужно сжатие Gzip? Ответ прост — позволяет передавать меньше данных через интернет (экономия до 60-70%). В нынешнее время техника уже настолько быстрая, что распаковать небольшие файлы из архива дело миллисекунд. Поэтому это полезно.
Обычно сжатие Gzip либо уже включено в хостинге, либо достаточно добавить в файл . htaccess следующие строки. Для отдельных ситуаций — в интернете полно мануалов с настройкой.
# сжатие text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
4. Создайте недостающие индексы в OpenCart с помощью IMDBOptimizer.
Одна из проблем OpenCart в том , что в ее БД нет ряда индексов. Чаще всего это начинает заметно ощущаться (медленная загрузка, превышение лимитов времени БД в хостинге и т.п.), когда сайт измеряется в тысячах, десятках тысяч и более товаров (хотя и бывают ситуации, когда с меньшим числом товаров, но это уже от установленных модулей зависит). При чем если у вас много атрибутов, то это становится еще более заметным (потому что они растут как на дрожжах).
Для решения этой катавасии и создан модуль IMDBOptimizer. Он позволяет создать индексы за пару щелчков мыши. Плюс обладает еще рядом преимуществ, таких как sql- кэш и логирование (см. описание).
5. Используйте бесплатный инструмент от гугла.
Поисковая система Google предоставляет бесплатный инструмент для определения проблемных мест сайта (адрес https://developers.google.com/speed/pagespeed/insights/?hl=RU).
Пользы от него много, поэтому советую хотя бы ознакомиться.
6. Проверьте наличие медленных модулей в интернет-магазине.
Порой бывает так, что проблема кроется в ряде медленных модулей. Поэтому стоит прошерстить сайт и, путем отключения/включения и замеров, определить насколько сильно они влияют на скорость загрузки и отображения страниц сайта.
При этом советую проверять сразу несколько разных видов страниц: главную, категорию, бренд и отдельный товар.
7. Старайтесь решать задачи интернет-магазина модульным подходом.
Простыми словами, старайтесь по минимуму вносить правки в файлы OpenCart (особенно ядровые) собственными силами.
Суть как минимум в нескольких вещах:
Обычно модули пишутся с расчетом, что они не будут одинокими в сайте, поэтому вероятность, что они будут совместимы с другими модулями и не приведут к проблемам, выше, чем когда вносятся ручные правки. Хотя 100% гарантии не существует.
Обычно у модулей существуют аналоги. Хотя бы посмотреть сколько вариантов модулей скидок и акций. Удобство в том, что процесс замены одного на другой представляет собой несколько щелчков мыши (плюс, естественно, настройка), а не долгое копание в коде OpenCart.
У модулей существует понятие версий. И от версии к версии их возможности обычно растут. У ручных же правок такого не бывает.
Если сайт сильно модифицирован, то большая часть модулей будет требовать допила.
Конечно, бывают разные ситуации. Не всегда существуют модули. Бывает требуются специфические вещи. И так далее. Но, все же.
8. Кэширование.
Суть незатейлива — то, что долго вычисляется, сохраняется в отдельном месте и поэтому быстро отображается во второй и последующий раз.
Однако, отмечу, что кэширование не решает внутренних проблем. Поэтому, например, создание индексов с IMDBOptimizer и поиск медленных модулей не стоит откладывать в сторону.
Поясню «почему?» на примере html -кэша.
Например, если у вас нет уверенности, что каждый из всех ваших товаров товаров будут открывать второй раз (помним, что первая генерация при этом медленная), то для части из них толку от html кэша не будет, так как будет происходить следующая ситуация.
Один пользователь открыл страницу с товаром (долгая загрузка + создание кэша), когда же второй пользователь откроет повторно эту страницу, то она опять будет долго генерироваться, так как html кэш формируется заново (потому что ранее сохраненный кэш устарел).
Иными словами, если у вас не бешеная посещаемость, то многие товары без оптимизации будут медленно открываться. Разве что только основные категории будут быстрыми.
9. Отключайте/удаляйте неиспользуемые модули.
Каждый включенный модуль это потенциальный источник задержек, который пожирает время при генерации и отображении страницы. В частности, это могут быть какие-то вычисления в сервере или добавленные JS /CSS файлы в шаблон. И если от одного модуля может и не будет эффекта, то от десятка вполне возможно.
Поэтому неиспользуемые модули стоит отключать или удалять.
10. Настройте кэширование браузером статических ресурсов.
Каждый браузер кэширует статические ресурсы (скрипты, картинки, стили и т.п.), чтобы не осуществлять их повторную загрузку при каждом открытии страниц.
Однако, вопрос в том, как долго браузер будет их хранить. Этот момент обычно определяется в файле . htaccess. К ак базовый пример, который, в принципе, можно сразу применять (но, естественно, можете настраивать под свои потребности; время задается в секундах):
# Кэшировать html и htm файлы на 6 часов
Header set Cache-Control «max-age=21600»
# Кэшировать css, javascript и текстовые файлы на одну неделю
Header set Cache-Control «max-age=604800»
# Кэшировать флэш и изображения на месяц
Header set Cache-Control «max-age=2592000»
# Отключить кэширование для исполняемых файлов
Header unset Cache-Control
Если у вас еще советы, то смело пишите в комментариях. Это и вам самим будет полезно, так как будет некий чек-лист.