Website Wireframe Prototyping With WikidPad
Все написанное справедливо для версий 1.8. В 1.9 и позже могут отличаться клавиатурные шорткаты, других отличий пока не заметил.
TOC:
2009-01-07 22:06:55 (W01)
Pros & Cons
pros:
Пробовал прототипировать в простейшем HTML -- это самый простой и естественный вариант, первым приходящий в голову. Но никогда не нравилось это делать, очень быстро становилось неудобно. И понятно, что из-за include и подобных вещей желательно сразу делать в своем движке, располагать файлы примерно там, где они и будут находиться, перемещаться по ним и думать уже не в терминах идеи, а в терминах реализации. Это убивало фантазию и прототипирование очень быстро -- по сути, проще было сразу начинать делать черновик приложения, а это немного другое. Для меня прототипирование -- это скорей порхание и расстановка идей то там, то здесь, их связи. А детали реализации очень мешают.
Опыт прототипирования на бумаге
Бумага и ручка/карандаш. Тоже не складывалось с ними. Интерфейс и расположение вторичны, и само очерчивание прямоугольничка "здесь будет страница... э-э-э..." уже вносило в процесс мышления какую-то даже не запятую, а целый пробел со знаком вопроса. Или даже многоточием. Это сбивает. Появляющиеся идеи только поначалу легко добавлять -- потом все сложнее и сложнее. С WikidPad'ом оказалось очень просто, проще, чем я думал. Некоторые моменты вообще удивили: скопировав блочок описания позиции общими словами и попробовав его разукрасить реальным примером, быстро нашел и переставил местами несколько частей -- стало гораздо лучше! На бумаге этого бы не стал делать. Или внесение изменений было бы делом непростым (перерисовать или раздвинуть-втиснуть, или переклеить). То есть эти изменения делались бы позже, на каком-то другом этапе, может быть тогда, когда это уже не слишком удобно: переставить местами, вписать в дизайн... Сколько раз так уже было! Может не удастся сейчас это толком описать, но думаю понятно, о чем речь.
Обустройство WikidPad
Рекомендую делать прототип в отдельной вики. И даже если для проекта используется своя вики, отдельная от основной и единственной, прототип делать лучше рядом с ней, но отдельно от записей по проекту и ТЗ. В этом есть недостатки (тудушки не в одном месте, а в двух), но мне пока сделать именно так кажется правильным.
Создавая вики, указываем папку с технической документацией по проекту -- в ней автоматически будет создана папка с названием вики (допустим, WebSitePrototype -- так можно называть все прототипы в разных проектах), а в ней -- всё необходимое.
Рекомендую при создании использовать формат ORIGINAL SQLITE, а не COMPACT! Все страницы будут храниться в отдельных текстовых файлах рядом с базой-индексом.
+ Wiki Settings
These are your default global settings.
[global.importance.low.color: grey]
[global.importance.high.color: red]
[global.importance.high.bold: true]
[global.contact.icon: contact]
[global.font: Verdana]
[global.todo.bold: true]
[global.todo.icon: pin]
[global.priority.1.color: red]
[global.priority.1.bold: true]
[global.priority.2.color: orange]
[global.priority.2.bold: true]
[global.priority.3.color: grey]
[global.priority.3.bold: true]
[global.priority.4.color: grey]
[global.priority.4.bold: false]
[global.wrap: 256]
[global.Current.urgent.color: red]
[global.Current.thisweek.color: lime green]
[global.someday.color: dim grey]
[global.tickler.color: grey]
[global.complete.color: light grey]
[icon: cog]
[global.import_scripts: GlobalScripts]
Глобальные привычки
Пусть войдёт в привычку перетаскивать используемые в вики картинки и файлы, используя Ctrl + drag'n'drop. Скриншоты, сканированные эскизы бумажных страниц. Это совет вряд ли для wireframe prototype, но wireframe вполне можно продолжать использовать и в качестве инструмента для storyboarding, и вообще в качестве техзадания на разработку сайта. Перетаскиваемые таким способом файлы будут при этом скопированы в папку files (создастся автоматически) рядом с папкой data, а ссылки будут относительными.
В документации (в основной вики) ставим ссылку на прототип (drag'n'drop файла с расширением .wiki, который располагается в указанной директории рядом с папкой "data"). Получтся что-то вроде этого:
wiki:///D|/PROJECTS/mega-website/WebSitePrototype/WebSitePrototype.wiki
а прототип будет открываться в новом окне.
Стартовую страницу оформляем примерно так:
Открываем Func. Pages / Global Text Blocks и дописываем выделенную строчку (третья сверху):
Продолжаем знакомство с полезными для прототипа возможностями
Здесь сделаем лишнее действие для иллюстрации пары полезных особенностей WikidPad. Пишем в любом месте страницы внутри квадратных скобок: [alias: NavMenu]
Переходим на HomePage.
Устанавливаем курсор под заголовком (здесь у нас наверняка будет горизонтальное меню, да?) и выбираем из меню WikidPad: Editor / Text blocks / include page. Мне удобней делать это на клавиатуре: Alt-E, T, T, Enter. Дальше по обстоятельствам, меню у всех может быть разное.
Узнаёте? include page -- это то, что мы писали в Global text blocks, а то, что пападёт на страницу, было написано после ";a=".
Переключаемся в Preview (Ctrl-Tab или по вкладкам вверху окна редактирования).
Во-о-о-т.
Что имеем? Включено содержимое страницы NavMenu. По Ctrl-O в режиме редактирования можем видеть как NavMenu, так и NavigationHorizontal. При этом физически у нас существует только страница NavigationHorizontal.
Это была иллюстрация прелестей alias'ов. Их при необходимости можно создать сколько захочется: например, русские и английские синономы названий страниц, если лень переключаться между раскладками и голова думает периодически на разных языках. Но это -- при необходимости. Подумайте: оно вам надо, зоопарк разных вариантов? Лучше с головой договориться. Но если надо -- делайте.
Если при дальнейшей работе стойкие ассоциации при поисках страниц не совпадают с тем, как назвали её вначале -- смело переименовывайте. Ctrl-Alt-R на переименовываемой странице. WikidPad спросит и найдёт-переименует все существующие ссылки на эту страницу.
И ещё одна иллюстрация удобств WikidPad. Возвращаемся на HomePage в режим редактирования, оставляем от слова NavMenu в инструкции по вставке страницы только Nav, и когда курсор находится после "v", нажимаем Ctrl-spacebar. Выпадающий список предложит существующие подходящие варианты. Удобно? Восхитительно! Отсутствием этой подсказки меня мучают веб-реализации вики-движков.
Если все понятно, можно убрать из меню мешающий там алиас. И вставить меню на всех основных страницах.
Как организовать работу с задачами
todo (задачи, тудушки с приоритетами, тудушки с датами)
Это у нас будут конкретные задачи по уточнению прототипа, заметки для себя "не забыть потом сделать здесь ЭТО", а после окончания работы с прототипом -- задачи по реализации. Об этом было сказано в самом начале, в секции "Обустройство WikidPad".
Итак, прототип не закончен, фантазия хлещет, на мелочах останавливаться неохота: пишем todo: описать подробней на обделенной вниманием странице и продолжаем творчество дальше. Когда экстаз спадёт, идём на спецстраницу ToDo (ей занимается плагин WikidpadTodoExtension) или в ветку дерева Views / todo, и последовательно занимаемся зачисткой хвостов.
Когда работа над прототипом кажется завершенной, ходим по нему, и периодически возникают мысли: "Здесь надо будет сделать то и сё". На этом этапе уже можно думать о приоритетах, поэтому тудушки лучше сразу сопровождать полезным суффиксом. Пишем на странице(-ах): todo.1: то и todo.2: сё. Или расставляем тудушки перед написанными ранее мыслями.
И запомним: приоритет пишем сразу после слова туду. Там на самом деле можно что угодно писать, будет группироваться. Основное, что надо запомнить: чем меньше, тем лучше.
В результате появится следующая картина для обзора:
(Приоритет 4 -- это неважно и несрочно. Так в прототипе сразу же помечаются особенности, про которые мысль проскочила, но было понятно: делать их в первой версии нет никакого смысла.)
Может и будут. Только позже.
Вообще всё то же самое, что и с тудушками, только доступны исключительно в дереве слева.
Если вы менеджер и управляете работой нескольких разработчиков
Тогда на страницах ToDoCalendar и ToDo увидим следующее:
и
Экспорт в HTML
Я предпочитаю экспорт всей вики в формате многостраничного HTML.
TOC:
- Pros & Cons
- Опыт прототипирования в HTML
- Опыт прототипирования на бумаге
- Обустройство WikidPad
2009-01-07 22:06:55 (W01)
Pros & Cons
pros:
- в отличие от прототипирования в HTML нет отвлечений на правку и просмотр-навигацию и на мелочи оформления HTML, которые хоть и мелкие, но понемногу сбивают. Здесь правка и просмотр большую часть времени ничем не отличаются, а в моменты просмотра "как в броузере" мгновенны и на том же месте: не происходит переключений контекста между редактором/броузером, остаешься "в потоке";
- нет перескоков внимания между плоским списком файлов-страниц и сетью взаимосвязанных страниц, нет никакого диссонанса, голова думает ассоциациями и связями и не отвлекается на реализацию и вопросы "где это расположено";
- легко помечать тудушками то, что нужно не забыть (а сейчас не отвлекаться, чтобы не забыть все возникшие мысли). Это заодно дает возможность не выпадать из потока, когда идеи на ходу возникают: сюда и сюда изменения добавим (например, в профайле надо не забыть, и еще в одном месте отображать новую инормацию), если их много -- никуда не переключаешься между страницами для правок, а возникшие мысли коротко записываешь списком, и тудушками метишь. А разнести можно позже;
- есть include, можно включать контент других страниц (меню вынести, некоторые части похожих по сути страниц -- функционал хранится и разрастается в одном месте, очень понравилось дополнять: все похожести быстро обнаружились, вспомнились, и были быстро объединены и перенесены в несколько блоков, "за скобки");
- идеи возникают по ходу дела просто фонтаном, и их легко добавить сразу же; с бумагой и HTML это обычно тормозилось или становилось неопрятной кучей, в которой сложно ориентирваться;
- нет нужды отсекать в прототипе идеи, которые будут реализованы позже (а сначала прекрасно понимаешь, что их не будет в первых версиях): просто записываешь ВСЁ, и тут же помечаешь это как "todo.4" (приоритет 4 -- это неважно и несрочно). Идеи останутся и будут развиваться на нужных местах, не будут забыты и будут размещены в разных местах прототипа сопутствующие настройки;
- наряду с todo можно использовать ключевое слово issue, чтобы пометить особенности, реализуемые на 1-ом, 2-ром, 3-ем этапах развития проекта;
- прототипирование на бумаге затруднено необходимостью перерисовывать замусоренный рисунок, в WikidPad перекомпоновка происходит естественно и быстро;
- техническое: легкая переносимость между платформами (WikidPad вроде бы существует под Win/Mac/Linux);
- техническое: легко хранить прототип и синхронизировать изменения в SVN (если база wikidpad = original_sqlite);
- техническое: удобные варианты экспорта в HTML (можно отдавать пользователям на тестирование, потестировать интерфейс на смартфоне и КПК хоть в оффлайне, хоть на любом, даже самом простом, хостинге);
- в отличие от бумаги, для которой нужно много места при фантазии и правках/перекладываниях-переклейках, WikidPad более компактен. Я иногда вообще на КПК в аутлайнере прототипирую рядом с записью идей, если муза нагрянет на прогулке или в дороге: это, конечно, не вики, но легко копируется на десктоп.
- немного вспомогательно-обслуживающих действий есть, в специализированных визивиг прототайперах этого наверняка можно было бы избежать совсем:
- инклуды страниц ([:page: NavMenu]) муторно писать, но это легко лечится -- дописать одну строчку в шаблоны и вставлять из меню;
- Названия несущесвующих ещё страниц не подсказываются по Ctrl-space: мелочь, но всё же. Выход: сразу кликать по всем придуманным страницам (создавая и сохраняя их), при этом они пропадут из ветки Undefined nodes (там можно было бы смотреть неописанные страницы, не проставляя на них принудительно пометки todo с действием "описать страницу"). Делать тудушки необязательно (их, кстати, можно тоже целиком внести в шаблонные строки и легко вставлять из меню одним движением), можно положиться на свою память и пройтись по всем страницам. Или после того, как креатив закончится, отсортировать страницы по размеру: пустые страницы легко определить по этому параметру и пройтись по забытым;
Пробовал прототипировать в простейшем HTML -- это самый простой и естественный вариант, первым приходящий в голову. Но никогда не нравилось это делать, очень быстро становилось неудобно. И понятно, что из-за include и подобных вещей желательно сразу делать в своем движке, располагать файлы примерно там, где они и будут находиться, перемещаться по ним и думать уже не в терминах идеи, а в терминах реализации. Это убивало фантазию и прототипирование очень быстро -- по сути, проще было сразу начинать делать черновик приложения, а это немного другое. Для меня прототипирование -- это скорей порхание и расстановка идей то там, то здесь, их связи. А детали реализации очень мешают.
Опыт прототипирования на бумаге
Бумага и ручка/карандаш. Тоже не складывалось с ними. Интерфейс и расположение вторичны, и само очерчивание прямоугольничка "здесь будет страница... э-э-э..." уже вносило в процесс мышления какую-то даже не запятую, а целый пробел со знаком вопроса. Или даже многоточием. Это сбивает. Появляющиеся идеи только поначалу легко добавлять -- потом все сложнее и сложнее. С WikidPad'ом оказалось очень просто, проще, чем я думал. Некоторые моменты вообще удивили: скопировав блочок описания позиции общими словами и попробовав его разукрасить реальным примером, быстро нашел и переставил местами несколько частей -- стало гораздо лучше! На бумаге этого бы не стал делать. Или внесение изменений было бы делом непростым (перерисовать или раздвинуть-втиснуть, или переклеить). То есть эти изменения делались бы позже, на каком-то другом этапе, может быть тогда, когда это уже не слишком удобно: переставить местами, вписать в дизайн... Сколько раз так уже было! Может не удастся сейчас это толком описать, но думаю понятно, о чем речь.
Обустройство WikidPad
Рекомендую делать прототип в отдельной вики. И даже если для проекта используется своя вики, отдельная от основной и единственной, прототип делать лучше рядом с ней, но отдельно от записей по проекту и ТЗ. В этом есть недостатки (тудушки не в одном месте, а в двух), но мне пока сделать именно так кажется правильным.
- это избавит от необходимости очищать основную вики от прототипа по окончании разработки (полезно)
- исключит пересечение частей разных прототипов (очень полезно)
- избавит от необходимости созерцания при навигации по Ctrl-O не относящихся к прототипу ссылок (очень полезно при креативе: не спотыкает)
- разделяются тудушки (недостаток). Можно вместо тудушек использовать issue (замечательно!) и помечать этим ключесловом этапы реализации (1 и 2 -- можно не отмечать при протипировании (сырая бета с минимумом возможностей и релиз-кандидат), а придуманное, но отложенное -- это какие-нибудь третьи и четвертые этапы, если пользователи или заказчики не придумают на тот момент более важных для них фич)
- хранение этапов в прототипе, а не отдельно от него в общей документации по проекту -- замечательная идея, по-моему. Возможно, хранить там же тудушки -- не менее замечательная идея, но у меня пока ситуация другая: работа часто ведется над разными проектами, и работа является частью жизни, поэтому предпочитаю видеть все дела в одном месте. Вот если отделять вики по проекту в отдельную от основной документацию (например, при работе не на себя и свои проекты, которые являются частью жизни и тесно связаны с другими идеями и записями, а на заказчика) -- тогда проголосую за отдельную вики для каждого проекта (ТЗ и текущие вопросы), а в прототипе хранить все тудушки по реализации UI и программной начинки. Это нормально и удобно: видно, с какой частью проекта связаны задачи (тудушки висят на конкретных страницах), для общих тудушек удобно использовать заглавную страницу вики или сделать TodoInbox и пометить его закладкой для быстрого доступа отовсюду!
Создавая вики, указываем папку с технической документацией по проекту -- в ней автоматически будет создана папка с названием вики (допустим, WebSitePrototype -- так можно называть все прототипы в разных проектах), а в ней -- всё необходимое.
Рекомендую при создании использовать формат ORIGINAL SQLITE, а не COMPACT! Все страницы будут храниться в отдельных текстовых файлах рядом с базой-индексом.
- в стеснённых условиях можно будет поправить их хоть на КПК в дороге, если хранить дубликат на карточке;
- беспроблемная синхронизация с SVN (проблемы могут оказаться заметны при работе нескольких пользователей с WikidPad-прототипом; хотя при такой работе web-based wiki будет наверняка присутствовать, но в некоторых случаях WikidPad может пригодиться, поэтому подстрахуемся на всякий случай);
- разницы в скорости не замечал, хотя не исключаю, что она есть. Моя основная вики занимает 4 мегабайта, папка data содержит 470 файлов, прототипы -- это обычно до 100 килобайт. Тут гарантированно не будет заметно никаких проблем со скоростью.
- копируем свою страницу WikiSettings (там настройки цветов, приоритетов, шрифтов)
- Wiki / Options / Current Wiki / New Page Title Prefix -- убираю один плюсик (по умолчанию их два, меня это удивляет)
- плагины никуда не деваются, но если викидпад свежепоставленный, рекомендую добавить как минимум WikidpadTodoExtension. Это можно сделать и позже, посмотрев на скриншоты и решив, надо ли. Ещё могут оказаться полезными:
- Count Words (вообще в вики, для прототипирования не нужно)
- Show Referring Pages (это может оказатся полезным для фиксации списка ссылающихся страниц)
+ Wiki Settings
These are your default global settings.
[global.importance.low.color: grey]
[global.importance.high.color: red]
[global.importance.high.bold: true]
[global.contact.icon: contact]
[global.font: Verdana]
[global.todo.bold: true]
[global.todo.icon: pin]
[global.priority.1.color: red]
[global.priority.1.bold: true]
[global.priority.2.color: orange]
[global.priority.2.bold: true]
[global.priority.3.color: grey]
[global.priority.3.bold: true]
[global.priority.4.color: grey]
[global.priority.4.bold: false]
[global.wrap: 256]
[global.Current.urgent.color: red]
[global.Current.thisweek.color: lime green]
[global.someday.color: dim grey]
[global.tickler.color: grey]
[global.complete.color: light grey]
[icon: cog]
[global.import_scripts: GlobalScripts]
Глобальные привычки
Пусть войдёт в привычку перетаскивать используемые в вики картинки и файлы, используя Ctrl + drag'n'drop. Скриншоты, сканированные эскизы бумажных страниц. Это совет вряд ли для wireframe prototype, но wireframe вполне можно продолжать использовать и в качестве инструмента для storyboarding, и вообще в качестве техзадания на разработку сайта. Перетаскиваемые таким способом файлы будут при этом скопированы в папку files (создастся автоматически) рядом с папкой data, а ссылки будут относительными.
- Это спасёт вас при экспорте вики в HTML формат от потери картинок при просмотре на другом устройстве (другом компьютере, телефоне, КПК)!
- http://baadoo.livejournal.com/tag/wikidpad (прерываться и читать прям сейчас необязательно -- может позже пригодится)
В документации (в основной вики) ставим ссылку на прототип (drag'n'drop файла с расширением .wiki, который располагается в указанной директории рядом с папкой "data"). Получтся что-то вроде этого:
wiki:///D|/PROJECTS/mega-website/WebSitePrototype/WebSitePrototype.wiki
а прототип будет открываться в новом окне.
Стартовую страницу оформляем примерно так:
- вверху -- служебные ссылки, по тудушным лучше сразу кликнуть и нажать на них Ctrl-S. Если после возврата и повторном заходе на них они останутся пустыми -- закройте вики и откройте снова. Хотя лучше сделайте это не сейчас, а через пару минут, после правки "Global Text Blocks" (Эти страницы с префиксом туду -- для плагина. Поудобней, чем встроенный, и добавляют удобств)
- HomePage -- главная страница сайта
- ниже -- список страниц, которые наверняка будут включаться во многие из них, поэтому как только родилась идея -- записываем в подходящем месте, чтобы кликнуть и сразу создать-прописать их. На странице NavigationHorizontal сразу же убираем заголовок и пишем: HomePage | ... (здесь будет горизонтальное меню). На NavPages -- что-то вроде "(назад-1) 1 2 3 4 5 6 7 8 9 10 (вперед+1)", тоже убрав заголовок, естественно: эти страницы будут только включаться в другие, и заголовки нам здесь ни к чему.
Открываем Func. Pages / Global Text Blocks и дописываем выделенную строчку (третья сверху):
- может потребоваться выполнить процедуру menu: Editor / Text blocks / Reread text blocks
Продолжаем знакомство с полезными для прототипа возможностями
Здесь сделаем лишнее действие для иллюстрации пары полезных особенностей WikidPad. Пишем в любом месте страницы внутри квадратных скобок: [alias: NavMenu]
Переходим на HomePage.
Устанавливаем курсор под заголовком (здесь у нас наверняка будет горизонтальное меню, да?) и выбираем из меню WikidPad: Editor / Text blocks / include page. Мне удобней делать это на клавиатуре: Alt-E, T, T, Enter. Дальше по обстоятельствам, меню у всех может быть разное.
Узнаёте? include page -- это то, что мы писали в Global text blocks, а то, что пападёт на страницу, было написано после ";a=".
Переключаемся в Preview (Ctrl-Tab или по вкладкам вверху окна редактирования).
Во-о-о-т.
Что имеем? Включено содержимое страницы NavMenu. По Ctrl-O в режиме редактирования можем видеть как NavMenu, так и NavigationHorizontal. При этом физически у нас существует только страница NavigationHorizontal.
Это была иллюстрация прелестей alias'ов. Их при необходимости можно создать сколько захочется: например, русские и английские синономы названий страниц, если лень переключаться между раскладками и голова думает периодически на разных языках. Но это -- при необходимости. Подумайте: оно вам надо, зоопарк разных вариантов? Лучше с головой договориться. Но если надо -- делайте.
Если при дальнейшей работе стойкие ассоциации при поисках страниц не совпадают с тем, как назвали её вначале -- смело переименовывайте. Ctrl-Alt-R на переименовываемой странице. WikidPad спросит и найдёт-переименует все существующие ссылки на эту страницу.
И ещё одна иллюстрация удобств WikidPad. Возвращаемся на HomePage в режим редактирования, оставляем от слова NavMenu в инструкции по вставке страницы только Nav, и когда курсор находится после "v", нажимаем Ctrl-spacebar. Выпадающий список предложит существующие подходящие варианты. Удобно? Восхитительно! Отсутствием этой подсказки меня мучают веб-реализации вики-движков.
Если все понятно, можно убрать из меню мешающий там алиас. И вставить меню на всех основных страницах.
Как организовать работу с задачами
todo (задачи, тудушки с приоритетами, тудушки с датами)
Это у нас будут конкретные задачи по уточнению прототипа, заметки для себя "не забыть потом сделать здесь ЭТО", а после окончания работы с прототипом -- задачи по реализации. Об этом было сказано в самом начале, в секции "Обустройство WikidPad".
Итак, прототип не закончен, фантазия хлещет, на мелочах останавливаться неохота: пишем todo: описать подробней на обделенной вниманием странице и продолжаем творчество дальше. Когда экстаз спадёт, идём на спецстраницу ToDo (ей занимается плагин WikidpadTodoExtension) или в ветку дерева Views / todo, и последовательно занимаемся зачисткой хвостов.
Когда работа над прототипом кажется завершенной, ходим по нему, и периодически возникают мысли: "Здесь надо будет сделать то и сё". На этом этапе уже можно думать о приоритетах, поэтому тудушки лучше сразу сопровождать полезным суффиксом. Пишем на странице(-ах): todo.1: то и todo.2: сё. Или расставляем тудушки перед написанными ранее мыслями.
И запомним: приоритет пишем сразу после слова туду. Там на самом деле можно что угодно писать, будет группироваться. Основное, что надо запомнить: чем меньше, тем лучше.
В результате появится следующая картина для обзора:
(Приоритет 4 -- это неважно и несрочно. Так в прототипе сразу же помечаются особенности, про которые мысль проскочила, но было понятно: делать их в первой версии нет никакого смысла.)
- В таком виде тудушки есть в любом WikidPad, сразу же после установки. Они тоже будут группироваться (в данном случае по приоритетам), и после разворачивания ветки видно, на какой странице они расположены.
- В таком виде их представляет упоминавшийся ранее плагин на страницах, начинающихся с ToDo.
- удобней тем, что в аналогичном виде страница окажется и при экспорте в HTML: на КПК или телефоне всегда можно держать под рукой;
- больше места для обзора;
- проще перейти, визуально сразу легко понять, что несколько задач относятся к одной странице (может быть проще поручить их одному разработчику).
Может и будут. Только позже.
Вообще всё то же самое, что и с тудушками, только доступны исключительно в дереве слева.
Если вы менеджер и управляете работой нескольких разработчиков
- можно писать ник ответственного в тудушках (todo.2.aaa, todo.2.bbb, todo.1.bbb) -- они сгруппируются по приоритетам (или если назначать даты -- по датам, но в этом случае приоритет уже лишний -- надо брать и делать, раз сегодня все равно надо сделать), а ответственный будет указан с скобках после названия страницы с тудушкой (видно, над какой частью проекта он работает) и перед самим описанием задачи;
- можно писать имя или ник человека, занимающегося всей секцией сайта, в виде [contact: aaa] где-нибудь на странице. В дереве Views в ветке contact можно видеть всех разработчиков и повешенные на них страницы. Конечно же, можно на одной странице указать несколько контактов;
- можно сделать каждому разработчику по странице и собирать все задачи там. Если так удобней. Не будет автоматически видно страницы, к которой относится эта задача, но тут каждый решает для себя в полевых условиях: что будет удобней, может показать только практика;
- не забываем, что WikidPad может быть установлен у всех и синхронизироваться через SVN: главное завести его в формате original_sqlite, чтобы страницы хранились отдельными текстовыми файлами!
- одно назначим на вчера и повесим на исполнителя "rb",
- пару задач сделаем регулярными (ежедневными) -- см. туду со звёздочками (а чтобы они правильно сортировались -- добавим a. и b. в начале),
- и просто для иллюстрации того, где надо писать исполнителей (перед датой, но после приоритета), добавим к ним, что это относится ко всем (all или team, например)
- дата в тудушках всегда в конце, приоритет всегда в начале; между ним пишите что угодно и сколько угодно -- в конце концов вам с этим работать. Я рекомендую придерживаться минимума "уточнений", даты по возможности не использовать, приоритеты использовать всегда. Даты назначать на несколько ближайших задач (на сегодня и завтра, например). Итого, общая схема: todo.(1-4)[.WHO][.DATE]: what to do
- иногда вместо конкретных дат гораздо удобней мыслить неделями (CW -- calendar week)
Тогда на страницах ToDoCalendar и ToDo увидим следующее:
и
Экспорт в HTML
Я предпочитаю экспорт всей вики в формате многостраничного HTML.
- одна большая страница поступает с мобильными броузерами так же, как капля никотина с хомячком (иногда -- как с лошадью, но это скорее исключение);
- так гораздо легче синхронизировать только изменения на карточках памяти гаджетов (я их дублирую на 2-3 карточках, одна из которых не самая быстрая, и процесс полного копирования моей экспортированной основной вики раз в неделю занимает неприлично много времени; Хоть это и не относится к прототипу, помнить об этом стоит)
- Здесь Total Commander в помощь: замечательно справляется. Или ищите другие синхронизаторы;
- один из вариантов -- использование логов SVN для ежедневной ручной синхронизации с файлами на карточке;
- второй вариант -- тот же SVN, но на карточке держать часть репозитория -- папку с обновляемым регулярно HTML экспортом. Но здесь возможны сюрпризы: я не пробовал. При экспорте время изменения у всех HTML файлов меняется, так что может быть SVN окажется неспособен игнорировать дату файлов при сравнении.