>Бывают и просто плохие интерфейсы, как, скажем, у GIMP или vi.

Бывают ещё и пользователи, не способные забраться высоко по кривой обучения, несмотря на все усилия.

(Reply to this) (Thread)

Я, кстати, такой! я даже печатать так и не научился быстро.
И в игрушки играть на среднем уровне.

(Reply to this) (Parent) (Thread)

Э… может потому, что никогда целенаправленно не учился?

Я вот, скажем, умею относительно быстро печатать (~200 знаков в минуту, со многочисленными ошибками), но я этому именно учился, то есть почти ежедневно тратил на упражнения время несколько месяцев подряд.

А в игрушки у меня тоже плохо получается играть. Ни одной серьёзной игры ещё не прошёл до конца, кажется.

(Reply to this) (Parent)

Ну, их гораздо меньше, чем кажется, ИМХО. Гораздо больше тех, кто не может как следует научиться, потому что не понимает, что учиться надо.

Товарищ, работавший одно время в Microsoft, говорил, что в восьмидесятые годы каждая американская секретарша знала SQL. Не знаю, так ли это на самом деле (в принципе, верится) — если и правда так, то это хорошая иллюстрация к тому, что тупость "конечного пользователя" сильно преувеличивают.

В конце концов, любой полуграмотный гопник способен научиться водить и даже ремонтировать автомобиль, а ведь это гораздо более сложная деятельность, чем набор текстов в LaTeX или повседневное программирование на bash…

(Reply to this) (Parent) (Thread)

Юра, никогда не видели, как работают тру олдскул турагенты? У них в винде есть волшебная консолька, в которую они вбивают зубодробительные команды для поиска авиарейсов со всеми вариантами пересадки. Практически SQL :) Я реально протащился, когда первый раз увидел :)

(Reply to this) (Parent) (Thread)

После этого вашего комментария я вспомнил, что примерно про это же рассказывал gogabr (и кабы не в ответ на ту же байку про секретарш).

(Reply to this) (Parent)

когда я был в 9-м классе (год так 94-95й), папаша написал некое учебное пособие по физике для поступающих в вузы. 120 страниц. папаша человек старой закалки и рукопись выложил передо мной со словами: набирай. комп мне тогда только купили. и я тупо стал набирать в ворде. более того когда я пошел к знакомому отца, тоже физику, он мне посоветовал для набора формул Microsoft Eqution. кстати, отец сразу сказал набирать БЕЗ формул и графических объектов. Он, как человек старой закалки, принимал как должное, что это все он впишет руками, опечатки заклеит врезками. Потом все напечатается офсетным способом. работа была аццкая. но доведена до конца, хотя совершенно через жопень.
с тех пор я ворд возненавидел.
бля, надо найти файлы с текстом, и на примере этой методички освоить ТеХ.

(Reply to this) (Thread)

О-о. Сочувствую.

Я ворд возненавидел, когда перед защитой понадобилось срочно вставить кусок в диплом, и в нём поехали сноски.

(Reply to this) (Parent)

А не могли бы снабдить ссылочкой, откуда можно качнуть более-менее свежую версию Латекса _в_удобной_сборке_ с локализованным русским интерфейсом под Вынь? В стиле- скачал-установил-запустил-и_нырнул_в_мануал. А то меня тут загрузили CobiT-ом, и переводить мне пока есть чего )))
Заранее очень признателен

P.S. Кста, сообщество решило наконец вопрос со знаком евро в Латексе? Из-за таких вот мелочей нормальный продукт и не получает нормального распространения...

(Reply to this) (Thread)

качнуть более-менее свежую версию Латекса _в_удобной_сборке_

Уже лет семь как не настраивал LaTeX на виндовских машинах, так что не в курсе, увы (на моей-то системе актуальная версия скачивается и настраивается одной командой; это, кстати, не последняя вещь из побудивших в своё время уйти с винды). Дистрибутивы emTeX и MiKTeX лежат на ftp-шнике МЦНМО; насколько они при этом "свежие" и "удобные", не знаю, но с MiKTeX'ом вроде не сильно компьютерно-продвинутые люди справляются без труда… Единственное — они с шенёвской русификацией; но babel там тоже, думаю, должен быть.

Кста, сообщество решило наконец вопрос со знаком евро в Латексе?

Опять же — ни разу не было надо, поэтому не знаю, результаты гуглирования вы и без меня представляете, думаю. А чем плохи eurosym (в tetex и, если я ничего не путаю, livetex он входит в поставку; так что, наверное, в виндовских версиях тоже) или использование euro из babel'евского пакета greek?

Да, и оно произносится "латех", ЕМНИП.

(Reply to this) (Parent)

> Про каждый из этих продуктов, я, пожалуй, берусь рассказать, почему он хорош, если это кому-нибудь интересно.


Гораздо интереснее было бы послушать, чем плохи аналогичные продукты :)

(Reply to this) (Thread)

Э… вообще-то весь постинг именно про это. И по второй и третьей ссылкам есть ещё.

(Reply to this) (Parent)

Впрочем, в треде чуть ниже раскрывается тема ворда.

(Reply to this) (Parent)

"Классический пример: много ли пользователей пользуются стилями в ворде?"

мне кажется, тут есть некоторая логическая ошибка.

причина неактивного использования стилей в ворде - не в неудобстве интерфейса. просто у ворда и у LaTeX'а - разная пользовательская аудитория.

большинству пользователей ворда стили просто не нужны. пользователям LaTeX - нужны.

людям, которым стили именно что нужны, по-моему, в ворде их освоить гораздо легче. а что там собственно осваивать? хорошо заметная панель на самом видном месте. в случае LaTeX'а, думаю, будет масса гугления и очень много мата ;-)

хотя, может быть, я так думаю, потому что у меня LaTeX, несмотря на активное использование, так и не пошёл. а вордом я пользуюсь как профессиональным инструментом, в том числе и для сложных вещей.

то есть, к ворду у меня тоже есть претензии, но не из-за интерфейса, а из-за стандарта документов.

(Reply to this) (Thread)

да - и самое главное - что такое "интерфейс LaTeX"? я что-то пропустила, и словом "LaTeX" теперь называется не только язык разметки, но и какой-то интерфейс?

(Reply to this) (Parent) (Thread)

Интерфейсом, в принципе, можно назвать любой способ взаимодействия человека и программы (или программы и другой программы, или программы и устройства, или человека и устройства…). См., например, термин "API" — "Application Program Interface".

Вообще, разделение способов взаимодействия с программой на "пользовательские интерфейсы", "языки разметки" и "языки программирования" иногда бывает вредно (я, собственно, начал это понимать, обдумывая комментарий вот к этому посту Витуса Вагнера; комментария не получилось, получился почему-то исходный пост этого треда) именно потому, что оно скрывает простой факт: пользуясь и первым, и вторым, и третьим мы всё равно программируем компьютер, то есть сообщаем ему о необходимости выполнения определённых действий.

Именно поэтому упомянутые вами претензии к вордовскому формату файлов для меня тоже — претензии к интерфейсу.

(Reply to this) (Parent)

большинству пользователей ворда стили просто не нужны. пользователям LaTeX - нужны.

Если бы это было так, у меня бы было поводом меньше писать этот пост (и несколько лишних лет жизни). К сожалению, это неправда.

В статье страниц на двадцать, присланной коллегой, ещё можно сбросить всё форматирование и применить нужные стили вручную. А вот когда у вас есть целая книжка, в которой заголовки сделаны ручным центрированием и сменой шрифта, абзацные отступы пробелами и т.д. — это иногда проще перенабрать, чем доводить до ума… Ещё хуже, кстати, случаи, когда из горы мелких документов, в каждом из которых думать о стилях, казалось бы, смешно, надо собрать один документ с очень жёстко определённым оформлением. Особенно если авторы этих мелких документов — разные люди.

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

Плохо не то, что стили трудно заметить (достаточно легко). Плохо то, что без них можно обойтись. И (главное!) то, что кто-то решил без них обойтись, может испортить жизнь лично мне. Вообще, я, наверное, общие претензии к ворду сейчас вынесу в отдельный комментарий, а то мы рискуем здорово отклониться от темы "ворд, латех и стили".

в случае LaTeX'а, думаю, будет масса гугления и очень много мата ;-)

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

Кривая обучения LaTeX'у напоминает график логарифмической функции: поначалу крутовато, но чем дальше, тем положе — принципы работы с системой не слишком просты, но они единообразны. В случае с вордом кривая обучения это скорее парабола: чем дальше, тем круче. Собственно, в вашем же блоге можно найти подтверждение тому. =) Кстати, должен выразить вам своё восхищение: я по работе время от времени имею дело с DocBook, умею писать XSLT-преобразования, немного представляю SVG изнутри, даже принимал участие в создании одного локального XML-формата, то есть не то, чтобы совсем не представляю себе XML-технологии — но понимание этого явно за пределами моих интеллектуальных возможностей.

…но это уже, кажется, пошли претензии к ворду в целом, которые я обещал изложить в следующем комментарии.

(Reply to this) (Parent) (Thread)

_______________________
В статье страниц на двадцать, присланной коллегой, ещё можно сбросить всё форматирование и применить нужные стили вручную. А вот когда у вас есть целая книжка, в которой заголовки сделаны ручным центрированием и сменой шрифта, абзацные отступы пробелами и т.д. — это иногда проще перенабрать, чем доводить до ума…
______________________

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

(Reply to this) (Parent)

Точнее, почему его нельзя использовать никому, кто планирует передавать людям какие-то результаты такого использования помимо распечаток на бумаге.

Собственно, причин всего три: в ворд трудно поместить информацию, её неудобно в нём обрабатывать, а после обработки её трудно привести в пригодный для дальнейшего использования вид. =)

Теперь подробнее о каждой из этих проблем.

С первой всё просто: у ворда закрытый бинарный формат, с до сих пор, кажется, не опубликованными спецификациями; авторы всех читающих и/или пишущих его библиотек изучали его методом обратной разработки. Более того, нет даже гарантии, что вордовский же файл правильно воспримет другая (а хотя бы и та же) версия ворда на другой машине: думаю, каждый, кто регулярно им пользовался, сталкивался с этим. OO XML должен, по идее, избавить от части этих проблем; но, во-первых, и в нём хватает путаницы и неоднозначностей, во-вторых, пока его мало где можно встретить, в-третьих, офис2007 имеет настолько убогий интерфейс, что это сводит на нет преимущества нового формата.

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

Вторая проблема: ворд это WYSIWYG-приложение, почти без возможности непосредственного контроля разметки и без чёткого разделения логической и визуальной структуры. Хуже того, интерфейс ворда навязывает пользователю их смешение, с неизменно катастрофическими последствиями. Ну, об этом хорошо сказано в статье, ссылку на которую я привожу в исходном посте. Кроме того (на самом деле, в результате сочетания убогости формата и выбранной парадигмы интерфейса) ворд совершенно не предназначен для а)совместной работы, б)контроля версий. Wiki или (DocBook|Latex)+Subversion для этого настолько удобнее, что даже как-то странно сравнивать. (На всякий случай: я знаю, что такое SharePoint, у нас в конторе, к сожалению, пытаются его использовать; это выдающееся уродство даже на фоне других изделий Microsoft; могу подробнее написать, почему.)

Третья причина не использовать ворд отчасти пересекается с первой: результаты его работы малопригодны для дальнейшей обработки в силу а)кривости формата (впрочем, об этом уже сказано); б)малоразвитых средств контроля над логической структурой документа, в результате чего, например, из вордовского документа нельзя получить человекочитаемый HTML- или LaTeX-файл (впрочем, сказано и об этом); в)непредсказуемости устройства выходного файла — в зависимости от действий пользователя во время редактирования этот файл может содержать самую странную информацию.

В фирме, в которой я работаю, я (как и ещё несколько людей с опытом работы в разумно управляемых проектах) по мере сил пытаюсь вместо ворда внедрить вики для внутренней документации, Doxygen для программистской и DocBook для пользовательской. У тех сотрудников, которых удаётся убедить откзаться от ворда, количество работы уменьшается в разы (и возрастает её качество).

Да, как правило, уважаемые коллеги при этом плохо знают ворд и неадекватно его используют. Но это, мне кажется, как раз пример того, чего стоит "дружественный" интерфейс: нужные им возможности ворда закопаны гораздо глубже, чем соответствующая функциональность вики или DocBook.

(Reply to this) (Parent) (Thread)

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

я свою контору несколько раз думала "пересадить" с ворда на docbook - потому что очень хочется нормальный single-source publishing. но мне так и не удалось выяснить, как делать некоторые важные для нас вещи - например, брошюру в pdf. может быть, я недостаточно хорошо искала, но, похоже, это можно сделать, только через xsl-fo. у меня в результате про docbook сложилось впечатление, что он хорош для электронных документов, но не особо хорош для полиграфии.

то есть - если у тебя задача сделать "настоящую взрослую полиграфию" (книги, статьи, глянец) - ты возьмёшь scribus или тот же LaTeX, ну, в общем что-то очень мощное и не очень простое. но вряд ли docbook.

для наших задач, где "настоящая взрослая полиграфия" не требуется - распечатки брошюр с руководствами пользователя - мощности ворда вполне хватает, и сделать там всё это можно просто и быстро. и мои коллеги пользоваться вордом вполне себе умеют, в том числе и "глубоко", я, честно говоря, вообще не очень понимаю, что там есть глубокого, это вам не русский язык настраивать при конвертации docbook > pdf ;-)

как те же самые брошюры сверстать в docbook - я коллегам не смогу объяснить, потому что и сама не знаю.

ну то есть... если бы менеджмент хотел - они бы нашли ресурсы. а пока этого хочу одна я, у меня их не хватает.

(Reply to this) (Parent) (Thread)

например, брошюру в pdf. может быть, я недостаточно хорошо искала, но, похоже, это можно сделать, только через xsl-fo.

Ещё через LaTeX можно.

то есть - если у тебя задача сделать "настоящую взрослую полиграфию" (книги, статьи, глянец) - ты возьмёшь scribus или тот же LaTeX, ну, в общем что-то очень мощное и не очень простое. но вряд ли docbook.

DocBook как раз сделан для того, чтобы описывать логическую структуру документа, а не его оформление, так что говорить о его применении в полиграфии бессмысленно. Конкретная вёрстка должна происходить на уровне выходных форматов, для, скажем, HTML своя, для LaTeX своя. Собственно, нам с коллегами летом придётся решать вопрос относительно сложной вёрстки документа с исходником в DocBook (печатную документацию надо будет оформить по стандартам ЕСКД), посмотрим, насколько оно разумно устроено.

как те же самые брошюры сверстать в docbook - я коллегам не смогу объяснить, потому что и сама не знаю.

Я по той же причине не торопился с поптыками массового внедрения DocBook'а, пока на фирму не пришёл ещё один сторонник правильных способов подготовки документации с большим опытом вёрстки в LaTeX и знанием XSLT (всё-таки ситуация, когда программист сам себе техпис, имеет свои бонусы — выше концентрация FOSS-озабоченных гиков среди техписов, например =)).

(Reply to this) (Parent) (Thread)

DocBook как раз сделан для того, чтобы описывать логическую структуру документа, а не его оформление, так что говорить о его применении в полиграфии бессмысленно.

иначе говоря, то что в "процессе на ворде" может сделать один человек, в "процессе на докбуке" будет реализовывать целый отдел, состоящий из профи в разных областях ;-)

(Reply to this) (Parent) (Thread)

"Профи" это преувеличение.

Кроме того, тут уместна аналогия с пресловутым TCO — затраты на внедрение, конечно, чуть больше, чем при установке ворда; но суммарное количество усилий, затраченных на подготовку документации, в случае DocBook будет в разы меньше.

Пример навскидку: в онлайновой документации ссылки на другие разделы должны выглядеть как гиперссылки, в печатной — как фрагменты вида "(см. раздел 1.7.5)". Нет, я допускаю, что очень хорошо знающий ворд человек сможет в нём такое сделать; но, например, в нашей фирме, где, как я уже говорил, практически каждый программист сам себе техпис, вопрос этот решается… по-разному. Где-то в печатном тексте бессмысленные подчёркивания вместо ссылок, где-то в онлайновой версии кликабельных ссылок нет… А в ситуации с DocBook уважаемым коллегам достаточно знать полтора десятка тегов. Остальное сделает XSLT-процессор; при этом, что важно, нет необходимости следить за тем, что все выдерживают требуемые стандарты оформления. Напомню, ссылки — это только пример, на практике такие ситуации возникают постоянно.

O'k, пусть даже фирма имеет отдельную ставку техписа. Всё равно требования к его квалификации в случае DocBook, на самом деле, меньше: с технической стороной работы в рамках налаженной технологической цепочки справится даже обезьяна; если же нужна действительно осмысленная вёрстка, понадобятся более специализированные программные средства (мы хорошо понимаем, что такое HTML и PDF, "подготовленные" в ворде, да?) и люди, ими владеющие, то есть пресловутые "профи".

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

(Reply to this) (Parent)

все же мало народа публикуется.

мне приходится писать статьи ну раз в год.
верстать их будут профессионалы. биологические статьи моей тематики не содержат формул. только текст и графики. мне проще написать текст в rtf - и отдать на правку шефу.
если напишу в .tex, шеф не сможет править, потому что она не знает его. ПДФ править тоже нельзя.

вообще, визуальные редакторы не заканчивается вордом.

можно еще Адобовскими иллюстраторами-индизайнами заморочится.

(Reply to this) (Parent) (Thread)

можно еще Адобовскими иллюстраторами-индизайнами заморочится.

Но это не средства набора текста, это средства вёрстки! Если для типична ситуация, когда твой текст верстают другие, набор текста в них это чистой воды мазохизм (особенно в иллюстраторе, хехехе).

если напишу в .tex, шеф не сможет править, потому что она не знает его

Ну, мы же обсуждаем сферического коня в вакууме: как нам было бы удобно при прочих равных. Сейчас-то, когда WYSIWYG это стандарт de facto, у тебя нет особого выбора, понятно.

мне проще написать текст в rtf

Ну, тут два момента.

1. Тебе (и десяткам тысяч твоих коллег) — проще. А вот тем, кто вынужден верстать, скажем, журналы из разнородных текстов, в половине (хорошо если только в половине) которых визуальное форматирование вместо логического… ну, судя по твоим комментам выше, ты меня хорошо понимаешь. =)


2. Если верстаешь твои тексты всё равно не ты, нужен ли тебе WYSIWYG? Ведь в твоём случае это чистой воды WYGIWYNG — "What You See Is What You Never Get", реальное оформление твоих статей на бумаге определяешь не ты, а верстальщики научных журналов. А раз так, нужно ли тебе средство подготовки текстов с возможностями вёрстки (хреновыми, к тому же), может, средство создания логической разметки (не обязательно текстовый редактор + компилятор, как в случае LaTeX, оно вполне может быть визуальным) тебе подошло бы больше? А многих менее продвинутых пользователей оно бы ограничило, не позволяя делать абзацный отступ пробелами, а заголовки — ручным центрированием…

(Reply to this) (Parent)

Вообще, знаешь, какой текстовый процессор я считаю наилучшим на сегодняшний день? Writely из Google Documents. При подготовке текста, сложность форматирования которого превосходит возможности Writely, я всё равно буду использовать что-нибудь типа LaTeX; но для небольших текстов с несложной структурой он очень удобен — помимо очевидных преимуществ веб-приложения, кнопочкой "Редактировать HTML". Только решив с её помощью ряд типовых проблем, возникающих при работе в WYSIWYG-средствах (типа слетания форматирования при удалении куска текста), понимаешь, как её не хватает в аналогичных оффлайновых программах.

Жаль, что и там существуют средства визуального форматирования, не меняющие логической структуры, конечно.

(Reply to this) (Parent)

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

Ну вот скажем юникс-консоль и ее стандартные средства - начиная от ls и вплоть до развесистых консольных редакторов вроде emax'а. Есть вещи, которые я знаю как сделать через консоль - и тогда это действительно очень удобно. Но если я не знаю - то все, труба. Либо сутки курить маны (потому что они написаны для профессионалов, а не для первого встречного) либо брать очередного word-подобного урода. Кто мешает, скажем в дополнение ко обычным манам сделать тьюториалы - типа "10 самых типичных задач решаемых командой такой-то"? Кто мешает выводить подсказки по ключам - если их там под сотню, про 90 из них вообще фиг поймешь что они делают? Типа - нажал после команды tab, оно мне прямо в строке формирует что-то вроде выпадающего списка ключей и когда я какой-то выбираю - еще и тип пишет. Google-подобный поиск по документации - я формулирую вопрос на человеческом языке, а мне предлагают способы решить мою задачу? Все это можно сделать отключаемым, не вопрос. Аналогично - с латехом и любыми другими языками и скриптами...

Хорошо, интерфейс не обязан быть интуитивен каждому барану. Но в нем обязательно должны быть подсказки, как решить типичные задачи в два тыка. И метод "обыскать интерфейс и найти то что тебе надо" тоже нужен - другой вопрос, что, как в примере с вордом и стилями - фиговфе решения должны быть внятно помечены как durty. Типа, я изменяю шрифт в редакторе что бы сделать заголовок - оно мне в ответ тут-же предупреждает плавающей подсказкой, лучше так не делай, а сделай стиль.

Что-то у меня не формулируется то, что я хотел сказать... Много конкретных примеров, а общая мысль как-то затерялась -:))

(Reply to this) (Thread)

>Что-то у меня не формулируется то, что я хотел сказать...
Да, не, как раз вполне внятно. Ощущения, по крайней мере. Хотела написать примерно то же, но не сформулировалось совсем.
Типа +1 и всё такое.

(Reply to this) (Parent) (Thread)

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

Подробнее — в моих ответах Мите в этом же треде, а тебе, если позволишь, несколько вопросов для взаимного прояснения позиций: =)

• Предполагает ли твой "+1" под митиным комментом то, что ты посмотрела ролик, демонстрирующий возможности Enso, не понимаешь, зачем нужен подобный инструмент, и не использовала бы его, если бы он был установлен на твоём компьютере?


• Предполагает ли твой "+1" под митиным комментом то, что среда, в которой данные и приложения можно объединять так же легко, как в линуксовой консоли (скажем, мышкой собрать из файлового менеджера, графического редактора и браузера единое приложение для всех действий, которые ты делаешь с фотографиями, от скачивания с камеры до вывешивания в Сеть) не облегчила бы тебе общение с компьютером, и изолированные (ну, интегрированные как сейчас — drag'n'drop, ActiveX/Corba) приложения тебя вполне устраивают?


• Считаешь ли ты некорректной аналогию, на которой построена эта сценка? Если да, почему?


• Наконец, есть ли среди современных прикладных программ хоть одна, владение которой на профессиональном уровне помогло бы тебе в твоей повседневной деятельности? Если нет, то возможна ли в принципе такая программа? Что она могла бы делать?

Речь-то, на самом деле, не о том, какой из существующих интерфейсов лучше (холивар "ворд vs. командная строка" во всех отношениях бессмысленен), а чего мы хотим от интерфейсов вообще?

(Reply to this) (Parent)

Митя, прости, но у меня есть ощущение, что ты а)не слишком внимательно прочитал мой пост, б)не ходил по ссылкам.

Сначала в защиту "не совсем адекватной парадигмы", потом по частным возражениям, o'k?

Основная проблема "быстрых и грязных" решений в том, что на самом деле они не являются решениями: в 90% случаев это просто переваливание проблемы на других, или (что гораздо хуже; и чаще =)) на себя же в будущем. Твои бои с почтовой базой Widisoft, тому ярчайший пример. К моменту, когда пользователь понимает, что перерос б.-и-г. решение, он накапливает, скажем, огромные массивы ценных данных, которые, к тому же никуда не переносимы по причине кривизны используемого формата, или что-нибудь ещё в таком же роде.

То же самое можно сказать и по-другому: глядя на начальные отрезки обеих кривых обучения (см. мой ответ пользователю yermishkina), ты аппроксимируешь их прямыми, причём аппроксимируешь неправильно. Повторюсь: сторонники пресловутого "UNIX way" ведь не поголовно же мазохисты, правда? Такой подход к организации взаимодействия с компьютером действительно экономит усилия, за счёт модульности рабочего окружения, единообразия принципов работы с ним и высокой интероперабельности каждого его компонента. В итоге, во-первых, каждая следующая задача решается проще предыдущей, потому что принципы их решения единообразны, а во-вторых, принципиально новые задачи, для решения которых нужны новые средства, встают перед тобой гораздо реже.

Здесь не удержусь от того, чтобы снова процитировать башорг:

Если бы люди умели пользоваться vim, grep, sed, awk, то миллионы программных продуктов так никогда и не были бы созданы

(у меня есть некоторые возражения по поводу vim, ну да ладно =)).

В который раз в этом обсуждении можно привести аналогию с автомобилем: говорить о трудоёмкости освоения UNIX way это всё равно что отказываться учиться водить, мотивируя это тем, что каждый раз, когда надо будет куда-то поехать, придётся ходить на курсы вождения.

Кроме того, идея моего поста не в том, что б.-и-г. решения — это плохо. Плохо, что именно под них заточена инфраструктура современных рабочих сред — то есть вместо упомянутых выше модульности, единнобразия интерфейсов и интероперабельности мы имеем зоопарк наглухо изолированных, несовместимых ни по принципам управления, ни по форматам программных продуктов.

Плохи не "дружественность", и тем более не GUI сам по себе — они вполне могут быть реализованы вместе с разумной организацией инфраструктуры. Но не вместо же неё, как это происходит сейчас!

Почитай ещё одну (помимо той, на которую ссылка в исходном посте) статью Витуса Вагнера — True Unix GUI. Он там объясняет всё настолько кратко и ясно, насколько это вообще возможно, не вижу нужды пересказывать. К сказанному им можно добавить только, что "True Unix GUI" мог бы быть ещё удобнее, чем он описывает, будь он объединён средой типа Enso — если уж обсуждать эту тему, сходи всё-таки по ссылке и посмотри ролик, не пожалеешь!

Забавно, но мы, на самом деле, движемся именно в этом направлении. Спасение человечества придёт… из веба. На самом деле, современные веб-приложения, с их mashup-сервисами, с их универсальными форматами обмена данными (HTML, RSS/Atom, XMLRPC), с пока маргинальной, но очень многообещающей концепцией WebOS (хотя, на мой взгляд, корректнее говорить о Web Desktop Environment) — шаг, и огромный шаг, именно в нужном направлении, в направлении "True Unix GUI".

Скрестим пальцы.

(Reply to this) (Parent)

Теперь по мелкой конкретике. =)

Кто мешает, скажем в дополнение ко обычным манам сделать тьюториалы - типа "10 самых типичных задач решаемых командой такой-то"?

Никто. Собственно, таких ресурсов море — не устаю рекламировать, например, прекрасную страничку "Linux-Unix cheat sheets".

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

Типа - нажал после команды tab, оно мне прямо в строке формирует что-то вроде выпадающего списка ключей и когда я какой-то выбираю - еще и тип пишет.

Примерно это уже делает Zsh.

Google-подобный поиск по документации

Тоже уже существует: по man это whatis и apropos, по info — M-x index-apropos и M-x info-apropos в просмотрщике info.

Кстати, локальные поисковые сервисы в Windows и Windows-подобных средах (KDE, Gnome) вообще недооцениваются. Mac с его развесистыми средствами локального поиска, вокруг которых построен интерфейс, в этом отношении куда удобнее. Это полный оффтопик, но не удержусь и прорекламирую прекрасную программу Recoll, лучших из протестированных мной свободных локальных поисковиков.

Аналогично - с латехом и любыми другими языками и скриптами...

Вот этой фразы я не понял. Ты про хорошие руководства начального уровня? Но по тому же латеху есть книжка Львовского, доступнее которой, по-моему, быть просто не может…

(Reply to this) (Parent)

Хорошо, интерфейс не обязан быть интуитивен каждому барану. Но в нем обязательно должны быть подсказки, как решить типичные задачи в два тыка. И метод "обыскать интерфейс и найти то что тебе надо" тоже нужен - другой вопрос, что, как в примере с вордом и стилями - фиговфе решения должны быть внятно помечены как durty. Типа, я изменяю шрифт в редакторе что бы сделать заголовок - оно мне в ответ тут-же предупреждает плавающей подсказкой, лучше так не делай, а сделай стиль.

Ты, мне кажется, мешаешь в одну кучу очень разные вопросы.

1. "Хорошо, интерфейс не обязан быть интуитивен каждому барану." — да нет, как раз обязан. В том смысле, что между интерфейсом и задачей в предметной области должна просматриваться интуитивно очевидная, легко заметная связь. Ещё раз вспомним аналогию с автомобилем: назвал ли бы ты "интуитивным" управление автомобилем, состоящее из двух кнопок, "Поехать в работу" и "Поехать на дачу", а движение по остальным маршрутам позволяющее только через многочасовое копание под капотом, или не позволяющее вовсе?
   
   Сценка "Если бы люди водили также, как они работают на компьютерах" написана не вчера и не мной, ага. =)
   
   "Интуитивный интерфейс" в том смысле, который обычно имеется в виду, это buzzword, в принципе. Удобнее то, что привычно (ну, посмотри, как пользователи vindoze ругаются на "неудобство" объективно более эргономичных Маков), но не всё привычное сколько-нибудь эффективно, вот в чём беда.
   


2. другой вопрос, что, как в примере с вордом и стилями - фиговфе решения должны быть внятно помечены как durty. — ты знаешь, я не уверен, что dirty решения должны вообще быть возможны. Вопрос должен стоять так: "Как организовать среду, в которой можно комфортно работать без возможности сделать кривое решение?", а не "Как сделать так, чтобы в среде, ориентированной прежде всего на кривые решения, можно было делать хоть что-то разумное?".


3. Типа, я изменяю шрифт в редакторе что бы сделать заголовок - оно мне в ответ тут-же предупреждает плавающей подсказкой, лучше так не делай, а сделай стиль. — угу, "плавали, знаем, вся жопа в этих ракушках". Мить, что первым делом пользователь сотворит с этими подсказками? Отключит нахер, не читая, что характерно. Вообще, научить пользователя читать хотя бы сообщения об ошибках — это большая и до сих пор не решённая проблема
=).

Ещё раз: настоящая задача организации интерфейса решается только на метауровне. Не "консоль vs. GUI", а "принципы, на которых организована юниксовая командная среда vs. принципы, на которых организована современная графическая среда".

(Reply to this) (Parent)