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

Transcript

1. Профессия «front-end архитектор» © Андрей Оконечников, 2007

2. Слово.

3. Слово.

4. Слово.

5. spacer.gif

6. И началась эпоха веб-дизайнеров.

7. Дизайнер- ремесленник

8. Фокусируясь на том, как сайт выглядит, дизайнеры часто забывают о

   целях и задачах.

9. Cайтом должны пользоваться люди,

10. искать и находить,

11. делать покупки,

12. читать новости,

13. участвовать в обсуждениях.

14. Стремление быть оригинальными приводит

15. к необычным результатам...

16. None
17. None
18. None
19. None
20. None

21. Дизайн ради дизайна

22. не ради пользователей

23. не ради их целей и задач

24. не ради удовлетворенности продуктом или услугой

25. 10 фишек

26. Почему так происходит?

27. Очень часто дизайнеры думают...

28. результат их работы — самый важный.

29. Это не так!

30. Графический дизайн — лишь один из аспектов веб-разработки.

31. Такой же, как

32. usability,

33. accessibility,

34. семантика,

35. и контент.

36. Немногие дизайнеры пишут код разметки страниц.

37. Поэтому...

38. После создания макетов, дизайнер выводится из проекта,

39. а реализацией занимаются другие люди...

40. Дизайнер теряет контроль над конечным продуктом.

41. None
42. None

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. Сегодняшняя веб- разработка немыслима без использования серверных фреймворков

69. None
70. None

71. призваны упрощать и ускорять разработку и отладку веб-приложений.

72. Усложняется логика работы приложений.

73. Растут объемы данных.

74. Это сделало стандартом «де-факто» наличие в проектах системного архитектора.

75. системный архитектор

76. Использование серверных фреймворков предполагает, что

77. разработчик должен больше думать о логике приложения, красоте своего кода,

    его объектной модели

78. нежели о деталях реализации под различными браузерами и платформами.

79. Но!

80. Результат работы фреймворка не всегда идеален и зачастую должен быть

    откорректирован.
81. None

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 архитектор

151. None
152. None
153. None
154. None
155. None

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. руководствуясь множеством факторов.

178. None

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