UX-designer, Analyst, QA-engineer
Information
- Rating
- 5,425-th
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Registered
- Activity
Specialization
UI/UX Designer, Systems Analyst
Python
SQL
Database
UI/UX design
Design testing
API Testing
Manual testing
Analytics of requirements
Не поймите меня неправильно. Но, вероятно, это происходит не просто так. А потому что качество и информативность подобного рода "личных трудов" находятся как раз где-то на уровне генерилок текста.
Извините, если вас это каким-то образом расстраивает. Просто на сегодня всякие GPT справляются с задачей написания простых статеек довольно неплохо.
Простите, не удержался :)
Hidden text
Согласен. Попытка найти технические решение нетехнической проблемы.
Так то да. Начинание интересное, но сейчас это больше сувенир и приколюха, чем полезный документ.
Пардон, но это как раз-таки UX-проблема в чистом виде. И это UX-проблема в целом функции "отмены". У нее даже название есть - модальность (мультирежимность, если по-русски).
Если быть совсем точным, то это проблема в области usability и проектирования взаимодействия при проектировании GUI.
Насколько я понимаю, это происходит при компиляции, а не при выполнении.
В целом, мне кажется, что вместо запиливания своих DE- или библиотекоспецифичных языков, лучше было бы вложиться в биндинги к уже существующим, вроде Dart и Swift.
Например, тот же Swift неплох, но состояние дел с GUI-либами вне Apple весьма печально. А жаль.
Выглядит так, будто бы вы спорите со мной, приводя мне мои же аргументы :)
Это не так. Задача лендинга - рассказать про продукт и продать его. И не важно, насколько лендос привлекает внимание и/или запоминается. Его задача - продать.
И обратите внимание, что именно лендинги как раз-таки максимально стандартизированы. Куда бы вы ни пришли, среднестатистический лендос будет имень очень даже предсказуемую структуру, как на картинке ниже:
Hidden text
Заменяем "приложение" на "сайт". Полностью с вами согласен. Сайтам (особенно, если речь не про лендосы и простенькие статические портфолио) тоже не повредила бы некоторая стандартизация :)
Дополню свой предущий комментарий.
Человек "нанимает" ваше приложение, чтобы решить какую-то свою проблему. Ваше приложение для человека - это инвестиция. Оно должно сэкономить время, деньги, какой-то другой ресурс или каким-то иным образом сделать жизнь лучше.
С точки зрения пользователя, у вашего приложения должно быть ROI, то есть отношение пользы к затратам на освоение и использование. Каждый человек стремится этот ROI максимизировать.
Как максимизировать этот показатель? Правильно: увеличить количество наносимой пользы и сократить затраты (издержки) на освоение. Первое делается с помощью грамотного управления продуктом. Например, решать реальную проблему реального человека, решать ее быстро и хорошо. Второе - с помощью стандартизации интерфейса и удаления из приложения функций, не имеющих отношения к решаемой проблеме.
Сайт, по-простому говоря, это документ внутри приложения-браузера. Веб-приложение - это интерактивный документ внутри приложения-браузера.
Традиционно люди не ждут от документов какого-то единообразного внешнего вида и поведения. Если же посмотреть внимательнее, то на уровне больших и средних организаций, даже на оформление и структуру документов есть стандарты.
Основная идея здесь заключается в том, чтобы поместить человека в знакомую заранее изученную на других примерах среду: внешний вид, структура и основные механики взаимодействия с интерфейсом. Это очень сильно экономит время и "мыслетопливо", так как человеку нужно понять только предметную область и не нужно тратить время на изучение уникальных интерфейсных изобретений авторов приложения.
А тот факт, что кому-то иногда удается с помощью нехитрых приспособлений превратить буханку белого (или черного) хлеба в троллейбус, не говорит о том, что теперь всем нужно поступать так же.
Возможно, мы друг друга не очень поняли. Потому что чисто внешне (по оформлению), это очень сильно отличается и от Mac, и от двух основных DE Linux.
Да, видно, что структура UI и некоторые механики взаимодействия похожи. Однако, "похоже" не означает "нужно заменить на средний".
Поправьте, если я что-то не так понял. Но насколько я знаю, дело не в V8.
V8 - это, грубо говоря, интерпретатор JS. Он быстрый. Даже очень.
Дело в DOM. DOM - фундаментально медленный. Стилизация DOM требует CSS, который тоже фундаментально медленный. И всё это великолепие требует наличия в роли GUI-библиотеки целого браузера, который тоже отнюдь не легковесный ибо тащит в себе огромное количество разных (порой вообще не нужных вашему приложению) штук.
Да. И это вовсе не означает, что все переходы (всмысле, любая анимация) точно имеют логичную природу. По моему опыту, анимацию пихают где надо и где не надо просто потому что можно. А главный агрумент - "чтобы было нескучно". И вот это уже клиника.
Внезапно, у каждой крупной ОС есть User Interface Guidelines. Внезапно же, у каждой крупной ОС есть GUI фреймворк/либа, основные контролы в которых уже реализованы с учетом этих гайдлайнов. Это и есть стандарт.
Очевидно, что гайды не покрывают всех хитровыделанных случаев и степень следования им в нестандартных ситуациях - это вопрос дискуссионный. Однако, они хотя бы избавляют от необходимости в 100500-й раз рисовать и программировать yet another neskuchnaya button. А пользователям не приходится каждый раз заново разбираться, что это за фигня такая тут торчит.
Это такая же часть работы, как запиливание новых нескучных фич.
Я обожаю Joplin и мечтаю, чтобы он вышел в виде нативных приложений :)
Между вашими утверждениями отсутствует логическая связь.
Из того, что "системы прут друг у друга решения" никак не следует, что "эта идея не работает".
Как минимум визуально, интерфейсы Mac, Win и Linux-десктопов отличаются очень сильно. И любой "универсальный" UI не вписывается ни в одну из ОС. Я уже молчу про разного рода OS-specific прибамбасы вроде dock, statusbar и боковые виджеты на макоси, systray и меню "Пуск" в винде и зоопарк DE для Linux.
Я прикрепил первые попавшиеся под руку скрины настроек, которые нагуглил. Как минимум, визуально они отличаются очень сильно. Даже самый лучший "универсальный" UI везде будет смотреться чужеродно.
То есть, если по-простому: дешево нагомнокодить любые безумные фантазии очередного безумного "гения"
Это не так. Поясню почему.
У каждой платформы есть свои особенности поведения, традиции и нюансы. А также, свой аутентичный визуальный стиль. Например, нативный UI для Mac заметно отличается от такогово для Win и вместе они отличаются от тем gtk/qt/etc. для Linux.
Когда человек выбирает для себя систему, он, в том числе, выбирает и пользовательский опыт, характерный именно для данной системы. И, что важно, привыкает в нему.
С этой точки зрения, десктопное приложение обязано как раз-таки интегрироваться в ОС и вести себя органично. Потому что иначе нарушается принцип наименьшего удивления и людям это кажется неудобным.
Например, выбирая Linux, я выбираю не просто ОС, но и набор подходов к решению своих повседневных проблем. И мне очень не нравится, когда у меня в системе оказывается какое-то поделие, которое навязывает мне некое "среднее по больнице" поведение и вычурный ни на что не похожий UI. И ломает мне все мои привычки.
Я уже молчу о том, что на вебе (при всех его плюсах) практически невозможно написать хорошо работающее приложение. Такое, у которого не едет верстка, отсутствуют тормоза и лютый бешеный аппетит по части оперативки.
"А как же богические Slack и VSCode?" - спросите вы. А так, что из всего неимоверного зоопарка electron-приложений вот только эти два и работают более-менее прилично. Да и то, Slack у меня на рабочем Win-компе отжирал до полутора гигов оперативки. Как по мне, многовато для мессенджера.
Так что, когда нужен одинаковый интерефейс - нужно делать обычный сайт и не выпендриваться. Если нужен desktop, то уж делать надо по-человечески. Чтобы у людей потом глаз не дергался от гениальных универсальных юаев.
Для одного из своих пет-проектов, связанных с серфингом, пользуюсь OpenWeatherMap. Говорить о его точности пока не могу, но их API мне вполне понравился.
Извините за, вероятно, глупый вопрос. Вы используете docker чтобы сделать mkdocs build и mkdocs serve?