Enhancements in Millennium (Was RE: MilCat, MilSerials, MilAcq)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thanks for your comments and I apologize for confusing scripts and macros. I tend to use them interchangeably and have no doubt confused people in the past.
I have two thoughts on the matter (these are not official anything as it relates to the enhancement process, but just some ramblings). First, I believe that many of the enhancements over the past few releases have involved moving telnet functions to Millennium. Some (like Create Lists, Rapid Update, etc.) have been improved in the transition and others have primarily morphed into the new interface without whiz-bang improvements (or at least none that are apparent to me). Innovative staff are earnestly interested in putting in improvements that address the needs, wishes, and practices of the libraries. They are very supportive of the enhancements process and have started to identify those items that are coming from the IUG process.
Second, some of the limitations of Millennium, like with Macros not being able to move from window to window, involve limitations that are driven by the Java platform and are beyond the control of the programmers at Innovative. As the Java platform changes, some of these limitations might go away and it may be possible, someday, for a Java macro to jump over two windows and give us everything we want to do. The changes in printing that came with Silver were (I believe) driven by changes in Java.
Having said these two, it seems to me that the enhancements process could be effective if we think exclusively about what we want the system to do. We set up macros in telnet to take care of things where there is no mechanism (or no simple mechanism) to accomplish our immediate goals in the software. Maybe I am wrong about this, but I know that people have a telnet macro that equates F4 with keystrokes that will create a new item and print the label. To this end, I think that these are exactly what we want the enhancements to accomplish. We want people to submit enhancements that address what they want to change to make the software easier to use. If they want to be able to key a single key when looking at a bib record and have the system create an item record, then that should be the enhancement request. Libraries should not worry if others might use it because many might not have even thought about that process. In the end, we should be submitting enhancements that improve the way that we can use the system.
Again, I thank you for your comments. Behind each of those macros and scripts there is something that the system is not doing as effectively as we want. Those should definitely be submitted via the enhancements process to ultimately help the system do everything that we want it to do.
Best -- Corey
Assistant Dean for Resource and Systems Management
Assistant Professor, University Libraries
University of Toledo
2801 W. Bancroft
Toledo, OH 43606
corey dot seeman at utoledo dot edu
http://library.utoledo.edu/userhomes/cseeman (my home page)
http://library.utoledo.edu (main library page)
I refuse to be intimidated by things I do not understand. -- me.
From: innopac-bounces at innopacusers dot org
[mailto:innopac-bounces at innopacusers dot org]On Behalf Of Hahn, Harvey
Sent: Wednesday, March 02, 2005 2:15 PM
To: IUG INNOPAC List
Subject: RE: MilCat, MilSerials, MilAcq
> -----Original Message-----
> From: innopac-bounces at innopacusers dot org
> [mailto:innopac-bounces at innopacusers dot org] On Behalf Of
> Seeman, Corey Glenn
> Sent: Wednesday, March 02, 2005 10:00 AM
> ... I have seen very sophisticated macros written
> by people that work off of Telnet. These macros tend (I
> believe) to work independently and can possibly still run as
> a library moves the staff functions from telnet to
NO, THEY CAN'T!!! (Sorry for the caps--the discussion of this issue has
been salt in an old wound, so to speak.)
By the way, it's *VERY* important to distinguish "macros" and "scripts"
when talking about Innovative compared to OCLC products (or
MacroExpress), for example. When OCLC refers to "macros" (using a
full-blown macro programming language), in Innovative lingo that's
"scripts"; when Innovative talks "macros", in OCLC parlance that's "text
strings" (and possibly the SendKeys macro command). It's very important
to use Innovative terminology when discussing this issue on this list,
otherwise people get confused when the topic "macros" appears and often
misunderstand what's being discussed.
The key difference between OCLC macros/scripts and Innovative macros is
that the latter merely "blindly" send a sequence of characters to the
screen. Innovative macros can't tell at all if they were successful or
not--they just send characters and hope and assume that everything
happened OK. OCLC macros/scripts, on the other hand, *can* do the same
(that is, blindly send sequences of characters to the Millennium
screen), but they can also go way beyond that in terms of invoking small
or large computer programs that incorporate elementary decision making
and artificial intelligence. It's this latter "intelligence" that
Millennium does not (and, according to III, *CANNOT* and *WILL NOT*)
support. The main hindrance to OCLC-type macros/scripts is that such
scripts cannot "read" the Millennium screens and automatically "react"
to any of the information that may appear on the Millennium screens.
(They can send data *to* the screens, but they cannot get any data
*from* the screens, as they can in the telnet version.)
Using OCLC (or MacroExpress) macros with the character-based INNOPAC
makes the latter system, in certain respects, *extensible* in terms of
functionality for the local user. Millennium is *not* extensible in
those same respects; everything is very much under the control of III.
Here's an analogy that may make the major difference clear: OCLC
macros/scripts are like "smart terminals", whereas Millennium macros are
like "dumb terminals".
> People have setup some incredibly creative
> processes to eliminate redundant work.
That's the point of automated systems, after all. It's a pity that
Millennium does not fully live up to being an automated system but
actually takes a big step backward in this regard.
> One suggestion might be to submit enhancements that can
> improve the functionality of the macros in Millennium.
I raised this issue at IUG and on this list for a year or two a couple
of years ago. What's the point of an enhancement when III finally
"officially" responded and publicly announced in various IUG forums
(cataloging, in particular, since that was my chief interest) that (as I
said above) Millennium *CANNOT* and *WILL NOT* support scripting.
> ... Elizabeth Thomsen (NOBLE) talks about using macros and scripts ...
Yes, but those "scripts" are Perl scripts and such that are done at a
more administrative level. What I'm talking about and where scripts are
needed is at the clerical and support staff level to add efficiency and
productivity to daily work efforts. In this respect Millennium is an
anti-efficiency and anti-productivity tool.
> ... I think that one of the things that I would ask is if these tasks
> should become part of the system and not as a macro.
I understand what you're asking here, and, to some extent, yes, some
routines and activities, I suppose, could be folded into the system. On
the other hand, there's no way that III can possibly add everyone's
unique ways of doing things into the system--and, if they did, it would
be so unwieldy that no one could use it!
That's why I feel that it is so important that III make *tools*
available (such as scripting), so that local users can customize and
extend the system to meet their particular local needs, similar to the
increasing flexibility and control that users now have over their Web
OPAC displays. This is similar to part of the philosophy behind the
"open source" movement, but the combination of "open" and "III" is an
oxymoron. ;-) OCLC, for example, *wants* users to use their software to
the fullest and extend the capabilities and functionalities of the tools
they provide; based on their words and actions, III seems not to want
> -----Original Message-----
> From: innopac-bounces at innopacusers dot org
> [mailto:innopac-bounces at innopacusers dot org]On Behalf Of Cindy Harper
> Sent: Wednesday, March 02, 2005 10:24 AM
> ... For those of us who were using a full-featured macro language
> such as Macro Express with telnet, it's a step back to have only
> the built-in macros of Millennium.
I agree 100%!
> III needs to address this question - is there no program that talks to
> the Java GUI and allows full-featured programming of the interface?
> Even if Millennium doesn't support this now, is there such a
> program in the Java world that some Java programs support?
It appears such things may be possible--here are just a handful of
On the other hand, I don't program in Java, so some of these references
may be inapplicable. In any case, III would have to modify Millennium
to incorporate scripting hooks and write an API for local users. This
is where the challenge probably lies in terms of III's interest or
Harvey E. Hahn, Manager, Technical Services Department
Arlington Heights (Illinois) Memorial Library
Desk: 847/506-2644 -- FAX: 847/506-2650 -- E mailto:hhahn at ahml dot info
Personal web pages: http://users.anet.com/~packrat
This message was distributed through the Innovative Users Group INNOPAC list
Public replies: INNOPAC at innopacusers dot org
Update your subscription options: http://innopacusers.org/mailman/listinfo/innopac