Должен ли мобильный сайт ссылаться на сайт, где функции недоступны на мобильных устройствах?

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

9 голосов | спросил Reloaded 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 13:11:32 +0400 2013, 13:11:32

4 ответа


19

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

Mobile не просто означает, что «люди сидели в кафе в течение 2 минут, глядя на свой iPhone». В наши дни Mobile означает « что-то , которое не является ноутбуком /рабочим столом» (и даже , которое немного расплывчато с помощью chomebook, MS Surface и подобных устройств в настоящее время).

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

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

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

У вас также может быть какая-то аналитика, чтобы узнать, сколько людей приходят в эти разделы на мобильном устройстве, чтобы передать это заинтересованным сторонам, и сказать: «Посмотрите, что X% посетителей пытается это сделать на мобильном устройстве, позволяет сделать это еще проще для них и оптимизировать эту область », поскольку она дает вам возможность для будущей работы и помогает определить приоритеты того, какие разделы рабочего стола пользуются более высоким спросом для мобильных пользователей, чем другие.

Черт, люди даже используют сайт приложения Passport US для подачи паспорта при использовании мобильного устройства (это не оптимизировано для мобильных устройств), и я не могу представить себе более болезненную задачу, чем выполнить на мобильном устройстве , но люди делают.

ответил JonW 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 13:19:54 +0400 2013, 13:19:54
3

Я думаю, здесь есть два момента:

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

  2. Дайте пользователю выбор: я не думаю, что есть что-то не так, если вы предоставляете пользователю возможность использовать полный сайт, если они захотят, чтобы это добавило значительную ценность. Например, мобильный мобильный сайт позволяет мне войти в мобильную версию, а затем использовать весь сайт, чтобы делать все остальное. Очевидно, что для банковского мобильного сайта это основная часть пользовательской поездки, поэтому это оправдано и позволяет мне мобильному банку. Там, где есть путешествие, которое находится за пределами основного набора поездок (например, смены пароля или настройки некоторых настроек), я бы вообще отказался от всех вместе. В обоих случаях предоставление ясных сообщений пользователю является важным, поэтому они могут решить, что они хотели бы сделать.

ответил Onkar 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 13:28:13 +0400 2013, 13:28:13
1

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

ответил SimonTeo 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 13:16:20 +0400 2013, 13:16:20
1

Пока вы не перенаправляете пользователей на домашнюю страницу какой-либо версии веб-сайта, который вы им обслуживаете, вы лучше, чем 90% веб-страниц, и не заслуживаете того, чтобы быть в этом особенном аду.

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

При наличии приличной структуры веб-сайта на большинстве мобильных устройств сайт на рабочем столе должен быть полностью работоспособен.

ответил Ben F 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 18:47:49 +0400 2013, 18:47:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132