Это уже не важно. Хотя статья действительно не несет чего-то особенного и имеет много ляпов.
Но, интересно то, что не смотря на стадо минусующих, есть сознательные люди, которые со мной согласны.
Не получилось у меня progress bar увидеть в последнем демо:
Chrome 24, файл .jpeg ~2Мб
По поводу критики… Удалять файл кликом по миниатюре как минимум не правильно. По клику миниатюра должна увеличиваться, тем более у вас нет названия загруженного файла рядом.
Нравится реализация прикрепляемых файлов в мегаплане, хоть и не хватает там сортировки.
UPD: Не сохраняется текст в поле «Сообщение» в примере отправки данных ajax-ом.
Спасибо за замечания. По поводу удаления файлов, это ведь голая демонстрация. Разумеется на проектах этот момент нужно улучшить. Информации в FileReader хватает, чтобы сделать всё красиво.
И, конечно, хорошо валидировать e-mail еще до отправки сообщения, выдавая, в случае необходимости, уникальное сообщение об ошибке: например «Поле заполнено некорректно», а не «Заполните электронную почту».
Ну и хорошим тоном считается объяснять пользователю для чего какие введенные данные будут использованы: «Для уточнения заказа», «Мы вышлем Вам подтверждения заказа на почту» и т.д.
И снова UPD: все это написано с позиции дизайнера и вряд ли нужно технарям и в этой статье)
В итоге у вас фраза «напишите свое имя» большим шрифтом написана, чем само имя. Ну круто, пусть пользователь заодно тренируется в меткости попадания пальцем в нужную область.
Чтобы избавится от дублирования надо просто сделать гибкий механизм валидации. Не писать хардкод валидации, а просто хранить мета-информацию для полей о том как их валидировать. И написать генератор валидации для яваскрипта и сервер-сайд языка. Затраты на такую систему окупятся в будущем с лихвой.
Для всех новых форм вы просто будете указывать тип полей, маску ввода и тд.
Насчет валидации браузером. В вашем примере прошло валидацию (Opera 12):
name 1651
email 1@2.3
message " " (пробел)
Скажите, это соответствует стандарту? Если да, то это стандарт не для реальной жизни. А значит по-любому тащить «многокилобайтные библиотеки» во все браузеры и т.д.
А в чем проблема-то? Пробел — обычный символ, а атрибут «required» требует наличия символа. По остальному все тоже вполне логично. Если нужно что-то более изащренное, то есть атрибут «pattern», а далее уже в сторону JS смотреть нужно.
Самое интересное, что он соответствует стандарту.
Второе 123 считается айпишником (0.0.0.123), из «домашней» подсети для исходящих сокетов. Ну то есть конечно криво и всё такое, но формально — валидно.
>Решить эту проблему можно по-разному, например, записывать данные в localStorage по мере ввода.
Спорное решение, на мой взгляд. Как оно будет взаимодействовать с аналогичной функциональностью самого браузера (настройка сохранять/не сохранять данные форм)? Какой UX а результате получит пользователь? :)
>После успешной отправки формы я советую оставить контактную информацию в localStorage, а остальное очистить.
Те же самые соображения. Обычно сохранение данных форм отключают как раз для того, чтобы не оставлять в них личную информацию.
Да, это проблема, особенно если сервис используется с «общего» компьютера.
Я бы делал такое только, если пользователь залогинен в системе, да и то, разделял бы локалсторедж по имени пользователя.
Мне кажется, что необходимо уменьшать количество взаимодействия с формами, а то что осталось, подавать под другим соусом. Почему яндекс.карты не прося вас вводить улицу и номер дома в разные окошки? Зачем пользователю нужна кнопка отправить? Он уже отправил картинку на ваш сайт кинув её в окошко браузера. Он уже оставил способ связи с собой когда дал вам свой профиль в фйсбуке.
Это одна крайность. Есть другая крайность.
Когда ваш интерфейс должен восприниматься не как игрушка, а как инструмент. И тогда вы берёте опыт использования Екселя, или ещё чего-то. Но ваша форма по прежнему не должна быть формой.
Изящно :) Особенно запись заполнения по мере ввода.
Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.
Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
Как по мне драг-н-дроп файлов даже не преждевременно а вообще не нужно по большому счету. Нас молодых которые такое могут делать не так и много, а люди взрослые вообще в страницы глядят и у них оторопь что делать, и когда что-то по новому им прям страшно становится. Все таки правильно что все должно оставаться привычным. А что если случайно на страницу уронишь не тот файл, или файл который вообще не планировал грузить и он куда то там загрузится, что-то не очень хочется. Да и при развернутом на весь экран браузере лезть куда-то в менеджер файлов чтоб тянуть как то не практично возможно.
Ну просто опишите взаимодействие, вот у тебя открыт на весь экран браузер, ты получается нужно или программу немного свернуть, или поверх завешивать менеджер. Я не против, но удобно ли это. Так часто мы цепляем файлы в формы.
Конечно как опция то все удобно, кто-то да освоит любые трюки :-)
>>element.onkeyup
и… при вставке мышкой текста из буффера обмена он не сохраняется. И даже onmousedown не приходит.
Единственно надёжный вариант — по таймеру раз несколько в секунд делать сериализацию всей формы и сравнивать с последним сохранённым сериализованным значением.
Ну и во имя скорости нужно сохранять именно сериализованную форму, а не поля по отдельности.
filereader конечно хорош и все о нем пишут, только реально его использовать можно будет когда в требованиях будет ie10+ т.е. в светлом будущем учитывая что сейчас еще пишут ie7+.
предосмотр слишком большая фича чтобы деградировать всех отставших
Улучшаем опыт взаимодействия с формами