Oleg Shevelev:
1C - ИМХО это уже стандарт, а хорошая интеграция - это то что нужно тысячам компаний. Бизнес не готов начинать с чистого листа. Да и сам 1С развивается, они уже в минорной версии начали поддерживать нативную работу с JSON =)
К тому же, если действительно возникнет необходимость, то можно будет дописать к своему ИМ "свою 1С с преферансом и шахматистками". Во всяком случае, архитектура приложения, которую я пытаюсь реализовать предполагает (как мне на данный момент кажется), что "перейти в полную автономку" можно будет относительно безболезненно. Но я такой задачи перед собой не ставлю, потому что я ненавижу всю эту бумажную волокиту - пусть лучше ей занимается 1Ска.
С вашим делением интернет коммерции не согласен, потому что потребности у всех "троих" на самом деле почти одинаковые - никому из них не повредит высокотехнологичный интернет магазин. Таким образом можно делить клиентов только, если вы просто хотите разово срубить с них денег за создание посредственного сайта с которым будет очень сложно эффективно работать. Да и вообще, даже в вашем делении 2 и 3 категорию можно объединить, потому что нужно им одно и тоже.
"часть из того что вы описали не просто реализовать в виде коробочного решения что бы подходило абсолютно всем, всем хочется уникального подхода." Не вижу проблем. Можно подробнее? Необходимость всего перечисленного в предыдущем сообщении я встречал в 100% ИМ с которыми сталкивался.
Другой вопрос что захочу ли я распространять такое решение. Мне будет интереснее скооперироваться с партнерами торгующими теми или иными товарами и продвигать и продавать получая свою долю.
Oleg Shevelev: ну что значит классический интернет магазин? В моем понимании интернет магазину нужно очень много, чтобы быть просто нормальным.
Нужна полная (свойства, цены, склады, статус заказа) интеграция с 1С (Т.к. то что сделано в Битрикс - это ад кромешный - жутко нестабильная штука. Может программистам и кажется, что это работает нормально, но у меня как у SEOшника волосы на голове дыбом вставали, когда эта "сихронизация" переставала видеть существующие товары и создавала/удаляла их с сайта).
Тут надо вспомнить, что внутри 1С у клиентов обычно находится все совсем не в том виде, в котором они бы хотели видеть это в интернет магазине. А значит нужен УДОБНЫЙ инструмент для контент менеджера/маркетолога/SEOшника, который позволит не затрагивая содержимое 1Ски (главбух вас скорее застрелит, чем позволит что-нибудь там менять) представить на сайте только то, что должно быть на сайте, с названиями которые должны быть на сайте и т.д.
Нужен нормальный фильтр по товарам по любым комбинациям их свойств с условиями AND OR и сортировками. Все это должно работать без перезагрузки страницы (ну т.е. с помощью AJAX и Virtual DOM), при этом мы должны заранее блокировать для юзера любые комбинации свойств, которые приведут к нулевому результату фильтрации. При этом надо фильтровать не только белый/красный, но и одновременно делать выборку из определенного диапазона цен, и попутно сортировать по цене или названию. Этот пункт с фильтрами на MySQL - не сделать, т.к. очень долго и очень много запросов. Тут пока решения вижу обратиться к разрабам одной БД, чтобы они допилили ее под меня, либо самому попытаться написать БД под свои задачи (я пока не до конца не понял на сколько это будет сложно - но времени займет точно не меньше года).
Касательно цен и складов - отдельная песня, но суть в том что складов и цен для одного товара может быть неограниченное количество. При этом мы не забываем, что для быстрой работы сайта скорее всего придется делать денормализацию, чтобы фильтры работали быстро.
Потом мы вспоминаем, что товары в магазине могут быть составными, т.е. состоять из нескольких позиций (ну например человеку нужен унитаз, но товар на складах числится как 2 разные позиции бачок и чаша, но пользователя это не должно волновать, при этом если ему нужно что-то одно он должен иметь возможность купить только что-то одно).
Возвращаясь к такому свойству, как например цвет/размер - представлять в каталоге товары отличающиеся только 1-2 свойствами отдельно - это неюзабельно - значит их нужно объединять как минимум в представлении, НО тут мы вспоминаем про фильтры и все сводится к тому, что базу нельзя приводить к нормальным формам.
Если мы хотим дать качественный сервис, то тут встаем вопрос логистики, мы должны еще до оформления заказа дать пользователю информацию, какими способами (и их комбинациями) мы можем ему доставить все что он заказал, а значит мы должны хранить и обрабатывать всю информацию по массе и габаритам товаров, причем задача знать эту информацию не только в отдельности для каждого товара, но и суммарно для всего что добавлено в корзину.
Мы должны генерировать метаинформацию для любого товара по шаблонам, в том числе с использованием известных нам свойств товаров.
Мы должны генерировать метаинформацию для любого набора фильтров по товарам и возможность задавать кастомные ЧПУ для наборов фильтров.
Все это должно хорошо индексироваться.
...тут еще пунктов 30...
Я мог бы продолжать долго, но по сути я что хотел сказать-то... Такое ощущение, что практически все разработчики интернет магазинов понятия не имеют о том что такое удобно, и какие проблемы стоят перед реальным бизнесом.
Можно ли это назвать обычным интернет магазином? Не думаю. Потому что даже Ulmart и WikiMart (а них все полностью написано для себя) не дотягивают до требований, которые я выдвигаю для для интернет магазинов.
Oleg Shevelev: насчет кучи движков для интернет магазинов - я с вами не согласен. Я более 5 лет находился в поиске нормального движка для ИМ и в итоге пишу его сам на Go...
Хочу отметить, что я не был программистом - я занимался продвижением сайтов. И именно убогость существующих решений заставила меня сесть изучать Golang.
P.S. PHP - был отброшен на начальном этапе как "недоязык". Node.js - взорвал мой мозг, да и к тому же до сих пор не вызывает ощущение, что сервер на JS это надежно. А вот с Go - я сразу нашел общий язык.
Виктор Ablebeam: это не преждевременная оптимизация. Это нормальных подход к проектированию. Зачем тратить в будущем десятки человека часов на переделку и костыли, когда можно сразу нормально спроектировать? Не говоря уже о случаях, когда бизнес уже вырос из старого интернет магазина, который без свистелок и перделок (хорошего юзабилити и функционала) дальше расти не может, при этом с учетом новых требований по функционалу нужно все писать с нуля.
вроде бы сработало.
P.S. Я ошибку сделал не usermodE, а usermod. В тексте вопроса я исправил. Вы если можете тоже отредактируйте ответ.