![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitНе могу сказать, что я со всеми этими тезисами согласен. Исходная публикация на листе "Знаток" навеяна тем, что один острый дискуссионный материал был опубликован в ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
chgk, а на листе - несколько позже. Поскольку он был дискуссионный, то флейма вокруг него хватило.
Мое мнение по данному вопросу может не совпадать с мнением Бориса. А может совпадать.
© Борис Вейцман
Наиболее удобная форма дискуссий -- листы, можно с архивом в WWW. Наименее удобная -- ЖЖ. Но за долгие годы я сформулировал для себя три закона, которым я хочу дать своё имя.
Итак, три закона Вейцмана:
Закон 1. Если есть несколько способо решить какую-либо задачу при помощи компьютера, то люди неизменно выбирают наименее удобный, наименее надёжный и наименее пригодный к решению задачи способ. Когда речь идёт о компьютере, люди неизменно забивают гвозди отверткой, а шурупы вкручивают плоскогубцами.
Закон 2. За годы пользования неудобным способом он обрастает разными примочками, заплатами и хаками. В итоге этот способ со всеми наросшими финтифлюшками начинает напоминать бледное подобие более удобных способов, предоставляя жалкое подмножество тех возможностей и удобств, которые были в более продуманной технологии с самого начала.
Закон 3. Когда люди выбирают неудобный способ, они обычно ссылаются на лёгкость в обучении. Более удобный способ надо изучать час, а менее удобный -- десять минут. Однако вскоре выясняется, что без набора финтифлюшек из Закона 2 менее удобный способ использовать нельзя. Поскольку финтифлюшки писались как заплатки, без логики и понимания, на их изучение надо потратить куда больше часа. Появляются Маги и Волшебники неудобного способа, знающие Секретные Танцы С Бубном, Которые Иногда Работают. Преподавание неудобного способа (т.е. Танцев С Бубном) становится важной отраслью компьютерной промышленности.
На основании этих законов я берусь предсказать, что скоро в нашем общении ЖЖ вытеснит листы. Всего неделя, потраченная на изучение разных примочек и специальных служб даст пользователям ЖЖ слабое подобие тех возможностей, которые дают полчаса, потраченные на изучение документации к вашему любимому мейлеру.
chgk, а на листе - несколько позже. Поскольку он был дискуссионный, то флейма вокруг него хватило.Мое мнение по данному вопросу может не совпадать с мнением Бориса. А может совпадать.
© Борис Вейцман
Наиболее удобная форма дискуссий -- листы, можно с архивом в WWW. Наименее удобная -- ЖЖ. Но за долгие годы я сформулировал для себя три закона, которым я хочу дать своё имя.
Итак, три закона Вейцмана:
Закон 1. Если есть несколько способо решить какую-либо задачу при помощи компьютера, то люди неизменно выбирают наименее удобный, наименее надёжный и наименее пригодный к решению задачи способ. Когда речь идёт о компьютере, люди неизменно забивают гвозди отверткой, а шурупы вкручивают плоскогубцами.
Закон 2. За годы пользования неудобным способом он обрастает разными примочками, заплатами и хаками. В итоге этот способ со всеми наросшими финтифлюшками начинает напоминать бледное подобие более удобных способов, предоставляя жалкое подмножество тех возможностей и удобств, которые были в более продуманной технологии с самого начала.
Закон 3. Когда люди выбирают неудобный способ, они обычно ссылаются на лёгкость в обучении. Более удобный способ надо изучать час, а менее удобный -- десять минут. Однако вскоре выясняется, что без набора финтифлюшек из Закона 2 менее удобный способ использовать нельзя. Поскольку финтифлюшки писались как заплатки, без логики и понимания, на их изучение надо потратить куда больше часа. Появляются Маги и Волшебники неудобного способа, знающие Секретные Танцы С Бубном, Которые Иногда Работают. Преподавание неудобного способа (т.е. Танцев С Бубном) становится важной отраслью компьютерной промышленности.
На основании этих законов я берусь предсказать, что скоро в нашем общении ЖЖ вытеснит листы. Всего неделя, потраченная на изучение разных примочек и специальных служб даст пользователям ЖЖ слабое подобие тех возможностей, которые дают полчаса, потраченные на изучение документации к вашему любимому мейлеру.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-09-22 05:57 am (UTC)no subject
Date: 2005-09-22 08:41 am (UTC)no subject
Date: 2005-09-23 08:10 am (UTC)no subject
Date: 2005-09-22 06:59 am (UTC)no subject
Date: 2005-09-22 09:21 am (UTC)И что несчастная картинка-юзерпик, которая укладывается в несколько килобайт, для кого-то несет больше информации, чем подпись.
Чем-то он мне со своими законами напоминает одного моего знакомого, который считал всех, кто слушает музыку, лицемерами: "Неужели приятно жить, когда у тебя в ушах какой-то бессловесный шум?!"
А кроме того, ЖЖ организован предельно грамотно в вопросе наполнения френдленты. И это удобство стоит многих. Не вопрос, можно было бы то же самое реализовать еще более разумно: хотя бы добавить функцию "следить за дискуссией", когда ты ставишь галочку на тему - и получаешь уведомления не только об ответах тебе лично.
Но листы этого не дают. Даже фидошные локалки - и те...
no subject
Date: 2005-09-22 09:34 am (UTC)это можно организовать отдельным сервисом.
и если будет достаточное количество заинтересованных - нужно.
кстати, интересно - если сделать символическую плату, скажем, 1WMZ, за регистрацию в сервисе - прокатит, как думаете? для компенсации трудозатрат на разработку :)
no subject
Date: 2005-09-22 09:36 am (UTC)no subject
Date: 2005-09-22 10:47 am (UTC)френдлента - это неграмотно. Это push-технология, а не pull-, и только этого достаточно, чтобы её похоронить.
no subject
Date: 2005-09-22 10:47 am (UTC)no subject
Date: 2005-09-22 11:42 am (UTC)no subject
Date: 2005-09-22 11:01 am (UTC)Кстати, аналогом наполнения френдленты можно признать, например, twit. Хотя аналогия достаточно условная.
О минусах технологии я напишу через какое-то время отдельно.
no subject
Date: 2005-09-22 11:41 am (UTC)Ближе, если на то пошло, локалка; но и в ней изменение сообщества - все равно не личное дело каждого. Даже хозяин локалки, и тот не может менять подборку произвольно (пойнты, линки...). А уж юзер...
Twit - нельзя.
Date: 2005-09-22 12:23 pm (UTC)Scoring (письма такого-то читаем раньше писем сякого-то, а этакого игнорируем) - уже совсем близко.
Re: Twit - нельзя.
Date: 2005-09-22 12:40 pm (UTC)Потому что есть еще порожденные этими людьми темы. А кроме того, ЖЖ со слежением (если его добавить) позволяет следить ТОЛЬКО за интересными темами. И это правильно.
no subject
Date: 2005-09-22 05:33 pm (UTC)no subject
Date: 2005-09-22 09:29 am (UTC)"Пока люди, разрабатывающие наиболее удобные и надежные способы, будут иметь в виду только СВОИ потребности и удобство, они обречены на то, что их гениальные находки останутся востребованы предельно малой аудиторией".
Этот принцип чеканно работает в любой области, предполагающей потребление пользователем конечного продукта. Но почему-то именно для компьютерщиков (некоторых) в нем видится что-то аморальное. :-)
no subject
Date: 2005-09-22 09:49 am (UTC)есть два метода разработки и внедрения - "сверху" и "снизу".
сверху - это сначала все спроектировали, разработали, отладили и начинаем внедрять. все бы ничего, но к моменту начала внедрения 1) время уже ушло и потребности поменялись, а архитектура системы уже заложена!
2) проектирование ведется на декларируемых задачах системы и потребностях пользователя, или - что еще хуже - на подразумеваемых. что кардинально отличается от реальных задач и потребностей (разворачивать мысль, надеюсь, не надо?). в результате - пользоваться не будут, либо потому что пользователям это не надо и их в лучшем случае придется загонять "в систему" насильно, либо реальные потребности руководства на самом деле не соответствуют декларируемым (какому руководству у нас в стране нужна прозрачность системы? а декларируют - почти все) и о системе тихо забудут.
снизу - это реализация частных реальных задач, причем начиная не с высшей администрации, а исполнителей. и получается это всегда на порядки дешевле, и как правило эффективнее. мелкие кубики потом можно собрать в большую систему, при необходимости - переписать какой-то конкретный кубик. свои грабли конечно и тут есть....
так вот, замечательные интерфейсы и т.д. - как правило, создаются по принципу, аналогичному принципу разработки "сверху"
no subject
Date: 2005-09-22 11:38 am (UTC)Стихийный вариант быстрее реагирует на соперативные изменения ("вышел новый вирус"), но крайне консервативен к серьезным изменениям, а также плодит много стандартов. Иногда лучше один кривой, чем три хороших...
no subject
Date: 2005-09-22 11:40 am (UTC)no subject
Date: 2005-09-22 11:53 am (UTC)И есть еще одна проблемка, которую часто забывают. Проектирование снизу, как правило, не обязано принимать во внимание интересы широкого круга пользователей (в силу менее коммерческого характера). Да, пользователь может сам что-то добавить; но в итоге получается система, приспособленная под нужды программиста. :-)
no subject
Date: 2005-09-22 01:06 pm (UTC)и системность тут уже ничем не помогает. идеальных систем - куча. работают реально - единицы.
вторая проблема - это уже вопрос организации. например, мне в такой ситуации задачи ставят не программисты, и результат оценивают не программисты.
no subject
Date: 2005-09-22 07:55 pm (UTC)Вспомни такую штуку, как "типовой сисадмин большой конторы". Все мы такое видели: человек, свято убежденный, что он тут главный, потому что только он знает в подробностях, как "правильно работать с техникой", гнущий пальцы направо и налево, пытающийся обустроить всю работу под свое удобство... и напрочь не помнящий, что он тут, вообще-то, не более чем обслуживающий персонал, и деньги ему платят исключительно за то, чтобы ОСТАЛЬНЫМ было удобно работать. Попробуй скажи, что ты такого не видел. :-)
Это было еще туда-сюда в эпоху больших ЭВМ, когда компьютер был исключительно высокопрофессиональным средством. И то порой работа летела только из-за наглости "жреца ЭВМ". А когда он нужен для любого хоть сколько-нибудь интеллектуального труда - такая ситуация абсурдна. Потому что у большинства программистов мозги закручены совершенно определенным образом, и понять, как мыслит, например, художник, они вообще не в состоянии. Что важнее - и не хотят понимать. Будучи свято убеждены, что там и понимать нечего: правильно мыслят только они, и надо всех остальных заставить думать так же.
no subject
Date: 2005-09-22 08:00 pm (UTC)а при работе снизу как раз с потребителями в плотном контакте и работаем.
no subject
Date: 2005-09-22 08:04 pm (UTC)Проектирование сверху как раз и пытается учесть как можно больше потребностей.
no subject
Date: 2005-09-22 08:12 pm (UTC)во-первых, по пункту . Если точно, то да, не накласть. А на выдоить :). Т.е. снять по-больше денег за по-меньше работы. И потребности пользователя им создаются на самом деле, а не анализируются. Попытка попрограммировать под MS очень быстро все расставляет на свои места.
Кроме того, по удобству работы именно десктопа тот же самый KDE (версии около 3.3-3.4) уже давно обогнал винды. Он чуть менее привычен, но зато на порядок функциональнее, и пользователи, просидевшие под KDE на виндовый интерфейсе.
У меня сейчас в эпсилон-окресности все компы, кроме дизайнерских, уже давно живут под линуксом. Секретарские в том числе. Коля вот только ради Zuma винду грузит иногда, хотя мог бы попросить меня поставить эмулятор :))
И эта окресность будет расширяться :)
no subject
Date: 2005-09-23 12:53 am (UTC)А песня о том, что линукс-де уже намного удобнее виндов, заслужил всенародное признание и не сегодня-завтра вообще обгонит винды по популярности в мире, поется столько лет, сколько существуют эти две линейки систем. Раза три я на нее даже покупался. Пожалуй, с меня уже хватит. :-)
no subject
Date: 2005-09-23 01:01 am (UTC)никто не говорит, что получать за свою работу по-больше - это неестественно.
также, как и естественно нежелание платить за воздух :)
мы-то смотрим со стороны потребителя, разве нет? :)
в домашнем секторе - не обгонит еще очень долго, до тех пор, пока там не будет заметно больше игр. в корпоративном секторе - все зависит от инерции системы, и тут ситуация легче. ну а все остальное по этому поводу уже пережевано много раз.
если есть желание - добро пожаловать в гости к нам в офис, посмотреть на практике, как оно работает.
no subject
Date: 2005-09-23 07:32 am (UTC)no subject
Date: 2005-09-23 07:42 am (UTC)полный бред по части копирайта и патентов, которые уже фактически изжили себя, а фактически только мешают (особенно патенты), кроме крайне редких случаев.
так и с закрытым ПО - мощность открытого ПО сейчас такова, что использование закрытого ПО фактически малоосмысленна и продолжается, по большей части, по инерции и за счет соответствующего лоббирования и откатов, кроме крайне редких случаев с очень специальным ПО.
no subject
Date: 2005-09-23 08:01 am (UTC)А что до ПО - "лоббирование" и "откаты" здесь глубоко ни при чем. Их иногда пытаются делать, но они не в состоянии создать монополию, на примере истории с Xbox это хорошо видно. Как бы это ни было досадно поборникам Линукса, огромное количество пользователей и программистов сделало свой выбор в пользу Виндов сознательно.
no subject
Date: 2005-09-23 08:07 am (UTC)Уточи, в каком месте хуже будет?
В случае более-менее крупных разработок и систем лоббирование и откаты - явления постоянные. Я не говорю о WinXP Home, конечно.
no subject
Date: 2005-09-23 08:22 am (UTC)А откаты и лоббирование, безусловно, происходят, с этим никто и не спорит. Но вот роль их очень сильно преувеличена.
На подобную работу с Хbox ушли колоссальные даже по меркам Микрософта деньги. Результат - приставка получила популярность. И только. Никаких "вытеснений с рынка", никакого даже существенного сокращения продаж конкурентов, а перспективы Xbox 2 - отнюдь не радужные, хотя деньги такой способ конкуренции продолжает жрать тоннами.
Я далек от мысли, что Микрософт "выше" этих методов (тем более, что их порой видно невооруженным глазом). Просто ошибкой было бы думать, что их применение все объясняет. Какое-то количество народу покупает "Кока-колу" ради "приза под крышкой", но если этого приза не будет - "Колокольчик" не вытеснит "Колу" с рынка. :-)
А еще я в своем ЖЖ только что просуммировал некоторые аргументы против виндов и в пользу линукса. :-)
no subject
Date: 2005-10-04 03:56 pm (UTC)Когда некрутые неинтеграторы в регионах понаделали массу невнятных продуктов по принципу "я его слепила из того что было", и встает задача, чтобы все это разом интегрированно заработало - вот тут и начинается радость в жизни. ;)) Нет, крупные системы - лучше уж сверху и в единой логике.
no subject
Date: 2005-09-22 11:44 am (UTC)"замечательные интерфейсы и т.д.", когда они создаются правильно, создаются по результатам иследования задач пользователей и методов, которые им для решения этих задач удобны.
В последнее время по этому поводу появляется все больше неплохих книг, да и заниматься этим начинают действительно всерьез.
Собственно, мне кажется, что в описании ты смешал зеленое со сладким. Методика разработки и методика внедрения - разные вещи.
no subject
Date: 2005-09-22 01:10 pm (UTC)т.е. с одной стороны, процесс согласования проекта там занимает огромное время (в МГУС вопросы организации внутренней информационной системы решаются уже полгода. только на днях были приняты первые необходимые решения)
с другой, к моменту принятия проекта ситуация изменилась (совершенно необязательно по вине самой организации, кстати), и проект надо переделывать.
если подходить к принятию проекта со всей полнотой ответственности, то в результате он не будет принят никогда.
no subject
Date: 2005-09-22 01:17 pm (UTC)Если делать проекты "снизу", наступаешь на массу хорошо знакомых грабель - постоянное допиливание, моментальная потеря прозрачности и читаемости кода, время "на разобраться" сравнимое или превышающее время "на переписать" и т.д. и т.п.
Эти проблемы тоже решаемы, но уже совсем не так легко, как просто смена метода проектирования. Сложность их решения уже сравнима со сложностью изменения системы работы больших неповоротливых структур. Здесь нужно воспитывать людей, писать строгие правила для того, в чем они привыкли чувствовать себя полноценными хозяевами - в коде, дизайне элементов... - и т.п.
no subject
Date: 2005-09-22 08:05 pm (UTC)проблема в том, что практически все системы, разрабатываемые "сверху" - закрытые, и там вообще практически ничего сделать нельзя.
кто бы спорил, но это нужно в любом случае.
еще раз - в контексте этого разговора "сверху" и "снизу" - это зарактеристика, описывающая, с какой стороны административной пирамиды мы идем, а не метод проектирования конкретного куска системы. проектирование "снизу" еще не означает, что мы пишем код абы как и прилепляем куда попало, лишь бы работало.
no subject
Date: 2005-09-22 10:50 am (UTC)Самый быстрый в изучении вариант выбирается при необходимости совершить единичное действие.
Самый удобный - при длительном пользовании, при условии, что человек умеет находить самый удобный вариант, и осведомлен, что самый быстрый в изучении != самый удобный.