По моему опыту работы в техподдержке, в таком подходе есть две проблемы:
Не все разработчики могут работать ровно 7 часов в день. Бывают дни, когда голова совсем не соображает, и вместо положенных семи-восьми часов на кодинг уходит часа два-три, а в остальное время залипаешь на хабре занимаешься непродуктивной деятельностью. Зато в другие дни прет так, что выполняешь 16-часовой объем работы за восемь часов. Преимущество двухнедельного спринта в том, что он позволяет сгладить эти пики и провалы и в среднем проиводительность каждые две недели получается одинаковой. Если же стоять с кнутом рядом с разработчиком, чтобы он, не дай бог, не тратил свое время на комментирование всяких статей на Хабре и каждый день выдавал 7-8 кодо-часов, то большинство разработчиков впадают в депрессию и увольняются. Справедливости ради, надо сказать, что я встречал и других разработчиков, которые способны работать 8 часов с перерывом только на обед и туалет, но, обычно, их производительность на двухнедельном интервале оказывалась либо такой же, либо даже ниже, а качество их работы, зачастую, было довольно посредственным. Если бы вот они хотели уволиться, то было бы, наверное, даже не особо-то и жалко, но увольняться хотели только те, кто писал хороший и качественный код, но не желал работать ровно по восемь часов в день. Но я, конечно, допускаю, что это, возможно, мне так не повезло и мне попались «избалованные разработчики», которые не могут работать без роликов с котятами на ютубе и ежедневного Хабра. (Сам я, если что, тоже такой.)
В зависимости от качества поддерживаемого продукта, бывает так, что приходит жалоба на какую-то проблему, начинаешь разбираться и оказывается, что это отдел разработки наговнокодилнаделал костылей реализовал не совсем удачное решение. Или что это проблема архитектуры, которая привела к тому, что абстракции нижележащего слоя в проекте стали протекать. Или что это бизнес-аналитик не предусмотрел такой сценарий и проблема на самом деле в требованиях. Или что бизнес-аналитиков на проекте вообще не нет, а разработчики не до конца понимали предметную область. Но ты — сотрудник техподдержки, вот у тебя задача, на которой стоит значок «XL», а значит она оценена в четыре часа или в два дня, или сколько там означает XL. И ты сидишь и думаешь, либо зарыться в 20 тысяч страниц спецификации предметной области, написанной инопланетянами для инопланетян (если она вообще есть), и потратить неделю только на локализацию проблемы, либо приделать еще пару костылей и скрестить пальцы наудачу. В общем, суть здесь в том, что проблемы здесь создают одни люди (говнокодеры из отдела разработки, тестировщики, которые это проморгали, бизнес-аналитики или менеджмент, который пожалел денег на бизнес-аналитиков), а разгребать все это приходится сотрудникам техподдержки. Это очень благодатная почва для возникновения межличностных конфликтов и если не предусмотреть возможность переадресации задачи, например, в отдел разработки после ее первоначального анализа сотрудником техподдержки, то у него может сложиться ощущение, что он целыми днями решает проблемы, созданные другими людьми, и что это не совсем честно, и что проходит время и ничего не меняется, и все навязчивее звучат в голове мысли о том, чтобы бросить все это и уволиться. У нас было не все так печально, как я здесь обрисовал, но все же была возможность приостановить задачу после первоначального анализа (который спокойно может занять полдня), отодвинуть ее ниже в списке приоритетных задач или вообще переадресовать в другой отдел.
Не совсем понял, как это могло бы помочь. Или вы предлагаете переключиться в режим просмотра, выделить текст, переключиться обратно, и чтобы выделение сохранилось? Мне кажется, так сделать не получится, потому что смежные параграфы реализованы отдельными contenteditable-блоками. Представьте, что каждый параграф — это отдельный textarea, просто без рамок. Очевидно, что нельзя начать выделять текст в одном textarea и продолжить выделение в следующем.
Вообще в стандартных контролах для редактирования текста (как в браузере, так и в десктопных приложениях) существует много "мелочей", которые, как мне кажется, большинством людей воспринимается как данность, доступная повсеместно из коробки или же легко реализуемая. Помню, как в самом начале моей карьеры тимлид поручил мне "набросать по-быстрому простой WYSIWYG-редактор" для десктопного приложения, которое мы разрабатывали. Все нужно было отрисовать на Windows GDI: рамку, курсор, скроллбар, выделение, ну и, конечно, отрендерить сам текст. К счастью, никаких картинок или таблиц. По оценке тимлида у него бы на это ушло два дня, но поскольку я был тогда джуниор, то мне он щедро выделил аж целых четыре дня. У меня на все это ушло три недели с дикими овертаймами. (К концу разработки мне уже в буквальном смысле снились кошмары про то, что я забыл учесть кернинг при расчете ширины текста.) Еще через неделю, после того, как это ушло в продакшн, пользователи прислали нам несколько десятков багрепортов вида: «А что это я тут нажимаю Shift+Ctrl+End (выделить от курсора до конца текста), а оно не работает?» Еще через две недели, потраченные на то, чтобы попытаться все это реализовать, тимлид плюнул и решил заменить наш контрол на стандартный RichTextBox. Пусть он корявый и ущербный (например, выравнивание текста по ширине, которое так хотел тимлид, в нем не поддерживается), но зато все "мелочи" в нем, в отличие от нашего велосипеда, реализованы на 100%.
В вебе ситуация еще более плачевная, поскольку к итак уже непростой задаче добавляются еще и ограничения браузера (если, конечно, вы не на канвасе все вручную рисуете — но тогда вам остается только посочувствовать). Есть прекрасный блог Content Uneditable от разработчиков CKEditor и вводная статья ContentEditable — The Good, the Bad and the Ugly, которая наглядно показывает масштаб проблемы, с которой сталкиваются начинающие разработчики, которые решили разработать свой онлайн-редактор и еще не подозревают, сколько "мелочей" им придется реализовать самостоятельно. Проиллюстрирую на примере Editor.js. Возьмем несколько абзацев текста, кликнем в середину первого абзаца и несколько раз нажмем кнопку "вниз" на клавиатуре. Сначала посмотрим, как это работает в "обычных" текстовых редакторах (Microsoft Word в качестве примера):
Обратите внимание, как Word старается, по возможности, точно сохранить горизонтальную позицию курсора при переходе между строками и абзацами.
Можно заметить, что при переходе между смежными абзацами позиция курсора теряется. (Плюс еще в конце каждого абзаца курсор сначала прыгает в конец строки перед переходом к следующему абзацу — ожидаемое поведение, если вспомнить, что каждый абзац ведет себя как отдельная textarea.) Можно возразить, что это мелочи — подумаешь, придется лишний раз кликнуть мышью — но из таких мелочей и складывается тот самый "user experience". Представьте себе контент-менеджера, годами пользовавшегося редакторами, которые ведут себя подобно Microsoft Word. У него все эти "мелочи" уже чуть ли ни на уровне мышечной памяти, поэтому процесс привыкания к поведению нового редактора у него будет выглядеть как-то так: нажал что-то на автомате -> получил неожиданный результат -> удивился -> вспомнил, что тут все не так -> в очередной раз проклял разработчиков -> исправил и продолжил работу до возникновения следующей проблемы. В результате он либо все-таки переучится, ценой потраченных нервов, либо плюнет на все и будет набирать текст в Word, а затем копировать результат в онлайн-редактор.
Все блочные редакторы на contenteditable, которые мне удалось нагуглить (включая и Editor.js), страдают от одной и той же проблемы: выделение текста ограничено одним блоком. То есть, если вы нажмете левую кнопку мыши в середине одного параграфа и переместите указатель мыши на середину следующего параграфа, чтобы выделить несколько предложений, то выделение текста остановится на конце первого параграфа. Да, в Editor.js есть еще и «прямоугольный» режим, который позволяет вам выбрать все блоки, попадающие в указанную мышью прямоугольную область, но во-первых, это не совсем типичное поведение для текстового редактора (пресловутый контент-менеджер, привыкший работать в Microsoft Word, может и не догадаться, что так можно), а во-вторых, выделяется либо сразу весь блок, либо ничего — часть блока таким образом не выделить. Ну и плюс с клавиатуры такое не сделать, только мышью.
В некоторых ситуациях эта проблема несущественна, например, если вам нужно быстро набрать большое количество текста с минимальными правками. Но если вам приходится часто заниматься редактурой уже написанных текстов, перемещая одни куски текста и переписывая другие, то WYSIWYG Markdown-редакторы могут оказаться удобнее в использовании.
залипаешь на хабрезанимаешься непродуктивной деятельностью. Зато в другие дни прет так, что выполняешь 16-часовой объем работы за восемь часов. Преимущество двухнедельного спринта в том, что он позволяет сгладить эти пики и провалы и в среднем проиводительность каждые две недели получается одинаковой. Если же стоять с кнутом рядом с разработчиком, чтобы он, не дай бог, не тратил свое время на комментирование всяких статей на Хабре и каждый день выдавал 7-8 кодо-часов, то большинство разработчиков впадают в депрессию и увольняются. Справедливости ради, надо сказать, что я встречал и других разработчиков, которые способны работать 8 часов с перерывом только на обед и туалет, но, обычно, их производительность на двухнедельном интервале оказывалась либо такой же, либо даже ниже, а качество их работы, зачастую, было довольно посредственным. Если бы вот они хотели уволиться, то было бы, наверное, даже не особо-то и жалко, но увольняться хотели только те, кто писал хороший и качественный код, но не желал работать ровно по восемь часов в день. Но я, конечно, допускаю, что это, возможно, мне так не повезло и мне попались «избалованные разработчики», которые не могут работать без роликов с котятами на ютубе и ежедневного Хабра. (Сам я, если что, тоже такой.)наговнокодилнаделал костылейреализовал не совсем удачное решение. Или что это проблема архитектуры, которая привела к тому, что абстракции нижележащего слоя в проекте стали протекать. Или что это бизнес-аналитик не предусмотрел такой сценарий и проблема на самом деле в требованиях. Или что бизнес-аналитиков на проекте вообще не нет, а разработчики не до конца понимали предметную область. Но ты — сотрудник техподдержки, вот у тебя задача, на которой стоит значок «XL», а значит она оценена в четыре часа или в два дня, или сколько там означает XL. И ты сидишь и думаешь, либо зарыться в 20 тысяч страниц спецификации предметной области, написанной инопланетянами для инопланетян (если она вообще есть), и потратить неделю только на локализацию проблемы, либо приделать еще пару костылей и скрестить пальцы наудачу. В общем, суть здесь в том, что проблемы здесь создают одни люди (говнокодеры из отдела разработки, тестировщики, которые это проморгали, бизнес-аналитики или менеджмент, который пожалел денег на бизнес-аналитиков), а разгребать все это приходится сотрудникам техподдержки. Это очень благодатная почва для возникновения межличностных конфликтов и если не предусмотреть возможность переадресации задачи, например, в отдел разработки после ее первоначального анализа сотрудником техподдержки, то у него может сложиться ощущение, что он целыми днями решает проблемы, созданные другими людьми, и что это не совсем честно, и что проходит время и ничего не меняется, и все навязчивее звучат в голове мысли о том, чтобы бросить все это и уволиться. У нас было не все так печально, как я здесь обрисовал, но все же была возможность приостановить задачу после первоначального анализа (который спокойно может занять полдня), отодвинуть ее ниже в списке приоритетных задач или вообще переадресовать в другой отдел.Не совсем понял, как это могло бы помочь. Или вы предлагаете переключиться в режим просмотра, выделить текст, переключиться обратно, и чтобы выделение сохранилось? Мне кажется, так сделать не получится, потому что смежные параграфы реализованы отдельными contenteditable-блоками. Представьте, что каждый параграф — это отдельный textarea, просто без рамок. Очевидно, что нельзя начать выделять текст в одном textarea и продолжить выделение в следующем.
Вообще в стандартных контролах для редактирования текста (как в браузере, так и в десктопных приложениях) существует много "мелочей", которые, как мне кажется, большинством людей воспринимается как данность, доступная повсеместно из коробки или же легко реализуемая. Помню, как в самом начале моей карьеры тимлид поручил мне "набросать по-быстрому простой WYSIWYG-редактор" для десктопного приложения, которое мы разрабатывали. Все нужно было отрисовать на Windows GDI: рамку, курсор, скроллбар, выделение, ну и, конечно, отрендерить сам текст. К счастью, никаких картинок или таблиц. По оценке тимлида у него бы на это ушло два дня, но поскольку я был тогда джуниор, то мне он щедро выделил аж целых четыре дня. У меня на все это ушло три недели с дикими овертаймами. (К концу разработки мне уже в буквальном смысле снились кошмары про то, что я забыл учесть кернинг при расчете ширины текста.) Еще через неделю, после того, как это ушло в продакшн, пользователи прислали нам несколько десятков багрепортов вида: «А что это я тут нажимаю Shift+Ctrl+End (выделить от курсора до конца текста), а оно не работает?» Еще через две недели, потраченные на то, чтобы попытаться все это реализовать, тимлид плюнул и решил заменить наш контрол на стандартный RichTextBox. Пусть он корявый и ущербный (например, выравнивание текста по ширине, которое так хотел тимлид, в нем не поддерживается), но зато все "мелочи" в нем, в отличие от нашего велосипеда, реализованы на 100%.
В вебе ситуация еще более плачевная, поскольку к итак уже непростой задаче добавляются еще и ограничения браузера (если, конечно, вы не на канвасе все вручную рисуете — но тогда вам остается только посочувствовать). Есть прекрасный блог Content Uneditable от разработчиков CKEditor и вводная статья ContentEditable — The Good, the Bad and the Ugly, которая наглядно показывает масштаб проблемы, с которой сталкиваются начинающие разработчики, которые решили разработать свой онлайн-редактор и еще не подозревают, сколько "мелочей" им придется реализовать самостоятельно. Проиллюстрирую на примере Editor.js. Возьмем несколько абзацев текста, кликнем в середину первого абзаца и несколько раз нажмем кнопку "вниз" на клавиатуре. Сначала посмотрим, как это работает в "обычных" текстовых редакторах (Microsoft Word в качестве примера):
Обратите внимание, как Word старается, по возможности, точно сохранить горизонтальную позицию курсора при переходе между строками и абзацами.
Теперь тот же самый эксперимент на главной странице Editor.js:
Можно заметить, что при переходе между смежными абзацами позиция курсора теряется. (Плюс еще в конце каждого абзаца курсор сначала прыгает в конец строки перед переходом к следующему абзацу — ожидаемое поведение, если вспомнить, что каждый абзац ведет себя как отдельная textarea.) Можно возразить, что это мелочи — подумаешь, придется лишний раз кликнуть мышью — но из таких мелочей и складывается тот самый "user experience". Представьте себе контент-менеджера, годами пользовавшегося редакторами, которые ведут себя подобно Microsoft Word. У него все эти "мелочи" уже чуть ли ни на уровне мышечной памяти, поэтому процесс привыкания к поведению нового редактора у него будет выглядеть как-то так: нажал что-то на автомате -> получил неожиданный результат -> удивился -> вспомнил, что тут все не так -> в очередной раз проклял разработчиков -> исправил и продолжил работу до возникновения следующей проблемы. В результате он либо все-таки переучится, ценой потраченных нервов, либо плюнет на все и будет набирать текст в Word, а затем копировать результат в онлайн-редактор.
В некоторых ситуациях эта проблема несущественна, например, если вам нужно быстро набрать большое количество текста с минимальными правками. Но если вам приходится часто заниматься редактурой уже написанных текстов, перемещая одни куски текста и переписывая другие, то WYSIWYG Markdown-редакторы могут оказаться удобнее в использовании.
Справдливости ради, объяснения
в книге нет. Там вообще мало внимания уделено цвету предметов.