Как стать автором
Обновить

Комментарии 27

удельный объём смартфонов в общем трафике (52%) делает целесообразным создание PWA отдельно для этой платформы с учётом её особенностей (размеры дисплея, устройства ввода, offline, …), вместо того, чтобы делать гибриды (адаптивный дизайн и т.п.).

плюнуть на 48% ради 52% — это так целесообразно

В процитированном Вами отрывке русским по фоновому написано: "делает целесообразным создание PWA отдельно для этой платформы с учётом её особенностей".

, что означает "сделай две версии PWA: для десктопа и для мобилы".

Когда ж читать научитесь, а?

именно это я и имел в виду:

делает целесообразным создание PWA отдельно для этой платформы с учётом её особенностей ..., вместо того, чтобы делать гибриды ...

52% это довольно много. Как и 48%. Есть смысл делать отдельно "самолёт" и отдельно "подводную лодку". Но вы можете пытаться сделать "летающую подлодку" или "ныряющий самолёт". Как я написал ниже - в обеих средах 3 степени свободы.

Я понимаю, что продавать отдельно мобильную и десктопную версии веб приложения выгодно.


Но в 2021 году пугать сложностями адаптивной вёрстки, кроссбраузерности итп, пожалуй, не стоит. "Ныряющие самолёты" получаются не из-за этого.


Адаптивный веб — это стандарт и норма, а отдельные мобильная/десктопная версии — исключение, объективная потребность в котором может возникнуть только в каких-то очень редких, сложных случаях. Типовое веб-формошлёпство (без всякого уничижительного оттенка, просто как есть) к этой категории не относится.

Типовая задача для web-приложений - табличное представление данных. Вот так это делает SmartClient:

Если "адаптивный веб — это стандарт и норма", то как выглядит аналогичная структура в стандартах адаптивного дизайна?

Подобное представление данных в каждой второй админке, если не в каждой первой (список пользователей, например).

каждая строчка таблицы силой flexbox'а превращается в "карточку", и в общем списке разворачивается в столбик. излишне длинные строки обрезаются с "...". наименее важные поля (1) скрываются на мелких экранах силой media-queries. по клику на каждый элемент списка можно перейти на отдельный экран/модальное окно с просмотром/редактированием


если хочется сделать хорошо пользователю — в прилипишем меню (header/footer) реализуется возможность выбрать нужные поля для отображения (чтобы не причинять пользователю боль своим выбором важных полей (1) ) и сохранять как пресеты, поиск, фильтры, и прочие удобные вещи.


ей богу, вы ни разу торговых представителей/кладовщиков с планшетами не видели?

А можете ссылку на типовую реализацию дать? А то, как "нарисовать сову" я тоже могу рассказать.

Ссылка на грид от Smart Client'а.

недоумеваю от вопроса.
типовую реализацию того, как строка таблицы превращается в карточку?
вы точно разработчик приложений для мобильных устройств?


вам правда нужно показывать скрины админки какого-нибудь вордпресса?
https://disk.yandex.ru/d/0scKrcjJ8Fb3VA


и показывать то как это делает smart client
https://ibb.co/F38mRjS


?

типовую реализацию того, как строка таблицы превращается в карточку?

А что, нет такой реализации?

Для десктопов грид-компонентов довольно много. Но у них у всех есть одна неприятная особенность - они не адаптивные. На больших экранах выглядят приятно, а на мобильных разрешениях "строки таблицы" ни в какую не хотят "превращаться в карточки".

Я бы взял какую типовую реализацию, воткнул в неё десяток-другой столбцов с разнородной информацией, с фильтрацией и сортировкой. А потом посмотрел, как оно адаптируется к различным размерам экрана и насколько user friendly остаётся при этом. А может вы можете ссылки на готовые showcase'ы дать? Так это ещё лучше будет.

Я просто не в курсе этой темы - "Стандарты и нормы адаптивного веба в 2021-м году". Так-то 4 столбца в карточку свернуть - не велика проблема. Особенно без фильтрации и сортировки.

Для десктопов грид-компонентов довольно много. Но у них у всех есть одна неприятная особенность — они не адаптивные. На больших экранах выглядят приятно, а на мобильных разрешениях "строки таблицы" ни в какую не хотят "превращаться в карточки"

они и не пытаются: они пытаются вместить таблицу в маленький экран ("впихнуть невпихуемое"), это решение другой проблемы.
невозможно удобно показать таблицу на маленьком экране, это не подходящий формат. впихнуть как-нибудь — можно, удобно показать — нельзя.


показать данные, и частично сохранить табличную функциональность (сортировка/фильтры итп) на маленьких экранах можно с помощью карточек и менюшки с кнопками. но для этого нужно отказаться от таблицы как формата.


Так-то 4 столбца в карточку свернуть — не велика проблема

в том то и дело. хоть 4 хоть 24 — принцип не меняется.

хоть 4 хоть 24 — принцип не меняется.

Принцип не меняется, меняется usability - возможность быстро "загрузить" в мозг некоторую совокупность данных. Именно поэтому таблица - это таблица, а не карточка и менюшка с кнопками. Именно поэтому вы не можете дать ссылку на типовой компонент для адаптивного представления табличных данных. Это просто нельзя сделать удобно на экране смартфона. Сделать в принципе - можно, сделать так, чтобы было удобно и на десктопе, и на смартфоне - нет.

И это мы ещё не трогали средства управления (мышь или touch), специализированный API (геопозиционирование, например) и работы в offline-режиме. Понятно, что адаптивный дизайн - не самая большая проблема на этом фоне. Но, если вам, в силу специфики каждой из сред, всё равно надо делать два различных приложения, то нужно дважды подумать, стоит ли их связывать посредством адаптивного дизайна или для каждого запилить свой, учитывающий особенности конкретной среды.

Разумеется, у вас другой опыт, чем у меня. И ваш опыт может говорить, что табличное представление данных a-la Smart Client встречается "только в каких-то очень редких, сложных случаях". Ну, считайте тогда, что этот мой совет касается очень редких и сложных случаев. Таких, для которых делали типовые десктопные грид-компоненты.

табличное представление данных a-la Smart Client встречается "только в каких-то очень редких, сложных случаях"

вот такое? да сплошь и рядом! :)
только не от редкости и сложности, а от криворукости и непрофессионализма.


здесь нет ни редкости кейса, ни представления данных, ни usability. зато есть select с выбором скина на 1/3 экрана.


яркий пример "летающей подлодки" или "ныряющего самолёта"


image

Вы же сейчас мне скините ссылку на типовой адаптивный компонент для представления табличных данных, не так ли? Наиболее "пряморукий и профессиональный" с вашей точки зрения. Или скажете, что каждый подобный случай уникален и его нужно рассматривать непосредственно в контексте задачи?

Я вам, между прочим, дал ссылку на страницу, где идёт сравнение 6 таких компонентов. Правда не адаптивных, а "заточенных" под десктоп. Т.е., ваш "яркий пример" - это не "ныряющий самолёт", а "самолёт под водой". Вы вытащили чисто десктопный компонент на смартфон и удивляетесь, что он "криворук и непрофессионален"? Он просто создан для другой среды. Знаете, обвинять в непрофессионализме разрабов Smart Client'а - это очень оригинально! Они в бизнесе с 2001 года, если что.

Мне кажется, я уже сделал даже больше того, что нужно, чтобы продемонстрировать, что я имел в виду под "делает целесообразным создание PWA отдельно для этой платформы с учётом её особенностей ..., вместо того, чтобы делать гибриды ...". Если у вас другая точка зрения .. ну делайте гибриды тогда. Кто ж вам запретит.

Ну, как бы и в воде, и в воздухе есть три степени свободы и можно предположить, что есть существа, которые неплохо (не хорошо, но хотя бы неплохо) чувствуют себя и в воде, и в воздухе. Но вот так, навскидку, я вспомнил только пингвинов и летучих рыб. Слишком уж разные среды. Приходится выбирать. Я лишь о том, что каждая из этих сред достаточно большая, чтобы быть интересной для специализации. Но вы можете попробовать усидеть на обоих стульях.

Можно ещё человека привести в пример: может плавать, может бегать, может по деревьям лазить. Но все это делает очень плохо: плохо плавает, медленно бегает, плохо по деревьям карабкается.

НЛО прилетело и опубликовало эту надпись здесь

А когда-то я ими пользовался...

Увы, "эффективные менеджеры" делают своё дело.

Потому как сайты проверяют только с Chrome, а другие идут лесом. Ну и Chrome сегодня работает ощутимо быстрее.

Если применить “принцип Парето” к разработке PWA, то есть только два браузера — Chrome и Safari, на остальные можно не заморачиваться.

Вот только Safari крайне ограниченно поддерживает PWA, ни пушей, ни фоновой синхронизации, ограничение на размер, отсутствие многих api, по факту чего-то кроме создания отдельной иконки от него добиться сложно. Service Workers с кешем вроде как поддерживается, но надо ли оно без всего остального, есть ли примеры полезных PWA работающих на яблочных устройствах?

есть ли примеры полезных PWA работающих на яблочных устройствах?

есть ли пример вприницпе полезных PWA?..)

Я полез в статистику по браузерам, когда столкнулся с ситуацией, что es6 import не работает для service worker'ов в браузере FireFox. В Chrome работает, а для FireFox предлагается подход с importScripts(). В Safari importзаработали с лета этого года. Понятно, что Google (со своим Chrome'ом) - "тягач" этой технологии, и что остальные будут в роли догоняющих в той или иной степени. Меня прежде всего интересовало то, насколько велик кусок "откушенный" Chrome'ом в среде мобильных браузеров и на кого ещё стоит ориентироваться при разработке PWA. Вывод - на Safari всё ещё приходится ориентироваться, но на FF можно уже не смотреть. Да, в Safari нет пушей и фоновой синхронизации, зато у Google'а есть Chrome под iOS. И тут уже два варианта - либо Safari догонит Chrome по функционалу, либо Chrome вытеснит Safari. Это, конечно, при условии, что PWA станут широко популярными.

есть ли примеры полезных PWA работающих на яблочных устройствах?

Starbucks говорят, что они что-то полезное сделали:

Так какой же вариант более вероятен? Господин Автор заманил и бросил.

Эппл продаёт на каждый комп по два iPad и восемь iPhone, при перевесе 10 к 1 статкаунтер насчитал разницу вдвое. Как минимум данным о планшетах верить точно нельзя.

Я как-то интуитивно постигаю, что Гугол со своей рекламой на что угодно пойдёт лишь бы хоть одним глазком подсмотреть что там делают в приложениях, а в нормальные ему путь заказан. Поэтому за PWA будет биться до последнего.

Кто-нибудь может объяснить как на PWA заработать помимо продажи услуг сервера? Например, написал я лучший в мире калькулятор, и дальше что? А если продавать услуги сервера, то как PWA мне объяснит состояние, скажем, моего заказа еды который я начал делать ещё до обрыва связи?

Как PWA выглядят среди прочих приложений в разделе расхода хранилища и батареи? А то пока мне PWA не очень интересны, а как начнут становиться интересны, так первым делом в плане блокировщика таковых…

Я начинал писать свои первые web-приложения на LotusScript в среде Lotus Domino и на возможности, предоставляемые PWA, я смотрю с точки зрения разработчика. И как человек, создававший web-приложения в Lotus Domino, могу сказать, что я в восторге от этих возможностей. Пригодятся ли технологии PWA именно вам? Не исключаю такой возможности, раз уж вы оставили свой коммент под этой публикацией.

А на ваши вопросы у меня ответов нет. Это вопросы бизнесмена, а я - технарь. Не моя специализация.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории