Блог NunDesign

Вот так, примерно. Это не напрягаясь, не ловила специально. После “публикации” отвлеклась, вернулась к компу, проверила, уже там. Видела значения и поменьше, это если вообще.

Формат - великое дело. Если где-то пишется в одном формате, выйти за рамки иногда (почти всегда) не просто. Думаю, именно поэтому оказалось, что на beta.ya.ru я пишу чаще (а о самой бете уже писала в этом блоге, но с тех пор закрытый и доступный по инвайтам сервис стал открытым), чем здесь, в личном блоге, хотя изначально предполагалось, что кросспоста (и, возможно, изредка - комментариев) из личного будет достаточно. Но всё-таки хочется большего, лучшего.

Вот, к примеру, один из приятных форматов записей - *настроение*, которое можно сменить - хоть несколько раз в день. Пользуюсь возможностью - меняю в зависимости от. Но когда захотелось полистать - как же менялось настроение за последние, к примеру, пару насыщенных разными событиями месяцев… ан нету. “Ленты настроений” - её нет. Поэтому это пока что такой сиюминутный формат, который и портрета-то настроенчиского показать не может. А ведь можно было бы и развить функциональность именно здесь, показывать ленту настроений и своих, и кого-то, кто вдруг стал интересен, из “друзей” или остальных пользователей.

Или вот ещё здоровский совершенно формат записи - “поделиться с друзьями” - та функциональность, которая позволяет перепроцитировать интересный текст из френдленты всем своим “друзьям”. Полезная вещь, но посмотрим с другой стороны. (more…)

Я опять про веб дизайнеров. Предыстория здесь, здесь, здесь и здесь и вообще в этом разделе. В общем, плюс один пришёл вчера, минус один ушёл сегодня. Как-то это печально, хоть и знала, что в период формирования подразделения так и будет, и принято-то из шести пять - что уже не мало, и новые, только пришедшие на свой испытательный срок - вполне, но всё равно не супер как-то. Что-то недорассказала? Плохо поставила задание? В общем, от руководства получила уведомление, что один из дизайнеров не подходит совсем, прощаемся.

Вот и меня достал корпоративный стандарт Сегодня моя рабочая машина будет в состоянии перерождения. Корпоративно обязали поставить всё-таки windows Висту.

Интересно, что за всю мою компьютерную жизнь у меня ни разу не падала винда. Ни 95-я в *95-м, ни 98-я, ни позже NT, ни потом почти год почему-то нелюбимый всеми Me, или 2000, и последняя XP стояла почти два года (почему почти? Таки два) без глюков, тормозов, вирусов и каких-либо обрушений. Что-то со мной не так? В то время как вся окружающая IT-шная публик, в том числе и в нашем офисе, переставлялась не реже чем раз в пол года, я за всё время работы с Win переставлялась исключительно только вынуждено - когда происходили значительные смены оборудования или работы. И здесь сопротивлялась до последнего - зачем что-то менять, если всё и так работает.

А дизайнеры-вебразработчики вообще-то в курсе, насколько нулёвую винду сложно довести до рабочего состояния - бэкапы почты, хистори всякие, профайлы, ручные настройки шорткатов в отдельных программах, шрифты, аккаунты (кстати, обнаружила у себя огромный просто список ftp-аккаунтов в FAR`e - я именно им в основном пользовалась для доступа к данным в качестве ftp-клиента. Потому что ещё есть аккаунты для доступа конкретно к сайтам (где шла удалённая правка), и их тоже ещё надо пособирать по всяким дримвейверам и хомсайтам. Вот уж действительно ftp-беспорядок). Так вот вопрос. Где же у него кнопка? у фара живут эти ftp-аккаунты, можно ли их как-то сбросить одним движением руки в архивный файл? Или копипастить вручную как всегда по одному? Кто знает?

И это ещё хорошо, что достаточное количество сервисов из тех, которые раньше страшно было потерять, вынесены в онлайн. Букмарки (о, раньше копировались из винды/браузера в винду/браузер, да с глюками, ежели в имени букмарка были русские и прочие нестандартные символы) , большая часть почты, некоторая часть документов (спасибо гугл ридеру и гугл докам), rss-читалки, список теперь не надо тягать непонятно как (хотя в опере там хорошие настройки фильтрованные на подписки были, с меточками по самым интересным и полезным чьим-то записям, которые хотелось или попиарить, или проанонсить, или вообще обсудить, но времени не находилось пока, так и висели с меткой “toodoo”).

В общем, все эти переустановки - сплошная головная боль и расстройство. Корпоративный стандарт блин, взялся на мою голову Но. Я в нашем уже давно не маленьком офисе осталась одна такая, непереустановленная пора, брат, пора!

Что представляет проектная матрица

Проектная матрица - простое представление планирующего и организационного фрейма, обеспечиваемого подсистемами и ООА (Объектно-ориентированный анализ). В проектной матрице каждая строка - этап в методе ООА и каждый столбец - подсистема. Ячейки, которые образуются пересечением строк и столбцов, представляют собой отдельные модули работы,которую необходимо выполнить. В результате Вы можете связать некоторые информационные сведения с каждой данной рамкой:

• сотрудники, определённые для выполнения работы, представленной ячейкой;
• рабочие продукты, которые должны быть созданы как результат выполнения работы;
• предполагаемые трудозатраты, требуемые для выполнения работы;
• текущее состояние работы: завершена, выполняется, будет проделана;
• ожидаемые даты начала и конца работы;
• трудозатраты, которые действительно потребовались для выполнения работы.

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

Деятельность при анализе

ООА (объектно ориентированный анализ) является процессом, состоящим из анализационной деятельности, которая требуется для обеспечения формализованных моделей. Процесс описывается во фрейме, данном проектной матрицей.

Строка информационной модели. Работа, связанная с рамкой в строке информационной модели, подразделяется на несколько отчётливых видов деятельности:

• исследование;
• разработка модели;
• интеграция;
• просмотр.

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

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

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

Как только у вас будет довольно законченный проект графической информационной модели, начните подготовку описаний атрибутов и объектов. Эта деятельность может потребовать решений дополнительных вопросов. Продолжите совершенствование модели и исследование вопросов по мере их возникновения до тех пор, пока не выясните все подробности.

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

Интеграция.Как только работа над информационной моделью и связанными с ней текстовыми документами закончена, постройте (или модифицируйте) модель связей подсистем для домена, в котором подсистема содержится.

Просмотр. Вследствии того, что информационная модель - основа для всего анализа и проектирования - ещё создаётся, мы проводим детализированный технический просмотр работы в этой точке. При этом мы преследуем две цели: проверить, что существенные аспекты реального мира были точно сохранены в формальных моделях, и проконтролировать соответствие модели правилам ООА, которые состоят в том, что каждый объект имеет идентификатор, все связи формализованы и описаны и т.д. Команда для просмотра должна, следовательно, включать как экспертов предметной области (для обеспечения первой цели), так и экспертов по моделированию (для второй). Если вы не можете предоставить экспертов предметной области для просмотра, замените их аналитиками, не работавшими над этой частной моделью. Снабдите аналитиков-рецензентов техническими замечаниями, которые могут в дальнейшем использоваться как описание действительности, с которой сверяется модель.

Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, - это разработка модели, вериикация взаимных действий, интеграция и просмотр.

Разработка модели. Начните работу с моделью состояний эскизной зарисовкой грубой модели взаимодействия объектов для установления иерархического представления объектов. Затем формируйте одну за другой модели состояний и накапливайте в процессе работы список событий. Может быть, будет необходимо провести некоторые дополнительные исследования, чтобы определить тонкости поведения различных объектов.В таком случае запишите полученные сведения в технические замечания.

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

Чтобы сделать более ясной корелляцию информационной модели с моделями состояний, многие аналитики используют возможность видоизменения планировки информационной модели, чтобы она соответствовала планировке модели взаимодействия объектов.

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

Интеграция. Как только модели состояний и модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.

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

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

Разработка модели и интеграция. Разделите работу так, чтобы каждый аналитик отвечал за создания ДПДД* для некоторого количества моделей состояний. Во время этой работы каждый аналитик может поддерживать отдельную таблицу процессов состояний. Когда ДПДД* закончены, объедените отдельные таблицы процессов состояний и устраните все расхождения в именах и идентификаторах процессов. Затем создайте модель доступа к объектам для подсистемы и модифицируйте модель доступа к подсистемам для всего домена.

Просмотр. Просмотрдля рамки моделей процессов даёт возможность убедиться в том, что действия моделей состояний точно отображены на ДПДД*. Поскольку никакой новой информации по предметной области на этом этапе не поступает, верификация лучше всего выполняется аналитиками.

—
* ДПДД - Action data flow diagram - диаграмма потоков данных действий.

—
Источник: Объектно-ориентированный анализ: моделирование мира в состояниях.
Авторы: Салли Шлеер, Стефан Меллор
Книга издана в 1993-м году, на счёт переизданий - не в курсе; посвяцена изложению самых первых этапов процесса разработки сложных (программных, технических и других) систем.

Как много конкурсов для пишушей братии организовывается последнее время. До середины ноября будут вычисляться победители конкурса копирайтеров, объявленного ещё летом, Интернетные штучки и Лайфхакер провели совместную акцию–конкурс, «Осеннее постописательство»; Владимир Жилинский анонсировал Конкурс конкурентов для пишущих о компьютерах и IT блоггеров; Дмитрий Чистов, директор по внешним связям “Бегун”`а, объявляет следующую тему: Конкурс: Маркетинг блогов. “Пришлите небольшой рассказ о том как вы раскручиваете свой блог и каких результатов добились на этом поприще на dima@chistov.net. В сабже поставьте пометку “конкурс”. Самые интересные и подробные истории попадут в финал и победитель определиться голосованием читателей. Обещаю к этому событию установить на свой WordPress плагин голосовалки. Возможно, что победитель будет не один. И, собственно, победитель/победители получат в качесте приза небольшой рекламный бюджет в Бегуне.” - Мне кажется будет интересно, очень хотелось бы в свою очередь почитать рассказы участников. Даже попыталась было подать заявку на участие, только вспомнила вовремя, что пока ещё свой блог никак не раскручиваю… всё собираюсь. Пишу потихоньку, ну и, пожалуй, всё, на этом моё участие в “раскрутке” блога заканчивается, т.е. рассказать-то и нечего..

И вот новый конкурс объявлен у Miku - Стань Интервьюером! - для участия в нём достаточно взять интервью в любом формате (текст, аудио или видео запись) у любого интересного вам человека (вовсе не обязательно у публичной личности. Главное, чтобы вопросы-ответы были на самом деле интересными). Ограничение только в том, что к участию не принимаются работы (интервью), ранее где-то опубликованные.

Дальше - просто: текст интервью должен быть где-то опубликован (на блоге, на форуме, на любом ресурсе) с пометкой “интервью взято специально для конкурса…” и ссылкой на страницу конкурса http://miku.ws/20070920/konkurs-stan-intervyuerom/. Заявки-интервью принимаются до 21 октября (включительно). После 21 октября члены жюри будут оценивать все заявленные интервью и голосовать за понравившиеся 3 интервью, распределяя между ними призовые места. Призовой фонд уже прилично так сформирован, так что участие в конкурсе может быть не только интересным развлечением, но и прибыльным.

Посмотреть на Яндекс.Фотках

Ещё одно значительное мероприятие ожидается в Москве в первых числах ноября, о чём прислала пресс-релиз Ирина Матвиенко:
—
В этом году в России впервые будет проведена международная конференция User Experience Russia 2007, приуроченная ко Всемирному Дню Юзабилити. Основная тема докладов конференции - юзабилити электронных технологий.

Мероприятие ориентировано на разработчиков интернет- и мобильных приложений, дизайнеров, тестировщиков, проектировщиков, владельцев интернет-ресурсов и всех тех, кто заинтересован в том, чтобы компьютерные технологии стали ближе и понятней пользователям. Основные направления конференции: E-government и общедоступность, Mobile Experience, Интранет, Методология юзабилити, Юзабилити в Интернет.

Доклады представят лучшие мировые специалисты в области юзабилити, руководители и эксперты из Microsoft, Google, Вымпелком, 1C, представители профессиональных ассоциаций UPA, ACM SIGCHI, Союза Вебмастеров России. Кроме того, на UE 2007 будет работать выставка, на которой производители оборудования и ПО для проектирования и юзабилити тестирования расскажут о преимуществах своих продуктов и продемонстрируют их в действии.

Всемирный День Юзабилити (World Usability Day) - это ежегодный праздник, основанный в 2005 году. “Как сделать интерфейс удобнее?” “Может ли система работать лучше?” Со дня основания Дня Юзабилити по всему миру проходят мероприятия, которые и помогают ответить на эти, а также многие другие вопросы, затрагивающие тему простоты использования продуктов и услуг.

В прошлом году Всемирный День Юзабилити имел огромный успех во всем мире. Было проведено около 225 мероприятий в 175 городах, в 35 странах. В них приняли участие более 40 тысяч человек.

В 2007 году планируется увеличение количества мероприятий, приуроченных ко Дню юзабилити. В России этому празднику впервые будет посвящена трехдневная конференция User Experience Russia 2007, освещающая большое количество самых актуальных вопросов usability и accessibility.

Мы приглашаем принять участие во Всемирном Дне Юзабилити в России всех, кому интересны технологии, призванные приблизить компьютерные разработки к пользователю. User Experience Russia 2007 пройдет с 8 по 10 ноября в гостинице “Рэдиссон САС Славянская”. Ознакомиться с программой мероприятия и зарегистрироваться вы можете на сайте http://userexp.ru/

Контактная информация:
Ирина Матвиенко,
тел.: +7 (495) 775-1543
org@userexp.ru
www.userexp.ru

Пришедшие летом-осенью дизайнеры старательно рисуют и верстают (и учатся верстать грамотно), но мы всё равно не успеваем, не справляемся, затыкаемся. В основном проблема на сложных участках: в большом .Net`овском проекте работы для как бы “дизайнера” очень, очень много, но ни одного из тех, кто уже есть на этот проект поставить не могу. Рисующим - так уже нарисовано всё. Верстающим - так порезка нарисованного тоже уже закончилась. Как назвать часть работы с интерфейсом, когда идёт даже не адаптация под движок, а такое совместное создание движка?

Вот, к примеру, есть “страница”. У неё в реальности контента много, но живёт он большей частью в скрытых блоках и показывается по событиям или генерится и выводится в зависимости от разных условий. “Дизайнер” здесь предподготавливает только общую модель данных (блоки, поименованные идентификаторами - те, к которым вызов, и внутренняя подструктура блоков), и к ней пишет таблицу стилей - оформление ссылок, кнопок, предоформление в css всех графических блоков, дизайнер же планирует сценарий поведения на этой странице в соответствии со своим представлением о юзабельности и знанием пожеланий заказчиков. Т.е. если грубо, я подхожу к программеру, отвечающему за этот фронт работ, и рассказываю ему, что: вот есть такие ссылки (список), по клику на каждую из них происходит следующее: в блоке контента этот контент скрывается, этот показывается, эта картинка меняется на другую (вернее нет. Это имя [класса/идентификатора] меняется на соответствующее вот это), а в подменюшке здесь меняем маркер на этот (тоже имя класса). Я просто не могу поручить эту работу никому из работающих дизайнеров - они так не смогут. И, самое обидное, что и руководству я объяснить не умею - что здесь нет ни порезки, ни рисования, а в ответ получаю, что шесть дизайнеров - и вы НЕ УСПЕВАЕТЕ? Чувствую себя по уродски. Понимаю, что не справляюсь - не только с дизайнерской частью работ (здесь просто вопрос времени, верстаю я быстро, но объёмы есть объёмы), но скорее с организаторской.

Да, в комментариях к предыдущим постам (прошлому, к примеру, или более давнему) темы было о том, что сразу надо брать профессионалов, пусть дороже - но профессионалов. Да как бы здесь руководство было не сильно против - всем повысили зарплату и подняли “входную” планку. Но - может офис у нас в нездоровом месте? Выбрала лучших из приходивших. А работать быстрее не стали, во всяком случае не на столько, как ожидалось. Почти паника (что же делать, что же делать…) . Вакансия (на хорошего дизайнера, хорошего верстальщика) всё ещё открыта. Специфика для верстальщика - это .Net и работа в M$ VS. Честно скажу, не вижу большой проблемы с платформой - если есть опыт работы с большими php, с java, то ознакомиться с особенностями дотнета - дело одного рабочего дня и по мелочам - по ходу работы (куда же без реальной практики). У меня тоже не было именно этого опыта полтора года назад. Но я пришла, и начала работать без инструкторов, без страховки, одна. Значит, теоретически, смогут и другие, было бы желание.

Ещё раз посмотрела текст дизайнерской вакансии. Добротно так написано, солидно, внушает. Может, надо как-то по-другому, другими словами? Чтобы обратили внимание именно те люди, которые нужны, чтобы заинтересовались и пришли, наконец-то, чтобы стыдно не было перед руководством, и не приходилось защищать их, объяснять начальству, почему вся эта компания “специалистов” не может сделать *эту* работу быстро и качественно, и почему я опять, одна в (именно этом) проекте, сижу в офисе по 12 часов. И, разумеется, конечно же надо долго отчитывать меня за то, что в координатах забыли поменять номер офиса с ***1 на ***7 (никто даже не обратил внимание на объём работ по созданию FAQ`а, сплошь динамичного документа, в котором информация разбита по рубрикам, внутри рубрики список вопросов со скрытыми ответами, которые при клике показываются каждый при своём вопросе, и при этом маркер вопросов меняется с плюса на минус, свой маркер отмечает выбранную рубрику и кучу ещё дополнительных чисто сценарных элементов поведения, и на объём работ по парочке других, так же достаточно грандиозных страниц).

Обращаю внимание на вакансии “по теме”, собираю себе в блокнотик. Вот, к примеру, то объявление, где Макс Россомахин посоветовал клонировать Макеева (заодно и попиарю объявление, сообщество ru_webdev и самого pepelsbey`a): (more…)

Недавно один из наших программеров в личке поделился сокровенным: оказывается во многих софтконторах, где уровень проектов плюс-минус приближен к нашему, одно из важных требований к программерам - обязательное знание html (xhtml)+css на достаточно глобальном уровне! Надо же… Раньше на эту тему никто у нас и не задумывался, а тут вдруг попёрло что-то, да ещё и подхлёстывается неожиданными дискуссиями в тему “разделения/распределения обязанностей”.

У наших программеров (.NET) такого требования не было и на собеседованиях никто ничего по теме вёрстке у них не спрашивал - основная среда разработки - M$VS, и знания тестировались только возвышенно-программерские. Вёрстку, как следствие, в большинстве своём публика знает только в первом приближении, и в том случае, когда начинается работа с интерфейсом и публике всё же приходится свои рабочие контролы как-то размещать на странице, они городят совершенно безумный код, разумеется, не ручками, а в режиме “design” - этого лучше не видеть, скажу только, что, когда я получаю в работу очередную страницу, основное время уходит на удаление всего того кода, который там предусмотрительно набодяжен.

Клиенты ныне настолько разбалованные аяксом, что требования к интерфейсам (во всяком случае служебным интерфейсам на сервисы) у них довольно масштабные, посему в конторе очень много используют как готовых решений типа telerik, RadControl и иже. Деревья, закладки (имитация виндовых “табов”), хитрые “комбобоксы” с расширенной функциональностью и прочее, и прочее. Иногда прокатывает - просто взять готовое и - напильником (в том числе и визуал), иногда так складывается, что напильником приходится из подводной лодки допиливать реактивный самолёт, и, оценив масштаб /когда готовый контрол доработать теоретически реально, но, для узкой задачи он, с одной стороны, является избыточным и тяжеловесным, с другой стороны - ковыряться детальнейше в больших объёмах чужого кода - то ещё удовольствие/, принимаем решение делать свой контрол (но на это понадобится, к примеру, один рабочий день. Как правило это самое трудное - выбить этот самый один рабочий день). (more…)