Я почти уверен, что нашим пользователям это нужно:
Например, пользователь читает статью про звук /ð/. У статьи есть тег «согласные». Кликает на согласные, в related tags будет «шипящие», «стопы», «назальные» и так далее. Кликает на «шипящие». в related tags будет «звонкие» и «глухие». Ну и так далее.
Кроме того, это очень удобно авторам. Например, автор пишет статью про что-нибудь хитрое. Он таким же путем подбирает себе связанные статьи, и может вставить готовую ссылку. Пользователь затем может эту ссылку отфильтровать дополнительно, или сделать еще что-нибудь полезное.
Вообще, мне кажется, мы часто недооцениваем, насколько важно хорошо структурировать контент. От этого все беды ))
Если придумаете, как это сделать на WP — пишите. Обсудим условия )
В своем ТЗ мы предложили несколько вариантов решения проблемы с дизайном. Включая покупку платных тем, готовых CSS фреймворков, и так далее. Просто использование базовой темы, наконец. Нас бы любой из этих вариантов вполне устроил.
Мы старались сделать это корректно. Что-то вроде «Ваш отклик на данное ТЗ крайне ценен для нас! Смеем ли мы надеяться, что не слишком затрудним вас, если попросим начать его со слов „Hello there“. Ну и дальше извиняемся строк на десять.
А это вывод статей, у которых есть все указанные теги. Вроде бы это ваше многие ко многим.
Хорошо, допустим мы вывели так все статьи где есть все три тега 'bread' +' baking' + 'recipe'. Но ведь этого недостаточно. Надо еще вывести список всех тегов, которые относятся ко все статьям, удовлетворяющим условию. За исключением тегов, входящих в условие, конечно. Например, 'pancake' и 'cupcake'.
Далее, пользователь кликнул, допустим, на 'pancake'. Условия списка меняется на 'bread' +' baking' + 'recipe' + 'pancake'. Разумеется, список связанных тегов меняется тоже.
Ну и помимо всего этого, сам UI надо как-то нарисовать.
Вообще спасибо, что вы стали это расписывать. Я сейчас только понял, что большинство веб-разработчиков просто не поняли, что значит «фильтры многие ко многим» в нашем ТЗ. Хотя мы приводим там примеры, со скриншотами.
Могу ответить только за себя: я прежде всего хочу узнать, насколько хорошо исполнитель понял задачу, и как он собирается ее решать. То есть сама цена меня вообще не интересует, меня интересует в насколько адекватные руки я отдаю свой проект.
Ведь в супермаркете вы точно видите, что ходите купить. Боюсь, этот аргумент играет как аз против вашей точки зрения. А так, да — Wordpress стоит $0, Laravel — 0$, October — $9. Вот именно столько это стоит в супермаркете. Все, что сверху, мне как заказчику неведомо, и именно это я и пытаюсь выяснить.
Ну, если говорить о WordPress (и, кстати, не только WordPress), то c дизайном-то все решается очень просто: мы купили несколько почти полностью устраивающих нас тем еще на этапе написания ТЗ. Так что дизайн и верстка нам были нужны только если исполнитель ну уж очень хочет заняться дизайном сам. И это было четко оговорено в ТЗ.
Так что насчет этого вашего расчёта я не соглашусь, пока…
Что касается сроков и стоимости. Давайте посчитаем. Дизайн здесь займет часов 40, ещё 60 займёт верстка и интеграция с WordPress. Сюда нужно добавить 20 часов работы менеджера
Могу я поинтересоваться, откуда взялось
10 часов на маркетинг
?
Вообще, примерно так нам писало как раз 90% «эффективных project managerов» — я ТЗ не читал, но УЖЕ точно знаю, что вам нужно 100 часов на дизайн, 50 часов на «посадку макета», 30 часов на маркетинг и 50 часов на SEO. Прямо даже забавно — прочитал статью и тут же подтвердил все ее тезисы в одном коротком комментарии.
Естественно, мы на это смотрим, но пока у нас a seller's market (спрос превышает предложение), выбирать не приходится. Точнее, приходится, и вот что получается (статистика по откликам):
Ну, мы хотели морфологический поиск вот почему: 90% наших пользователи — не носители языка, на котором они читают материалы (а иначе зачем бы им исправлять акцент?). Они слова типа diphthong и pronounce пишут с пятой попытки. Просто снять хоть часть этой боли.
Видимо я слишком плохо себе представляю, как работает Wordpress. Скажем, есть тема, и есть пара плагинов. Все трое тянут свои библиотеки и еще кучу всего. В результате банальная страница статьи весит 4 мега, включая пачки разных версий одинаковых библиотек.
Как это оптимизировать, не вмешиваясь в плагины? Какая-то магия CloudFlare?
Да я не пытаюсь выглядеть лучше, чем я есть, но мы как раз начали с того, что опубликовали отдельный заказ, чтобы нам написали ТЗ. Никто не откликнулся, разумеется.
В статью это включать не стал, не хотел выглядеть слишком уж наивным.
Например, пользователь читает статью про звук /ð/. У статьи есть тег «согласные». Кликает на согласные, в related tags будет «шипящие», «стопы», «назальные» и так далее. Кликает на «шипящие». в related tags будет «звонкие» и «глухие». Ну и так далее.
Кроме того, это очень удобно авторам. Например, автор пишет статью про что-нибудь хитрое. Он таким же путем подбирает себе связанные статьи, и может вставить готовую ссылку. Пользователь затем может эту ссылку отфильтровать дополнительно, или сделать еще что-нибудь полезное.
Вообще, мне кажется, мы часто недооцениваем, насколько важно хорошо структурировать контент. От этого все беды ))
Если придумаете, как это сделать на WP — пишите. Обсудим условия )
Так можно сделать? Что для этого потребуется?
Хорошо, допустим мы вывели так все статьи где есть все три тега 'bread' +' baking' + 'recipe'. Но ведь этого недостаточно. Надо еще вывести список всех тегов, которые относятся ко все статьям, удовлетворяющим условию. За исключением тегов, входящих в условие, конечно. Например, 'pancake' и 'cupcake'.
Далее, пользователь кликнул, допустим, на 'pancake'. Условия списка меняется на 'bread' +' baking' + 'recipe' + 'pancake'. Разумеется, список связанных тегов меняется тоже.
Ну и помимо всего этого, сам UI надо как-то нарисовать.
Вообще спасибо, что вы стали это расписывать. Я сейчас только понял, что большинство веб-разработчиков просто не поняли, что значит «фильтры многие ко многим» в нашем ТЗ. Хотя мы приводим там примеры, со скриншотами.
Могу ответить только за себя: я прежде всего хочу узнать, насколько хорошо исполнитель понял задачу, и как он собирается ее решать. То есть сама цена меня вообще не интересует, меня интересует в насколько адекватные руки я отдаю свой проект.
Ведь в супермаркете вы точно видите, что ходите купить. Боюсь, этот аргумент играет как аз против вашей точки зрения. А так, да — Wordpress стоит $0, Laravel — 0$, October — $9. Вот именно столько это стоит в супермаркете. Все, что сверху, мне как заказчику неведомо, и именно это я и пытаюсь выяснить.
Так что насчет этого вашего расчёта я не соглашусь, пока…
Могу я поинтересоваться, откуда взялось
?
Вообще, примерно так нам писало как раз 90% «эффективных project managerов» — я ТЗ не читал, но УЖЕ точно знаю, что вам нужно 100 часов на дизайн, 50 часов на «посадку макета», 30 часов на маркетинг и 50 часов на SEO. Прямо даже забавно — прочитал статью и тут же подтвердил все ее тезисы в одном коротком комментарии.
Laravel 19%
Bitrix 10%
Drupal 7%
Самописная 5%
OpenCart 5%
Django 5%
Joomla 2%
Saas 2%
Next.js 2%
Tilda 2%
October 2%
DataLife Engine 2%
MODX 2%
Ну, мы хотели морфологический поиск вот почему: 90% наших пользователи — не носители языка, на котором они читают материалы (а иначе зачем бы им исправлять акцент?). Они слова типа diphthong и pronounce пишут с пятой попытки. Просто снять хоть часть этой боли.
Как это оптимизировать, не вмешиваясь в плагины? Какая-то магия CloudFlare?
В статью это включать не стал, не хотел выглядеть слишком уж наивным.