Здравствуйте, goto, Вы писали:

G>Ты мне приписываешь лишнее. Я ничего не оправдываю и не предлагаю, а лишь пытаюсь объяснить. Реализация всех эти гибких и удобных фич требует дополнительных усилий (деньги, сроки) и культуры разработки (которую не всегда купишь). При этом такие фичи исторически не являются стандартом, т.е. могут делаться в виде приятного дополнения, но по дефолту не ожидаются. Я здесь и далее говорю о приложениях десктопных и веб-, которые их имитируют.
Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.
При этом некоторые разработчики зачем-то вкладывают дорогостоящие усилия в эмуляцию тех "фич" десктопа, которые вообще не нужны.
G>Иногда такие фичи просто не нужны объективно. А в случае приложений с тяжелыми данными я не совсем представляю, как это могло бы работать хорошо. Например, для чего-то типа Фотошопа или 3д редактора создавать копию приложения, синхронизировать каждый чих между копиями может быть накладно по ресурсам/тормозам.
Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.
Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

G>Если бы "многокопийное" поведение было стандартом де факто для юзеровских приложений, то для каких-то их классов могли бы вылезти некоторые связанные с этим свои, новые ограничения, в конечном итоге сказывающиеся на возможностях для пользователя. Я это допускаю (органы на плаху не положу).
Не важно, стандарт это или нестандарт. Ограничения большинства известных нам приложений связаны не с какими-то естественными причинами, а в основном с историческими соображениями.
Тот же Excel прекрасно может показывать один и тот же спредшит параллельно в режиме split view. Но при этом открыть его второй раз в отдельном окне не получится — ни в рамках того же процесса, ни в отдельном процессе. Есть ли объективые причины для этого? Ну, просто тридцать лет назад были приняты определённые архитектурные решения, а сейчас этот продукт находится в maintenance mode, и в него добавляют только мелкие косметические изменения. Денег на сколь-нибудь существенную переработку движка нет примерно с 2003 года.
Почему я думаю, что нет фундаментальных причин не поддерживать "многокопийное" поведение? Да потому что google docs. Там с одним спредшитом прекрасно работает не только один человек через много окон, но и много людей одновременно.

G>По безопасности веб приложений могут открыться интересные горизонты и побочные эффекты со своими требованиями к коду, мозгам и ресурсам.
Нет никаких интересных горизонтов для безопасности веб приложений. Веб приложения всю жизнь умели работать в многих копиях. Чтобы это поведение сломать, нужно принимать специальные меры в разработке приложения.

G>Удобные фишки из веб вроде back/forward можно реализовывать другими средствами, без копий. В той же Майе можно гулять туда-сюда по view и по layout'ам экрана в рамках ее воркфлоу, никак не связанного с привычками из веб. Там в этом была необходимость изначально, и все давно было сделано.
Ну так и я о том же говорю — навигационный доступ нужен достаточно часто, и реализован даже на десктопе.
Невозможность открыть линку веб-приложения в другом окне тесно связана с навигацией: если линка не открывается в другом окне, то при клике в том же окне она не будет корректно отрабатывать кнопку back.
Ну, если быть совсем точным, то можно сделать такую линку, которая корректно воспроизводит back/forward, но при этом в отдельном табе или окне не открывается.
Но для этого нужны прямо отдельные сознательные усилия.

G>Ближе к топику. Если у пользователя одностраничного веб приложения возникает желание открыть копию в новом табе, и невозможность сделать это его бесит, то, весьма вероятно, это приложение просто плохо продумано. Вряд ли дело только в том, что кнопка внешне выглядит как линк.
Совершенно верно. Речь — именно о том, что приложение плохо продумано. Замена линки на кнопку всего лишь сделает этот факт более очевидным.

G>Юзабельные софты есть и будут, но в целом я пессимистичен. Тенденция не меняется. Кому необходимо или кто может — делает хорошие фичи, а в остальном и среднем просто решается некая задачка, как получится, как побыстрее. Последнее время вообще модно делать MVP (который может быть практически пустым сайтом без вменяемого продукта) и сразу как можно стремительней бежать искать инвестора.
Ну, концепция MVP ортогональна SPA Можно делать офигенно полезный и нужный продукт, интерфейс которого крайне требователен к пользователю, и любая ошибка в нём фатальна. А можно сделать полностью выглаженное приложение, с офигенно продуманными сценариями для операций второй и третьей степеней редкости, но при этом абсолютно бесполезное для потребителя

В принципе, наверное, современные подходы к приоритизации разработки отчасти виноваты в таких результатах.
В том смысле, что навязываются всякие scenario-based approach, когда менеджмент фокусируется на каких-то конкретных историях. С одной стороны, это позволяет избежать порождения софта в стиле "конструктор", когда пользователь вынужден сам собирать нужный ему сценарий по кусочкам из имеющихся "функций". Иногда с риском так и не собрать его до конца.
С другой стороны, feature-based approach позволяет продумывать поведение приложения и за пределами прописанных в сценарии путей.
Мой любимый пример — устаревший много лет назад API для Microsoft Online Syndication Interface, MOSI. Если бы его проектировали в терминах фич, то там было бы что-то вроде partner can manage the tenant subscriptions. Ок, есть тенант, у него есть подписки. Что такое "manage"? Create, List, Read, Update, Suspend, Resume, Cancel. Поехали, реализуем.
Увы, его проектировали в терминах "сценариев". (Я видел внутренний документ, на основе которого писался код). Сценарий "Партнёр перечисляет подписки тенанта" в список включён не был. В итоге, если клиент фейлился между тем, как он получил результат операции Create, и сохранил ID подписки в свою базу, то подписка тупо утекала. Не было никакого способа восстановить её ID.

С SPA происходит примерно так же — менеджер продукта описывает бизнес-сценарии. Ему не приходит в голову опускаться до универсальных деталей обстановки вроде "кнопки должны нажиматься", или "линки должны поддерживать навигацию вперёд-назад, сохранение в закладки и формирование шорткатов". В итоге девелоперы-нигилисты тупо выбрасывают эти аспекты поведения. В итоге получаем — тексты, которые нельзя скопировать по Ctrl-C, документы, которые невозможно напечатать, и ссылки, по которым можно пройти только один раз.

Здравствуйте, goto, Вы писали:

G>Ты мне приписываешь лишнее. Я ничего не оправдываю и не предлагаю, а лишь пытаюсь объяснить. Реализация всех эти гибких и удобных фич требует дополнительных усилий (деньги, сроки) и культуры разработки (которую не всегда купишь). При этом такие фичи исторически не являются стандартом, т.е. могут делаться в виде приятного дополнения, но по дефолту не ожидаются. Я здесь и далее говорю о приложениях десктопных и веб-, которые их имитируют.
Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.
При этом некоторые разработчики зачем-то вкладывают дорогостоящие усилия в эмуляцию тех "фич" десктопа, которые вообще не нужны.
G>Иногда такие фичи просто не нужны объективно. А в случае приложений с тяжелыми данными я не совсем представляю, как это могло бы работать хорошо. Например, для чего-то типа Фотошопа или 3д редактора создавать копию приложения, синхронизировать каждый чих между копиями может быть накладно по ресурсам/тормозам.
Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.
Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

G>Если бы "многокопийное" поведение было стандартом де факто для юзеровских приложений, то для каких-то их классов могли бы вылезти некоторые связанные с этим свои, новые ограничения, в конечном итоге сказывающиеся на возможностях для пользователя. Я это допускаю (органы на плаху не положу).
Не важно, стандарт это или нестандарт. Ограничения большинства известных нам приложений связаны не с какими-то естественными причинами, а в основном с историческими соображениями.
Тот же Excel прекрасно может показывать один и тот же спредшит параллельно в режиме split view. Но при этом открыть его второй раз в отдельном окне не получится — ни в рамках того же процесса, ни в отдельном процессе. Есть ли объективые причины для этого? Ну, просто тридцать лет назад были приняты определённые архитектурные решения, а сейчас этот продукт находится в maintenance mode, и в него добавляют только мелкие косметические изменения. Денег на сколь-нибудь существенную переработку движка нет примерно с 2003 года.
Почему я думаю, что нет фундаментальных причин не поддерживать "многокопийное" поведение? Да потому что google docs. Там с одним спредшитом прекрасно работает не только один человек через много окон, но и много людей одновременно.

G>По безопасности веб приложений могут открыться интересные горизонты и побочные эффекты со своими требованиями к коду, мозгам и ресурсам.
Нет никаких интересных горизонтов для безопасности веб приложений. Веб приложения всю жизнь умели работать в многих копиях. Чтобы это поведение сломать, нужно принимать специальные меры в разработке приложения.

G>Удобные фишки из веб вроде back/forward можно реализовывать другими средствами, без копий. В той же Майе можно гулять туда-сюда по view и по layout'ам экрана в рамках ее воркфлоу, никак не связанного с привычками из веб. Там в этом была необходимость изначально, и все давно было сделано.
Ну так и я о том же говорю — навигационный доступ нужен достаточно часто, и реализован даже на десктопе.
Невозможность открыть линку веб-приложения в другом окне тесно связана с навигацией: если линка не открывается в другом окне, то при клике в том же окне она не будет корректно отрабатывать кнопку back.
Ну, если быть совсем точным, то можно сделать такую линку, которая корректно воспроизводит back/forward, но при этом в отдельном табе или окне не открывается.
Но для этого нужны прямо отдельные сознательные усилия.

G>Ближе к топику. Если у пользователя одностраничного веб приложения возникает желание открыть копию в новом табе, и невозможность сделать это его бесит, то, весьма вероятно, это приложение просто плохо продумано. Вряд ли дело только в том, что кнопка внешне выглядит как линк.
Совершенно верно. Речь — именно о том, что приложение плохо продумано. Замена линки на кнопку всего лишь сделает этот факт менее очевидным.

G>Юзабельные софты есть и будут, но в целом я пессимистичен. Тенденция не меняется. Кому необходимо или кто может — делает хорошие фичи, а в остальном и среднем просто решается некая задачка, как получится, как побыстрее. Последнее время вообще модно делать MVP (который может быть практически пустым сайтом без вменяемого продукта) и сразу как можно стремительней бежать искать инвестора.
Ну, концепция MVP ортогональна SPA Можно делать офигенно полезный и нужный продукт, интерфейс которого крайне требователен к пользователю, и любая ошибка в нём фатальна. А можно сделать полностью выглаженное приложение, с офигенно продуманными сценариями для операций второй и третьей степеней редкости, но при этом абсолютно бесполезное для потребителя

В принципе, наверное, современные подходы к приоритизации разработки отчасти виноваты в таких результатах.
В том смысле, что навязываются всякие scenario-based approach, когда менеджмент фокусируется на каких-то конкретных историях. С одной стороны, это позволяет избежать порождения софта в стиле "конструктор", когда пользователь вынужден сам собирать нужный ему сценарий по кусочкам из имеющихся "функций". Иногда с риском так и не собрать его до конца.
С другой стороны, feature-based approach позволяет продумывать поведение приложения и за пределами прописанных в сценарии путей.
Мой любимый пример — устаревший много лет назад API для Microsoft Online Syndication Interface, MOSI. Если бы его проектировали в терминах фич, то там было бы что-то вроде partner can manage the tenant subscriptions. Ок, есть тенант, у него есть подписки. Что такое "manage"? Create, List, Read, Update, Suspend, Resume, Cancel. Поехали, реализуем.
Увы, его проектировали в терминах "сценариев". (Я видел внутренний документ, на основе которого писался код). Сценарий "Партнёр перечисляет подписки тенанта" в список включён не был. В итоге, если клиент фейлился между тем, как он получил результат операции Create, и сохранил ID подписки в свою базу, то подписка тупо утекала. Не было никакого способа восстановить её ID.

С SPA происходит примерно так же — менеджер продукта описывает бизнес-сценарии. Ему не приходит в голову опускаться до универсальных деталей обстановки вроде "кнопки должны нажиматься", или "линки должны поддерживать навигацию вперёд-назад, сохранение в закладки и формирование шорткатов". В итоге девелоперы-нигилисты тупо выбрасывают эти аспекты поведения. В итоге получаем — тексты, которые нельзя скопировать по Ctrl-C, документы, которые невозможно напечатать, и ссылки, по которым можно пройти только один раз.