Сегодня мы потребляем Веб в том виде, как решили продукт-менеджеры в больших корпорациях. Алгоритмические ленты, релевантная и нерелевантная реклама, интерфейсы для Целевой Аудитории.
Если повезёт, то команда, работающая над интерфейсами, слышала про доступность и работает над этим. Если повезёт, то новый A/B тест не поломает твои сценарии использования.
Индисайты публикуют посты в формате, который могут читать и люди, и машины — мы можем делать интерфейсы, которые подходят именно нам. Например, Твиттер, но заточенный прямо для меня.
Ридер, или читалка, это мой агент в сети — она собирает посты с сайтов, на которые я подписался, и показывает их в удобном мне виде. В идеале — ещё и даёт возможность провзаимодействовать с постом: лайкнуть, ответить, зарепостить.
На вики Индивеба есть список уже существующих читалок, но я предлагаю, если есть возможность, попробовать написать свою.
Одна из ловушек мышления, в которую частенько попадают программисты, — это желание сделать общее решение: зачем писать программу для вот этой конкретной проблемы, когда можно потратить больше времени и получить Универсальный Фреймворк для Решения Таких Проблем, на котором я с лёгкостью решу изначальную проблему. Эта ловушка мышления иногда оправдана: когда мы точно понимаем Такие Проблемы. Но чаще у нас есть Некоторые Предположения, которые могут оказаться неверными, а мы уже потратили полгода на обсуждение Архитектуры и Правильных Абстракций.
Это я всё к чему. У Индивеба есть два важных принципа: UX is more important than formats and specs и use what you make. UX — это сложно. Пытаясь сделать Универсальную Читалку, программисты больше фокусируются на абстракциях и логике, но мало думают про то, как это использовать. На самом деле, это одна из причин, почему ПО с открытым кодом обычно имеет интерфейс, который, ну, не очень.
Когда логика системы уже запрограммирована, то изменить её сложно. Случаются ситуации, где UX будет лучше, если бы абстракции в системе, которыми манипулирует пользователь, были немного другими. Но редко кто будет переписывать ради этого программу, и в результате страдает UX.
Но если зайти с другой стороны: ориентироваться больше на опыт взаимодействия с интерфейсом, чем на код, который его поддерживает, то получившийся продукт будет лучше. Как пример: в приложениях iOS обычно нет кнопки «Сохранить», хотя внутри такая же файловая система, как на Маке, где такие кнопки есть, оно просто работает, и такой UX сложно получить, идя от того, что уже есть.
Возвращаясь к читалкам, очень сложно заранее угадать, какой интерфейс лучше всего подойдёт для меня для чтения постов. Если не думать об этом, то получится только скопировать имеющиеся: Фейсбук/ВК, Твиттер, RSS-читалки, Инстапейпер/Покет. Это тоже может быть валидной целью, но мне кажется, что лучшие читалки ещё не написаны.
Поэтому так важно писать не для кого-то, не для абстрактного пользователя, а для себя — если я буду делать для себя и использовать каждый день, то недостатки будут мешать в первую очередь мне — и мотивировать на улучшения. Большим компаниям приходится для этого собирать тонну аналитики, но когда главный пользователь — это ты, то легко понять, это работает или это не работает.
С другой стороны, есть определенная часть программирования, которой не избежать при написании читалок: например, скачивание фидов и парсинг микроформатов. Чтобы упростить разработку читалок, появилась ещё одна спецификация: Microsub. В ней тяжелые части берёт на себя сервер, а клиенту отдаёт JSON, который уже легко отрендерить. Можно взять Aperture, сервер Microsub, написаный Аароном Пареки, одним из основателей IndieWebCamp.
Постепенно, из десятков разных проектов мы, как сообщество, неизбежно будем находить общие моменты, которые работают для многих, и это хорошо! Но не стоит пытаться делать универсально изначально. Сначала надень маску на себя, потом на ребёнка.
Про свою читалку я расскажу завтра.