Comments 17
Буквально вчера закралась мысль сделать свой фреймворк, есть над чем подумать. Спасибо за отличную статью.
Пожалуйста, эта статья родилась после бесед с различными дизайнерами-голландцами (я сейчас в командировке у них), есть очень много специфики в оценке работы фронт-энд-разработчиков здесь, все озабочены поиском вдохновения в искусстве, особенно современном, постами вроде: www.smashingmagazine.com/the-death-of-the-blog-post/, все понимают, что затраты на типичные решения должны быть минимизированы, чтобы позволить кодерам и дизайнерам как можно чаще выходить за привычные рамки, их «отжигание» на проектах становится необходимостью
Все верно пишете. Фрейворк — это именно показатель того, в какую сторону идет команда как команда. Последнее время часто вспоминаю грабли и наработки прошлых лет, и этот подмеченный Вами факт многое объяснил.
Несмотря на опыт велосипедиста, мне не приходила в голову мысль численной оценки полезности фреймворка, за идею спасибо. Хотя мне ближе оценка «сэкономленного» благодаря фреймворку кода (тут как бы подразумевается, что временнАя оценка по Вашему рецепту — уже хорошая).
Несмотря на опыт велосипедиста, мне не приходила в голову мысль численной оценки полезности фреймворка, за идею спасибо. Хотя мне ближе оценка «сэкономленного» благодаря фреймворку кода (тут как бы подразумевается, что временнАя оценка по Вашему рецепту — уже хорошая).
Просто сэкономленный код интересует разработчиков и всех, кто внутри разработки, а бизнес (и всех, кто снаружи) интересуют только монетизируемые параметры, кот. в первую очередь являются сэкономленные человеко-часы, которые должны оправдать инвестированные человеко-часы в разработку фреймворка, эта оценка для убеждения в первую очередь тех, кто снаружи
Кстати, (имхо) блог Вы выбрали неудачный, тема более глобальна, чем пользовательские интерфейсы и касается не только фронт-енда. Скорее, сюда относится приведенный Вами пример.
род мой деятельности завязан на интерэкшн-дизайн, не решился играть на неродном поле, где не знаю подводных течений, пост на самом деле про психологию коллективного творчества и как её «инсталлировать» в команде (дизайнеров-кодеров)
Статья весьма плотно набита информацией и поднимает интересную тему — автору спасибо! Но написана несколько сумбурно — нет четкой постановки задачи и четких путей решения. Я понимаю, что она дискуссионная, но в этом случае структура статьи все же должна быть явно выраженной — тогда будет проще комментировать те или иные выкладки автора.
А вообще мне кажется сомнительной идеей, что все именно фреймворк является центром вселенной разработки, то есть, получается некий framework-oriented design. Все же фреймворк это внутренний артефакт разработчика, пользователь сталкивается с его внешним проявлением, но не более. Не может фреймворк являться движущей силой проектирования интерфейсов.
А вообще мне кажется сомнительной идеей, что все именно фреймворк является центром вселенной разработки, то есть, получается некий framework-oriented design. Все же фреймворк это внутренний артефакт разработчика, пользователь сталкивается с его внешним проявлением, но не более. Не может фреймворк являться движущей силой проектирования интерфейсов.
я боялся написать роман и отпугнуть «неосиливаемостью из-за многобуковости», в каждое предложение запакованы 1-2 абзаца рассуждений-разговоров, я расчитывал, что какие-то из них вызовут прямые вопросы, тогда в комментариях я раскрою больше информации; здесь фреймворк — это как сеты ди-джея, каждый разработчик работает над своей «музыкальной» темой, но редко кто слышит, как звучит их материал, когда всё сводится в единую композицию, тут мысль в том, чтобы разобраться с «попсовой» частью и начать ориентироваться в своих сочинениях на общую созвучность; спасибо за критику, никак не могу найти формат поста, чтобы и всё расскрыть, и не быть косноязычным и ясности было больше, чем запакованности; опять-таки пост называется приближение, т.е. мысли в направлении того, чем может быть фреймворк
Жду хорошей статьи с разархивированными смыслами :), а также с разбитием на главы, а если еще будут и иллюстрации в виде интерфейсов, то цены ей не будет.
ок, найти бы толковую книжку по стилистике русского языка, что-нибудь для журналистов, пишущих для технических изданий
Кто-то уже спрашивал об этом в Хабре. Попробую сформулировать собственный подход:
1. Определиться с целями статьи. Их не должно быть много — от одной до трех, максимум. Цели вам помогут выкинуть лишнее и добавить недостающее.
2. Сделать скелет статьи в виде заголовков неких смысловых блоков. Каждый следующий блок должен плавно вытекать из следующего (логически связан). При этом автор идет от общего к частному (в текущей версии статьи общее и частное тщательно перемешано, как в блендере).
3. Желательно использовать трехчастную структуру повествования — вступление, завязка и катарсис (разрешение).
— Во вступлении мы вводим читателя в контекст статьи и сообщаем нечто достаточно понятное сразу. Если автор применяет некую специальную или неустоявшуюся терминологию, желательно дать краткие определения.
— В завязке мы ставим проблему (проблемы) — заинтересовываем читателя, чем больше читатель знаком с проблемой тем больше шансов, что он будет читать дальше.
— В катарсисе мы показываем как эти проблемы разрешаются.
Желательно в самом конце сделать краткие выводы из статьи. Эти же выводы можно поставить, наоборот в самом начале статьи, чтобы читатель мог понять — интересна ему вся статья или нет? Еще этот блок поможет блоггерам, которые смогут выводы быстро поставить его в качестве цитаты внутри своих сообщений по поводу вашей статьи. То есть в этом случае повышается шанс, что обсуждение вашей статьи разойдется по сети.
1. Определиться с целями статьи. Их не должно быть много — от одной до трех, максимум. Цели вам помогут выкинуть лишнее и добавить недостающее.
2. Сделать скелет статьи в виде заголовков неких смысловых блоков. Каждый следующий блок должен плавно вытекать из следующего (логически связан). При этом автор идет от общего к частному (в текущей версии статьи общее и частное тщательно перемешано, как в блендере).
3. Желательно использовать трехчастную структуру повествования — вступление, завязка и катарсис (разрешение).
— Во вступлении мы вводим читателя в контекст статьи и сообщаем нечто достаточно понятное сразу. Если автор применяет некую специальную или неустоявшуюся терминологию, желательно дать краткие определения.
— В завязке мы ставим проблему (проблемы) — заинтересовываем читателя, чем больше читатель знаком с проблемой тем больше шансов, что он будет читать дальше.
— В катарсисе мы показываем как эти проблемы разрешаются.
Желательно в самом конце сделать краткие выводы из статьи. Эти же выводы можно поставить, наоборот в самом начале статьи, чтобы читатель мог понять — интересна ему вся статья или нет? Еще этот блок поможет блоггерам, которые смогут выводы быстро поставить его в качестве цитаты внутри своих сообщений по поводу вашей статьи. То есть в этом случае повышается шанс, что обсуждение вашей статьи разойдется по сети.
Еще один подход от НЛП-практиков. Как простейший вариант — проходитесь по каждому пункту в этом же порядке, но можно и поменять местами. В результате получится подать тему достаточно широко.
Итак:
1. Определяете проблему — то, что побудило Вас написать статью
2. Можно копнуть вглубь и подумать над причинами данной проблемы, но не всегда обязательно.
3. Определяете результат, которого хотите достигнуть
4. Описываете Ваше решение — то, что превращает проблему в результат.
5. Обязательно рассмотреть, какие дополнительные эффекты возникнут благодаря такому решению. Они могут быть как положительными, так и отрицательными.
Фактически это модель SCORE, при помощи которой удобно систематизировать информацию. Никто не мешает использовать ее не для сбора информации, а для ее подачи :) Если интересно, копните гугл за примерами, ну или в личку.
Итак:
1. Определяете проблему — то, что побудило Вас написать статью
2. Можно копнуть вглубь и подумать над причинами данной проблемы, но не всегда обязательно.
3. Определяете результат, которого хотите достигнуть
4. Описываете Ваше решение — то, что превращает проблему в результат.
5. Обязательно рассмотреть, какие дополнительные эффекты возникнут благодаря такому решению. Они могут быть как положительными, так и отрицательными.
Фактически это модель SCORE, при помощи которой удобно систематизировать информацию. Никто не мешает использовать ее не для сбора информации, а для ее подачи :) Если интересно, копните гугл за примерами, ну или в личку.
Sign up to leave a comment.
Приближение к front-end-фреймворку