Ну, не надо думать, что мы год кроме интерфейса ничем не занимались) Задач — вагон и маленькая тележка. Нужно работать над качеством самого распознавания, поддержкой различных сканеров, интеграцией в сторонние продукты, общей программной архитектурой и т.п. Список можно продолжать очень долго. Интерфейс делался весьма неспешно: зарелизим очередную версию, попользуемся пару недель, найдём неудобные вещи. Потом улучшаем разные мелочи, фиксим баги, потихоньку раздумываем над новыми фичами. Увы, за раз всё не придумывается, нужно планомерно пользоваться продуктом и доделывать интерфейс.
Рад слышать от вас конструктивные предложения. A/B тестирование собираемся проводить, когда пользователей будет немного больше.
ещё раз скажу я обычный пользователь с голосом
Ваш голос мы учтём, но впредь хотелось бы попросить вас быть менее категоричным. Бросать фразами вида «Элементарно хреновый интерфейс» или «если же по вашему делать то все выйдет в разы дольше» в программу, которой вы никогда не пользовались, как-то не очень вежливо. Или говорить «никаких аргументов за привести за обратный порядок», когда я только что привёл аргументацию (которую вы благополучно проигнорировали). Или настаивать, что в нашем варианте на сверку уходит слишком много времени, заявляя что при «правильном порядке полей» у вас ушло бы 10 секунд (в то время, как я трачу 3–4 секунды на паспорт).
Я на вас не обижаюсь, просто мне хочется донести до вас мысль, что у нас был резон сделать всё именно так. Мы тестировали программу на пользователях, мы опрашивали целевую аудиторию и мы сделали всё именно так из-за того, что у нас были причины. Порядок полей в российском паспорте (который не оказывает никакого влияния на процесс проверки) был принесён в жертву ради того, чтобы во всех документах был единообразный порядок полей.
Послушайте, я сам пользуюсь этим интерфейсом раз по 50 каждый день. И очень часто мне доводится общаться с пользователями, которые высказывают мне свои мысли по поводу удобства программы. Меня удивляет то, насколько категорично вы отзываетесь об удобстве интерфейса, не поработав с ним лично.
Могу засвидетельствовать, что мне не нужно в разы больше времени на проверку, чем вам. Мне даже не нужны 10 секунд, я проверяю правильность распознавания намного быстрее. Также мне ни раз доводилось видеть реальных операторов за нашей программой: всё должно быть очень плохо, чтобы кто-то потратил 10 секунд на проверку результатов. На оригинальную картинку смотреть нет никакой необходимости, это слишком долго.
Но если вы захотите купить PassportVision, то специально для вас мы можем выставить тот порядок полей, который вас устроит. Если очень надо, то можем даже серию и номер паспорта повернуть под 90 градусов, чтобы совсем было как в паспорте.
Я надеялся, что соседство слов «строгая» и «вжух» создаст ощущение иронии, которая повлечёт за собой лёгкую улыбку на лице у читателя. Извиняюсь, если мой манёвр не удался. На самом деле, перед написанием каждой отдельной фичи мы подолгу обсуждали прототип на бумаге, рисуя эскизы и составляя подробное описание. Но приводить подобные технические документы в посте на Хабр смысла особого не имеет, поэтому захотелось сократить этот текст до пары предложений, кратко передающих общую суть наших задач в юмористической форме.
Не соглашусь с вами. Введение всплывающих подсказок позволило вообще не обращать внимание на оригинальную картинку — вы проверяете распознавание конкретных полей вне зависимости от того, в каком порядке они стоят в исходном документе. С другой стороны, статичный порядок данных очень удобен (оператор привыкает, что сначала идёт фамилия, потом имя и т.д.). Представьте, что у вас большой поток клиентов, каждый из которых приносит разные документы: кто-то обычный паспорт, кто-то заграничный, кто-то водительские права (в некоторых местах подходит любой документ для идентификации личности). Оператору совершенно неважно какой документ ему дали, и в каком порядке на нём идут поля. А если для каждого документа делать свой порядок полей, то как раз это и внесёт путаницу. Проблемы могут возникнуть даже с одним типом документа: например, загранпаспорта разных версий имеют различный порядок полей. Мы считаем, что нет смысла тусовать поля в зависимости от типа документа ввиду того, что в нашей системе для оператора вообще нет необходимости смотреть на оригинальное изображение.
Но если так уж сильно коробит, то можно поправить в настройках, последнее слово всё равно за пользователем.
Штука прикольная, но, к сожалению, она работает только с машиночитаемой зоной. Для загранпаспортов этот вариант пойдёт, но на обычных русских паспортах такая зона появилась совсем недавно. PassportVision умеет работать как с русскими паспортами различных версий, так и с загранами.
Большое спасибо, приятно слышать подобные отзывы. Если будет интерес аудитории, то в будущем можем сделать ещё парочку подобных постов. Занимательных интерфейсных задач у нас хватает)
Для русского паспорта применяется следующая таблица отображение русских букв в цифры и английские буквы:
А Б В Г Д Е Ё Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
A B V G D E 2 J Z I Q K L M N O P R S T U F H C 3 4 W X Y 9 6 7 8
Таким образом, тройка как раз соответствует букве 'Ч' (об этом отдельно написано в посте), а предлагаемая вами четвёрка соответствует букве 'Ш'. Сверка основных данных с машинными присутствует, но в данном случае всё совпадает. Если бы данные разнились, то в результатах распознавания вам бы предложили два варианта (скорее всего, МЧЗ был бы выбран по умолчанию).
Ну, неудобные вещи-то не очень сложно найти. Сложнее придумать как же всё-таки сделать удобно. А для этого нужно много знать и уметь) Я считаю, что изучение подхода к интерфейсам в различных программных продуктах должно развивать эти навыки.
Согласен с вашей мыслью, со словом «рефакторинг» действительно часто происходит подмена понятий. В статье я имел ввиду улучшение кодовой базы без видимого добавления нового функционала. Это вовсе не означает, что мы должны немедленно воткнуть в нашу архитектуру 600 паттернов проектирования, один лучше другого. Понятно, что к любой переработке кода нужно подходить разумно и без фанатизма, имея на то особый резон. И должны это делать люди, которые понимают, что они делают.
Критерии совершенного кода — тема отдельная и очень сложная. По этому поводу можно несколько отдельных постов накатать, т.к. с формализмом тут всё очень сложно. Но можно начать отталкиваться от классической литературы, например: Совершенный код Чистый код Читаемый код
А неформальные критерии стандартные: легкость чтения, гибкость, простота внесения изменений и поддержки и т.п. Но тут много субъективизма, так что по каждому пункту можно много рассуждать и холиварить, ведь у каждого свой подход. Например, Кент Бек с Мартином Фаулером любят говорить про плохие запахи кода как критерий.
Мои 15 давно прошли. Позвольте встречный вопрос, вам плохой код нравится? Вам не хочется исправить ситуацию, если вы видите плохую архитектуру? Считаете ли вы, что все взрослые программисты должны позитивно относится к подобным вещам?
А почему в соседнем классе бардак? Учитель не справляется? Пробовали обращаться к директору школы?
Рад слышать от вас конструктивные предложения. A/B тестирование собираемся проводить, когда пользователей будет немного больше.
Ваш голос мы учтём, но впредь хотелось бы попросить вас быть менее категоричным. Бросать фразами вида «Элементарно хреновый интерфейс» или «если же по вашему делать то все выйдет в разы дольше» в программу, которой вы никогда не пользовались, как-то не очень вежливо. Или говорить «никаких аргументов за привести за обратный порядок», когда я только что привёл аргументацию (которую вы благополучно проигнорировали). Или настаивать, что в нашем варианте на сверку уходит слишком много времени, заявляя что при «правильном порядке полей» у вас ушло бы 10 секунд (в то время, как я трачу 3–4 секунды на паспорт).
Я на вас не обижаюсь, просто мне хочется донести до вас мысль, что у нас был резон сделать всё именно так. Мы тестировали программу на пользователях, мы опрашивали целевую аудиторию и мы сделали всё именно так из-за того, что у нас были причины. Порядок полей в российском паспорте (который не оказывает никакого влияния на процесс проверки) был принесён в жертву ради того, чтобы во всех документах был единообразный порядок полей.
Могу засвидетельствовать, что мне не нужно в разы больше времени на проверку, чем вам. Мне даже не нужны 10 секунд, я проверяю правильность распознавания намного быстрее. Также мне ни раз доводилось видеть реальных операторов за нашей программой: всё должно быть очень плохо, чтобы кто-то потратил 10 секунд на проверку результатов. На оригинальную картинку смотреть нет никакой необходимости, это слишком долго.
Но если вы захотите купить PassportVision, то специально для вас мы можем выставить тот порядок полей, который вас устроит. Если очень надо, то можем даже серию и номер паспорта повернуть под 90 градусов, чтобы совсем было как в паспорте.
Но если так уж сильно коробит, то можно поправить в настройках, последнее слово всё равно за пользователем.
Таким образом, тройка как раз соответствует букве 'Ч' (об этом отдельно написано в посте), а предлагаемая вами четвёрка соответствует букве 'Ш'. Сверка основных данных с машинными присутствует, но в данном случае всё совпадает. Если бы данные разнились, то в результатах распознавания вам бы предложили два варианта (скорее всего, МЧЗ был бы выбран по умолчанию).
Очень хорошее правило. Если бы все в своих бизнес-планах закладывали время на улучшение кодовой базы, то мир бы стал чуточку лучше.
Совершенный код
Чистый код
Читаемый код
А неформальные критерии стандартные: легкость чтения, гибкость, простота внесения изменений и поддержки и т.п. Но тут много субъективизма, так что по каждому пункту можно много рассуждать и холиварить, ведь у каждого свой подход. Например, Кент Бек с Мартином Фаулером любят говорить про плохие запахи кода как критерий.
Мои 15 давно прошли. Позвольте встречный вопрос, вам плохой код нравится? Вам не хочется исправить ситуацию, если вы видите плохую архитектуру? Считаете ли вы, что все взрослые программисты должны позитивно относится к подобным вещам?
Не оценил вашего тонкого юмора, извините.