Звучит как обида на дизайнеров. Естественно меня волнует то как будут работать фронты. И описанный мной компонент был сделан совместно с фронтами. Именно для того чтоб фронты не делали каждый раз одну и ту же работу, а тестировщики и дизайнеры не проверяли одну и ту же работу. Что сильно упрощает и ускоряет процесс разработки. Да и на проектах мы его используем без проблем будь в нем форма, таблица или еще что-то. Если у вас возникают с этим трудности, ну я хз, может стоит пересмотреть подход к работе, сделайте один раз компонет чтоб потом его переиспользовать, я хз чем вам помочь.
Сколько это займет часов действительно неважно, есть только финансовая целесообразность той или иной фичи. Если так будет лучше для пользователя и если клиент готов платить за эти человеко-часы то почему бы и нет. Но в любом случае мы этот компонент и делали для того чтоб его использование на проекте не занимало эти самые часы.
"Не делать все что сложно сделать" как по мне заведомо проигрышный подход.
Когда мы задаем какой-то вопрос пользователю (сколько вам лет?) и от него требуется ввод информации или выбор действия, то это уже диалоговое окно а не модальное.
По реализации тут может быть несколько вариантов: 1) Окно ввода возраста появляется при входе на сайт. Такое окно я бы не делал диалоговым, а делал отдельной страницей. Так диалоговое окно не будет воспринято как спам, плюс нельзя будет через devtool скрыть элемент диалогового окна и получить доступ к сайту который мы не хотим предоставлять пока не получим возраст.
2) Если мы запрашиваем возраст в процессе использования сайта то это должно происходить по действию пользователя. Например он жмет на кнопку "смотреть фильм" и прежде чем начать проигрывание мы у него запрашиваем его возраст. В таком случае должна быть возможность закрыть диалоговое окно, так как пользователь может передумать и не захочет вводить свой возраст.
3) Ситуация когда пользователь уже пользуется сайтом и диалоговое окно появляется само по себе без действия со стороны пользователя (например через 5 минут после входа), это плохая практика. Так как диалоговое окно появляется внезапно и прерывает работу пользователя тогда когда он этого не ожидает. Опять же такое окно будет воспринимается как спам, из серии "введи номер телефона и получи скидку 10%". А во вторых даже если мы спрашиваем его возраст таким образом то у пользователя должна быть возможность закрыть диалог, иначе если он не захочет вводить возраст то ему останется только покинуть сайт. Но мне сложно представить кейс когда такое необходимо. Скорее всего даже если и сделать так то это будет неэффективно и будет способствовать уходу посетителей.
Отступы кратны 4 пикселям, так как это хорошая практика. 0, 8, и 16 потому что на мой взгляд это самые подходящие отступы в данном месте.
Кратность в 80 пикселей обусловленная тем что это удобное значение для гибкого выбора размера, при этом разница между размерами 480 и 560 все еще заметна. Плюс так удобней считать в уме когда уже привык использовать 8px grid system.
В целом это чисто вкусовщина, мои значения это как база, которую можно взять и уже работать с ней. Если вы в своем ките используете другие значения и вам так будет удобней то почему бы и нет.
Насколько я помню основная причина была в том что на фронте не получалось нормально сделать stiky элементы с таким расположением скроллбара. А с точки зрения дизайна удобнее попадать в скрол когда он находится у самого края экрана, так как край экрана ограничивает курсор.
Давайте в следующем году номинацию по дизайну:) ПЖ
То что вы пишите про вибрацию ее настройки и тд это актуально только для ios или на андройд можно сделать так же?
Звучит как обида на дизайнеров.
Естественно меня волнует то как будут работать фронты. И описанный мной компонент был сделан совместно с фронтами. Именно для того чтоб фронты не делали каждый раз одну и ту же работу, а тестировщики и дизайнеры не проверяли одну и ту же работу. Что сильно упрощает и ускоряет процесс разработки.
Да и на проектах мы его используем без проблем будь в нем форма, таблица или еще что-то.
Если у вас возникают с этим трудности, ну я хз, может стоит пересмотреть подход к работе, сделайте один раз компонет чтоб потом его переиспользовать, я хз чем вам помочь.
Сколько это займет часов действительно неважно, есть только финансовая целесообразность той или иной фичи. Если так будет лучше для пользователя и если клиент готов платить за эти человеко-часы то почему бы и нет.
Но в любом случае мы этот компонент и делали для того чтоб его использование на проекте не занимало эти самые часы.
"Не делать все что сложно сделать" как по мне заведомо проигрышный подход.
Нужно понимать в каком контексте это происходит.
Когда мы задаем какой-то вопрос пользователю (сколько вам лет?) и от него требуется ввод информации или выбор действия, то это уже диалоговое окно а не модальное.
По реализации тут может быть несколько вариантов:
1) Окно ввода возраста появляется при входе на сайт. Такое окно я бы не делал диалоговым, а делал отдельной страницей. Так диалоговое окно не будет воспринято как спам, плюс нельзя будет через devtool скрыть элемент диалогового окна и получить доступ к сайту который мы не хотим предоставлять пока не получим возраст.
2) Если мы запрашиваем возраст в процессе использования сайта то это должно происходить по действию пользователя. Например он жмет на кнопку "смотреть фильм" и прежде чем начать проигрывание мы у него запрашиваем его возраст. В таком случае должна быть возможность закрыть диалоговое окно, так как пользователь может передумать и не захочет вводить свой возраст.
3) Ситуация когда пользователь уже пользуется сайтом и диалоговое окно появляется само по себе без действия со стороны пользователя (например через 5 минут после входа), это плохая практика. Так как диалоговое окно появляется внезапно и прерывает работу пользователя тогда когда он этого не ожидает.
Опять же такое окно будет воспринимается как спам, из серии "введи номер телефона и получи скидку 10%". А во вторых даже если мы спрашиваем его возраст таким образом то у пользователя должна быть возможность закрыть диалог, иначе если он не захочет вводить возраст то ему останется только покинуть сайт.
Но мне сложно представить кейс когда такое необходимо. Скорее всего даже если и сделать так то это будет неэффективно и будет способствовать уходу посетителей.
Отступы кратны 4 пикселям, так как это хорошая практика. 0, 8, и 16 потому что на мой взгляд это самые подходящие отступы в данном месте.
Кратность в 80 пикселей обусловленная тем что это удобное значение для гибкого выбора размера, при этом разница между размерами 480 и 560 все еще заметна. Плюс так удобней считать в уме когда уже привык использовать 8px grid system.
В целом это чисто вкусовщина, мои значения это как база, которую можно взять и уже работать с ней. Если вы в своем ките используете другие значения и вам так будет удобней то почему бы и нет.
Спасибо, добавил нумерацию.
Насколько я помню основная причина была в том что на фронте не получалось нормально сделать stiky элементы с таким расположением скроллбара.
А с точки зрения дизайна удобнее попадать в скрол когда он находится у самого края экрана, так как край экрана ограничивает курсор.