XML — вольное изложение темы. Какие теги придумаешь, какую структуру создашь, то и твое. HTML — жестко очерченные рамки и названия. Если использовать только XML, то поисковые системы сойдут с ума. Потому что один назвал заголовок HEADER_LEVEL_ONE, а второй — H1. Как догадаться, что это одно и то же? Поэтому я и смешиваю два разных языка, выбирая для разных задач лучшее.
Поработайте с DOM деревом с учетом del и ins, и поймете в чем претензия. Мало того, вы знаете хоть одну систему, которая использует данные теги? Лично я не видел ни одной.
По поводу contenteditable, draggable. Им самое место в css.
Во поводу div'ов вместо конкретных тегов. Да, конечно же, можно так использовать, но читабельность такого кода ниже, чем чистый XML. Работа с DOM сложнее. Шанс на ошибку валидации выше. Попробуйте хоть раз поработать с XML в качестве оформления страниц, поймете разницу.
Шаблонная разметка не учитывает современные тенденции. Разместить все по шаблону не есть плохо. Плохо то, что это только статика. Да, и если я перенесу какой-то блок с одного места дерева DOM, в другое, он визуально поменяет свою позицию, если у него будет стоять position: a?
Я о приведенной по ссылке капче. Там используется несколько радиобатонов с картинками, и вопрос. Текстовый вопрос распарсить не составляет труда, это простой регексп. Дальше, подгружаем картинки, которые приведены в головоломке. Эти картинки созданы в чернобелом варианте, без шума, без градиентов. Если нужно найти не цифру, то для каждой цифры вручную или неким алгоритмом находятся три точки на картинке, которые стопроцентно характеризуют эту картинку как цифру, и дальше выбирается картинка, которая не совпадает с 10-ю паттернами.
Например, для 1 будут некие координаты [ [10, 7], [16, 7], [4, 5] ]. Если цвет пикселя в данных точках черный, то это единица. Иначе идем дальше.
Это типичный микроменеджмент. Не удивлюсь, если у вас хорошая текучка кадров или напряженная обстановка. На Хабре была уже отличная статья про микроменеджмент, найдите ее и почитайте.
Вы не доверяете своим работникам, считая, что они могут неправильно вас понять, не то сделать, не в ту сторону пойти. Лично я рассказываю сначала вводные данные, какую проблему мы реализовываем, потом мы долго общаемся на уровне каких-то абстракций, формируя логику системы в целом, потом расходимся по своим местам и реализовываем задуманное. Если кто-то находит проблему, то о ней немедленно сообщает, и снова возвращаемся к обсуждению. Сделать что-то не то в такой схеме почти нереально. Изучайте литературу про экстремальное программирование.
На счет креатива. Или контроль, или креатив. Выбирайте. Креатив — это способ вольной работы над задачей или задачами. Человек должен сам для себя выбрать, что он хочет сегодня делать, думать или работать, или отдохнуть. Постоянный контроль подстегивает его делать вид, что он работает, хотя ему хочется именно думать сегодня. Доверяйте работнику, пусть он три раза лучше шишки набьет на своем коде, но в итоге научится делать что-то и понимать что-то с первого раза.
Вопрос не в том, что работает или нет. Вопрос в том, нужно ли изучать сейчас DOS, или Windows98, чтобы удовлетворить потребность в изменениях в тех программах, которые уже работают в отрасли. Кривая интереса к данным продуктам давно ушла вниз, привлекательность данных знаний стремится к нулю. Но те люди, которые обладают знаниями устаревающих продуктов, они могут спокойно на этом сыграть, просто увеличивая стоимость своих работ.
В демонстрации я ограничиваю количество вариантов перестановки 5-ю вариантами. В статье же взял специально три, чтобы наглядно показать слабую сторону этого метода.
У вашего решения есть одна проблема. Пользователь может не всегда заметить то, что надо сделать еще что-то. В моем решении не заметить того, что напротив имени будут стоять чекбоксы с выбором пола, нереально. Т.е. конфуз человека будет акцентирующим внимание стимулом.
Сервисы распознают те капчи, которые популярны. Вставьте formcha в любой форумный движок, как тут же сотни человек по всему миру начнут придумывать алгоритмы взлома. Спрос рождает предложение.
Тотальный контроль говорит про то, что вы набрали недостаточно мотивированных работников. Или не получилось наладить информационные потоки в команде. Лично я всегда знаю, что если у человека трудности с реализацией, он придет ко мне. И он никогда не придет ко мне, если у него все хорошо, все получается, проблем нет. Узнать о неправильности действий работника можно только со временем, когда нужно будет переделывать этот кусок кода, расширять его функциональность, изменять его. Тотальный контроль убивает желание работать, не оставляя места для рабочего креатива.
Идея интересная, но не очень удобная. Если перенести полоску сенсорного экрана в низ монитора, то эффективность работы с таким помощником будет на порядок выше. Главная проблема ведь в том, что придется постоянно переводить взгляд с монитора на клавиатуру. Другая проблема в скорости прокрутки контента. Я могу ухватиться мышей за ползунок скроллбара и за несколько секунд быстро пролистать объемный массив информации, ища нужный элемент. Тут это превратится в пытку. Третий момент — когда будет светить солнце в бок клавиатуры, то ничего не будет видно на этом экранчике. Продукт направлен на домохозяек, и может вполне иметь успех.
Мешать будет множество пазловых задач, которые можно подсовывать роботу. Например, фигуры напротив должны совпасть, но могут быть разного цвета; пересесение двух знаков не должно оставлять пустот; смайлики должны или не должны быть всегда улыбающимися и так далее. Нужно решить пазл стопроцентно правильно, а это будет сложнее, чем нынешние капчи.
Ничего не мешает. Но обновляя страницу он всегда будет попадать на неправильный вариант. Это описано в статье.
Я специально не накручивал систему защиты от неправильных постов, чтобы пользователи могли поиграться с отправкой данных. По идее, каждая неправильная попытка с данного IP должна приводить к увеличивающимся задержкам между следующей порцией данных. Да, я не спорю, решение не идеально.
Это сугубо личные наблюдения за процессом решения проблем. Обычно человек зацикливается на каких-то заданных условиях и не может выйти за их пределы, потому что считает их константой. Изменять условия задачи — единственное, что остается, чтобы решить ее. Этот принцип не нов, и очень активно используется в математике.
XSLT не решает эту проблему.
По поводу contenteditable, draggable. Им самое место в css.
Во поводу div'ов вместо конкретных тегов. Да, конечно же, можно так использовать, но читабельность такого кода ниже, чем чистый XML. Работа с DOM сложнее. Шанс на ошибку валидации выше. Попробуйте хоть раз поработать с XML в качестве оформления страниц, поймете разницу.
Шаблонная разметка не учитывает современные тенденции. Разместить все по шаблону не есть плохо. Плохо то, что это только статика. Да, и если я перенесу какой-то блок с одного места дерева DOM, в другое, он визуально поменяет свою позицию, если у него будет стоять position: a?
Например, для 1 будут некие координаты [ [10, 7], [16, 7], [4, 5] ]. Если цвет пикселя в данных точках черный, то это единица. Иначе идем дальше.
Логика понятна?
На счет креатива. Или контроль, или креатив. Выбирайте. Креатив — это способ вольной работы над задачей или задачами. Человек должен сам для себя выбрать, что он хочет сегодня делать, думать или работать, или отдохнуть. Постоянный контроль подстегивает его делать вид, что он работает, хотя ему хочется именно думать сегодня. Доверяйте работнику, пусть он три раза лучше шишки набьет на своем коде, но в итоге научится делать что-то и понимать что-то с первого раза.
У вашего решения есть одна проблема. Пользователь может не всегда заметить то, что надо сделать еще что-то. В моем решении не заметить того, что напротив имени будут стоять чекбоксы с выбором пола, нереально. Т.е. конфуз человека будет акцентирующим внимание стимулом.
Сервисы распознают те капчи, которые популярны. Вставьте formcha в любой форумный движок, как тут же сотни человек по всему миру начнут придумывать алгоритмы взлома. Спрос рождает предложение.
Я специально не накручивал систему защиты от неправильных постов, чтобы пользователи могли поиграться с отправкой данных. По идее, каждая неправильная попытка с данного IP должна приводить к увеличивающимся задержкам между следующей порцией данных. Да, я не спорю, решение не идеально.
Тенденция развития мобильных браузеров радует. Скоро проблема отсутствия JS не будет волновать разработчика.