Профессия "Front-end архитектор"

Transcript

1. Профессия «front-end архитектор» © Андрей Оконечников, 2007
2. Слово.
3. Слово.
4. Слово.
5. spacer.gif
6. И началась эпоха веб-дизайнеров.
7. Дизайнер- ремесленник
8. Фокусируясь на том, как сайт выглядит, дизайнеры часто забывают о целях и задачах.
9. Cайтом должны пользоваться люди,
10. искать и находить,
11. делать покупки,
12. читать новости,
13. участвовать в обсуждениях.
14. Стремление быть оригинальными приводит
15. к необычным результатам...
21. Дизайн ради дизайна
22. не ради пользователей
23. не ради их целей и задач
24. не ради удовлетворенности продуктом или услугой
25. 10 фишек
26. Почему так происходит?
27. Очень часто дизайнеры думают...
28. результат их работы — самый важный.
29. Это не так!
30. Графический дизайн — лишь один из аспектов веб-разработки.
31. Такой же, как
32. usability,
33. accessibility,
34. семантика,
35. и контент.
36. Немногие дизайнеры пишут код разметки страниц.
37. Поэтому...
38. После создания макетов, дизайнер выводится из проекта,
39. а реализацией занимаются другие люди...
40. Дизайнер теряет контроль над конечным продуктом.
43. Можно относиться к дизайну как к искусству,
44. но это имеет мало общего с реальным миром и его потребностями.
45. +
46. Низкое качество разметки страниц
47. =
48. Source: http://www.accessibility.nl/files/images/tag-soup2-035.jpg
49. Source: http://andyhiggs.co.uk/blog/images/162.jpg
50. Веб-стандартист
51. Появились люди, называющие себя «веб-стандартисты» и выступающие…
52. создание семантического и валидного кода
53. разделение представления и содержания
54. использование безтабличной верстки
55. Веб-сообщество приняло их как реальное решение накопившихся проблем.
56. Дизайнеры заявляют:
57. «Веб-стандарты, не являясь выразительным средством коммуникации, мешают их творческой работе»
58. Графический дизайн не зависит от веб-стандартов!
59. Source: http://www.uwsp.edu/geo/faculty/ritter/images/maps/ocean_currents.jpg
60. Source: http://www.photos-screensaver-maker.com/screen/images/scr-ocean.jpg
61. Выверенный и хорошо выполненный графический дизайн действует на пользователей лишь через визуальный канал.
62. Семантическая разметка, на которую «наложена» графическая составляющая, будет взаимодействовать с технологиями и механизмами Веба.
63. Создать уникальный графический дизайн и реализовать его, используя веб-стандарты, — это реальная задача.
64. Кроме того...
65. хорошая разметка ускоряет разработку веб-приложений.
66. Source: http://www.webdimension.co.uk/
67. Время front-end архитекторов
68. Сегодняшняя веб- разработка немыслима без использования серверных фреймворков
71. призваны упрощать и ускорять разработку и отладку веб-приложений.
72. Усложняется логика работы приложений.
73. Растут объемы данных.
74. Это сделало стандартом «де-факто» наличие в проектах системного архитектора.
75. системный архитектор
76. Использование серверных фреймворков предполагает, что
77. разработчик должен больше думать о логике приложения, красоте своего кода, его объектной модели
78. нежели о деталях реализации под различными браузерами и платформами.
79. Но!
80. Результат работы фреймворка не всегда идеален и зачастую должен быть откорректирован.
82. C развитием серверных фреймворков, становятся все более сложными и фронт-енд технологии.
83. и динамическое изменение страниц, Ajax
84. drag & drop
85. визуальные эффекты
86. сложные элементы пользовательского интерфейса
87. +
88. user experience
89. usability
90. accessibility
91. современные задачи уже не могут быть решены лишь с помощью
92. HTML & CSS
93. безтабличной версткии
94. умением писать валидный код
95. Front-end архитектура
96. Учитывая то количество различных технологий и способов решения тех или иных задач
97. часто бывает сложно принять решение, какой из этих способов следует использовать в данном конкретном случае.
98. — Использовать CSS или JavaScript для создания выпадающих меню?
99. — Использовать текстовые, графические или sIFR загловки?
100. Каждый из способов имеет свои плюсы и минусы, которые могут иметь разное значение в зависимости от конкретной ситуации.
101. Необходимо знать не только слабые и сильные стороны технологии, но и владеть ситуацией.
102. Для принятия правильного решения
103. требуется человек, способный оценить ситуацию в целом, учитывая большое количество факторов:
104. usability
105. accessibility
106. серверную реализацию
107. задачи пользователей
108. бизнес-цели
109. Разметка страниц
110. Основой фронт-енда является HTML разметка страниц.
111. — Какой doctype стоит использовать?
112. — Каким (x)HTML элементом кодировать тот или иной блок на странице?
113. — Использовать атрибут id или class?
114. Это зависит от...
115. Какой серверный фреймворк будет использоваться?
116. Какая функциональность будет на страницах?
117. Потребуется ли менять внешний вид страниц?
118. CSS
119. CSS является презентационным уровнем фронт-енд модели приложения.
120. — Как организовать CSS документы?
121. — Создавать имена классов или привязать к элементам DOM?
122. — Использовать наследование или писать дублирующий код?
123. Это зависит от...
124. Насколько крупное создается приложение?
125. Будет ли меняться разметка страниц в процессе разработки?
126. Как взаимосвязана функциональность страниц?
127. JavaScript
128. JavaScript & DOM scripting — это логика фронт-енд приложения.
129. — Использовать onclick или “unobtrusive” обработчики событий для элементов?
130. — Реализовать валидацию на стороне клиента или сервера?
131. — Назначать стиль отображения inline через JavaScript или использовать className?
132. — Организовать код через namespaces или использовать global scope?
133. Это зависит от...
134. Что решает эта функциональность?
135. Как именно она должна работать?
136. Поддерживают ли данную реализацию необходимые браузеры?
137. Существуют определенные практики, знание и владение которыми позволит избежать множества проблем при использовании JavaScript.
138. Ajax
139. Полный Ajax!
140. — Использовать Ajax или стандартный механизм с обновлением страницы?
141. — Какой из вариантов наиболее удобен для пользователей в контексте решаемой задачи?
142. — Как это отразится на доступности приложения?
143. — Смогут ли использовать эту функциональность пользователи мобильных устройств?
144. Это зависит от...
145. Если отключен JavaScript, то Ajax функциональность перестанет работать.
146. Этот недостаток можно обойти, но это потребует дополнительных усилий.
147. И снова требуется кто-то, кто сможет дать рекомендации по использованию,
148. кто сможет принять решение о необходимости Ajax в конкретном случае.
149. Front-end архитектор
150. front-end архитектор
156. Какими знаниями и навыками должен обладать фронт-енд архитектор?
157. XHTML & CSS
158. Кросс-браузерная и кросс-платформенная совместимость
159. JavaScript разработка (DOM scripting, Ajax, UI)
160. Flash & ActionScript
161. Progressive Enhancement & Graceful Degradation
162. Accessibility
163. Usability
164. Информационная архитектура
165. Дизайн пользовательских интерфейсов
166. Визуальный дизайн
167. Логика генерации страниц (ASPX, Rails Views, etc.)
168. Бизнес-логика
169. • XHTML & CSS • Кросс-браузерная и кросс-платформенная совместимость • JavaScript разработка (DOM scripting, Ajax, UI) • Flash и ActionScript • Progressive Enhancement & Graceful Degradation • Доступность использования (Accessibility) • Удобство использования (Usability) • Информационная архитектура • Дизайн пользовательских интерфейсов • Визуальный дизайн • Логика генерации страниц (ASPX, Rails Views, etc.) • Бизнес-логика
170. +
171. Уметь общаться на языке разработчиков и принимать критические интеграционные решения.
172. Хороший клиентский код — это часть задачи.
173. Необходимо, чтобы код взаимодействовал с серверной частью в реальных условиях.
174. Фронт-енд архитектор должен
175. владеть ситуацией на высоком уровне
176. уметь оценить преимущества и недостатки
177. руководствуясь множеством факторов.
179. Умение писать код,
180. проектировать пользовательские интерфейсы,
181. владеть современными технологиями,
182. следить за их развитием
183. обязательные качества специалиста.
184. Будущее профессии
185. Пусть этим занимаются системные архитекторы?
186. Системные архитекторы поглощены техническими аспектами разработки.
187. Когда такие профессионалы будут востребованы?
188. Вчера!
189. Обязательно ли это связано с интернетом и «социальными» или «Веб 2.0» сервисами?
190. Отнюдь!
191. Российский рынок труда
192. Компании не доверяют многопрофильным специалистам и предпочитают нанимать узконаправленных фронт-енд специалистов:
193. графических дизайнеров,
194. кодировщиков HTML/CSS,
195. JavaScript разработчиков.
196. Но!
197. они не смогут решить 100% возникающих проблем.
198. Спрос на фронт-енд архитекторов появится в ближайшее время.
199. Кто-то должен управлять узкопрофильными специалистами, координировать их действия, отвечая за конечный результат.
200. А что сейчас?
201. В настоящий момент явного спроса на фронт-енд архитекторов в России не существует.
202. «Многостаночник» не может хорошо владеть всеми заявленными знаниями.
203. Относительная дороговизна таких сотрудников.
204. Не уделяется должного внимания вопросам usability, user experience, accessibility...
205. Подводя итог
206. Современному фронт-енду требуются свои архитекторы.
207. Чем более сложные приложения будут разрабатываться,
208. тем больше эта потребность будет расти.
209. Отреагировать на изменения рынка — задача сегодняшних специалистов.
210. Спасибо за внимание.
211. Андрей Оконечников andrej.okonetschnikow@gmail.com © Андрей Оконечников, 2007