22 декабря 2011 г.

Повторы

Текущая ситуация такова, что легчше всего в интернете живётся Авторам. Т.е. тем, кто создаёт контент (или копирует). Создал, выложил и забыл.
А вот Читателям (т.е. потребителям контента) - ровно наоборот. Надо найти нужный (интересный), прочитать (просмотреть, прослушать) и ... не забывать. А то в следующий раз придётся опять читать (смотреть, слушать). Но даже если Вы помните, это всё равно не защитит Вас от повторного получения того же самого контента.
Потому Читатель и кричит беспомощно - "БАЯН!"

Динамическое меню

Когда-то давно, в 2000 году точно (а может и раньше), в пакете программ Microsoft Office использовалось меню, когда по умолчанию в нём отображаются только наиболее часто используемые элементы (команды).
Это было одно из худших интерфейсных решений.
С тех пор прошло больше 10 лет. Мне казалось, что все запомнили этот урок, любезно предоставленный нам MS. Но нет, получается, большие компании слишком большие, чтобы учиться на чужих ошибках (я как бы не назвал эту компанию):

20 декабря 2011 г.

Шаурма


Голосование

На повестке дня - N вопросов.
Пользователь может одобрить или отклонить (проголосовать) только по одному из вопросов, а по каждому из оставышихся:
  • либо ничего не делать, тогда вопрос переносится на следующий день;
  • передать вопрос на голосование другому пользователю (другу), который, по его мнению, более компетентен в решении данного вопроса, т.е. "передать голос";
  • отказаться от голосования и передачи голоса.
Вопрос, по которому проголосовали (отказались голосовать), получает (удаляет) как голос проголосовавшего пользователя, так и все голоса тех, кто передал свои голоса этому пользователю для голосования по этому вопросу.
При возникновении замкнутого цикла переданных голосов (например, пользователь А передал голос пользователю Б, а пользователь Б передал голос пользователю А), данные голоса удаляются.
Голосование по вопросу завершается, когда по нему проголосует P% пользователей.
На следующий день на повестку дня добавляется K вопросов и процесс повторяется.

13 декабря 2011 г.

Создать созданное

Разрабатывая с нуля какой-нибудь существующий сервис (т.е. не беря сервис за основу, пытаешься создать этот сервис), начинаешь понимать, почему было сделано так, а не по другому.
Например, про Google Wave понял, почему было сделано редактирование в реальном времени. Почему такая структура интерфейса. Почему были придуманы боты и т.д. и т.п.
Именно "почему", а не "зачем". Про "зачем" можно и так почитать в помощи (help) к этому сервису.
И понимаешь это с функциональной точки зрения, а не с точки зрения дизайнера или разработчика.
А самое главное, полностью понимаешь создателей: для кого и чего сервис придумывался и где он не смог бы использоваться при всём их желании. (Ну, конечно, если желание это не "взять всё и переписать". :) )

Но что интересно: становятся явно видны альтернативы реализованной функциональности, а вот понять, почему было сделано так, а не альтернативно, уже почти не возможно.

Авторизация с помощью email

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