Вынес обсуждение технической реализации XGM из обсуждения контента
Тема
21 5.9K
28
ZlaYa1000, и данный подход по сути может лишать тебя одной важной вещи - основного потока трафика.
29
ZlaYa1000,
Легко если приложения не интегрируются друг в друга. Но если понадобится интегрировать все в себя то тут начинается разрастание кучи API, потом при расширении функциональности начинается возня с обратной совместимостью, порядком релиза модулей. Разведение зоопарка из технологий и т.д.
35
alexprey:
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
Трудозатратный почему? Из-за поддержки множественных обменов? А если держать только логин как объединяюще? Можно где-то почитай больше?
29
ZlaYa1000, классический подход микросервисной архитектуры. Очень трудозатратный.
35
Попробуйте немного может наивно и слишком агрессивно, но попробую такую стратегию сформулировать:
Что если xgm оставить только приложением, которые хранит данные о профиле пользователя (опыте, абилках), а весь остальной необходимый в доработке функционал делать отдельными (если сторонними, то опенсорс) приложениями (чат, форум, багтрекер?, новостную ленту и прочее), в которые в свою очередь авторизация поизводится через xgm.
Тем самым решаются проблемы:
  1. Нет необходимости сосредотачивать всё у себя, специализированные сторонние приложения будут всегда лучше из-за количества вложенных в них часов и опыта
  2. Нет смысла поддерживать старый код в местах, которые можно вынести вне основного приложения
  3. В случае устаревания функционала приложения его можно просто «выкинуть» портировав пользовательские данные во что-то новое (это сложный момент)
Минусы:
  1. Разные стили кода — разные проблемы
  2. опенсорс — наличие известных эксплоитов, в закрытом коде их надо искать
  3. Фрагментация
  4. Ограничиность передаваемых данных между приложениями. Например нужно передавать статус пользователя (заблокирован, пользователь, модератор, админ) помомимо логина — это отдельный код на каждое приложение.
  5. Отсутствие синхронизации между приложениями (иначе надо городить громоздкие обмены данными и их поддерживать)
Ветка обсуждения UX XGM вынесена из контентной стратегии.
Тема
12 3.7K
35
Озвучивал эту мысль несколько лет назад, но повторюсь, думаю что то что граждане сделали с логотипом, сделав на его основе самопальный объёмные версии для административных разделов есть глубокий и ничем не оправданный харам.
Логотип конечно не идеален, но пошаговая очистка и возврат в невинность принесут ощутимую пользу. Сразу визуально всё начнёт выглядеть приятнее. Ну а там и над редизайном можно задуматься.
Загруженные файлы
27
ZlaYa1000, то что ты скинул, открылось))
я имею в виду тему xgm.guru/p/wc3/189638 (это как к примеру) здесь скрин как открыть? сорри, блин туплю конечно, можно через "открыть изображение" и браузер покажет изображение
не знал, что есть такая кнопочка, если тыкнуть правой кнопкой мыши. все время скачивал
35
Steal nerves, думаю это не сложно, а открыть в новой вкладке не помогает?
тест
у меня открылось
27
А можно увеличить изображение картинки? Просто пользователи часто скидывают скрины, тем более с широкими размерами. И иногда не видно что там изображено (мелкий текст, например скрин триггеров), поэтому часто приходится скачивать изображение, чтобы у себя на компе рассмотреть. Потом мусор надоедает удалять. Мб сделать так, тыкнул и изображение увеличилось, еще раз тыкнул еще раз увеличил, не скачивая ничего
35
Jusper:
ну вот есть альтернативное мнение дока, что txt2 проще чем маркдаун, а для блогеров уже стандарт форматирование из медиумама
Все что надо, имхо, это нормальная панель с инструментами, чтобы не читать этот вековой мануал каждый раз.
Ну это боль всё-равно. Если угорать по разметке, то лучше мануал чем панель, но в целом попробуй medium или notion отличные визуальные редакторы там, есть решение на гитхабе для внедрения. Остаётся самая малось — внедрить. (ах да совместимость с txt2 не уронить)