Комментарии 30
Перепутаны поддержка возможностей и навязывание методологии.
Можно поточнее, что и где перепутано?
на самом деле все на месте)
методологии, возможности, фичи, расширяемость, прочее — все это не важно.
Главное — продукт должен быть и быть успешен. Его разработчики должны ясно видеть что и зачем они делают. Все остальное — вторично. Патерны и подходы, методологии и стандарты — все это не является необходимым в качественном продукте. Предусмотреть все невозможно и гонка за охватом более широкой аудитории обычно проигрывается.
методологии, возможности, фичи, расширяемость, прочее — все это не важно.
Главное — продукт должен быть и быть успешен. Его разработчики должны ясно видеть что и зачем они делают. Все остальное — вторично. Патерны и подходы, методологии и стандарты — все это не является необходимым в качественном продукте. Предусмотреть все невозможно и гонка за охватом более широкой аудитории обычно проигрывается.
Ну вот вам простой пример. Можно к каждой правке в Вики привязывать стоимость. Автор вносит свой вклад и называет цену, владелец анализирует вклад и цену и либо принимает правку выплачивая автору гонорар, либо отклоняет её.
Наличие подобной функциональности не означает что программное обеспечение выбрало сторону. Это, всего лишь, реализация конкретного бизнес-процесса. Можно считать что программное обеспечение содержит виденье — «правки должны оплачиваться», но это не так. Виденье — это «правки должны быть». Всё, точка. Всё что дальше это не виденье, а конкретика.
В википедии авторство не важно, потому что многие правки анонимны, все правки бесплатны и содержимое свободно (не попадает под чьё-либо авторство, нет оригинальных исследований). Поэтому текущая реализация MediaWiki всего лишь отвечает насущным потребностям. Это не какая-то там креативная реализация навязывающая своё виденье, это не более чем адекватная реализация, которая не заставляет пользователя заполнять кучу полей обязательных с её точки зрения, но опциональных с точки зрения пользователя.
WYSWIWYG — это виденье. Microsoft Word это не виденье, это реализация заточенная под конкретную группу пользователей. WYSIWYM это виденье, оформление документа стилями это подход, TeX — конкретная реализация. С другой стороны Microsoft Word содержит элементы WYSIWYM. Как же так?
Так что то что тут называется виденьем, всего лишь специализация, поддержка возможностей необходимых конкретной группе пользователей и, напротив, отсутствие реализации ненужных возможностей.
Есть, правда, и другой момент. Как только вы делаете приложение универсальным оно с большой вероятностью становится одинаково неудобным для всех и будет иметь меньше пользователей, чем удобное специализированное приложение. Но это, опять таки, не имеет никакого отношения к виденью. Это всего лишь определение и фиксирование группы потенциальных пользователей. Да, надо определиться для кого пишется приложение, чтобы сделать его лучше. И иногда, лучше рискнуть и выбрать хоть какую-то группу пользователей, чем вообще никакой. Однако это не takes side, это fits purpose.
Наличие подобной функциональности не означает что программное обеспечение выбрало сторону. Это, всего лишь, реализация конкретного бизнес-процесса. Можно считать что программное обеспечение содержит виденье — «правки должны оплачиваться», но это не так. Виденье — это «правки должны быть». Всё, точка. Всё что дальше это не виденье, а конкретика.
В википедии авторство не важно, потому что многие правки анонимны, все правки бесплатны и содержимое свободно (не попадает под чьё-либо авторство, нет оригинальных исследований). Поэтому текущая реализация MediaWiki всего лишь отвечает насущным потребностям. Это не какая-то там креативная реализация навязывающая своё виденье, это не более чем адекватная реализация, которая не заставляет пользователя заполнять кучу полей обязательных с её точки зрения, но опциональных с точки зрения пользователя.
WYSWIWYG — это виденье. Microsoft Word это не виденье, это реализация заточенная под конкретную группу пользователей. WYSIWYM это виденье, оформление документа стилями это подход, TeX — конкретная реализация. С другой стороны Microsoft Word содержит элементы WYSIWYM. Как же так?
Так что то что тут называется виденьем, всего лишь специализация, поддержка возможностей необходимых конкретной группе пользователей и, напротив, отсутствие реализации ненужных возможностей.
Есть, правда, и другой момент. Как только вы делаете приложение универсальным оно с большой вероятностью становится одинаково неудобным для всех и будет иметь меньше пользователей, чем удобное специализированное приложение. Но это, опять таки, не имеет никакого отношения к виденью. Это всего лишь определение и фиксирование группы потенциальных пользователей. Да, надо определиться для кого пишется приложение, чтобы сделать его лучше. И иногда, лучше рискнуть и выбрать хоть какую-то группу пользователей, чем вообще никакой. Однако это не takes side, это fits purpose.
все не так
37 сигналс придерживается и популяризует позицию управления продуктом с точки зрения концепции, носителями которой являются команда продукта.
И тут совершенно пофиг что думают и считают пользователи. Чисто теоретически они могут убедить тысячами, или может сотням тысяч обращений команду в своей правоте. А могут не убедить.
Плюсы в том что продукт имеет целостность и концепцию. Идеологически целен. Минус в том что если ты не согласен с данной концепцией, и следующей из нее use case и так далее- ты за бортом.
37 сигналс придерживается и популяризует позицию управления продуктом с точки зрения концепции, носителями которой являются команда продукта.
И тут совершенно пофиг что думают и считают пользователи. Чисто теоретически они могут убедить тысячами, или может сотням тысяч обращений команду в своей правоте. А могут не убедить.
Плюсы в том что продукт имеет целостность и концепцию. Идеологически целен. Минус в том что если ты не согласен с данной концепцией, и следующей из нее use case и так далее- ты за бортом.
> «Автор вносит свой вклад и называет цену, владелец анализирует вклад и цену и либо принимает правку выплачивая автору гонорар, либо отклоняет её. Наличие подобной функциональности не означает что программное обеспечение выбрало сторону. Это, всего лишь, реализация конкретного бизнес-процесса.»
Как раз-таки это и есть видение, для конкретного отдельного проекта. То есть — кто-то может взять и сделать такую модель, как в вашем примере, и это будет другой opinion.
> «WYSWIWYG — это виденье. Microsoft Word это не виденье, это реализация заточенная под конкретную группу пользователей. WYSIWYM это виденье»
Нет, видение — это, например, «WISYWYM с возможностью менять только формат, потому что это подходит большинству наших пользователей и упрощает работу в сто раз». То есть — вполне конкретная, очевидная вещь, которая «не подойдет» для целой группы «не клиентов», и когда не преследуется попытка подстроиться под всех и сразу. Это и есть opinion.
Как раз-таки это и есть видение, для конкретного отдельного проекта. То есть — кто-то может взять и сделать такую модель, как в вашем примере, и это будет другой opinion.
> «WYSWIWYG — это виденье. Microsoft Word это не виденье, это реализация заточенная под конкретную группу пользователей. WYSIWYM это виденье»
Нет, видение — это, например, «WISYWYM с возможностью менять только формат, потому что это подходит большинству наших пользователей и упрощает работу в сто раз». То есть — вполне конкретная, очевидная вещь, которая «не подойдет» для целой группы «не клиентов», и когда не преследуется попытка подстроиться под всех и сразу. Это и есть opinion.
Целостность и концепция продукта это хорошо. Это даже отлично, если продукт находит свою аудиторию. А если эта аудитория приносит разработчикам продукта прибыль, то это вообще супер!
Но довольно часта ситуация, когда твое видение не совпадает с мнением пользователей или ты вообще не смог хоть кого-то убедить пользоваться твоим продуктом. Варианты действий основные примерно такие:
— забить на продукт (по крайней мере как массовый, делать чисто для себя)
— продвигать продукт, навязывая свое видение рынку
— забить на свое видение и подстраиваться к требованиям рынка
— создавать семейство продуктов для решения одних, в принципе, задач, но с разным видением путей этого решения (самый простой вариант — «лайт» и «про» версии), рассчитывая на то, что рано или поздно пользователи проникнутся твоим видением.
Твой выбор, %username%?
Но довольно часта ситуация, когда твое видение не совпадает с мнением пользователей или ты вообще не смог хоть кого-то убедить пользоваться твоим продуктом. Варианты действий основные примерно такие:
— забить на продукт (по крайней мере как массовый, делать чисто для себя)
— продвигать продукт, навязывая свое видение рынку
— забить на свое видение и подстраиваться к требованиям рынка
— создавать семейство продуктов для решения одних, в принципе, задач, но с разным видением путей этого решения (самый простой вариант — «лайт» и «про» версии), рассчитывая на то, что рано или поздно пользователи проникнутся твоим видением.
Твой выбор, %username%?
Ну, определиться со своей целевой аудиторией и со своим opinion'ом никто не отменял. Более того, те же 37signals настаивают на том, что нужно слушать своих пользователей, но в определенной мере. Разумеется, opinion, который понимает только сам разработчик, никому не нужен.
Имеется в виду, что не нужно из каждого проекта делать монстра, который подойдет потенциально 96% пользователей вместо положенных 80%, а сосредоточиться на том, что нужно именно этим 80.
Имеется в виду, что не нужно из каждого проекта делать монстра, который подойдет потенциально 96% пользователей вместо положенных 80%, а сосредоточиться на том, что нужно именно этим 80.
Ну, если в такой пропорции то, в принципе, согласен, тем более может позволить избежать исков о монополизации рынка если что :) Просто по тону статьи мне показалось, что речь идёт о сосредоточении на куда меньшей группе — 5%, 1%, может ещё меньше.
Хорошо, вы все правильно поняли.
Ну, может быть и 5% или 1% — если это действительно ваша целевая аудитория, ваша ниша. Но тут речь именно про действия уже внутри определенной ниши, про то, что не нужен перегруз особыми фичами, даже если какие-то из них кому-то реально нужны.
P.S. А тон — весь Getting Real написан в таком немного «навязывающем» стиле — тут главное это адекватно воспринимать :)
Ну, может быть и 5% или 1% — если это действительно ваша целевая аудитория, ваша ниша. Но тут речь именно про действия уже внутри определенной ниши, про то, что не нужен перегруз особыми фичами, даже если какие-то из них кому-то реально нужны.
P.S. А тон — весь Getting Real написан в таком немного «навязывающем» стиле — тут главное это адекватно воспринимать :)
А как в плане opinionated software будет выглядеть решение сделать для продукта открытый API для модулей/расширений (или вообще открыть код) и «бросить» его пользователям со словами: «нате, делайте что хотите, а я буду делать то, что считаю нужным» — это кардинальное изменение видения или лишь небольшая уступка массам. Или зависит от глубины проникновения API в ядро?
Ну, здесь решение открыть код само по себе, а opinion, заложенный в него — сам по себе. То есть, тот, кому этот код не понравится/не подойдет, так или иначе начнет писать что-то свое или будет искать что-то более подходящее конкретно ему. Или возьмет какую-то часть, которая ему подходит, но поверх ее напишет что-то свое.
Кстати, важный момент — казалось бы, зачем нам целая куча технологий (фреймворков, платформ, библиотек, сервисов), решающих одни и те же задачи. Ведь это огромные «лишние и ненужные» временные и денежные затраты. Почему нельзя договориться и сделать что-то одно, удобное для всех? Невозможно :) Того, что понравится всем, не существует. Вот именно потому и появляется куча opinion'ов.
На примере веб-технологий — что лучше — RoR или Django? ;) Очень провокационный вопрос, и одновременно ответ, почему я не любитель холиваров. Я не смотрю на это с позиции «лушче-хуже», потому что это не так. Это — 2 разных «opinion'а» в одной нише, они в определенной степени одинаковы, и в определенной — разные; находятся те, кто использует одно, и те, кто другое.
Кстати, важный момент — казалось бы, зачем нам целая куча технологий (фреймворков, платформ, библиотек, сервисов), решающих одни и те же задачи. Ведь это огромные «лишние и ненужные» временные и денежные затраты. Почему нельзя договориться и сделать что-то одно, удобное для всех? Невозможно :) Того, что понравится всем, не существует. Вот именно потому и появляется куча opinion'ов.
На примере веб-технологий — что лучше — RoR или Django? ;) Очень провокационный вопрос, и одновременно ответ, почему я не любитель холиваров. Я не смотрю на это с позиции «лушче-хуже», потому что это не так. Это — 2 разных «opinion'а» в одной нише, они в определенной степени одинаковы, и в определенной — разные; находятся те, кто использует одно, и те, кто другое.
Вообще их Getting Real мне нравился, но вот это какое-то стремное дело, из разработки софта сделали партию какую-то, или ты с нами или ты против нас.
Разработка любая это удовлетворение нужд потребителей
Философия Юникс тут гораздо лучше, как мне кажется
Разработка любая это удовлетворение нужд потребителей
Философия Юникс тут гораздо лучше, как мне кажется
Вспоминается редактор nano со своим «видением» хоткеев. (особенно умиляет Alt+Пробел)
nano, вернее его предшественник pico в составе мэйлера pine получил свои хоткеи еще тогда, когда все эти ваши „ctrl-c“ и „ctrl-v“ ходили в кортеньких детских штанишках.
и кстати, это не alt+пробел, а Meta+пробел. клавиша мета совершенно необязательно должна быть альтом. к примеру, ее можно симулировать последовательностью двух нажатий на эскейп и нажатием нп пробел.
и в свою очередь, это вызвано аппаратной особенностью первых терминалов, в которых один канал связи использовался и для передачи данных, и для управления программой.
и кстати, это не alt+пробел, а Meta+пробел. клавиша мета совершенно необязательно должна быть альтом. к примеру, ее можно симулировать последовательностью двух нажатий на эскейп и нажатием нп пробел.
и в свою очередь, это вызвано аппаратной особенностью первых терминалов, в которых один канал связи использовался и для передачи данных, и для управления программой.
Согласен, много чего тянется из глубин истории… Но как HAL и X выпиливать, кнопки влево переносить — так можно, а выкинуть хоткеи с ламповых терминалов (и заменить на современные де-факто) — лень?
дело не в том, что их лень выпилять. дело в том, что консольные unix-приложения должны оставаться совместимыми с «железными» терминалами. и если их форкнуть с новыми хоткеями, то придется тащить две ветки — с новыми хоткеями и со старыми, которые совместимы с терминалами последовательного доступа (собственно говоря, те, которые работают через компорт)
а хал и иксы для конечного пользователя — прозрачные объекты, будет хал, будет хал модульным или не будет хала вообще — пользователь может и не узнать.
а хал и иксы для конечного пользователя — прозрачные объекты, будет хал, будет хал модульным или не будет хала вообще — пользователь может и не узнать.
Вместо того, чтобы отмечать атрибутами каждое изменение именем автора, они просто убрали большую часть того, что связывает контент с автором.
Учебник английского — читать, траву — курить. Не наоборот. Я уж не говорю о том, что за «отмечать атрибутами каждое изменение именем автора» нужно публично сечь розгами. За «конкретное время», кстати, тоже.
Берем оригинал:
Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership.
Фрагмент про visual representation, который Вы выбросили, принципиально важен. Авторы wiki вовсе не убирали связь контента с автором — в этом легко убедиться, просмотрев историю правок. Суть совсем в другом — они отказались от «выпячивания» авторства. Когда мы читает страницу wiki — нам не навязывают информацию о том, кто какой вклад внес в ее контент.
«Лучший софт принимает однозначную позицию («takes side» — прим. пер.). Когда кто-нибудь использует твою программу, он ждет от нее не только невероятных фич и функциональности, он ждет особого подхода. Он ждет особого видения. Определись, какое у тебя видение и двигайся вперед вместе с ним.»
Сам недавно пришел к такому выводу. Перестал делать как от меня хотят — делаю как вижу правильным, конечный продукт заказчику как правило нравится.
Сам недавно пришел к такому выводу. Перестал делать как от меня хотят — делаю как вижу правильным, конечный продукт заказчику как правило нравится.
Есть опасение, что сотни программистов, сейчас начнут оправдывать «особым видением» свою лень и нежелание продумать и заложить правильную архитектуру.
Не исключено.
По-моему, речь больше о функционале и ui, а не архитектуре. Или вы о том, что при правильной архитектуре реализовать фичу не лень, а при неправильной — лень? :)
Они начнут чем-нибудь оправдывать свою лень в любом случае, и это совсем другой разговор. Что касается архитектуры — то она сама может быть еще какой «opinionated», так что статья в той же мере относится к разработке библиотек, фреймворков и компонентов.
А аргумент «Bad devs will mess it up» можно применить к любой ситуации.
А аргумент «Bad devs will mess it up» можно применить к любой ситуации.
>Any opinions? ;)
По-моему статья просто ни о чем (ничего личного, это мое имхо). Вы привели один из тезисов 37signals из книги Getting Real (а их 91 шт в 16 главах) и это сразу статься на Хабр?
PS: стоит ожидать еще 90 статей ???
PSS: Если бы была краткая выжимка из всей книги — я бы понял. Еще раз ничгео личного, сугубо мое имхо
По-моему статья просто ни о чем (ничего личного, это мое имхо). Вы привели один из тезисов 37signals из книги Getting Real (а их 91 шт в 16 главах) и это сразу статься на Хабр?
PS: стоит ожидать еще 90 статей ???
PSS: Если бы была краткая выжимка из всей книги — я бы понял. Еще раз ничгео личного, сугубо мое имхо
«Чудесный пример — оригинальный дизайн «вики». Уорд Каннингем и Ко намеренно вырезали огромную часть фич, которые до этого считались ну совершенно необходимыми для коллективной работы с документами.»
Сомневаюсь. MediaWiki по сути дела построен на идеологии систем конктроля версий известных и широко используемых программистами задолго до этого. Есть исходный текст программы, где есть только исходный текст. А вот чтобы узнать авторов надо смотреть историю ревизий.
Т.е. это не ново и не оригинально. Оригинальным можно назвать компот из:
— примитивный интерфейс, с которым не нужно разбираться
— система контроля версий статей
Сомневаюсь. MediaWiki по сути дела построен на идеологии систем конктроля версий известных и широко используемых программистами задолго до этого. Есть исходный текст программы, где есть только исходный текст. А вот чтобы узнать авторов надо смотреть историю ревизий.
Т.е. это не ново и не оригинально. Оригинальным можно назвать компот из:
— примитивный интерфейс, с которым не нужно разбираться
— система контроля версий статей
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приложения, которые «сами себе на уме» или что такое «Opinionated Software»