Re: календарный_вид

[Катя <katekut@mail.ru>]

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

Конечно. Это несложно, просто эта задача не первоочередная.

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

В нашем случае: требование - добавление данных, контролируемых админом.
Оно реализовано. Очень просто :)))

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

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

Катя
//////


>> Привет!
>>         Вот читаю твою "конкретизацию" каледарика :)))
>> Я  хотел  бы  поделиться опытом, знаниями и дать несколько советов при
>> проектировании требований такого рода систем.

K> Привет, Миклер!
K> Классное замечание! Я сам читал то, что написал, и
K> Интересная штука Rational Unified Process -- что-то я о нем слышал. Как ему
K> учатся, очно или по книжке?
K> Это напоминает мне о второй логике. Значит, перед тем, как приступить к
K> анализу, который советуешь ты, ставлю себе вопрос -- что тут важно, какие
K> компоненты важны?

K> 1. Вся затея вообще и подпроцесс "календарный вид представления эзо и
K> обучающих событий" должны быть интересны для занимающихся ею. Т.е. должно
K> быть минимум рутины, и максимум творчества.

K> 2. Нужно, чтобы подпроцесс "календарный вид представления эзо и обучающих
K> событий" -- или попросту "календарик", воспользуюсь твоим словом,
K> способствовал интересному и обучающему получению прибыли из проекта Эзонет.
K> Если такое пойдет, то даже возникнут новые ячейки на площадке, т.е.
K> несколько человек смогут активно вариться в среде!

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

K> 4. Исполнение "календарика" дизайн и программирование должно быть не
K> громоздким и эффективным. Желательно сделать так, чтобы в него легко было
K> вносить изменения в будущем. Он должен быть хорошо согласован с тем, что уже
K> существует у Кати и Ани (платформы, языки, что еще?).

K> Ну хорошо, теперь попробую применить твой совет.

>> Нужно оперделить кто с ней взаимодействует.

K> Админы, читатели, организаторы тусовок, заинтересованные доноры информации,
K> незаинтересованные доноры информации, случайные читатели

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

K>> 2. Механизм добавления ресурсов (дата, событие, описание, контакт)
K>> пользователями (возможность предварительного одобрения админом);

K> Катя: Сейчас механизм такой:
K> 1. пользователь заполняет форму, нажимает Ок -> админу отсылается письмо с
K> заявкой
K> 2. админ вносит ресурс в базу

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

K>> 3. Механизм добавления ресурсов администраторами - вручную и из списка с
K>> разделителями (чтобы можно было подготовить список, а потом загрузить).

K>> 4. Несколько View (видов, представлений) -- 1 неделя, две, месяц,
K> несколько
K>> месяцев. Что-то подобное как на Yahoo Groups --> Calendar.

K> 5. Отображение в календарике только событий, отобранных по критериям "Город
K> или города, страна, время начала события, ключевое слово"

K> 6. поощрение доноров информации. Мы собираем имейлы людей, которые добавляют
K> инф. и поощряем их, даже заохочуємо їх, они же помогают нам. Кто-то из них
K> может, станет нашими сотрудниками.

K> 7. классный дизайн пустого календаря будет привлекателен и сам по себе.

K> Народ, какая еще тут может быть и нужна нам функциональность?

K> Костя

K> ----- Original Message -----
K> From: Mikler <Mikler_mpz@tut.by>

>> Привет!
>>         Вот читаю твою "конкретизацию" каледарика :)))
>> Я  хотел  бы  поделиться опытом, знаниями и дать несколько советов при
>> проектировании требований такого рода систем.
>> 1. Выделение Актантов.
>> Актанты  - это нечто внешнее для системы. Как то админ, пользователь и
>> т.д.
>> Нужно оперделить кто с ней взаимодействует.
>>
>> 2.  Кадидаты  в  варианты использования. Мозговым штурмом определяется
>> вся  мыслимая  функциональность  рассматриваемой  системы.  Потом  эта
>> функциональность  фильтруется,  структурируется общим обсуждением. Для
>> оставшейся функциональности (Вариантов Использования системы) детально
>> описываются  последовательности  возможных  действий  пользователся  и
>> возможных результатов.
>>
>> Дальше  всё  не  так  важно.  Например  можно  дать  задание  человеку
>> разработать  интерфейс  - чисто на бумажке или в графическом редакторе
>> (Visio...)  и  посмотреть насколько он удобен и выполняет определённым
>> требованиям.
>>
>> Что  касаеться  технологий,  то  это  чем-то  напоминает совмещение не
>> совместимого.    Архитектура    (набор    технологий)   ограничивают
>> функциональность, а функциональность определяет архитектуру.
>>
>> Важно разделять взгляд на систему со стороны пользователя и со стороны
>> разработчика.  У  тебя  это  несколько  путается.  Когда  мы  начинаем
>> разработку  с  постоения модели ВАриантов использования мы закладываем
>> фундамент нужной системы, даже в таких мелочах как Календарик.
>>
>> Это было мизерное введение в Rational Unified Process :)))
>>
>> Удачи. :))
>>
>>
>> ....
>> дочитал
>> посмотри какая у тебя каша :)))
>> раньше тоже что-то похожее было и у меня. Кучу идей разношёрстных...
>> Разделяй! :))))
>>
>>




K> -------------------------------
K> "Урал-2003. Летний лагерь Школы по Второй Логике" - 
K> http://klein.zen.ru/zen-spirit/ural-2003/



Катя

ЭZО-Сеть. Межрегиональный Эзотерический Ресурс.
http://ezonet.net



-------------------------------
"Урал-2003. Летний лагерь Школы по Второй Логике" - 
http://klein.zen.ru/zen-spirit/ural-2003/