Архив рубрики: Разработка и управление

Воспоминания об опыте взаимодействия (проектирование интерфейсов)

Опубликовано автором
Добавить комментарий

Оригинал статьи тут

Перевод на русский

 Что мне здесь понравилось (было интересно).

Обоснование смещения фокуса с опыта взаимодействия с интерфейсом на ВОСПОМИНАНИЯ об этом опыте…Оказывается — это "две большие разницы".

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

У человека присутствует два Я: Читать далее →

jQuery календарь — пригодится!!!

Опубликовано автором
Добавить комментарий

jQuery Datepicker. Основан на jQuery UI Datepicker, но отделён от него в связи с тем, что разработчики jQuery UI Datepicker захотели более простой функционал. То есть данный плагин обладает дополнительными функциями, которых у первого нет. Перечислять их нет смысла, нужно смотреть. Пробегитесь по ссылке с примерами по различным вкладкам и сами поймёте. Его возможности очень и очень радуют.

Пример

Исходник

 

А здесь еще дофига всяких  http://shublog.ru/ajax/jquery/jquery-calendars-and-datepickers/

Сто правил руководителей проектов NASA

Опубликовано автором
Добавить комментарий

Джерри Мэддон

Источник: Профессионал управления проектами

Документ подготовлен Джерри Мэддоном (Jerry Maddon), ассоциированным директором Директората полётов Годдартовского центра космических полётов NASA. Джерри собрал эти драгоценности мудрости за много лет из разнообразных источников. Они были отредактированы Родом Стюартом (Rod Steward) из Mobile Data Service из Хантсвилла в Алабаме (Huntsvill, Alabama),. 1 января 1995 года. Обновлено 9 июля 1996 года. Переработано и отформатировано Оливером Ф. Леманом (Oliver F. Lehmann, Ismaning, Germany (http://www.oliverlehmann.com/).

Оригинальный источник: uc-adc1.uc.utoledo.edu/100_rules.html Читать далее →

Структура проекта Android

Опубликовано автором
Добавить комментарий

 

AndroidManifest.xml — основной конфигурационный файл приложения (файл манифеста);

• default.properties — сгенерированный файл сборки, используемый Eclipse и плагином ADT. Не редактируйте его;

• /src — папка, в которой хранится весь исходный код;

• /src/com.androidbook.droidl/DroidActivity.java — главная точка входа приложения — деятельность DroidActivity. Эта деятельность была определена как деятельность запуска по умолчанию в файле манифеста Android;

• /gen/com.androidbook.droid1/R.java — сгенерированный исходный файл управления ресурсами. Не редактируйте его; ;

• /assets — папка для хранения ^скомпилированных файлов ресурсов проекта;

• /res — папка, необходимая для управления всеми ресурсами приложения. Ресурсы приложения включают анимацию, графические объекты, файлы макетов, данные строкового и числового типа, а также подключаемые файлы;

• /res/drawable — графические ресурсы приложения (значки) разных размеров;

• /res/layout/main.xml — файл макета, используемый деятельностью DroidActivity для прорисовки экрана;

• /res/values/strings.xml — строковые ресурсы.

реакция на изменения

Опубликовано автором
Добавить комментарий

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



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

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

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