За оценку пасиб, но еще рано.

1. Краткое БО (brief) выдаваемой отображается сразу после выдачи в списке выданных экземпляров.
2. Над отображением характера сейчас как раз и думаю (см. мое предыдущее сообщение - про интерфейс лога операций)
3. Чекбоксы для выделения нескольких выданных книг и произведения над ними каких-либо операций. Сейчас реализована операция продления - можно выделить сразу несколько книг и нажать на кнопку "Продлить" (иконка прямо над списком выданных) - все выделенные книги продлятся до даты, указанной в поле "Дата возврата" (слева)

Выставить ее в демо-режиме можно. Так, наверное, дело пойдет быстрее и проще. Попробую создать набор тестовых БД, и тестовую учетную запись, что б можно было погонять удаленно (работа не только в локальной сети, но и через интернет - одна из возможностей, которую стараюсь заложить). Заодно интересно будет проверить возможность создания нескольких библиотечных пространств (в данном случае ОмГУ и тестовой) на одном сервере Ирбис 64. Лишь бы юзеров на сервере хватило

Цитата:

Кирилл Соколинский
Да, относительно того, что большинство библиотекарей «никуда не торопятся» Вы правы. Но вот рассматривать такое положение дел как норму я бы не стал.

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

Цитата:

Кирилл Соколинский
Что касается Руслана, то в этой системе вообще не предусмотрен групповой учёт и я не помню как выглядит её интерфейс выдачи.

По-моему мы ведем речь не о групповом или индивидуальном учете, а о скоростном? Давайте с мейнстримом определимся.

Цитата:

Кирилл Соколинский
Но если Вы приложите скриншот, это позволит сделать нашу дискуссию более продуктивной.

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

Так вот, по сути дела: предоставить скриншот я вам не могу, наверное догадываетесь почему? Правильно -- эксплуатирую Ирбис. Со скриншотами Вам в политехе, наверное, помочь смогут. А мы там были в рамках деловой командировки два года назад и мельком посмотрели процесс работы библиотеки.

Описывая же книговыдачу в "Руслане", хочу отметить, что наибольшим отличием АРМ-ов является целостность интерфейса скоростной книговыдачи. В "Руслане" ничего дополнительно не надо тыкать, двигать: считал ШК читателя, вот тебе сразу его фотография, список долгов и пр. И сразу, немедленно, можно начать считывать ШК книг. Да, отличия от Ирбиса незначительны -- у тех поля ввода ШК сбоку, а у нас сверху, но мне почему-то сразу захотелось воспользоваться интерфейсом "Руслана", а не Ирбиса, где нужно будет схватится за мышь и начать задвигать диалог в угол, чтобы не мешал. Иными словами -- там интерфейс более технологичен (естественно на мой субъективный взгляд).

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

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

Кстати, хочу напомнить, что если желательно, чтобы при считывании штрих-кода читателя (в скоростном интерфейсе) сразу (т.е. ДО считывания штрих-кода выдаваемой книги) появлялась запись читателя, необходимо установить параметр
BARCODERELATION=2



Редактировано 1 раз. Последний раз 28.02.2008 10:18 пользователем Alio.

Цитата:

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

Ваша аналогия неприемлема, поскольку наводит на мысль об усложнении технологии, в то время как речь идёт о её предельном упрощении.
Укажу приемлемый пример. Если сейчас картошку приходится копать и параллельно отбирать, то при реализации описанного режима можно будет не думать об отборе – эту работу будет делать машина-сепаратор.

Цитата:

Григорий Пригодин
По-моему мы ведем речь не о групповом или индивидуальном учете, а о скоростном? Давайте с мейнстримом определимся.

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

Цитата:

Григорий Пригодин
Только без готовности разработчиков к переделке интерфейса ничего после нашего с вами продуктивного диалога не изменится.

Александр Иосифович вполне определённо сообщил о своей поддержке предложений, связанных с оптимизацией режима и своей готовности воплотить их в жизнь. Цитирую:

Цитата:

Александр Иосифович
Беру "повышенное обязательство" - сделать в 2008.1 дополнительный интерфейс для суперскоростной книговыдачи на штрих-кодах (радиометках) с ЕДИНСТВЕННЫМ окошком для ввода (не считая, разумеется, ввода исходной БД ЭК и предполагаемой даты возрата), рассчитаный на то, что:
- любая операция книговыдачи начинается с идентификации чичтателя;
- есть признак, позволяющий формально различить штрих-код экземпляра и штрих-код читательского билета.
Жду предложений по деталям этого интерфейса (предложение по звуковым сигналам принимается).

Григорий, пожалуйста, просматривайте предыдущие сообщения прежде чем начинать новое. . .

Цитата:

Григорий Пригодин
В "Руслане" ничего дополнительно не надо тыкать, двигать

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

Спасибо Илье за то, что он упомянул о кнопке продления. Действительно было бы очень хорошо иметь эту кнопку непосредственно на форме скоростной книговыдачи. Правда избирательное продление лишь некоторых книг кажется мне нецелесообразным. Допустим, срок правомерного удержания книги А истекает сегодня, а книги Б - завтра. Неужели читатель должен два дня подряд приходить в библиотеку и дважды просить о продлении? :)

Кирилл, насколько я понимаю, Вы все еще считаете, что я пытаюсь Вас переубедить в том, что одно поле ШК -- это плохо?

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

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

...а то, какой вид интерфейса Вы нарисовали в вображении (и насколько он будет информативен), согласитесь, я представить не могу. Отсюда и наш бесполезный спор. Тем более, что Александр Иосифович уже сделал шаг в правильном направлении. Еще бы втискивать это оконце (моё видение таково) на место справочника читателей/держателей/etc (v.2006.2) на время использования скоростной книговыдачи (можно, к примеру, контролы разнести на две tpanel, а потом панельки просто менять местами, ну или как-то иначе). Тогда бы этот сервис не смотрелся так инородно в АРМе. ...а там хоть одно поле, хоть четыре... Несбыточная мечта?

Цитата:

Григорий Пригодин
А я вообще-то о другом

Это очень хорошо, что Вы сообщаете о проблеме, которая Вас беспокоит. Но согласитесь, если эта проблема не связана со скоростной книговыдачей в условиях многоэкземплярного учёта, то о ней едва ли стоит писать в этой ветке. . .

Цитата:

Григорий Пригодин
Вы оппонировали с применением теории вероятности, рассмотрев только невероятность наступления события.

Вы можете предложить другой подход? Вы полагаете, что в системе «человек-машина» может быть достигнута абсолютная надёжность? Вы думаете, что ручной выбор списываемой с читателя книги – это на 100% надёжная операция?
Мне кажется очевидным, что мы можем сравнивать лишь вероятности возникновения ошибок, анализируя вызывающие их факторы. Одним из ключевых факторов является количество и сложность совершаемых сотрудником операций...

Цитата:

Григорий Пригодин
И граблями с эргономичной ручкой они копать картофель не начнут, так как не будут уверены в том, что они его вообще когда-нибудь извлекут из земли.

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

Цитата:

Григорий Пригодин
Еще бы втискивать это оконце (моё видение таково) на место справочника читателей/держателей/etc (v.2006.2) на время использования скоростной книговыдачи (можно, к примеру, контролы разнести на две tpanel, а потом панельки просто менять местами, ну или как-то иначе). Тогда бы этот сервис не смотрелся так инородно в АРМе. ...а там хоть одно поле, хоть четыре...

В одной библиотеке я наблюдал за синхронизированной работой основного и скоростного интерфейса и сделал вывод, что этот путь для нас не приемлем. Несмотря на использование клиент-серверного ИРБИС 64 и хорошее железо система работала в этом режиме крайне медленно. Я считаю более целесообразным размещение на форме скоростной книговыдачи всей необходимой информации, чтобы полностью устранить необходимость обращения к основному интерфейсу.

> Тем более, что Александр
> Иосифович уже сделал шаг в правильном направлении.
премного благодарен-с...

Вот так, работаешь, работаешь... Как сказал ВВП: пашешь, как раб на галере...


ОГРОМНОЕ СПАСИБО за ВСЕ нововведения, появившиеся за последнее время! То, что нет предела совершенству - понятная истина, но всякий раз находятся такие решения, которые заставляют восторгаться и кричать УРА! Отдельное спасибо за восприимчивость, готовность к диалогу!



Редактировано 1 раз. Последний раз 03.03.2008 20:51 пользователем А. Роман.

Итак - есть желание создать интерфейс скоростной выдачи, который содержит ЕДИНСТВЕННОЕ поле для ввода штрих-кода (или радиометки) (не считая, разумеется, установочных элементов: имя БД и дата предполагаемого возврата). Такой интерфейс ориентирован на технологию, которая базируется на двух обязательных условиях:

1. Есть формальный признак, позволяющий отличить штрих-коды читательских билетов от штрих-кодов экземпляров изданий.
2. Любая операция (выдачи или возврата) ОТНОСИТСЯ к читателю, чей штрих-код считан ПОСЛЕДНИМ, т.е. иными словами - любая операция должна начинаться со считывания штрих-кода читателя.


Возникает вопрос: а что делать в рамках такого интерфейса, если все таки надо оформить возврат книги (индивидуального учета) БЕЗ читательского штрих-кода - ведь такая ситуация может возникнуть...

Цитата:

Alio
Возникает вопрос: а что делать в рамках такого
интерфейса, если все таки надо оформить возврат
книги (индивидуального учета) БЕЗ читательского
штрих-кода - ведь такая ситуация может возникнуть...

Предложение:
1. Создать флажок на интерфейсе (предпочтительнее чем в настройках - у нас им пользуются часто) "Предупреждать, когда сдается книга, не принадлежащая текущему читателю".
2. Выбрасывать сообщение (то что это именно книга - мы можем понять по существующему формальному признаку)
Например: Попытка сдать книгу, которая выдавалась другому читателю (Установлен флажок предупреждения). Книга находится на руках у другого читателя: 20023000006385 (Кат. сотрудник ОмГУ) - Михайленко Илья Иванович, 19790629.
3. Предлагать под этим сообщением 2 варианта:
1 - Принять книгу (происходит все-таки возврат литературы - с изменением/без изменения текущего читателя на владельца книги - параметрировать через ini)
2 - Отказаться (Книга остается выданной, текущий читатель не меняется)

На вопрос Александра Иосифовича:
Нужно всё равно ставить для каждого типа (вида кода) поля некий логический контроль. Т.е. есть буфер, из которого в зависимости от алгоритма код попадает либо в ячейку "условно1-читатель", либо в ячейку "условно-2-экземпляр". И возможность строить такой алгоритм (или править его) нужно отдать пользователю (или не отобрать у него такую возможность).
Кроме этого, интересно про флажки. Лучше, если будет возможнсть включать разные цвета в неких ячейках интерфейса, опять же - по логике, описанной пользователем.

Цитата:

Илья Михайленко
1. Создать флажок на интерфейсе (предпочтительнее чем в настройках - у нас им пользуются часто) "Предупреждать, когда сдается книга, не принадлежащая текущему читателю".

Хочу заметить, что здесь предполагается расширение предложенной изначально концепции книговыдачи в условиях многоэкземплярного учёта, её дополнение элементами оптимизации для индивидуального учёта.
Всё описанное касается лишь экземпляров индивидуального учёта и может быть реализовано лишь при условии, что ЛЮБАЯ операция приёма книг начинается со сканирования читательского билета. В случае с групповым учётом, даже если целый поток будет разыгрывать свои экземпляры в рулетку, книга всё равно будет числиться и списываться с нужных студентов.

Думал, думал над новым интерфейсом и понял, что то, что обещал сделать, реализуется на существующем интерфейсе скоростной выдачи при условии задания параметра

READERBARCODE=

определяющего префиксную часть штрих-кода читателя, которая отличает его от штрих-кода экземпляра.(Хотя кое-какие уточнения алгоритма работы при этих условиях все-таки сделал).

То, что при этом имеются четыре поля ввода штрих-кода, а не одно, не имеет НИКАКОГО значения - можно вводить штрих-коды "не глядя" в любое окно, система сама разберется, куда его перенаправить.

Чекбокс ИДЕНТИФИКАЦИЯ ЧИТАТЕЛЯ в этом случае играет следующую роль:
- если он включен, то при попытке оформить возврат экземпляра, который принадлежит НЕ текущему читателю, возникает ошибка и соответствующее сообщение (чтобы такой возврат выполнить, надо выключить чекбокс и повторно считать штрих-код экземпляра);
- если он выключен, то возврат экземпляров, принадлежащих НЕ ТЕКУЩЕМУ читателю, выполняется без каких-либо сообщений.

Напоминаю, что ТЕКУЩИМ явяляется читатель, чей штрих-код считан последним.

Таким образом, скоростной интерфейс превращается в суперскоростной (в том смысле, как мы здесь обсуждали), если в IRBISB.INI задается параметр
READERBARCODE=nnnn..
а также возможно
BARCODERELATION=2 (чтобы видеть ТЕКУЩЕГО читателя в окне основного интерфейса)
и
PRMHRKV=1 (особенно для тех, у кого экземпляры группового учета (одного наименования) находятся в разных местах хранения и при этом имеют одинаковые штрих-коды)

Готов передать для тестирования этого режима АРМ Книговыдача ИРБИС64 с уточненным алгоритмом для этой технологии.

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

Создание самостоятельного интерфейса позволит:

1. Избавится от проблем связанных с переработкой имеющегося программного кода;

2. Отображать в одном из окон данные о читателе, а в другом данные о книге, генерируемые разными форматами. Это принципиально важная возможность, поскольку, выведя в «формате читателя» данные о его долгах, например, можно избавить библиотекаря от потребности основном интерфейсе книговыдачи;

3. Обеспечить адекватное форматирование библиографической записи и записи читателя. Если учесть, что дискуссия по поводу режима сводилась главным образом к вопросу о вероятности ошибок, можно сделать вывод о первостепенном значении для данного режима наглядности и информативности интерфейса. Например, ФИО читателя желательно должны выводиться каким-нибудь шестнадцатым кеглем и жирным начертанием без всяких подписей, а всё остальное ниже и меньшим шрифтом;

4. Реализовать наиболее наглядную визуальную индикацию вида операции. Очевидно, что лучшим вариантом такой индикации будет изменение цвета фона окон(самого большого объекта на экране). Это позволит выработать у сотрудников рефлекторное восприятие процесса;

5. Сократить количество окон для ввода штрихкодов и таким образом предупредить массу вопросов со стороны библиотекарей; :)

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



Редактировано 1 раз. Последний раз 04.04.2008 04:37 пользователем Кирилл Соколинский (СЗТУ).

Взять из РУСЛАНА стоило бы много чего еще, я писал об этом очень подробно (пока не могу найти где). Особенно идею объединенного АРМа Комплектатор/Каталогизатор.
Но разработчики по-прежнему не только не сотрудничают, но даже не общаются друг с другом. Хотя по отдельности крайне приятные человечки. А не мешало бы завести профессиональный форум, кстати.