Подписка на блог

В Телеграме помимо ссылок на заметки делюсь околодизайнерскими наблюдениями.

В Твиттере помимо ссылок на заметки пишу всякую чушь.

В Тумблере и Же-же есть автоматические трансляции. Если не работает, напишите мне: ilyabirman@ilyabirman.ru.

По РСС и Джейсон-фиду трансляции для автоматических читалок

Классификация

Оглавления по тегам

Начал наводить порядок в тегах, делаю там некие оглавления со ссылками на важные заметки по теме. Пока прошерстил теги:

В самих заметках по этим тегам появились сверху ссылки на эти оглавления. Пока коряво и не очень последовательно, но это 5% усилий для получения 95% пользы.

Вообще, формат блога требует серьёзного переосмысления. Таймлайн как основное средство организации материалов почти бесполезен.

 5   2015   блоги   классификация   этот сайт

Навигация на сайте Студии Лебедева

Изучал устройство необъятного портфолио Студии Лебедева и обнаружил любопытную вещь. Вот, например, недавняя работа — пакет для кафе. Где в структуре сайта лежит эта страница? Смотрим на верхнее меню:

В разделе «Наше всё» есть подраздел «Графдизайн», в нём — «Проекты студии», и уже внутри него лежит наш пакет. Так?

Нет, не так. Посмотрим, куда ведут ссылки в меню, и на адрес страницы пакетов:

Наше всё /everything/
Графдизайн /everything/graphic/
Проекты студии /everything/als/
Пакеты для кафе /everything/als/gift-bag/

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

Берём приём на вооружение.

Инбокс везде

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

Во всех этих местах я использую инбокс. Смысл его в том, что это место, куда объекты попадают изначально, до «обработки». В почте это так устроено само собой, и это очень удобно — представьте себе, если бы при получении каждого письма почтовик бы просил вас выбрать папку, в которую его нужно положить. В других приложениях инбокс нужно создать самостоятельно.

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

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

Сегодня, разбирая залежи букмарок в браузере, я догадался, что там тоже нужно сделать инбокс, чтобы все новые закладки добавлять именно в него:

Инбокс везде

Короче, видите, то есть это не просто я так делаю, а это аж целая моя методология, и поэтому этому посвящается аж целая заметка.

 15 комментариев    32   2011   Айтюнс   жизнь   классификация   рабочее место   решения   софт

Плейлисты в Айтюнсе

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

Музыка у меня всегда лежала в папках Исполнитель — Альбом (Год) в одном бесконечном списке, безо всякого разделения по жанрам или ещё какой-нибудь фигне, и ещё была папка (In), куда скидывалось всё новое, чтобы не забыть про него за то время, пока ещё не выучил.

Когда я перешёл на Мак, как раз вышел восьмой Айтюнс, позволяющий организовать библиотеку так, как я привык, то есть по альбомам, дополняя это приятной красотой в виде обложек. Меня это очень порадовало. Дело в том, что меня, как любого пользователя (тогда) Виндоуса, совершенно бесил Айтюнс, а одним из главных поводов для переживаний в связи с переходом на Мак было именно практически неизбежное использование Айтюнса. Поэтому мне было приятно, что новый Айтюнс может показывать мне музыку так или примерно так, как я привык её видеть. Жизнь показала, однако, что этим режимом с альбомами-обложками я почти не пользуюсь.

Оказалось, что самое главное средство организации музыки в Айтюнсе — это плейлисты (в сто раз полезнее рейтингов). Плейлист в Айтюнсе не имеет никакого отношения к тому, что сохраняют виндовые плейеры в файл с расширением m3u. Плейлист — это по сути просто папка, куда можно накидать песен. Да, он помнит, в каком порядке ты их накидал, но это совершенно не важно в большинстве случаев: песни в плейлисте можно отсортировать как угодно, организовать по исполнителям или жанрам.

То есть плейлист — это способ взять какое-то подмножество музыки и поименовать его. Это «надо будет поиграть в „Гараже“», это «записал мне Петя», а это «возможно подойдёт для следующего выпуска подкаста». Никто не имеет в виду, что ты будешь слушать плейлист по порядку или целиком.

Поскольку трек может входить в несколько плейлистов, то их можно использовать ещё и как теги: грустный медленный трек с женским вокалом можно закинуть в плейлисты «грустное», «медленное», «женский вокал». Треков-то тысяч десять, так что если забыл назвние чего-то (что со мной бывает крайне редко, но всё же), фиг найдёшь. Так что я стараюсь добавить трек в максимально возможное количество плейлистов, чтобы потом я мог найти его по любым признакам. Допустим, плейлисты всех мои миксов у меня есть в Айтюнсе, а значит я могу найти трек, помня, что я его, скажем, играл на «Эль-радио».

Есть плейлист Shazam — там лежат все треки, которые я нашёл после распознавания «Шазамом». Есть плейлист Dad’s Shelf — там лежат все пластинки «с папиной полки», то есть то, что я сграбил с его дисков (в основном джаз). Есть плейлист Find better — там лежат треки, которые у меня есть в плохом качестве или в обрезанном виде. Есть даже плейлист Nice Covers, где лежат альбомы, у которых крутые обложки (очень удачный плейлист для просмотра в кавер-флоу). Ну, и так далее.

А ещё плейлисты можно сами организовать по папкам (прямо внутри Айтюнса), что добавляет всей конструкции ещё больше гибкости. В папке Podcast лежат плейлисты, связанные с подкастом, папке Tags — плейлисты, которые я использую как теги, а в папке CDs — плейлисты моих нарезанных дисков.

В следующий раз расскажу про одну фичу плейлистов, которая имеет фундаментальную важность.
 30 комментариев    24   2009   Айтюнс   классификация   музыка

Критерии адекватности

Да! Он прикрутил Rubrika к e2. Как трогательно.
Зачем делать рубрикацию древовидной, если эта древовидность никак не визуализирована при написании заметки? Непонятно.
Вопрос примерно из серии «Зачем пользоваться интернетом, когда у тебя не заводится машина?» То есть, никакой связи между первой и второй частями не прослеживается.

Интерфейс написания заметки в e2 не самый удобный. Я это чувствую очень хорошо, у меня много кейвордов. Глазами искать среди них нужные трудно, быстрее просто ввести кейворд. Хочется сделать что-нибудь вроде «find-as-you-type» и здесь, и, вероятно, я это сделаю в ближайших релизах.

Теперь про Рубрику. Ну, достустим, ты её прикрутил, изменив core.php. Отлично, но теперь ты не сможешь обновить движок. Точнее, сможешь, но рубрика при этом открутится. Не проще ли было написать мне вот такое письмо:
Илья, прикрути, пожалуйста, Рубрику к e2. Хотелось бы, чтобы это выглядело так: бла, бла, бла. Готов помочь, если необходимо. номер ICQ — такой-то.
Спасибо, с уважением, Иван/Алексей/Пётр
В моём представлении, существенно проще, но даже если не проще, то по крайней мере эффективнее:
  • я бы сделал в e2 нормальную поддержку Рубрики (вместо костыля);
  • другие пользователи e2 тоже могли бы пользоваться Рубрикой, если считают её удобной.
 1 комментарий   2004   классификация   Эгея

Что же делать с кейвордами?

Будет очень интересно почитать планирующуюся культовую смирновскую книжку «Как перестать классифицировать записи и начать писать», потому, что без книжки этого понять невозможно. Вот пишет, например, Вадим про нити. Ну как не высказать своё мнение на этот счёт? Обязательно надо высказать. Высказываю.
  1. Нити и кейворды — это одно и то же;
  2. Не нужно плодить лишние сущности без надобности.
Вот есть у тебя цепочка заметок по поводу одной задачи, типа «поставлена задача» — «возможные пути решения» — «решена вот так», ну и что мешает создать кейворд «задача»? Просто сделай кейворд, зачем его называть словом «нить»? Тут есть два варианта: или Вадим не дописал о каких-то потайных функциях нитей, или он просто не понял, что это то же самое, что и кейворды. Разумеется, я склоняюсь к первому. Точнее, даже, надеюсь на первое; а также на то, что он напишет что-нибудь на эту тему.

Тем не менее, хоть функционально кейворды и нити — это одно и то же, семантически это всё-таки разные вещи, поэтому нужно придумать и функциональность какую-нибудь, которая была бы связана как-то с этой разницей. Например:
  • в любой заметке, участвующей в нити, должна быть ссылка на предыдущую и следующую заметки именно этой нити;
  • когда мы открываем страницу кейворда-нити, то заметки должны выводиться в режиме «новые снизу», чтобы за темой можно было нормально следить.
По этому поводу у меня уже давно есть, например, мысль ввести синтаксис и  для вставки ссылок на предыдущую и следующую заметки, содержащие хотя бы один из кейвордов данной. Возможность отображать «новые снизу» реализовать вообще не трудно. Можно даже просто сделать, чтобы по /keywords/path/to/key выдавались новые сверху, а по /threads/path/to/key — снизу.

В конце концов, ничего не мешает сделать в таблице Keywords столбец IsThread, чтобы формально отделить кейворды от нитей. Но я лично в этом не вижу смысла.

Что ещё? А, вот что. Кейворды, в отличие от нитей, не теряют актуальности. То есть, задачу ты поставил и решил, а про идиотов, например, можно писать всегда — тема неисчерпаема. Благодаря Юлии Шабунио в e2 можно сортировать кейворды по дате последнего использования. В этом случае, неактуальные нити постепенно будут сдвигаться вниз.

В e2 Release 1.02 предположительно будет очень крутая штука, которая позволит ориентироваться в бесконечных кейвордах и нитях, а также отличать те кейворды, которые по сути кейворды от тех, которые по сути — нити. Причём, без IsThread.

Теперь немного о том, какая же всё-таки структура кейвордов является самой правильной? Линейная, древовидная или в стиле R2?

Проблема линейной структуры том, что кейворды (сюрприз!) никак не связаны друг с другом. Получается, что «программирование» и «PHP» настолько же самостоятельные темы, насколько «снукер» и «toki pona». Но это не так, программирование и PHP — близкие темы. И это хочется как-то обозначить в структуре, потому, что нужно как-то связать соответствующие заметки друг с другом. Программирование — это более общая тема, чем PHP, Delphi и mySQL. Исходя из этой посылки возникают древовидные кейворды.

Однако, у древовидных кейвордов тоже полно проблем: в половине случаев непонятно, какая тема является общей для двух других. Мой случай, например: я не знаю, «комментатор Саша» должен быть субкейвордом «снукера» или «идиотов»? По идее, и того и другого. В результате этих рассуждений возникают кейворды в стиле R2 (aka «паутинообразные»)

Но и тут не всё гладко. Новая проблема состоит в том, что нам обязательно нужно определиться с тем, какой из двух связываемых кейвордов является более общим. А это не всегда легко/возможно. То, что «fight club» по отношению к «кино» кейворд дочерний — сомнений не вызывает; но вот я, например, не знаю, как бы я связал «Лебедева» и «дизайн». Однако, связать бы их хотел.

Поэтому теперь я думаю, что самая правильная система — это ассоциативная система кейвордов. Всё как у Смирнова, только вместо связей «содержит в себе» и «входит в» мы делаем просто «связан с». Ага?

Дальше, на странице любого кейворда мы пишем «См. также» и перечисляем ссылки на связанные кейворды. По-моему, вот так и надо делать.

Разумеется, кейворды «PHP 5» и «программирование» связаны сильнее, чем «PHP5» и «web-строительство». Поэтому, по кейворду «PHP 5» хотелось бы видеть:
Cм. также: PHP, программирование, web-строительство
То есть, именно в таком порядке, а не, скажем, по алфавиту. Для этого можно ввести необязательный параметр «сила связи» и дать возможность задавать его при связывании.

Вот такие мысли. 
 8 комментариев    1   2004   классификация

One step further — 2

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

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

А во-вторых, я пошёл ещё дальше, предложив выстроить древовидную систему самих отношений. Смайлик. Поэтому подкол всё-таки удался, не нужно этого отрицать!

См. заметку One step further.
 2   2004   идеи   классификация

One step further

Исторический экскурс: как развивались кейворды.
  • сначала кейвордов не было (с точки зрения структуры это была точка, один кейворд на всех);
  • потом появились линейные кейворды;
  • потом появились древовидные кейворды (кейворды могут иметь одного родителя и сколько угодно детей);
  • теперь вот новые, паутинообразные кейворды (кейворды могут иметь сколько угодно родителей и сколько угодно детей).
На самом деле, если честно, то даже переход с линейных на древовидные большого прироста хоть чего-нибудь не дал. Новые паутинообразные кейворды вызывают у меня ещё больший скептицизм, хотя, признаюсь, тыкаться в них — одно удовольствие, красиво Смирнов нарисовал.

Для того, чтобы не держать прогресс на месте, я предлагаю новую, ещё более запутанную, но совсем крутую концепцию гиперпаутинообразных кейвордов. Деревянность паутинообразных кейвордов заключается в том, что кейворды могут находиться только в отношении «родительский-дочерний» друг с другом. Гиперпаутинообразные кейворды лишены этой проблемы, так как любые два кейворда могут находится в любом отношении друг с другом, например, можно указать, что кейворд «торт» слаще кейворда «каша». Впрочем, зачем ограничиваться только бинарными отношениями? Лучше вот так: любые N кейвордов могут находиться в любом N-местном отношении друг с другом! Вот теперь — полноценная система.

Хотя... нет, не полноценная. Теперь у нас есть неогранизованная куча новых сущностей — отношений. Их ведь нужно тоже как-то классифицировать. Думаю, для начала можно и по-старинке, древовидно. Например, «субъективные > вкус > слаще» или «объективные > физические > острее». Теперь добавляем возможность к каждому отношению привязать свой аватар — и one step further сделан.
 2   2004   классификация   странный юмор

Помогите разобраться

Если у вас нет блога, — представьте обратное. А то у меня тут есть несколько вопросов:

1. Нужна ли блогу древовидная система кейвордов?

Аргумент «за»: когда по некоторому кейворду (например, «идиоты») накапливается очень много заметок, то поиск по нему перестаёт быть хоть сколько-нибудь эффективным — нужно разделить «идиотов» на подкатегории «комментатор Саша», «Ээльмаа», и т. д. Через несколько месяцев плоская система кейвордов абсолютно перестаёт работать.

Аргумент «против»: если кейворды становятся самостоятельными объектами, которые нужно создавать, выстраивать отношения между ними и т. д., то блогер просто не будет ими пользоваться — это становится слишком сложно. Если же сделать, что кейворды создаются автоматически при их «упоминании», то тогда, по мнению Смирнова, просто никто не будет утруждать себя созданием дерева, — кейворды, несмотря на возможности движка, так и останутся плоскими.

А вы что думаете?

2. Кстати, в моём представлении, каждый кейворд должен быть уникальным, то есть не может быть «программирование/web» и «дизайн/web» одновременно. Кто считает иначе и почему?

Я считаю так, потому, что если бывает «программирование/web» и «дизайн/web», то, значит, web — самостоятельное явление, и, следовательно, он должен быть корневым кейвордом, а заметки должны маркироваться как «программирование; web» и «дизайн; web».

3. Допустим, древовидная система кейвордов есть. Как сделать максимально удобным её использование?. Что должно быть в форме «написать новую заметку»?

Вариант. Рядом со строкой ввода «Keywords» отображается список всех уже существующих кейвордов (по алфавиту? в виде дерева?). Если кликнуть на кейворд, он добавляется в
строку ввода (в виде «php» или «программирование/web/php»?). Можно вручную дописать новые кейворды (если указано в виде «php», то кейворд создаётся в корне, а если в виде
«программирование/web/php», то где указано? а если такой кейворд уже есть в другой категории?).

Какие еще мысли по этому поводу у кого возникают — делитесь, интересно.

Кстати, какой (какие?) кейворд должен быть у этой заметки?
 24 комментария    3   2004   вопрос   классификация