Как спроектировать/организовать/спроектировать разработку мобильного веба в приложении Rails?

В 9 случаях из 10 вам будет лучше, если вы спроектируете сайт так, чтобы вы могли использовать одну и ту же кодовую базу для любого устройства, чтобы он разумно адаптировался к вашему устройству и чтобы он отображал наиболее важный/полезный контент/функциональность для каждое устройство на основе таблиц стилей или вариантов выполнения рендеринга/не рендеринга. Помните, что, в отличие от 6 лет назад, ваша главная проблема с мобильными устройствами сегодня — это не недостаток вычислительной мощности, а скорее другой размер экрана и другой ввод.

Как правило, мобильные пользователи не хотят видеть урезанную или урезанную версию вашего сайта. Они хотят видеть удобную версию вашего сайта. То, что означает Usable, варьируется, но часто это означает, что к наиболее часто используемым функциям очень легко получить доступ, в то время как более неясные опции спрятаны немного ниже или, возможно, не совсем оптимизированы. Пригодность может означать, что вы предоставляете им те же функции, что и на настольных компьютерах, но оформлены так, чтобы они лучше отображались на мобильных устройствах. Или что вы вырезаете вещи, которые не имеют смысла на мобильном телефоне. Но вы сделаете это намного сложнее для себя, если настроите его так, что вам придется поддерживать два потока кода, или один поток кода, который разветвляется очень рано, или принципиально другое приложение. Это гораздо больше тестов, намного больше кодирования и гораздо больше вероятности поломки.

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

• предположим, что все устройства будут обращаться к одному и тому же URL-адресу
• предположим, что 90 % оптимизаций устройств будут выполняться с использованием медиазапросов CSS, 7 % — с использованием хаков jQuery, а 3 % — с использованием обнаружения браузера на очень раннем этапе.
• создайте свое приложение так, чтобы отдельные компоненты или модули пользовательского интерфейса можно было легко включать/отключать с помощью кода (логика в ApplicationController? Rack Midleware?). Мы делаем это, помещая наши отдельные «виджеты» в партиалы, которые обернуты проверками включения виджета (либо в Rails.config, либо в качестве переменной экземпляра в стороннем ApplicationController), чтобы мы могли отключить, возвращаем ли мы соответствующий HTML обратно в браузер
• используйте медиа-запросы CSS не только для стилизации шрифтов и ширины, но также для изменения меню/функций и других элементов пользовательского интерфейса, чтобы они работали с различными форм-факторами, которые вам нужны.

Как правило, подход API для мобильных устройств будет наиболее полезен, если вы собираетесь создавать скомпилированное приложение для мобильного устройства и собираетесь выполнять тяжелую работу с пользовательским интерфейсом, используя библиотеки пользовательского интерфейса устройства, а не HTML генерируется на сервере. С другой стороны, если вы решите использовать такой подход, как Backbone.js или Angular.js, для управления интерфейсным дисплеем, то подход, основанный только на API, МОЖЕТ быть также хорошей архитектурой для вас. Но тогда вы намного больше выходите за пределы Rails.

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

При условии, что вы используете гибкий макет, похожий на потрясающие макеты Мэттью Джеймса Тейлора, которые изменить размер в соответствии с доступным размером экрана. Единственная причина, по которой я вижу потребность в шаблонах для мобильных устройств, заключается в том, чтобы обеспечить определенный стиль css, чтобы ваши представления больше походили на мобильное приложение.

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

Я вижу, что у вас действительно есть два варианта в зависимости от бюджета и сроков.

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

2) Перепроектируйте существующие шаблоны и функциональные возможности, чтобы сделать веб-сайт удобным для мобильных устройств.

В любом случае пользователи настольных компьютеров и планшетов получат выгоду, но насколько далеко вы пойдете с этим, зависит от ваших сроков и бюджета, причем вариант 1 является более дешевым и быстрым способом в краткосрочной перспективе, а вариант 2 — более дешевым и быстрым способом в долгосрочной перспективе. срок. Я вижу, что, не предоставляя одни и те же шаблоны как для мобильных пользователей, так и для пользователей настольных компьютеров/планшетов, вы ставите кого-то в невыгодное положение, поэтому предоставьте наилучший возможный опыт для всех пользователей.

Это действительно решение для ваших менеджеров проектов.

ОБНОВЛЕНИЕ: на основе комментариев

В этом случае я бы пошел на разработку отдельного мобильного приложения. Я бы даже рассмотрел возможность использования альтернативных технологий для потоковой передачи обновленных данных в реальном времени. Существует хорошее сравнение между Rails Live. Потоковое вещание и Node.js.

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

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

Я полагаю, вы уже пришли к своим собственным выводам относительно наилучшего пути вперед, и лучший совет, который я могу вам дать, — это сказать вам, чтобы вы просто дали себе немного больше времени на размышления и позволили выбранному вами решению утвердиться, и я' Я уверен, что если это правильный вариант, он просто «почувствуется» правильным для вас.

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