Все новости компании - Pumpinteam.com

Упс, обновите браузер [/] О нас Студия PUMPKIN Наши работы Project Cases Блог Новости Контакты Свяжитесь с нами Спасибо! Ваше сообщение было отправлено. Отправить сообщение PUMPKIN PUMPKIN BACKGROUND STORIES Блог Ниже вы найдете интересные статьи в области дизайна, разработки и жизни нашей студии Ховер умер. Да здравствует ховер! 2 августа 2016 В феврале 2013 года у пользователей появились новые возможности работы с вебом, востребованность которых вот уже 3 года спустя все так же остается немного тайной для разработчиков и дизайнеров. В тот месяц на рынок ворвались 2 новые модели ноутбуков: Chromebook Pixel и Microsoft Surface. Это были первые ноутбуки массового производства с тачскрин экраном. Начиная с того периода, производство 2 в 1 начало активно развиваться. Вместе с тем, перспективы использования ховера стали сомнительными. Как пишет специалист в области UX Джоржан Станици, два с половиной года спустя их команда проводила пользовательское тестирование веб сайта, которые давайл возможность поточно комментировать статьи. Они обнаружили, что множество людей разных возрастных категорий, просматривали большие куски текста проводя курсором мыши по каждой строке. Некоторые даже выделяли текст, который уже был прочитан. Приняв это во внимание, они решили сделать добавления комментария невидимым до тех пор, пока пользователь не наведет курсор на необходимый абзац. Это работало прекрасно… До тех пор, пока один парень не принес Surface Pro. Surgace Pro укомплектован тачпадом (с поддержкой USB мыши) и сенсорным экраном. Пользователь прочитал бы статью таким же образом как бы это он сделал на смартфоне или планшете, исользуя свайт экрана для перелистывания. Следовательно, этот юзер не мог пользоваться их продуктом. Он бы никогда и не увидел его. Даже при условии, что он узнал бы, где смотреть, он бы физически не смог бы увидеть интерфейс. Это сбило с толку их MacOS-центричную команду, и было приняторешение внести этот кейс в категориию очень редких. Surface продавался не очень хорошо, и все ожидали, что он вскоре просто исчезнет с рынка. Но этого не случилось… О дивный новый мир и как использовать в нем ховер Спустя некоторое время, появилось множество Windows и Chromebook ноутбуков,которые имели сенсорные экраны. Каждый уважающий себя производитель ПК сейчас выпускает ноутбуки 2 в 1 (включая Apple). Согласно Международному Центру Данных устройства 2 в 1 составят 30% рынка планшетов к 2020 году. Принимаясь за проектирование продукта для десктоп устройств дизайнеры и разработчики также учитывают особенности ноутбуков 2 в 1. В современном интерфейсе можно встретить замену громоздких кнопок на более мелкие, увеличение количества информации на одном экране и быстрый доступ к возможностям наведения курсора на экране. Это должно быть переосмыслено в нашем современном “сенсорном” мире. "+" ЗА Действие ховера все еще очень важны. Мыши и трекпады еще не ушли с рынка. Использование ховера для таких устройств может дать пользователю необходимую информацию о возможности кликнуть на определенное место и что произойдет при этом. Используйте ховер на кликабельных элементах для юзеров, которые пользуются мышью. Используйте ховер для вызова контекстных действий, но убедитесь, что они не обязательные. Всегда продумывайте основной способ сделать то же действие при помощи пальцев. × Против Никогда не используйте ховер для первичного, основного и первоочередного действия. Н-И-К-О-Г-Д-А. В следующий раз, когда вы прочтете комментарий ваших клиентов о том, что они не могут совершить основное действие на своем ноутбуке, прислушайтесь. Это может привести вас к решению никогда больше не использовать ховер. READ MORE Ещё больше комфорта в разработке фронтенда с TARS 2 июня 2016 Прошли очередные полгода с последних новостей о TARS (раз и два), а значит настало время поделиться новинками. Как всегда напомню, что TARS — это основанный на Gulp сборщик фронтенда, который помогает фронтенд-разработчику или даже целой команде создавать проекты любой сложности. Мы продолжаем уверенное шествие по России и не только. TARS уже используют в Нидерландах, Японии, Китае, Украине, Польше и других странах. Это можно заметить и по количеству звёзд на github, и по числу участников чата в gitter, и по количеству установок TARS-CLI за последний месяц (больше тысячи, а в пике больше 3 тысяч). Мы закрыли почти две сотни issue, выпустили два крупных обновления. Пользователи сборщика активно репортят, участвуют в разработке. Можно сказать, что у нас родилось маленькое сообщество. Основные изменения TARS стал по-настоящему, без каких-либо оговорок, модульным. Скорость запуска и сборки увеличилась в разы. К наиболее значимым изменениям относятся webpack и автообновление проекта (обновление версии сборщика, а не перезагрузка в браузере). Наконец-то JavaScript можно собирать не только простой конкатенацией файлов. Даже стыдно было, что в 2016 году сборка скриптов в TARS была настолько отсталой. Webpack развязал руки в работе с JavaScript. Hot Module Replacement, который также поддерживается в TARS из коробки, творит чудеса. А с опцией injectChanges для стилей в Browser-sync разработка становится просто фантастической — браузер не перезагружается, а на лету применяет изменения в CSS и, если это возможно, в JavaScript. Если пойти дальше, то можно переложить работу со стилями и шаблонами на webpack. Так как любой таск в TARS теперь можно без труда переопределить — перенос ответственности за CSS и шаблонизацию легко реализовать с webpack. Если же говорить только о сборке JavaScript, то webpack тут предоставляет массу возможностей, о которых проще прочесть в документации. Кроме того, со второй версии (она находится в стадии beta-тестирования) появился Tree shaking, который позволяет импортировать в каждую точку приложения только тот код, который реально используется в модуле. С приходом webpack в проект вы можете спросить, зачем вообще Gulp нужен, если всё можно сделать с помощью webpack и npm-скриптов? Ответ здесь очень простой: с Gulp всё гораздо проще. На самом деле, про webpack вопрос не стоит — в TARS можно просто отключить таски, которые занимаются компиляцией шаблонов и сборкой CSS и использовать соответствующие лоадеры. Так что стоит перефразировать вопрос по-другому: зачем нужна некая абстракция в виде Gulp, когда его функции могут выполнять npm-скрипты? Уже написано много статей, в которых объясняется вся мощь и преимущество npm. Постараюсь ответить на самые веские аргументы. Думаю, сразу стоит уточнить, что речь идёт о том случае, когда у нас много задач, между которыми есть зависимости в очерёдности выполнения. Начнём с того, что вам придётся писать свою реализацию для запуска задач последовательно и параллельно. Зачем, если есть Gulp, который умеет это делать на «отлично»? К тому же иногда удобно работать с потоками при обработке какого-либо набора файлов. Либо вам придётся писать такую функциональность самому, либо просто отказаться от неё. Серьёзный аргумент в пользу перехода на npm-скрипты — плохая поддержка плагинов для Gulp. Речь идёт о gulp-плагинах, которые являются обёрткой для различных модулей типа UglifyJS, PostCSS и т.д. Естественно, может быть небольшой «лаг» между, например, обновлением UglifyJS и gulp-uglify, но чаще всего это не существенно. Часто бывает так, что создатель Gulp-плагина и самого пакета, для которого этот плагин был написан, — одно лицо. Не исключается и тот факт, что кто-то может просто забросить свою разработку. В этом случае можно либо продолжить разработку за автора, либо использовать пакет напрямую, без gulp-обёртки. Таким образом работает webpack в TARS. Ну, и напоследок: работа с тасками куда более приятна, нежели длинные портянки в package.json. Конечно, для проекта, в котором всего несколько задач, портянка вряд ли получится. В случае с TARS, когда мы пытаемся покрыть как можно больше потребностей разработчика одним инструментом и имеем сложные зависимости между последовательным и параллельным исполнением тасков, использование npm-скриптов не оправдывает себя, а, скорее, вставляет палки в колёса. Gulp — это очень простая в использовании штука, протестированная в различных окружениях, на разных платформах. Для вас доступно всего 4 метода API и возможность создания сложного сценария параллельного и последовательного запуска тасков. В конце концов, вам даже не нужно знать, что под капотом находится именно Gulp, ведь TARS просто работает. Если поддержка webpack уже давно реализована во многих проектах (а где-то сборщик построен только на webpack), то такой фичи, как автообновление проекта, не предоставляет никто. С TARS вы можете спокойно разрабатывать ваш сайт/сервис/что-то ещё и получать все последние фичи TARS одной командой. При этом все настройки, файлы проекта, пользовательские таски и вотчеры будут сохранены. Ещё вчера вы конкатенировали JavaScript-файлы, а уже сегодня, обновив проект, получили возможность использовать webpack. Все шаги обновления логируются плюс есть возможность добавить свои команды, которые будут запущены при обновлении проекта. Далее пойдут не столь значимые, но не менее полезные изменения. Полезные мелочи ESLint заменил JSCS и JSHint. Кстати, совсем недавно майнтейнер проекта JSCS Марат Дулин сообщил о переходе команды JSCS в проект ESLint. Так что, если вы ещё не используете ESLint, — самое время начать. Проверка кода стала проходить гораздо быстрее, с конфигом работать удобно — в общем, удобство со всех сторон. Код TARS и TARS-CLI хорошенько отрефакторили и переписали на ES6 (с поддержкой тех фич, что доступны в 4 версии NodeJS). В целом всё стало чище и понятнее, надеемся, что pull request’ов в связи с этим станет больше. Основной gulpfile теперь радует глаз, потому что состоит всего из 30 строк. Так как код написан на ES6, пришлось отказаться от поддержки NodeJS версии ниже 4. Документацию привели в актуальное состояние, исправили много опечаток, ошибок и т.д. Добавили возможность использовать SVG-символы. При этом есть возможность выбрать вариант подключения готового спрайта символов: вставить код спрайта в тело каждой страницы, держать все символы в отдельном файле, а при подключении указывать путь до этого файла (естественно, автоматически) или дать возможность вам самому реализовать подгрузку файла с символами. Модули были переименованы в компоненты. При этом имя для папки с компонентами/модулями можно настроить в конфиге, если новое название вам не по душе. Появилась возможность вкладывать компоненты в компоненты. Эта фича также поддерживается и со стороны CLI-утилиты. Было много просьб о том, чтобы можно было создавать компоненты с кастомной структурой с помощью CLI. Вы просили — мы сделали! Теперь можно описать схему компонента в json-файле, при этом схем можно сделать сколько угодно. Почти все плагины, которые используются в TARS можно настраивать так, как удобно вам в одном общем конфигурационном файле. Реализовали возможность компиляции стилей не автоматической конкатенацией, а с помощью точек входа, в которые вы можете импортировать только то, что потребуется в конечной сборке. Надеемся, что это даст больше свободы в работе со стилями. Значительно ускорили пересборку Jade-шаблонов. Кэшируем теперь все, что можно и пересобираем только то, что действительно необходимо на данном этапе. А самое главное — все эти нововведения вы можете получить просто запустив команду: tars update-project Ваш проект будет автоматически обновлен до последней версии с сохранением всех настроек. READ MORE 8 вредныхсоветов по «ускорению» сайта 1 апреля 2016 Время идет, интернет становится быстрее, а устройства пользователей — мобильнее. Практики, которые были актуальными 5-10 лет назад, устаревают, и на смену им приходят новые. За 9 лет существования WEBO Group (WEBO Site Speedup, webo.in, webopulsar.ru, Айри.рф) мы проанализировали, увеличили и промониторили скорость сотен тысяч сайтов. С годами браузеры становились быстрее, а сайты — более тяжелыми. И каждый год подходы по ускорению сайтов немного но менялись. Я рассмотрел наиболее часто встречаемые проблемы скорости сайта и наиболее эффективные методы их решения на сегодняшний день. Дисклаймер: все советы вредные, применять их не нужно! 1. Отключите сжатие (gzip) В далеком 2008 году исследование показало, как именно gzip-сжатие ускоряет сайты. Но сейчас пропускные способности каналов существенно превышают заявленные 1500 Кб, а мобильные процессоры находятся на уровне компьютеров 10-летней давности. Поэтому накладные издержки на разархивацию (обратный gzip) превосходят выигрыш от экономии времени на передачу данных. 2. Чередуйте стили и скрипты Современные браузеры умеют загружать файлы в несколько потоков, а потом применять их к HTML-документу. Для оптимизации времени загрузки можно чередовать загрузку стилей и скриптов. Как это будет работать: пока браузер загружает второй файл (скриптов) он сможет отрендерить первый файл (стилей), и далее по списку. Вы сможете сэкономить время загрузки всех файлов за счет рендеринга (парсинга) предыдущих! 3. Загружайте счетчики в самом верху Сложилась следующая практика — вставлять счетчики и сторонние виджеты внизу страницы, якобы для предотвращения блокировки загрузки. На самом деле, предварительная загрузка сторонних виджетов с самого начала документа позволяет распараллелить загрузку и использовать канал пользователя наиболее рациональным образом. Обращение к домену отличному от домена сайта вызывает дополнительный DNS-запрос. В этом время браузер «простаивает», а мог бы загружать ценную информацию с вашего домена. Вставляйте все сторонние скрипты в самое начало документа — так вы максимально распараллелите загрузку данных. 4. Создайте для каждого ресурса отдельный поддомен Все браузеры имеют ограничение в 10 параллельных запросов к одному домену (не серверу). Чтобы максимально утилизировать канал передачи данных, необходимо распараллелить запросы. Вы можете разбить их на группы по 10, а можете каждый стиль, скрипт, шрифт, изображение загружать со своего поддомена. Это несколько сложно в настройке, и придется дорабатывать систему управления сайтом, но результат превзойдет все ожидания. 5. Не оптимизируйте изображения Любая оптимизация изображений изменяет их структуру и бинарное представление. Для JPEG-файлов это может привести к нарушению исходных таблиц Хаффмана (снижению качества изображения), для PNG-файлов — к различных «сторонним» эффектам (например, потери прозрачности или искажению цветовой палитры на некоторых устройствах). Если вы хотите быть уверены в качестве изображений — никогда их не оптимизируйте. А лучше всего — используйте BMP-формат на сайтах: он гарантирует передачу всей информации без потерь. 6. Используйте таблицы в верстке Стандарты CSS создают все предпосылки для легкой и семантической верстки страниц. Но реализация стандарта в браузерах не всегда поддерживает эти предпосылки. И достаточно часто специальные возможности CSS3 (например, градиенты или тени) приводят к существенному замедлению отображения страницы. Также существуют проблемы с большим количеством вложенных блоков, имеющих относительное (или плавающее) позиционирование и сложными селекторами (пруфлинк 1, пруфлинк 2, пруфлинк 3). Только таблицы смогут обеспечить космическую скорость и стабильность отображения страницы на всех устройствах. Это давно забытая практика верстки, но настало время дать ей второе дыхание. Вы задумывались, почему даже сегодня в e-mail рассылках повсеместно используются таблицы? За ними будущее! 7. Избегайте оптимизации стилей или скриптов Оптимизация CSS или JavaScript файлов дает не более 15% выигрыша в размере, но при этом может привести к трудно отслеживаемым проблемам в верстке или выполнении (например, при изменении порядка селекторов или удалении «неиспользуемых» переменных из скриптов). Отказ от минимизации текстовых файлов позволит вам также отлаживать все проблемы разработки прямо на самом сайте, не восстанавливая исходные, не минимизированные версии файлов. Если вдруг для объединения и сжатия файлов вы используете какие-то модули системы управления — отключите их. Модули создают динамический код для объединения файлов, и код этот дополнительно нагружает хостинг и тратит его ресурсы. 8. Отключите кэширование файлов Как показала практика оптимизации сайтов за последние 10 лет, кэширование файлов в браузере — сложноуправляемый и неоднозначный механизм. Никогда нельзя быть полностью уверенным, что браузер показывает именно те файлы, которые загружены на хостинг. Если вы хотите, чтобы у пользователей всегда показывался именно ваш сайт (а не его старая версия), то нужно отключить кэширование статических файлов. Это делается в два этапа: нужно отключить безусловное кэширование (заголовки Expires и Cache-Control) и условное (заголовки ETag и Last-Modified). Отключение кэширование также позволит выдавать поисковым роботам наиболее актуальную версию вашего сайта, а не какое-то старье (подробнее об отключении кэширования). READ MORE Студия Студия PUMPKIN ул. Екатерининская 65089 Одесса Украина КОНТАКТЫ pumpkinandteam@gmail.com +38098 84 85 163 +38063 05 70 907 Copyright © 2017 Studio PUMPKIN | All rights reserved