Здравствуйте. Не совсем поняли вашу задумку. Разные типы SKU направлены на разные сценарии работы. Первый тип переключает торговые предложения в верхней области. Например, это полезно для интернет-магазинов одежды. Когда клиенту нужно рассмотреть, как меняется товар и стоимость.
Второй тип подойдет интернет-магазинам, где нужно рассмотреть все предложения в табличном виде. Например, для продажи металла. В этом случае клиент сможет рассмотреть отличие особенностей товара, не акцентируя внимание на изображение.
Если реализовать отображение сразу двух типов, то они будут дублировать друг друга. Причем SKU2 не будет сразу в поле видимости. Велика вероятность, что клиент все равно увидит сначала SKU1.
Поэтому мы отклоняем идею. Если мы вас не правильно поняли, пожалуйста, расскажите свою просьбу подробнее. Хороших вам выходных!
Здравствуйте. Не совсем поняли вашу задумку. Разные типы SKU направлены на разные сценарии работы. Первый тип переключает торговые предложения в верхней области. Например, это полезно для интернет-магазинов одежды. Когда клиенту нужно рассмотреть, как меняется товар и стоимость.
Второй тип подойдет интернет-магазинам, где нужно рассмотреть все предложения в табличном виде. Например, для продажи металла. В этом случае клиент сможет рассмотреть отличие особенностей товара, не акцентируя внимание на изображение.
Если реализовать отображение сразу двух типов, то они будут дублировать друг друга. Причем SKU2 не будет сразу в поле видимости. Велика вероятность, что клиент все равно увидит сначала SKU1.
Поэтому мы отклоняем идею. Если мы вас не правильно поняли, пожалуйста, расскажите свою просьбу подробнее. Хороших вам выходных!
Вы всё правильно поняли, но не видите преимущества такого варианта. Всё ниже написанное касается удобства использования с мобильных устройств. Всем известно, что более 75% визитов - это мобилы.
Например, у многих детских магазинов для новорожденных, где продают детские коляски есть особенность. На каждую модель коляски по 7-15 торговых предложений, отличающихся только расцветкой ткани и иногда ценой. И при выборе SKU1 чтобы узнать какие коляски есть в наличии в магазине и цену, нужно кликнуть на иконку SKU1 (ок, цену узнали, теперь наличие), затем кликнуть на "наличие", а потом еще проскролить страницу вверх, потому что при нажатии на "наличие", срабатывает автоскролл в нижнюю часть страницы к табу/блоку с наличием. Неудобно.
Ок. Переключаем на SKU2. Опа, наличие по складу/магазину невозможно узнать. Ну ок. Прикрутили кастомным шаблоном наличие всплывающим окном. В списке товаров мы видим одну расцветку и цена ОТ "от 10000р". Заходим на детальную страницу товара, мы видим одну расцветку и надпись цена ОТ "от 10000р". Нужно проскролить вниз, чтобы догадаться, что есть расцветки и что цена ОТ на самом деле не от того что, есть какие-то нюансы, секреты, а потому что у товара есть расцветки (кстати с одинаковой ценой). Также при SKU2 в вашей демоверсии нельзя открыть фото SKU на весь экран и посмотреть доп картинки SKU. На нашем сайте не могу посмотреть так как мы уже начали переделывать SKU под свой "объединённый" тип SKU. Нам уже не важна эта идея в новых обновлениях, всё самостоятельно делаем.
Кто-то может написать что не нужно такой товар хранить в торговых предложениях, нужно отдельно товар заводить на каждый цвет, но вот моделей колясок в среднестатистическом магазине более 30шт, а в нашем более 40 моделей в наличии в одном розничном магазине и еще 20-30 моделей на удалённом складе. Итого 70 моделей умножаем на 5 расцветок (минимум). Умножаем. В итоге раздел прогулочных колясок из 350 колясок. Сортировать это так чтобы пользователь не ушел с сайта невозможно.
Конкретной просьбы у меня уже нет. На данный момент, проанализировав ваш код, я предположил, что вы уже с этим, скорее всего, ничего не сделаете. Чтобы сделать удобным использование SKU для мобильных устройств, вам придётся всё перелопачивать и писать шаблоны для catalog.section и catalog.element практически с нуля.
Вы всё правильно поняли, но не видите преимущества такого варианта. Всё ниже написанное касается удобства использования с мобильных устройств. Всем известно, что более 75% визитов - это мобилы.
Например, у многих детских магазинов для новорожденных, где продают детские коляски есть особенность. На каждую модель коляски по 7-15 торговых предложений, отличающихся только расцветкой ткани и иногда ценой. И при выборе SKU1 чтобы узнать какие коляски есть в наличии в магазине и цену, нужно кликнуть на иконку SKU1 (ок, цену узнали, теперь наличие), затем кликнуть на "наличие", а потом еще проскролить страницу вверх, потому что при нажатии на "наличие", срабатывает автоскролл в нижнюю часть страницы к табу/блоку с наличием. Неудобно.
Ок. Переключаем на SKU2. Опа, наличие по складу/магазину невозможно узнать. Ну ок. Прикрутили кастомным шаблоном наличие всплывающим окном. В списке товаров мы видим одну расцветку и цена ОТ "от 10000р". Заходим на детальную страницу товара, мы видим одну расцветку и надпись цена ОТ "от 10000р". Нужно проскролить вниз, чтобы догадаться, что есть расцветки и что цена ОТ на самом деле не от того что, есть какие-то нюансы, секреты, а потому что у товара есть расцветки (кстати с одинаковой ценой). Также при SKU2 в вашей демоверсии нельзя открыть фото SKU на весь экран и посмотреть доп картинки SKU. На нашем сайте не могу посмотреть так как мы уже начали переделывать SKU под свой "объединённый" тип SKU. Нам уже не важна эта идея в новых обновлениях, всё самостоятельно делаем.
Кто-то может написать что не нужно такой товар хранить в торговых предложениях, нужно отдельно товар заводить на каждый цвет, но вот моделей колясок в среднестатистическом магазине более 30шт, а в нашем более 40 моделей в наличии в одном розничном магазине и еще 20-30 моделей на удалённом складе. Итого 70 моделей умножаем на 5 расцветок (минимум). Умножаем. В итоге раздел прогулочных колясок из 350 колясок. Сортировать это так чтобы пользователь не ушел с сайта невозможно.
Конкретной просьбы у меня уже нет. На данный момент, проанализировав ваш код, я предположил, что вы уже с этим, скорее всего, ничего не сделаете. Чтобы сделать удобным использование SKU для мобильных устройств, вам придётся всё перелопачивать и писать шаблоны для catalog.section и catalog.element практически с нуля.
Здравствуйте. Спасибо за уточнение. Теперь поняли, что важно видеть наличие товара. Но совмещение двух типов SKU на одной странице этот вопрос не решит. Так как при SKU 2 не отображается наличие на складе.
На многих сайтах просмотр наличия в магазине находится в отдельном блоке. Пока мы не видим другого варианта реализации. Дублировать отображение SKU не вариант. Это будет лишь дополнительной нагрузкой на сайт. Поэтому статус задачи не меняем — отклонено. Будем рады видеть другие ваши идеи!
Здравствуйте. Спасибо за уточнение. Теперь поняли, что важно видеть наличие товара. Но совмещение двух типов SKU на одной странице этот вопрос не решит. Так как при SKU 2 не отображается наличие на складе.
На многих сайтах просмотр наличия в магазине находится в отдельном блоке. Пока мы не видим другого варианта реализации. Дублировать отображение SKU не вариант. Это будет лишь дополнительной нагрузкой на сайт. Поэтому статус задачи не меняем — отклонено. Будем рады видеть другие ваши идеи!
Здравствуйте. Не совсем поняли вашу задумку. Разные типы SKU направлены на разные сценарии работы. Первый тип переключает торговые предложения в верхней области. Например, это полезно для интернет-магазинов одежды. Когда клиенту нужно рассмотреть, как меняется товар и стоимость.
Второй тип подойдет интернет-магазинам, где нужно рассмотреть все предложения в табличном виде. Например, для продажи металла. В этом случае клиент сможет рассмотреть отличие особенностей товара, не акцентируя внимание на изображение.
Если реализовать отображение сразу двух типов, то они будут дублировать друг друга. Причем SKU2 не будет сразу в поле видимости. Велика вероятность, что клиент все равно увидит сначала SKU1.
Поэтому мы отклоняем идею. Если мы вас не правильно поняли, пожалуйста, расскажите свою просьбу подробнее. Хороших вам выходных!
Здравствуйте. Не совсем поняли вашу задумку. Разные типы SKU направлены на разные сценарии работы. Первый тип переключает торговые предложения в верхней области. Например, это полезно для интернет-магазинов одежды. Когда клиенту нужно рассмотреть, как меняется товар и стоимость.
Второй тип подойдет интернет-магазинам, где нужно рассмотреть все предложения в табличном виде. Например, для продажи металла. В этом случае клиент сможет рассмотреть отличие особенностей товара, не акцентируя внимание на изображение.
Если реализовать отображение сразу двух типов, то они будут дублировать друг друга. Причем SKU2 не будет сразу в поле видимости. Велика вероятность, что клиент все равно увидит сначала SKU1.
Поэтому мы отклоняем идею. Если мы вас не правильно поняли, пожалуйста, расскажите свою просьбу подробнее. Хороших вам выходных!
Комментарии на данной страницы заблокированы!