Месяц назад кто-то нашёл у меня на гитхабе незаконченный проект и выложил ссылку на него на Designer News. Внезапно я увидел, что на сайте проекта постоянно сидит по 50 человек, и мне даже пришлось срочно сбежать с работы чтоб экстренно выпилить хотя бы самые адовые баги. Этим проектом был интенс, UX-компонент заменяющий полосу прокрутки (скроллбар) на специальный индикатор, который подсвечивает прокручиваемую область текстурой. Выглядит это примерно так:


_{на сайте проекта можно поскроллить самостоятельно}

Сообщества UX-экспертов и программистов отреагировали очень возбуждённо:

Не могу понять, почему мне это не нравится… _{— GrumpyUX Man @ layervault}

Святые какашки, эта штука бесит _{— Thecoss @ reddit}

Да я себе скорее установлю ПЕРДЯЩИЙ СКРОЛЛ http://theonion.github.io/fartscroll.js/ в качестве дефолтного, чем КОГДА-ЛИБО заменю мою полосу прокрутки на это. _{— Kyle Donmoyer @ layervault}

Спасибо, не надо. Никогда не мог понять это желание поменять стандартные элементы интерфейса. Полоса прокрутки — это одна из тех вещей, которая просто работает. Она не мешается и легко даёт понять, насколько много контента. _{— madk @ reddit}

Шта? _{— magenta_placenta @ reddit}

…
Я не очень понял, что за проблему оно решает _{— jineshshah36 @ reddit}

(кто-то даже создал сабреддит Real Bad UX чтоб разместить там ссылку на этот проект)

Вместе с UX-экспертами, возбудился и я. Бесполезные проекты обычно никому не интересны, у меня есть пара таких. Но сейчас было очень непохоже — этот получился очень спорным, и такой движухи я ещё не видел. В течение следующих недель я попытался учесть основные комментарии и либо исправить что-то в самой библиотеке, либо добавить пояснения на сайте проекта. И одновременно выкладывал его на остальных ресурсах — градус фидбэка вроде бы стал смягчаться.

Здесь я хочу рассказать, какие области применения у интенса, и попробую объяснить, как я себе представляю «жизнь после скроллбара». А также предлагаю читателям покритиковать этот проект, обсудить скроллинг вообще, UX вцелом, и целесообразность замены традиционных элементов в частности.

Hello World,

Helios Kernel — это библиотека для управления зависимостями между javascript-модуями, реализующая «классический» подход, часто встречаемый в других языках и средах — с помощью функции include().

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

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

Helios Kernel поддерживает динамическую загрузку (и выгрузку) зависимостей в рантайме, а сама библиотека и формат модулей являются совместимыми между nodejs и броузерной средой — то есть модули можно использовать без изменений или трансляции.

В этой статье классический подход реализованный в Helios Kernel сравнивается с управлением зависимостями с помощью RequireJS и показывается, каким образом подход Helios Kernel позволяет избежать некоторых сложностей.

Hello World,

Helios Kernel — это библиотека позволяющая описывать зависимости между javascript-модулями «в стиле include»:

// объявление зависимостей
include("path/to/library1.js");
include("../path/to/another/library2.js");

init = function() {
    // использование зависимостей
    library1.doSomething();
    ...
}

Я уже писал про Helios Kernel раньше, с тех пор проект переехал на гитхаб, а поводом к новому релизу стал тот факт, что весь платформо-зависимый код был выделен, и после некоторого допиливания тесты наконец прошил и под nodejs:



Поэтому теперь я могу написать здесь про библиотеку громкое слово «кроссплатформенная»

Hello World,

Этот топик о том, каким образом можно предварительно зарефакторить код так, чтобы улучшить его минимизацию. Недавно я перед релизом минимизировал библиотеку Helios Kernel (о которой написал позавчера). Исходник библиотеки весит 28112 байт, в нём щедрые комментарии, и поэтому он с пол пинка ужимается YUI компрессором до 7083 байт. Не то что бы мне показалось, что 7 килобайт — слишком жирно. Но просто, посмотрев своими глазами на минимизированный код, я смог увидеть кучу мест, где можно было бы сэкономить ещё:



Посмотрим, что можно сделать с кодом, чтобы превратить 7083 байт в 4009 3937.

Hello World,

Всё начилось с простой идеи: мне захотелось, чтоб я мог в шапке скрипта написать что-то вроде

include( "path/to/someLibrary.js" );

а ниже использовать объекты, объявленные в скрипте someLibrary.js. Так появилась библиотека Helios Kernel.

Helios — это открытый фреймворк и набор библиотек на Javascript для разработки «богатых» клиентских веб-приложений. Фреймворк обеспечивает поддержку модульной структуры, предоставляя таким образом возможность создавать приложения на чистом Javascript и при этом использовать привычную конструкцию include для подключения требуемых модулей. Набор библиотек в комплекте предоставляет необходимый API для разработки приложения. В частности, есть удобный тулкит виджетов Heliwidgets с поддержкой настраиваемых движков.

По ссылке можно посмотреть на демо-приложение, написанное с использованием Helios & Heliwidgets:

home.gna.org/helios/helioscalc

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

Исходный код фреймворка и библиотек доступен под GPLv3+

Домашняя страница проекта:

gna.org/projects/helios