Даже практически.
fb.ru лучший пример, ну и ряд подобных сайтов.
Уникальный контент - это хорошо.
Уникальные тексты - это плохо, потому что в 100% случаев под этим подразумевается блевотный рерайт :)
Нормальные люди не используют эту терминологию. Никто журналисту не скажет "напиши уникальный текст", ставится задача написать статью, обзор, мнение и т.д.
Вся эта индустрия написания уникального кало-рерайта - это одно большое надувательство, которое конечно выгодно тем, кто в этом работает.
А вообще надо танцевать от сайта, его направленности, типа. Где-то лучше оставить и текст и картинки официальные, естественно, неуникальные, но зато хоть читаемые и смотрибельные. Чем сочинять какой-то бред по мотивам + уникализировать картинки искажениями и украшать собственными ватермарками.
Как итог: с контентом надо работать. А когда все сводится к заказу текстов - это не контент.
Оставьте профессионалам.
Если задаются такие вопросы - понятно, что на коленке за копейки делается, кому оно такое нужно?
Как правило, когда говорят, что тестирование есть - на самом деле вообще ничего не значит. Хорошо, если хотя бы выполняется полный список обычных действий на сайте по добавлению, редактированию - это уже честно говоря высший сорт, в большинстве случаев и этого не делают.
Потом, должен заметить, каждое исправление цвета ссылки требует времени, чтобы выяснить, можем ли мы менять цвет ссылки, насколько это критично отразится на других элементах, оценивать риски и т.д. Вот поэтому я против систем, для простых сайтов. И искренне не понимаю, когда так принято в некоторых конторах. Порядок ради порядка, педантичность ради увеличения срока правки до космических размеров.
Сидит муж на кухне, кроссворд разгадывает, а жена моет посуду. Вдруг муж спрашивает:
- Первый мужчина, четыре буквы?
- Коля.
Prior,
Я к тому, что очень многие проекты не требует никаких самописных решений. И в них, как ни странно, все нормально работает, если начинаешь функционал расширять. просто надо это делать по правилам, как принято. Костыли во многих случаях получаются корявыми, потому что человек плохо знает CMS и начинает придумывать велосипед, вместо того, чтобы вставить пару строк уже известного работающего кода и спать спокойно.
Но берется самопис и потом вот не могут меню добавить без создания проблем.
Такие ситуации гораздо характернее и массовее. Просто потому что один-два человека не могут создать систему, в которой протестировано и улажено множество проблем. А CMS с их пользователями и разработчиками - могут.
Давайте по-чесноку, ведь когда делают сайт на заказ на каком-то фреймворке, никакого тестирования ведь и нет :) Как правило.
VoV@,
Конкретику давайте, конкретику. И ТС тоже.
У меня пока есть полное ощущение, что сижу в треде, где общаются разрабы Пейпала, Амазона, Фейсбука, e-bay и т.д. ну и порталов поскромнее, но все равно масштабных.
А еще этот топик - антиреклама самописов, причем очень показательная.
Мне не нравится этот подход и эта картинка тоже не нравится, как не нравятся и снобские статьи-переводы на хабре про то, как нужно организовать процесс.
Просто оно не имеет никакого отношения к реальности. К реальности, в которой мы говорим о магазинах, контентных проектах и т.п. - сайтов не настолько сложных, чтобы каждый пук документировать и создавать для каждого пункта каждого меню отдельную документацию на полсотни страниц.
В действительно крупных компаниях знают, как это все организовать. Там и бюджет и состав команды позволяют. Там можно экспериментировать, строить новые системы и т.д.
Но мы же не говорим о действительно крупных, так?
Ржака в том, что все эти советы и системы, которые применяются в крупных компаниях - они вообще не применимы к компаниям поменьше. И будут только тормозить разработку. Но я знаю, что есть любители почувствовать себя Гуглом или еще кем-то, внедрить сразу все известные системы, всю документацию, и смотреть на 2 программистов, которые умирают, пытаясь все это прочесть и учесть.
Надо изначально проектировать так, чтобы добавление новых модулей не могло критически затрагивать функционал. Т.е. задача эта - на плечах программеров, которые создавали проект изначально. Ну и конечно плохой вариант - когда программистов каждый раз находят на аутсорсе под кажую хотелку. Тут и без документации будет полный бардак, а с документацией - еще более навороченный бардак. Хорошо - когда программисты свои в офисе, либо постоянные на удаленке.
Владимир-C,
Я это к тому, что зачем составлять ядро, если можно взять лучший сайт по теме такого плана, отдать его райтерам и пусть пишут то же самое? Уже все составлено давно, именно поэтому все статейники одинаковы.
Если же подходить с другой стороны, то нужен толковый редактор, контент-редактор, который будет составлять план и главное следить за трендами, чтобы раньше отвечать на запросы, которые еще может быть даже не сформировались. И так далее, еще глубже, создавать эти самые запросы.
Семантическое ядро для контентных проектов не нужно.
