Форум
Читайте нас также:

об электронной торговле - для интернет-магазинов и ритейла. портал и сообщество

Форум

самостоятельно наполнение контентом без зависимости от разработчика



Ссылка на сообщение alliya


Извините, я наверное не идеально точно описала ситуацию, просто вкратце хотела без подробностей. Но поскольку шквал возмущения по поводу добавления категорий, я опишу подробнее.
Я начала тестировать админку на своем сайте.
Карточка товара создается, проблем нет. А вот новая категория - тоже создается, но возникает проблема с ее удалением, на сайте она удаляется, а в админке остается - выделенная красным и никак не убирается - я написала исполнителям, на что получила ответ, что категории лучше они сами подправлять, возможно это связано еще с тем, что у меня всплывающее "мультименю" (место для категорий ограничено высотой меню). Видите категория "клетки для птиц" уже упираются в дно. Картинку прикладываю
[/img]Изображение[img]



Ссылка на сообщение Arm


вообще-то блок должен быть динамическим... или по высоте или пускать в 2 колонки...

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

это скорее к юзабилити



Ссылка на сообщение Дмитрий Осипов


alliya:

Здравствуйте!

Очень нужна информация и совет от владельцев интернет магазинов.
На данный момент у меня заказан и практически сделан интернет магазин на базе ModX.
В процессе выясняются подводные камни.
Я бы хотела максимально не зависеть от разработчиков сайта в вопросе наполнения контентом, а именно:

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

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


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


Здравствуйте.

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

Цитата:

Меня такой расклад не устраивает, подскажите, есть ли такие цмс-ки, где можно баннеры главной через админку убирать и добавлять, или может даже в modX это можно сделать, а мои разработчики просто не хотят это делать?

В modx как и любой другой системе управления контентом можно сделать всё что угодно что заложено в договор на разработку сайта
Всё что в обязательства разработчика по договору не заложено - он делать не обязан.

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



Ссылка на сообщение Олег Ом


Цитата:

В modx как и любой другой системе управления контентом можно сделать всё что угодно что заложено в договор на разработку сайта


Договор с разработчиком сайта-то каким боком? Смотреть функционал самого движка. Если предусмотрено управление категориями через Панель управления – значит, управление должно быть доступно владельцу сайта, вне зависимости от написанного в договоре с разработчиком (читай - интегратора) сайта.



Ссылка на сообщение Дмитрий Осипов


Олег Ом:

Если предусмотрено управление категориями через Панель управления – значит, управление должно быть доступно владельцу сайта, вне зависимости от написанного в договоре с разработчиком (читай - интегратора) сайта.

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

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

В частности, действия с категориями: создание, удаление, редактирование.
В этом случае исполнитель будет обязан всё исправить.
А если же об этом ничего в документах нет, то он вам может ответить "Ну мы же договаривались что мы вам сами будем категории заводить". И предъявить вам на это исполнителю с юридической точки зрения нечего. Это буквоедство конечно для задачи тса, которая исправляется за 20 минут, но пример показательный.



Ссылка на сообщение Олег Ом


Дмитрий Осипов:

А если же об этом ничего в документах нет, то он вам может ответить "Ну мы же договаривались что мы вам сами будем категории заводить".


Так и вижу эту картину маслом: в Т.З. заказчик скрупулезно перечисляет дефолтный функционал коробочного движка (тысячу абзацев, не меньше) и приписывает комментарий к каждому пункту «этот функционал оставить в дефолтном исполнении».

Или многодневную скайп-конференцию с заказчиком провести? «Клик по кнопке «Каталог» в верхнем меню будет вести на заглавную страницу каталога, согласны, нет? Отлично. Теперь рассмотрим и документально зафиксируем функционал клика по ссылке «Каталог» в нижнем меню...»



Ссылка на сообщение Дмитрий Осипов


Олег Ом:

Теперь рассмотрим и документально зафиксируем функционал клика по ссылке «Каталог» в нижнем меню...»

На самом деле подобное визуализируется в компоновочных макетах и моделях поведения, которые заказчик может сделать и самостоятельно благо программ для этого достаточно в свободном доступе. А именно, отрисовать в моделях поведения пользователя и администратора куда он может переходить, "что видеть" и что "может делать". Эти же макеты можно прикрепить к техническому заданию или приложением к договору.
Практика показывает, что если это хотя бы проговаривается с разработчиком, то обычно реализуется. А вот если заказчик умолчал о чем-то посчитав это что-то очевидным, то очевидным этот функционал с позиции разработчика может и не оказаться.
Не хотим фиксировать в документах или хотя бы обсуждать то что хотим получить на выходе на этапе согласования, тогда получаем то, что нам сделали и не обижаемся.
Или переплачиваем потом за доработки при худшем раскладе.






Ответить



:D
:)
:(
:o
:shock:
:?
8)
:lol:
:x
:P
:oops:
:cry:
:evil:
:twisted:
:roll:
:wink:
:!:
:?:
:idea:
:arrow:
:|
:mrgreen:







2001 - 2017 © Оборот.ру. Все права защищены