Xpoint
   [напомнить пароль]

Что нужно знать заказчику сайта и как стать "профессиональным заказчиком"?

Метки: [без меток]
2006-11-25 14:52:24 [обр] Bearcub[досье]

Уважаемые любители и профессионалы в области создания сайтов,

Подскажите, пожалуйста, что нужно знать заказчику сайта и где можно почерпнуть эти знания. Желательны не общие фразы, а конкретно по пунктам: надо знать то-то и то-то…
Я просмотрел достаточно материалов в рунете, но не нашел ни одной статьи, как заказчику сайта стать «профессиональным заказчиком».

Хочу вложить относительно крупную сумму в создание информационного сервиса в Интернет, поэтому мне необходимо знать, какие методы используются для решения той или иной задачи, каковы их достоинства и недостатки.
Я пока что ничего не знаю в области проектирования сайтов, но, скажем, имею ряд вопросов, которые, наверное, задавал себе любой заказчик более-менее крупного проекта. Неужели нет какого-то пособия, faq или платных хороших курсов для заказчиков сайтов?
Рассматриваю вложение пусть и не очень больших, но трудом заработанных денег в сайт прибыльным делом, поэтому хочу знать, за что я плачу и выбрать наилучшие инструменты для создания сайта, чтобы сайт был удобным, быстродействующим и защищенным. Не секрет, что разработчики сайта стараются экономить силы и время и идти «проторенным путем» используя шаблоны сайтов и т.п. Мне же нужно сделать нестандартный сайт, с расширенными возможностями размещения и поиска информации пользователями, форумом, аналогов которому я не встречал и т.д.
Понимаю, что можно пойти в какую-нибудь крупную контору и за 50-80 тыс. USD сделают конфету, но я могу потратить только 10-15, максимум 20 тыс. на нестандартный сайт и поэтому буду вынужден обращаться к услугам фирм не первой величины. Отсюда и опасения, что сделают не так как надо, недостаточно защищено, что в процессе эксплуатации сайта вылезут какие-либо косяки, которые надо будет срочно латать (а сайт нельзя будет закрыть ни на день!), либо вообще переделывать сайт. Всего этого хотелось бы избежать, заранее четко оговорив в проекте на сайт задачи и методы решения.

Один маленький пример, чтобы было понятно о чем я говорю:

Задача оптимизации сайта под различные разрешения. Есть:
А) несколько способов определения разрешения, установленного на дисплее пользователя, и
Б) несколько способов оптимизации сайта под различные разрешения.
В случае просто постановки задачи оптимизации сайта, разработчик может пойти по самому простому пути, сиречь выберет наиболее дешевые (и плохие) сочетания вариантов А и Б. Из-за этого сайт может потерять значительную часть потенциальных клиентов из-за плохой «юзабилити» сайта, особенно это актуально в нашей стране, где парк мониторов очень пестрый.

Та же самая проблема с неоптимальным выбором метода и средства решения может дать «тяжелый» форум, медленный поиск по сайту и т.д. и т.п. и все такие отдельные задачи могут на корню загубить изначально отличную идею…

И таких вопросов и путей их решения множество, о большинстве из них я и не подозреваю. Хотелось бы узнать о хотя бы основных из них…

Я также забочусь о потраченном на разработку сайта моем времени и времени разработчика, не хочется, чтобы от «тупости» и неподготовленности клиента ухудшалось взаимопонимание и тормозилась работа. Поэтому большая просьба помочь, если кто может дать конкретные рекомендации…

Буду признателен всем ответившим!

спустя 1 час 6 минут [обр] Даниэль Алиевский(0/125)[досье]

Интересный вопрос.

Сразу приходит в голову следующее, что неплохо бы знать клиенту. Правда, набор вопросов бессистемен, уж извините...

  1. Какие разрешения экрана вообще популярны и в каких ситуациях? И какие есть варианты дизайна с точки зрения разных разрешений? (Раз уж вы сформулировали этот момент, хотя это далеко не главное.)
  2. Как сайты индексируются поисковыми роботами, что здесь важно, а что нет?
  3. Что такое формат gzip?
  4. Какие есть варианты поиска по сайту, что такое и чем плох поиск через Google или Yandex?
  5. Чем резиновая верстка отличается от жесткой? (В принципе! Как это делается, должны знать верстальщики.)
  6. Аналогично, чем div-ный дизайн отличается от табличного? Тут я не имею в виду знание, как работают теги <div...> и <table...>, но неплохо бы представлять, что ранее таблицы часто использовались не по назначению - для размещения элементов на странице, и лишь относительно недавно появилась стандартизованная альтернатива в виде стилей для тега div. Хороший разработчик использует div-ный дизайн, когда это возможно, а таблицы применяет именно для табличных данных.
  7. Что такое CSS и для чего он служит?
  8. Какие броузеры нынче популярны?
  9. Какая вообще ситуация со стандартизацией HTML, и в чем суть "войны" между Microsoft с ее Internet Explorer и прочими броузерами? (Опять же, в принципе.)
  10. Неплохо бы знать, что такое фреймы (frame), ActiveX, Java-апплеты и Macromedia Flash, в чем их плюсы и минусы - на случай, если разработчик решит применить что-то подобное.
  11. А также - что такое AJAX.
  12. Что такое серверный и клиентский скрипт? Какие есть скриптовые решения на стороне сервера - PHP, Perl, Java. (На стороне клиента - почти однозначно JavaScript.)
  13. Какие бывают варианты хостинга? Как зависят требования к хостеру (shared, dedicated) от применяемых на сайте технологий? Какие здесь масштабы цен?

Найти эту информацию - наверно, не проблема. Главное, знать, что искать :) По части дизайна, могу порекомендовать весьма завлекательное "ководство" Лебедева: http://www.artlebedev.ru/kovodstvo/

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

спустя 58 минут [обр] Роман Гринго aka gringo(0/4)[досье]

Я бы посоветовал вам, как заказчику, при разработке сайта придерживаться методики "от простого к сложному". Если вы заказчик-новичок, вы не сможете сразу поставить задачу правильно в максимальном обьеме. Кроме этого, вы не сможете определить качество разработки и поэтому вам придется играть с разработчиком в игру "пан/пропал".

  1. Начните с разработки сайта, с минимально необходимым набором функций, которые позволят реализовать вашу идею.
  2. Ни в коем случае не пытайтесь удовлетворить всю потенциальную аудиторию сразу. Это касается упомянутой вами "оптимизации под разные разрешения монитора" и других функциональных особенностей вашего сайта.

Таким образом, вы сэкономите время и деньги, и параллельно сможете продвинутся в вопросах, часть из которых перечислил Даниил Алиевский. Затем вы сможете приступить к созданию более сложного варианта сайта, учтя накопленный опыт.

спустя 2 часа 6 минут [обр] Marat Tanalin(3/78)[досье]

При выборе исполнителя полезно узнать, как это ни банально, какие вида пути будут на сайте:

— нормальные (site.com/about/history/)
— или дурацкие (site.com/template.pl?id=4&qwerty=main&moreuglyparams…).

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

Вторые, напротив, не отражают иерархию (все страницы имеют схожие адреса, различающиеся лишь набором параметров после имени шаблона) и при этом содержат бесполезную для пользователя информацию, как то имя шаблона и множество параметров, нужных зачастую только разработчику, не способному написать (хотя бы) систему, где для выдачи правильной страницы достаточно лишь одного параметра — её уникального идентификатора. Например, имя шаблона пользователю знать совершенно незачем, поскольку оно не имеет никакого отношения к той информации, которая содержится на странице.

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

спустя 15 часов [обр] Даниэль Алиевский(0/125)[досье]

Marat Tanalin[досье] По-моему, данный совет не безусловен и является предметом обсуждений: Реальная польза от Урлов, дружественных поисковым машинам К этому надо стремиться, но не надо ставить целью во что бы то ни стало избежать цифровых индексов в URL. Например, вот путь к программе ICQ на весьма уважаемом и чрезвычайно популярном сайте download.com:
http://www.download.com/ICQ/3000-2150_4-10535372.html?tag=pop.software
А вот еще пример:
http://news.yahoo.com/s/ap/20061126/ap_on_re_mi_ea/israel_palestinians
Вряд ли такой URL назовешь очень "осмысленным", и в то же время Yahoo - сайт #1 по популярности во всем Internet.

Все-таки, не так уж много обычных пользователей действительно разглядывают URL или, боже упаси, набирают его вручную. На хорошем сайте и без URL видно, где мы находимся. А при попытке набрать URL в адресной строке тот же FireFox подсказывает не только последние набиравшиеся адреса, но и названия соответствующих страниц. Поисковики тоже обычно неплохо справляются со сложными URL. Хотя, не буду спорить, при прочих равных простой и "красивый" URL лучше, чем "бессмысленный".

спустя 14 часов [обр] Marat Tanalin(3/78)[досье]

http://news.yahoo.com/s/ap/20061126/ap_on_re_mi_ea/israel_palestinians

В действительности этот адрес вполне осмысленный:

  • s — полные тексты новостей,
  • ap — новостное агентство, предоставившее новость (Associated Press);
  • 20061126 — дата в международном формате;
  • ap_on_re_mi_ea — уточнение территории, к которой относится новость (Middle East);
  • israel_palestinians — краткое название собственно новости.

Главная же беда системы адресации страниц с использованием GET-параметров в том, что зачастую такие адреса содержат избыточные параметры, например, такой относительно абстрактный случай:
/index.php?id=10&section=5&localnav=yes вместо просто /index.php?id=10 с извлечением остальных параметров из записи в БД, однозначно соответствующей указанному id.

Здесь id — идентификатор материала, section — раздел, к которому он принадлежит, localnav — выводить ли на странице локальную навигацию. Раздел, как и прочие атрибуты материала, которым в URL делать совершенно нечего, очевидно, должен являться полем базы данных и однозначно связан с идентификатором материала, уже указанным в адресе — и потому присутствие таких параметров с большой вероятностью может свидетельствовать о лени разработчика либо его недостаточной компетентности/навыках/способностях.

Что уж говорить о случаях, когда URL в системе имеет жёстко определённый вид (зачастую «в лоб» заданный в виде не подлежащего какой-либо модификации на лету шаблона пути вроде
/index.php?param1=%param1%&param2=%param2%)

и содержит параметры даже в том случае, если они пусты:
/index.php?section=5&id=10&moreparam1=&moreparam2=&etc=… вместо (хотя бы) просто /index.php?section=5&id=10

Проблема адресов с GET-параметрами не столько в параметрах как таковых, а в том, что используют их зачастую описанным невменяемым образом.

Иерархически осмысленные пути таких проблем как минимум не поощряют.

спустя 14 часов [обр] Даниэль Алиевский(0/125)[досье]

В такой формулировке вполне согласен. Если адреса в стиле download.com и yahoo.com не считаются "дурацкими".

Ибо лень либо "невменяемость" разработчика, проявившиеся в URL, наверняка проявятся в куда более серьезных аспектах.

Из этой же серии могу добавить совет "профессиональному заказчику": покажите исходный HTML-код сделанных для Вас веб-страниц хотя бы одному профессионалу в области HTML. Бывает, с виду страница выглядит и прилично (в вашем броузере), но реализована абсолютно кошмарно. Профессионал это увидит почти сразу. Пользователю это не видно, но плохой стиль исходного кода свидетельствует о крайней небрежности и опять же лени разработчика. По меньшей мере, такой сайт будет куда дороже обновлять и поддерживать.

спустя 3 часа 14 минут [обр] гоша(6/39)[досье]

Bearcub[досье]

хороший заказчик прежде всего не лезет не в свое дело.
ваше дело — объяснить ВАШУ предметную область
а вопросы реализации предоставьте разработчикам

спустя 1 день [обр] Роман Гринго aka gringo(0/4)[досье]
Хороший совет для случая идеальных заказчика и разработчика в вакууме. А по жизни если не лезть, то сделают как всегда.
спустя 18 часов [обр] гоша(6/39)[досье]
Вы наверное из тех, кто в автосервисе сам лезет в яму, в ресторане руководит ощипыванием курицы, а детстве учил дедушку кашлять.
спустя 3 часа 46 минут [обр] Даниэль Алиевский(0/125)[досье]

гоша[досье] Не согласен.

Я не очень в курсе, как оно в других странах. Но в России мне совсем недавно довелось учить сантехника соединять "устаревшую" раковину и "современный" сифон :)

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

спустя 1 час 56 минут [обр] Thirteensmay(0/157)[досье]

гоша[досье] Согласен. Тем не менее заказчик разбирающийся в вопросах реализации, при определенных условиях более продуктивен, и может быть полезен.

Роман Гринго aka gringo[досье] По жизни если хотите чтобы было "по Вашему" - делайте сами. В противном случае издержки неизбежны, в лучшем случае в виде икоты, но чаще в виде горя от ума. Заказчик всеже как правило на порядок менее квалифицирован нежели разработчик. Впрочем с Вами тоже согласен - контроль необходим, но разумный.

Даниэль Алиевский[досье] Не сравнивайте общеестественные знания со спецтехническими. Большинству того что Вы перечислили можно научить и обезъяну, точно также как соединять сифон с раковиной, это могут практически все. На анализ транзакций в современных клиент-серверных системах, или хотябы простейшую настройку файервола, даже после очень длительной подготовки, не каждый сантехник способен. Впрочем я прекрасно понимаю что Вы хотели сказать - знать с чем имеешь дело всеже надо, хотябы на уровне понятий, с этим я согласен.

Итак, IMHO основное для "профессионального" заказчика - точно знать что он хочет, четко знать, и непротиворечиво, уметь объяснять предметную область, готовиться к этому, знать принципы жизненного цикла ИС, иметь представление о процессе разработки, в частности процесс взаимодействия с исполнителями, необходимую документацию, знать законодательство и пр.
Вторично, но крайне желательно - знание технических аспектов.

По второму вопросу Даниил списочек представил, лично с половиной не согласен, коечто добавил бы, но суть не в том. Суть что мы умалчиваем о первом, основном пункте. Тут конечно на первом плане навыки проектирования. Конечно, заказчик это не постановщик задачи, но без хотябы элементарных навыков проектировщика заказчик что собака - знает, чувствует, но сказать не может, а если и открывает рот - то мычит и путается, не, ну не собака конечно, но чтото типа того. Думаю понимание ER диаграмм, диаграмм прецедентов, последовательностей, компоновки и пр. для "профессионального" заказчика жизненно необходимо, как и умение их составлять, хотябы примитивно, оно не так постановщику поможет, как самому заказчику от каши в голове избавиться. Далее, знание жизненного цикла ИС, процесс разработки, взаимодействие, документация, законодательство - тут думаю понятно.

спустя 1 час 19 минут [обр] Даниэль Алиевский(0/125)[досье]

Thirteensmay[досье]

...точно также как соединять сифон с раковиной, это могут практически все

Правда? Может быть, вы замечательный сантехник? :) Мой сантехник (да нет, совершенно нормальный профессионал, судя по его прочим визитам) не догадался. Ну захотелось мне чего-то нестандартного, в том числе экономии денег... А совместно все получилось нормально.

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

Это факт. И это как раз нормально, мне кажется. На то и профессионалы, чтобы объяснить заказчику, что на самом деле ему нужно. Сталкивался не раз (в роли профессионала). Нормально, если заказчик что-то невнятно "мычит" на тему, что ему надо что-то другое, но толком не понимает, что именно. Гораздо хуже, если заказчик вообще не понимает, что ему нужно не это, и платит деньги за халтуру или за постороннюю для него задачу.

Думаю понимание ER диаграмм, диаграмм прецедентов, последовательностей, компоновки и пр. для "профессионального" заказчика жизненно необходимо, как и умение их составлять, хотябы примитивно, оно не так постановщику поможет, как самому заказчику от каши в голове избавиться. Далее, знание жизненного цикла ИС, процесс разработки, взаимодействие, документация, законодательство - тут думаю понятно.

Ну тогда я точно не способен быть профессиональным заказчиком, по крайней мере сайтов :) Про ER и диаграммы прецедентов вовсе не слышал. Хорошо хоть способен программировать да на каком-то уровне реализовывать сайты (крайне любительском, вероятно)...

спустя 12 часов [обр] Thirteensmay(0/157)[досье]

Даниэль Алиевский[досье]
Вот я и говорю что прикручивание сифона к раковине задача достаточно обыденная, лишний раз это подтверждает факт того что Вы не являясь профессионалом смогли помочь. А смог ли бы сантехник помочь Вам настроить файервол, спроектировать БД, или хотябы написать простейший CGI обработчик ?

Ну тогда я точно не способен быть профессиональным заказчиком, по крайней мере сайтов :) Про ER и диаграммы прецедентов вовсе не слышал.

Зато похоже Вы не первый год в IT, для Вас оно компенсируется суммой других знаний, и обзаводились Вы ими достаточно долго и не просто, Вам не надо объяснять что такое алгоритм и его особенности, отличие алгоритмических языков от декларативных, принципы клиент-серверных систем, построения сетей, принципы баз данных, построение интерфейсов и пр. Бедный сантехник, как же ему стать профессиональным заказчиком ИС ? Ведь он всего этого не знает, а если и знает то крайне поверхностно, а от попыток применения этих поверхностных знаний ничего кроме ругани с исполнителем не получается. Может быть просто обратиться к профессионалам ? всеравно он не в состоянии тратить годы на изучение всех наших технологических моментов. Думаю у нас ошибка - мы рассматриваем заказчика со своей колокольни, подразумеваем что он знает нашу кухню, но ведь это совсем не так. ER и пр. эту проблему частично решают. Конечно, для большинства сайтов это возможно будет излишним, в силу того что они достаточно просты. Но ведь мы говорим о "профессиональном заказчике", суммах в десятки тысяч баксов, и нестандартных ИС.

Вообще, понятие "профессиональный заказчик" меня несколько смущает. Это что, чтото типа риэлтера от IT получается ? Ну ведь есть же постановщик задачи, а заказчик IMHO по определению не профессионал. Рассматривать тут наши частные случае думаю не стоит, т.е. когда один IT спец заказывает работу другого это несколько иная басня.

спустя 1 день 12 часов [обр] Роман Гринго aka gringo(0/4)[досье]

гоша[досье] Вы наверное из тех, кто в автосервисе сам лезет в яму.
Сравнения между созданием дорогого, высокотехнологичного продукта в единичном экземпляре по эскизу заказчика с автосервисом и ощипыванием курицы не корректны. Да, я буду интересоваться процессом его создания.

Thirteensmay[досье] По жизни если хотите чтобы было "по Вашему" - делайте сами.
Нет, делать сам я не буду, но конечный продукт должен рождаться совместными усилиями разработчика и заказчика.

Thirteensmay[досье] Заказчик всеже как правило на порядок менее квалифицирован нежели разработчик.
Проблема в том, что у них разные области компетенции. Заказчик может отлично разбираться в своей предметной области, но совершенно быть не способным правильно поставить задачу. Отсюда и распространённое в среде разработчиков и дизайнеров мнение, что заказчик - дебил.

Thirteensmay[досье] Впрочем с Вами тоже согласен - контроль необходим, но разумный.
Разумный, я это и имел в виду.

Thirteensmay[досье] Вообще, понятие "профессиональный заказчик" меня несколько смущает.
Меня тоже. Я вкладываю в этот термин такой смысл: Заказчик должен иметь хотя-бы небольшие навыки в постановке задачи, общения с разработчиками. Если он это делает не впервый и не во второй раз, такие навыки у него скорее всего появятся.

спустя 15 часов [обр] Даниэль Алиевский(0/125)[досье]

Thirteensmay[досье]

А смог ли бы сантехник помочь Вам настроить файервол, спроектировать БД, или хотябы написать простейший CGI обработчик?

Это некорректное сравнение. Сантехнику, который обратился к специалистам из нашей области, не надо уметь настраивать firewall, но хорошо бы знать, что это такое. Не надо уметь проектировать БД, но надо бы понимать, что вообще означает такая деятельность. Не надо писать CGI-скрипты, но надо представлять, что бывают еще и решения на PHP, mod_perl, Java-сервлеты и JSP и пр., и зачем вообще все это нужно. Так же как и мне, покупая телевизор или монитор, не надо уметь собирать телевизор, но полезно представлять, что такое ЖК-мониторы, чем вредны телевизоры, что такое разрешение растра и пр.

Роман Владимирович прав: нормальный заказчик не "менее" квалифицирован, чем нормальный разработчик, а просто квалифицирован в другой области. Именно он лучше всех представляет, что конкретно ему нужно, и ему желательно обладать теми знаниями, которые позволяют грамотно сформулировать свои потребности - для начала, самому себе. Я, скажем, вряд ли пойду чинить унитазы, ибо мой опыт и знания здесь ниже всякой критики: это становится очевидным при любом разговоре с сантехниками. Но зато я прекрасный специалист, когда речь идет о том, чего я хочу от моей сантехники. Ни один мастер лучше меня не скажет, какую цену я считаю приемлемой за то или иное усовершенствование, где у меня проблемы с засором трубы, где и почему нужно регулярно менять прокладки, нужна ли мне новая раковина или лучше приспособить старую, и т.д. Бывают значительно менее сведующие люди в области заказчика сантехники, что иногда оборачивается для них крупными неприятностями: например, невозможнотью решить банальную проблему вроде подтекающего крана, когда вместо замены прокладки (стоимостью несколько рублей, сама замена занимает 5 минут) покупается новый смеситель за 1000р. и вызывается сантехник за 500р.

Лучшие программные продукты, по моим впечатлениям, создаются именно при сотрудничестве профессиональных разработчиков и профессиональных заказчиков. Либо когда это - одни и те же люди (скажем, при разработке программ для использования самими программистами), либо когда потенциальные будущие пользователи специально привлекаются к процессу разработки.

спустя 7 минут [обр] Даниэль Алиевский(0/125)[досье]
Thirteensmay[досье] Кстати, прикрутить сифон к моей раковине для моего сантехника оказалось неразрешимой задачей :) Он предложил купить новую раковину и установить ее - именно в этом он профессионал. А я сумел решить задачу, так как хорошо представляю возможности, имеющиеся в моей квартире, и ставлю правильные цели. Более того, в firewall я разбирался ничуть не лучше вашего гипотетического сантехника, когда мне впервые пришлось его настраивать пару лет назад. И ничего, поискал документацию, инструкции, разобрался и настроил. Точнее, помог настроить профессионалам из моей хостинг-компании: опять же в роли заказчика, который хорошо представляет, что ему нужно.
спустя 1 день 23 часа [обр] Thirteensmay(0/157)[досье]

Роман Гринго aka gringo[досье], Даниэль Алиевский[досье]
Да, не спорю, профессиональный заказчик должен ориентироваться в технических моментах. Но следует учитывать оговорку: "Т.к. заказчик всеже шарит в этих технических моментах на порядок хуже разработчика, то он должен быть осторожен.", "Контроль должен быть разумным". гоша[досье] был слишком категоричен, тем не менее он озвучил основную задачу заказчика. Я же в соответствии с топиком предлагаю перечень тех знаний которые могут помочь в решении этой задачи. Ктото знает еще - милости просим, а также дополняем/редактируем список Даниила.

Итак, что нужно знать "профессиональному" заказчику web-ориентированной ИС ?: ;)

  1. Компоненты программно-аппаратной среды (читай что такое сервер, база данных, браузер, их возможности, архитектура клиент-сервер, серверный и клиентский скрипт, клиентские плагины и пр.).
  2. Организация internet/intranet (что есть провайдер, что есть хостинг, его виды, особенности, пр.).
  3. Жизненный цикл ИС, процесс разработки, взаимодействие с разработчиком, документация, законодательство, отличие информационного наполнения от функционального. (т.е. этапы жизненного цикла ИС, их особенности, персонал на каждом этапе, затраты, последовательность разработки, кто такой постановщик задачи, его функции, какая необходима документация, законно ли это, процесс информационного наполнения).
  4. Методология описания предметной области (читай ER диаграммы (UML)).
  5. Основные Web технологии (на уровне понятий) что такое HTML, CSS, JavaScript, Flash, ActiveX, CGI, AJAX, Perl/PHP/ASP, их области использования. Тут список конечно можно сильно расширить.
  6. Популярность решений и использования компонентов, положение со стандартизацией, поддержка и совместимость (читай какие программные компоненты наиболее часто используются, популярность браузеров, понимание наличия различий в стандартных реализациях, последствия).
  7. Основы эргономики, верстка (читай основные подходы, ориентация на целевую аудиторию, оптимизация выполняемых операций, отличие жесткой верстки от адаптивной).
  8. Методы организации поиска, индексирование поисковиками, кеширование (читай как организуется поиск, его разновидности, особенности, как работают internet поисковики, чем это нам грозит, понятие кеширования, преимущества и недостатки).
спустя 22 минуты [обр] Thirteensmay(0/157)[досье]
Да, блин, как всегда прощелкал самое главное ;) - Безопасность.
  1. Методы организации безопасности, основные уязвимости (читай какие места в web-ориентированных ИС наиболее уязвимы, как решается эта проблема, а также важность периодических обновлений).
Powered by POEM™ Engine Copyright © 2002-2005