| Time |
Nick |
Message |
| 06:02 |
|
rlefaive joined #evergreen |
| 07:25 |
|
rjackson_isl joined #evergreen |
| 07:37 |
|
rlefaive joined #evergreen |
| 07:41 |
|
JBoyer joined #evergreen |
| 07:58 |
|
agent11 joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:01 |
|
ericar joined #evergreen |
| 08:05 |
|
rlefaive_ joined #evergreen |
| 08:16 |
|
Dyrcona joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:49 |
|
mrpeters joined #evergreen |
| 09:06 |
|
jwoodard joined #evergreen |
| 09:08 |
|
berickm joined #evergreen |
| 09:11 |
|
dkyle joined #evergreen |
| 09:14 |
|
maryj joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:26 |
yboston |
heads up, there is an IRC practice time starting in about 5 minutes |
| 09:29 |
kmlussier |
yboston++ |
| 09:31 |
krvmga |
yboston++ |
| 09:32 |
yboston |
welcome to anyone that is here on IRC for the first time |
| 09:33 |
yboston |
Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 09:33 |
yboston |
(this message will be repeated several times int he next 27 minutes) |
| 09:34 |
yboston |
if this is you first time on IRC, pelase say hello |
| 09:34 |
yboston |
*please |
| 09:35 |
yboston |
those that are veteran users of IRC, do you want to use the channel to talk until new IRC conenctions are made? |
| 09:37 |
krvmga |
will do. :) |
| 09:40 |
|
rlefaive joined #evergreen |
| 09:45 |
kmlussier |
yboston: It looks like we don't have any new IRC users for this session. But thanks for volunteering to be here in case the extra assistance was needed! |
| 09:45 |
kmlussier |
yboston++ |
| 09:46 |
yboston |
kmlussier: no problem, though I am hiping the closer we are to the start we will get new folks |
| 09:46 |
yboston |
kmlussier: if I miss a new connection pm me |
| 09:46 |
yboston |
unless they are a "veteran" user |
| 09:46 |
yboston |
:) |
| 09:46 |
kmlussier |
I was just looking at the Doodle. We have a fairly small turnout, and I recognize most of the names. :) |
| 09:46 |
kmlussier |
The Friday one looks like it will be a little busier. |
| 09:48 |
|
abneiman joined #evergreen |
| 09:48 |
jwoodard |
@weather |
| 09:48 |
pinesol_green |
jwoodard: Aubrey, TX :: Overcast :: 59F/15C | Tuesday: Thunderstorms - some may contain locally heavy rain, especially during the morning hours. A few storms may be severe. High near 75F. Winds SSE at 15 to 25 mph. Chance of rain 100%. Rainfall possibly over one inch. Tuesday Night: Scattered thunderstorms this evening becoming more widespread overnight. A few storms may be severe. Low (1 more message) |
| 09:48 |
|
ScottThomas joined #evergreen |
| 09:48 |
|
mdriscoll joined #evergreen |
| 09:49 |
jwoodard |
@more |
| 09:49 |
pinesol_green |
jwoodard: around 60F. Winds ESE at 5 to 10 mph. Chance of rain 80%. |
| 09:49 |
ScottThomas |
I have never used this before. I assume typing here and pressing Enter will do the job. |
| 09:49 |
ScottThomas |
It did. |
| 09:50 |
alynn26 |
@weather |
| 09:50 |
pinesol_green |
alynn26: Error: I did not find a preset location for you. Set via setweather <location> |
| 09:50 |
jwoodard |
I am looking at the radar here and it is just a band of red. |
| 09:50 |
yboston |
hello ScottThomas |
| 09:50 |
kmlussier |
ScottThomas: Yes, that works! :) |
| 09:50 |
alynn26 |
setweather anderson,sc |
| 09:50 |
alynn26 |
@weather |
| 09:50 |
pinesol_green |
alynn26: Error: I did not find a preset location for you. Set via setweather <location> |
| 09:50 |
yboston |
ScottThomas: today I am here to offer help to new IRC users |
| 09:51 |
jwoodard |
alynn26: "@setweather [zip code]" |
| 09:51 |
yboston |
ScottThomas: Click this link for a presentation I made explaining how to get started with IRC: http://goo.gl/w3zml2 |
| 09:51 |
ScottThomas |
Thank you. I will click the link now. |
| 09:51 |
alynn26 |
thanks jwoodard |
| 09:51 |
alynn26 |
@setweather 29621 |
| 09:51 |
jwoodard |
np |
| 09:51 |
pinesol_green |
alynn26: I have changed alynn26's weather ID to 29621 |
| 09:52 |
alynn26 |
@weather |
| 09:52 |
pinesol_green |
alynn26: Anderson, SC :: Clear :: 53F/12C | Tuesday: Sun and clouds mixed. High around 75F. Winds SW at 5 to 10 mph. Tuesday Night: A few passing clouds. Low 47F. Winds light and variable. |
| 09:52 |
yboston |
if anyone else is using IRC for the first time, please say hello? |
| 09:52 |
yboston |
right now we are havign a practice time specifically for new users |
| 09:53 |
yboston |
ScottThomas: one key tip I want to share with you is how to "adress" or "reply" to someone directly in IRC |
| 09:54 |
yboston |
ScottThomas: it is done as you can see by typing out the IRC "nickname" of a person at the beguining of the line, then addign a colon (:) |
| 09:54 |
ScottThomas |
Yboston: Thank you. I noticed that in your presentation too. |
| 09:55 |
kmlussier |
ScottThomas: to make it easier, if you start to type the person's name, in most IRC clients, including the web gateway, you can complete it by using your Tab key. |
| 09:56 |
kmlussier |
I find it saves time when I'm typing. |
| 09:56 |
yboston |
for example to type my nickname you will probably only have to type the letters "yb" and hit tab, then ti will auto complete |
| 09:57 |
ScottThomas |
kmlussier: That did work. Thank you. Can I assume that if I am addressing the entire group, I need not use the name: convention? |
| 09:57 |
kmlussier |
ScottThomas: Yes, that's right. You only type the name when you want to grab one person's attention. Or multiple people |
| 09:58 |
|
jlundgren joined #evergreen |
| 09:58 |
ScottThomas |
kmlussier: thank you |
| 09:58 |
abneiman |
* abneiman just learned about this TAB feature, thank you kmlussier++ |
| 09:59 |
csharp |
tab_autocompletion++ |
| 10:00 |
kmlussier |
OK, I think we're ready to begin our first focus group discussin on Evergreen search. |
| 10:00 |
kmlussier |
#startmeeting 2016-03-08 - Evergreen focus group discussion on search |
| 10:00 |
pinesol_green |
Meeting started Tue Mar 8 10:00:59 2016 US/Eastern. The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 10:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 10:00 |
pinesol_green |
The meeting name has been set to '2016_03_08___evergreen_focus_group_discussion_on_search' |
| 10:01 |
kmlussier |
#info Please read the ground rules for this discussion at http://wiki.evergreen-ils.org/doku.php?id=scratchpad:search:focus_groups |
| 10:01 |
kmlussier |
#topic Introductions |
| 10:01 |
kmlussier |
Please introduce yourselves, as follows |
| 10:01 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 10:02 |
jeff |
#info jeff is Jeff Godin, Traverse Area District Library (TADL) |
| 10:02 |
ScottThomas |
#info ScottThomas is Scott Thomas, Pennsylvania Integrated Library System |
| 10:02 |
alynn26 |
#infor alynn26 is Lynn Floyd, Anderson County Library, SCLENDS |
| 10:02 |
|
Chris___ joined #evergreen |
| 10:02 |
rhamby |
#info rhamby is Rogan Hamby |
| 10:03 |
jlundgren |
#info jlundgren is Jeanette Lundgren, C/W MARS |
| 10:03 |
JBoyer |
#info JBoyer is Jason Boyer, Evergreen Indiana |
| 10:04 |
kmlussier |
OK, there are a couple of people who signed up for this one who haven't introduced themselves yet. If anyone else arrives, please feel free to introduce yourselves at any time. |
| 10:04 |
kmlussier |
To start, I just want to explain that the goal of this discussion is mainly to have a high-level discussion on what you all think an ideal search system looks like for Evergreen. |
| 10:05 |
kmlussier |
It really is just a time to brainstorm at this point. What I would like to do from these sessions is to pull all of the input together so that we're better able to paint a picture of what we ultimately want to see in Evergreen. |
| 10:06 |
yboston |
#info Yamil Suarez - Berklee College of music (mostly lurking) yboston |
| 10:06 |
kmlussier |
If we can eventually gain community consensus around a discussion, my hope is that we can ultimately do some development to make it happen. But that step is further down the road. |
| 10:06 |
kmlussier |
So I'm going to start with my first question. |
| 10:06 |
kmlussier |
#topic Strengths of current search |
| 10:06 |
kmlussier |
I want to start by asking people to identify what they like about the current Evergreen search. What are its strengths? |
| 10:07 |
|
Christineb joined #evergreen |
| 10:07 |
* kmlussier |
finds it easier to facilitate focus group discussions in person because she can stare people down. :) |
| 10:08 |
* jeff |
laughs |
| 10:08 |
JBoyer |
Talking is also faster than typing (for better or worse, depending on the speaker ; )) |
| 10:08 |
yboston |
EG search can handle diacritics |
| 10:08 |
alynn26 |
faceted searching |
| 10:08 |
kmlussier |
yboston++ #Awesome, thanks for getting us started! |
| 10:08 |
ScottThomas |
There is an attempt at auto complete. |
| 10:09 |
yboston |
EG can handle left anchored and right anchored search |
| 10:09 |
kmlussier |
ScottThomas: The autosuggest that tries to predict what you're typing? |
| 10:10 |
yboston |
left anchored and right anchored search: that means it can do partial matching on either side of a word |
| 10:10 |
ScottThomas |
I believe the more correct term is autosuggest. Sorry. |
| 10:10 |
kmlussier |
ScottThomas: No, I think you can use either term. I just wanted to make sure we were talking about the same things. :) |
| 10:11 |
yboston |
EG can sort results in various ways: like date created |
| 10:11 |
kmlussier |
The reason I ask this question is because, if we make major changes to search, we want to make sure we don't lose the things that are already working. |
| 10:11 |
kmlussier |
So think of the question in terms of things you don't want to lose. I think all of the thoughts raised so far fall within that category. |
| 10:12 |
yboston |
EG allowed me to create a custom index on a bib 9xx tag (p45) that my library uses for song titles |
| 10:12 |
yboston |
I was able to include "song titles" as one of the choices on top of keyword/titl/author, etc |
| 10:12 |
kmlussier |
yboston: So it sounds as if you like the ability to create your own indexes, even if those indexes don't fall in lines with larger community needs? |
| 10:13 |
yboston |
kmlussier: yes |
| 10:13 |
* kmlussier |
agrees that this is a very powerful feature of the current system. |
| 10:13 |
kmlussier |
Are there any other elements of search we want to make sure we keep before we move on to our next topic? |
| 10:13 |
yboston |
EG allowed me to specify a custom "format" of "electronic score" using the Multi Valued Field feature |
| 10:14 |
ScottThomas |
It makes use of the MARC fixed fields when determining format. Our old ILS did not do that. |
| 10:14 |
jeff |
I'm hearing "flexibility" :-) |
| 10:14 |
kmlussier |
jeff: Yes, I think that's right. A lot of flexibility. |
| 10:15 |
rhamby |
I would say depth also. It allows access to searching a lot of the MARC data that other ILSes often hide. It's usefulness depends on the quality of cataloging but that will vary. :) |
| 10:15 |
kmlussier |
rhamby: Great, thanks for throwing that out there. |
| 10:16 |
kmlussier |
I'm going to move on to the next topic now, but if you think of anything else while we continue the discussion, feel free to put it out there. |
| 10:16 |
kmlussier |
#topic Areas of improvement |
| 10:16 |
kmlussier |
Where are the areas where you would like to see improvement in Evergreen's search? |
| 10:16 |
JBoyer |
I think there's been a consensus among larger groups around speed. |
| 10:17 |
yboston |
as powerful and useful that "stemming" can be; currently the implementation can be useless for certain words like: music, musician, musical |
| 10:17 |
kmlussier |
Yes, speed was a big focus of the discussion the developers had at the hack-a-way. |
| 10:17 |
JBoyer |
(As in more of it, that was kind of a partial thought) |
| 10:17 |
yboston |
since they all stem to "music" |
| 10:18 |
yboston |
(is stemmign the right word in EG/postgres? can't remember) |
| 10:18 |
JBoyer |
yboston: yes. |
| 10:18 |
jeff |
One of the things we hear from patrons and staff is "unforgiving". |
| 10:18 |
kmlussier |
yboston: So it sounds like you're acknowledging that fuzziness is a desired feature, but that you would like to see more precision within that context? |
| 10:18 |
JBoyer |
Parallelization would also be helpful for this, and may allow other interesting improvements. |
| 10:18 |
kmlussier |
jeff: hmmm...can you elaborate on that? |
| 10:19 |
miker |
(note: stemming is extremely configurable at the PG level, we just don't surface the pg features through the staff client) |
| 10:19 |
yboston |
kmlussier: yes, I kinda want it both ways to a degree |
| 10:20 |
jeff |
kmlussier: What, you want more than a single word? ;-) |
| 10:20 |
kmlussier |
JBoyer: Also, can you explain more what you mean by parallelization and where it could result in improvements? |
| 10:20 |
kmlussier |
jeff: How about 10? ;) |
| 10:21 |
yboston |
miker: thanks for bringing this up, I looked at the PG optiosn but was not sure what to try |
| 10:21 |
jeff |
kmlussier: "unforgiving" meaning that if you provide a search string that is not found in a record, barring stemming and possibly some other things, you won't get the results you're looking for. |
| 10:22 |
jeff |
kmlussier: it sounds silly when you say "i want to see matches for things i didn't search for", but... that's the user expectation. |
| 10:22 |
jeff |
kmlussier: "find what i mean, not what i searched for" |
| 10:22 |
alynn26 |
jeff: that is one thing I hear from around here. |
| 10:22 |
kmlussier |
jeff: And these are things that if they searched in Amazon or Google, they would probably get the match they're looking for, right? |
| 10:22 |
jeff |
kmlussier: or, in two words: "be fuzzier" |
| 10:23 |
kmlussier |
What I'm hearing, in conjunction with yboston's comments, is smarter about the fuzziness. |
| 10:23 |
JBoyer |
Currently the speed of a search is limited to how fast a single core can handle the results of a query limited to 10000 (configurable) records. If instead we were running 10 cores against the results of 1000 records it would be difficult not to be somewhat faster. The other interesting improvements part I hadn't fully formed, I think I mean that in a larger backend context than just search. |
| 10:23 |
jeff |
kmlussier: pretty much. |
| 10:23 |
kmlussier |
JBoyer: Thanks for the further explanation. |
| 10:24 |
JBoyer |
jeff, kmlussier: for better or worse the best example I can think of for that is searching for au:Meyer,stephanie (that's not how she spells it) and the the catalog saying that we don't have any of the Twilight books. |
| 10:24 |
kmlussier |
Since we're talking about the fuzziness vs. precision question, are there other ways the system could assist the user in finding what they need? |
| 10:24 |
jlundgren |
would fuzziness also address better search results for one word titles and alternate author names |
| 10:24 |
JBoyer |
re: jeff's point, that is. |
| 10:24 |
ScottThomas |
I've always wondered how Amazon does their indexing and stemming because it is so much friendlier than any OPAC I've ever tried. |
| 10:25 |
yboston |
Here we get hurt by document density(?), when we have a great bib records with lots of extra 7xx and 945 (song title tags) for a musical album, but the top choices are tiny horrid MARC record with only a 245 and a 100 tag for elctronic records |
| 10:25 |
kmlussier |
ScottThomas: I could be wrong, but I think some of it is based on user behavior. |
| 10:25 |
kmlussier |
ScottThomas: If a title is offered and users click on it a lot, it's seen as a better match. |
| 10:26 |
miker |
ScottThomas: a big part of amazon is human curation, and another is the fact that they link their stuff |
| 10:26 |
miker |
(and what kmlussier said) |
| 10:26 |
kmlussier |
yboston: Yes, I hear that too. Shorter records seem to get higher relevance. |
| 10:26 |
jeff |
also, money. :-) |
| 10:26 |
kmlussier |
jlundgren: I don't know if fuzziness would address it, but could you describe the problem you're seeing? |
| 10:26 |
miker |
jeff: also, data ;) |
| 10:27 |
jeff |
miker: also, data. agreed. :-) |
| 10:27 |
kmlussier |
jeff: Amazon has more money, but then those who don't have the money can learn from their lessons, right? :) |
| 10:27 |
jlundgren |
with one word titles, they are often not at the top of search results especially with common words (ex. The Blue) |
| 10:28 |
miker |
yboston / kmlussier: re record quality, we already try to track that, and could easily make it more important. record size (by field count) is a huge component of that already... |
| 10:28 |
kmlussier |
OK, so better relevance for one-word titles (I'm guessing 245a |
| 10:28 |
jlundgren |
For the author names, our libraries get frustrated when the name on the book doesn't match the MARC and results aren't returned when they type for example Judith Jance vs JA Jance |
| 10:29 |
kmlussier |
Just a note, as we review the notes for these focus groups, we will follow up with what's doable and how to do it, so that we don't have to go into all the dirty details of what miker is mentioning now. |
| 10:29 |
kmlussier |
jlundgren: OK, thank you for the further clarification. |
| 10:29 |
miker |
kmlussier: the algos that amazon/google use are 1) based on linked data 2) hard (as in, complicated, and cpu-expensive) ... ISTM that every other retailer would have good search if it was just a matter of learning from amazon |
| 10:30 |
kmlussier |
miker: gotcha |
| 10:30 |
jeff |
also, the search interface of large companies are not without error or fault. we shouldn't get hung up on imitating them. |
| 10:30 |
kmlussier |
So I'm hearing comments in terms of better speed, better balance between fuzziness and precision, some relevance issues. |
| 10:30 |
miker |
kmlussier: gotcha (re details) ... I'll hold off, except where there may be a misunderstanding about what does exist (assuming I'm in the room -- which I'm not officially right now ;) ) |
| 10:31 |
JBoyer |
(It's a ghost!) |
| 10:31 |
kmlussier |
miker: You do a good job of not being in the room |
| 10:31 |
miker |
BOO |
| 10:31 |
miker |
kmlussier: ... |
| 10:32 |
kmlussier |
ScottThomas: In the things we like part, you mentioned attempt at autocomplete. The way you worded it made me think there was also a "room for improvement" piece to it. |
| 10:32 |
jeff |
i think that summarizing (at least the points i mentioned) as "be more like {google|amazon|whatever}" would be doing ourselves a disservice. |
| 10:32 |
* dbs |
simul-attending a conf call, but wants to respond to kmlussier's "what do you want" with "speed - particularly with formats, copy locations, other options enabled" |
| 10:32 |
kmlussier |
jeff: No, I have no intention of summarizing it that way. |
| 10:32 |
miker |
jeff++ |
| 10:32 |
kmlussier |
dbs: Great, thanks! |
| 10:33 |
* csharp |
notes that the original PINES focus group flipchart sheets from 2004/2005 are full of "search more like google/amazon"-type items |
| 10:33 |
kmlussier |
jeff: I was just using it as a reference point as to why users are expecting to find records when the search terms don't match. |
| 10:33 |
rhamby |
Let's remember that CPU power is less of an issue for Amazon to throw at problems than it is for libraries since they own what might be the largest server farms in the world. :) |
| 10:33 |
jeff |
"nice to haves" include: "show me EVERYTHING with copies in these locations at these libraries" |
| 10:34 |
ScottThomas |
Autocomplete is a nice feature, but it seems wonky. When I type in "Harry" in the Keyword index, "Harriet" (Title) is the first thing that appears. |
| 10:34 |
yboston |
Autosuggest needs improvements 1) work for screen readers (though it worked fine recetnly with a blind Berklee professor) 2) be able to "highlight" in red lettters with diacritics |
| 10:34 |
jeff |
as opposed to "search for all records then filter them by a shelving location / etc" |
| 10:35 |
miker |
jeff: use-specific api? IOW, does that need to be "search"? |
| 10:35 |
jeff |
rhamby: also, remember that there are ways to avoid needing prohibitive amounts of CPU. we're running most in-building search on a pretty modest VM or two. |
| 10:35 |
miker |
it sounds like "browse" to me |
| 10:36 |
kmlussier |
Just a reminder that this is brainstorming for now to throw ideas out there. |
| 10:36 |
JBoyer |
miker: I take that to mean "Here are some additional constraints, I should use these to tighten up the core query rather than checking for them ATF." |
| 10:36 |
miker |
yboston: that's great news (autosuggest working recently with a screen reader) |
| 10:36 |
csharp |
I attended a session on Blacklight yesterday and one of the presenters afterwards made a point about the goals of search vs the goals of data storage and that using the same mechanism for both can be problematic |
| 10:36 |
alynn26 |
One thing I find missing, is Item searching completely. I am thinking I want all items ( Not titles) that have a certain shelving location and a certain Circ Modifier at a certain library. |
| 10:36 |
jeff |
miker: yup. no objection here. it might be nice if it could be somewhat transparent -- the backend decides to use the use-specific API based on the search input. |
| 10:37 |
miker |
JBoyer: I took it as "what's on this shelf (and maybe let me order by my choice of attribute/field)" ... |
| 10:37 |
kmlussier |
alynn26: OK, so you would like to do more searching at the item level. |
| 10:37 |
alynn26 |
yes, rather than having to run reports everytime. |
| 10:37 |
jeff |
alynn26: that suggests a reporting interface or use case to me -- do you think the item-level view is something mostly for staff, or patrons? |
| 10:37 |
kmlussier |
Since we're about 35 minutes in, I'm would like to move on to the next question. |
| 10:38 |
miker |
alynn26: is that something you want to expose to patrons? |
| 10:38 |
JBoyer |
I meant to mention this earlier: Regularly there are requests to search Copy Notes. I would assume that could be staff only, unless you want to look up the items your grandfather left to the library or something similar. |
| 10:38 |
alynn26 |
jeff: staff mostly |
| 10:38 |
* miker |
just lets jeff read his mind from now on ;) |
| 10:38 |
jeff |
alynn26: yeah, we have nice reports for those kinds of things. sometimes people then click through to the opac view for a given bib from the report, which is handy... |
| 10:39 |
kmlussier |
#topic Features from other search tools / features that make Evergreen unique |
| 10:39 |
JBoyer |
miker: True, re: the "EVERYTHING" part, but in a broader sense if I'm limiting to a specific library the CQ could in theory be limited to items they hold. |
| 10:39 |
kmlussier |
Are there features you see in other search tools, particularly those that, like Evergreen, are primarily searching metadata, that you would like to see implemented in Evergreen? Conversely, is there something Evergreen search has that makes it unique? |
| 10:40 |
JBoyer |
(This is fresh on my mind recently because there's a lib with a common keyword that won't return results until you up the core limit to 50K+...) |
| 10:40 |
kmlussier |
For clarification, I'm highlighting search tools that search metadata because I think tools like Google are an entirely different animal. Full-text searching is different than what we're doing. |
| 10:42 |
jeff |
kmlussier: while realizing that you don't want to steer/influence the conversation too much, do you have any examples of such tools in mind? it might help to understand where you're coming from. |
| 10:42 |
yboston |
In a previous ILS I again had created a local index for ib tag 945 (for song titels). Unlike EG, when I searched for a song it only matched words ina single 945 tag. I beleive EG matches on words that may appear in adjoining 945 tags? |
| 10:42 |
kmlussier |
Yeah, I have lots of ideas, but I don't like to steer the conversation. An example of something that comes up all the time here is "Did you mean?" |
| 10:42 |
JBoyer |
I'll also admit that 99%+ of my searching happens in a FTS context (Google, Bing) I'm actually a poor library/journal user. |
| 10:43 |
jlundgren |
facet for publication date to limit result set by year of publication |
| 10:43 |
yboston |
I think this "adjoining tag words" can happen with repeated tags??? |
| 10:43 |
yboston |
(n EG) |
| 10:45 |
kmlussier |
jlundgren: OK, I want to summarize that as facets that aren't based on data in MARC fields, but, in this case, the data is in the MARC fields. You would just want that facet to be treated differently than we currently do facets? |
| 10:45 |
miker |
(yboston: yes, you can search across all 945's in any given record, if you choose) |
| 10:45 |
yboston |
miker: I want the opposite |
| 10:45 |
kmlussier |
jlundgren: IOW, I'm thinking you don't just want a facet with a long list of dates, but maybe a way to specify a range of dates. |
| 10:46 |
miker |
yboston: you can have the opposite, too :) |
| 10:46 |
yboston |
miker: not sure how to do it |
| 10:46 |
miker |
yboston: let's discuss later ;) |
| 10:46 |
* miker |
dodges kmlussier |
| 10:46 |
yboston |
miker: thanks!!! |
| 10:46 |
kmlussier |
JBoyer: If there are features from those searches you think would be useful in Evergreen, go with it. Sorry, I didn't mean to keep you from bringing one up. :) |
| 10:46 |
kmlussier |
If you had one in mind |
| 10:46 |
jlundgren |
kmlussier: yes that is correct |
| 10:48 |
kmlussier |
I'm going to give this question a minute longer before I move on. |
| 10:48 |
kmlussier |
Maybe everything had already been covered by the previous topic. |
| 10:48 |
miker |
jlundgren / kmlussier: "typed limiters" |
| 10:48 |
miker |
yes? |
| 10:48 |
JBoyer |
kmlussier: That was me seconding jeff's request that you maybe give an example of another metadata search tool. :) My primary desire would be a Did you Mean, which would be most easily implemented by storing every Q in the db and looking for "similar" ones. Difficult. |
| 10:49 |
miker |
or, "typed facets" I guess ... so that they're data type or context aware |
| 10:49 |
jeff |
"did you mean" can be "here, we tried your terms against some authority records" |
| 10:49 |
miker |
"it's a year" ... "it's a size" ... etc |
| 10:49 |
jeff |
or lots of other options. |
| 10:49 |
kmlussier |
Yeah, I |
| 10:49 |
miker |
jeff: that's actually what the jspac did, fwiw |
| 10:49 |
miker |
authority records, I mean |
| 10:49 |
JBoyer |
All 3 are possible ways to do implement it. |
| 10:50 |
kmlussier |
I'm not particularly interested right now in how the "did you mean?" gets implemented, but just that it's an example of a feature. Other examples of metadata search tools would be other library catalogs or even Amazon, which isn't searching the full text of the book. |
| 10:50 |
kmlussier |
But I also don't want to re-enter the discussion of 'don't just make it like Amazon.' |
| 10:51 |
* kmlussier |
is moving on for now |
| 10:51 |
kmlussier |
#topic Factors used in relevance |
| 10:51 |
JBoyer |
I'd like to see a "users that did this also did this" type of feature, but it's not necessarily search specific (and patron privacy concerns may lurk thereabouts) |
| 10:51 |
kmlussier |
We already addressed this a bit above, but the question comes from conversations I've had where we say, 'we want to improve relevance,' and the first question I get back is 'what do you mean by relevance?" |
| 10:52 |
kmlussier |
My question, then, is what factors do you think are important when ranking search results by relevance? |
| 10:52 |
kmlussier |
JBoyer: Thanks for putting that out there. It might not be primarily search, but I do think it's related because it helps people find what they're looking for. |
| 10:53 |
kmlussier |
Another way to phrase the question, when you type a search, what should determine which record comes up first? |
| 10:53 |
dbwells |
Sorry to jump in late, but I think our biggest desire is also generally in the speed camp, but more specifically, consistency and predictability of that speed. People generally think (and rightly) that smaller result sets means quicker turnaround, but then get flummoxed when trying to reduce the set size by choosing a location or org_unit, and this actually makes their search take longer. |
| 10:53 |
ScottThomas |
The obvious one is recency. Patrons seem to want to see new stuff first. |
| 10:54 |
kmlussier |
ScottThomas: So recency should play a role. Good. |
| 10:54 |
JBoyer |
Date published, holdings count (more = better), circ count in the last year (possibly as a percentage of circs across a dewey range or subject group, that's very fuzzy) |
| 10:54 |
kmlussier |
ScottThomas: But I assume recency isn't the only thing if those search words are buried in the notes, right? |
| 10:54 |
|
ericar_ joined #evergreen |
| 10:54 |
yboston |
as a coutner point, I don;t think for academics libraries there is such a strong desire for recency |
| 10:54 |
kmlussier |
JBoyer: Intersting, so you want to make sure activity/popularity is included. |
| 10:54 |
jeff |
"recency" can really bury relevant results for some users/searches. |
| 10:55 |
jeff |
we once had a request for "the default search sort should be pubdate newest to oldest" -- it was withdrawn rather quickly. |
| 10:55 |
kmlussier |
Of course, any one factor used can make one search better, and another search worse. Search is hard. |
| 10:55 |
* jeff |
nods |
| 10:56 |
|
rlefaive joined #evergreen |
| 10:56 |
jeff |
i've drawn the comparison to at least one children's tool -- where you push down on this peg, and this other peg pops up... :-) |
| 10:56 |
kmlussier |
From the discussion up above, I know shorter records was seen as an issue with relevance, I'll read the logs to see if there are any others that came up. |
| 10:56 |
jeff |
s/tool/toy/ |
| 10:56 |
kmlussier |
jeff++ |
| 10:56 |
ScottThomas |
Our demographics slew older so our patrons seem to like sorting results newest to oldest because they are used to pre-Google OPACs. |
| 10:57 |
yboston |
I already mentioned earlier that cover density has frustrated us, when we have really short (and sloppy) records always float to the top. but apparently there are ways that can be addressed |
| 10:57 |
kmlussier |
ScottThomas: When you say newer, are you referring to publication date or when the record was added? |
| 10:57 |
* kmlussier |
will need to leave more time for the relevance question next time. |
| 10:58 |
kmlussier |
We have two minutes left, so I want to ask my last question. |
| 10:58 |
yboston |
also, we woudl want more relevance to certain tags like 1xx or 245, but currently it has a big performace hit to do that(?) |
| 10:59 |
kmlussier |
yboston: Relevance for specific MARC fields. I can answer your question regarding performance after we wrap up. |
| 10:59 |
kmlussier |
But I'm noting it down as something that is seen as important for relevance. |
| 10:59 |
kmlussier |
Last question |
| 10:59 |
kmlussier |
We talked about lots of improvements here, but if there was just one improvement that you would make to search, what would it be? |
| 11:00 |
kmlussier |
The one and only thing you would do to make search better. |
| 11:00 |
alynn26 |
speed |
| 11:00 |
jeff |
speed. |
| 11:00 |
JBoyer |
same. |
| 11:01 |
jeff |
(and hopefully goes without saying, but speed without degredation of quality) |
| 11:01 |
kmlussier |
jeff: I think it should be stated. |
| 11:01 |
kmlussier |
Anyone else? |
| 11:02 |
dbwells |
A certain speed threshold is magic elixir for search. Users are much more willing to accept a bad search result if trying again is super fast. |
| 11:02 |
kmlussier |
OK, I'm going to end the meeting, but if anyone else who was actively participating wants to chime in on that question, feel free to let me know. I'll be here all day. |
| 11:02 |
kmlussier |
#endmeeting |
| 11:02 |
pinesol_green |
Meeting ended Tue Mar 8 11:02:56 2016 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 11:02 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-08-10.00.html |
| 11:02 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-08-10.00.txt |
| 11:02 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-03-08-10.00.log.html |
| 11:03 |
kmlussier |
Thanks everyone! |
| 11:03 |
yboston |
kmlussier: improved stemming is my last thought |
| 11:03 |
* berickm |
looks forward to reading the notes |
| 11:03 |
JBoyer |
kmlussier: perhaps for the other chats, give an option for 2 improvements if #1 is speed? Not sure if it helps, but I wonder if it might not be more illustrative (for the future, if nothing else) |
| 11:03 |
kmlussier |
Also, if anyone wants to give feedback on the questions asked, ways to improve the discussion, let me know. |
| 11:03 |
berickm |
er, minutes |
| 11:04 |
kmlussier |
As JBoyer just did. Thanks JBoyer! |
| 11:04 |
kmlussier |
I think it's useful in seeing what the clear priority is, but I don't think 2 options would necessarily take away from that. |
| 11:05 |
JBoyer |
That said, I hadn't come up with a #2 actually, I just didn't want there to be a single dogpile of "moar fast" and nothing else. :) |
| 11:07 |
kmlussier |
yboston: In terms of your question on MARC field weighting for relevance, both C/W MARS and NOBLE use MARC field weighting. |
| 11:08 |
yboston |
kmlussier: I thought there was a big performance hit when doing that |
| 11:08 |
kmlussier |
yboston: If you're doing it for the title proper and author, as you mentioned, I don't think the hit on performance is too bad. It's when you start adding lots and lots of indexes that I think you start to see a performance hit. |
| 11:08 |
yboston |
kmlussier: I can put in aticket with ESI to see if they think it would be OK to do on my system |
| 11:08 |
yboston |
kmlussier: I see |
| 11:10 |
kmlussier |
yboston: You might be thinking about the big performance hit you get when using the search.relevance_adjustment table. |
| 11:10 |
miker |
yboston: it would be fine for 2 fields. warnings start when we're talking about 50+ fields ... not naming any names... |
| 11:11 |
yboston |
kmlussier: I think I may be confused |
| 11:13 |
|
vlewis joined #evergreen |
| 11:13 |
kmlussier |
Usually, 50+ fields are added not just due to relevance, but because they want additional fields searched. Speaking for the unnamed names, I would say they strongly beleive they should have that flexibility without a big hit on performance. ;) |
| 11:13 |
kmlussier |
believe, even |
| 11:14 |
yboston |
kmlussier: I mean that I was thinking of search.relevance_adjustment table and not sure what the other approach is |
| 11:14 |
kmlussier |
yboston: I'm curious. What screen reader was your professor using? Was it JAWS? |
| 11:15 |
yboston |
kmlussier: I am pretty sure I just have to review some of your prevoius presentation |
| 11:15 |
yboston |
*presentations on search |
| 11:15 |
yboston |
kmlussier: yes, he used JAWS |
| 11:15 |
kmlussier |
Interesting |
| 11:16 |
yboston |
kmlussier: his biggest complaint was that there are HTML tables inside of HTML tables used |
| 11:16 |
yboston |
kmlussier: when listing volume/copy info |
| 11:16 |
yboston |
kmlussier: extremely hard to navigate thorugh with a screen reader |
| 11:16 |
kmlussier |
I no longer have access to JAWS, so I don't know if I can re-test it |
| 11:16 |
kmlussier |
yboston: Also, do you know if he had javascript turned off? |
| 11:17 |
yboston |
kmlussier: I might have made a bug about the nested table? |
| 11:17 |
yboston |
kmlussier: I was standign right next to him and saw the autosuggest trigger |
| 11:17 |
kmlussier |
yboston: I don't remember seeing it, but I find I'm having a difficult time remembering LP bugs as well as I used to. |
| 11:17 |
yboston |
kmlussier: I think he just tabbed(?) away from the auto sugegst |
| 11:17 |
yboston |
kmlussier: I will look for it |
| 11:18 |
yboston |
lp 1467645 |
| 11:18 |
pinesol_green |
Launchpad bug 1467645 in Evergreen "OPAC's search results use of nested tables create page navigation issues for screen reader users" [Undecided,New] https://launchpad.net/bugs/1467645 |
| 11:19 |
yboston |
kmlussier: I created it back in June 2015 |
| 11:19 |
kmlussier |
Tabbing away from the autosuggest? The problem essentially was that the screen reader wasn't telling the user that they were on a text-entry form. So they basically didn't know where they were supposed to enter their search terms. |
| 11:19 |
kmlussier |
yboston: That would explain why I don't remember it. :) |
| 11:20 |
dbs |
@blame dojo |
| 11:20 |
pinesol_green |
dbs: It really IS dojo's fault! |
| 11:20 |
dbs |
@blame really_old_dojo |
| 11:20 |
pinesol_green |
dbs: really_old_dojo is NOT CONNECTED TO THE NETWORK!!! |
| 11:20 |
yboston |
kmlussier: I don't think we are out of the woods, but when I watched him trigger the auto suggest I asked him if that was a problem and he said no |
| 11:22 |
|
jvwoolf1 joined #evergreen |
| 11:22 |
jwoodard |
@praise record buckets |
| 11:22 |
* pinesol_green |
In days of old, it was prophesied that a hero would come and restore karmic balance to #evergreen. record buckets is that hero. |
| 11:24 |
|
kmlussiercopy joined #evergreen |
| 11:39 |
miker |
kmlussier / yboston: current c4l talks is relevant to your current interests ... it's streaming somewhere, and will be archived for later viewing. about a11y. |
| 11:40 |
kmlussier |
miker: Excellent! Thanks for the tip. |
| 11:40 |
yboston |
miker: thanks |
| 11:49 |
|
eady joined #evergreen |
| 11:50 |
|
jihpringle joined #evergreen |
| 11:50 |
* csharp |
just ran gapines.org through http://wave.webaim.org/ and wasn't dismayed at the results |
| 11:51 |
kmlussier |
csharp: I just ran a stock catalog through another checker recently. It wasn't too bad. |
| 11:52 |
csharp |
kmlussier: I just tried webby.evergreencatalog.com and it kind of choked |
| 11:53 |
csharp |
but that wasn't because of accessibility |
| 11:53 |
kmlussier |
huh |
| 11:58 |
|
agent11 joined #evergreen |
| 12:06 |
|
bmills joined #evergreen |
| 12:21 |
|
kitteh_ joined #evergreen |
| 12:32 |
gsams |
I sent the survey to my consortium's general list |
| 12:32 |
gsams |
It was suggested to add an option "All of the above" to the question "How do you use Evergreen?" |
| 12:33 |
gsams |
I got a good laugh out of it |
| 12:33 |
gsams |
since it's a select all that apply |
| 12:36 |
mmorgan |
:) |
| 12:36 |
|
vlewis joined #evergreen |
| 12:39 |
|
ericar joined #evergreen |
| 12:44 |
jwoodard |
gsams: less clicking ;) |
| 12:44 |
jwoodard |
Or a "Evergreen Overlord" option would suffice |
| 12:47 |
kmlussier |
Did somebody just say my name |
| 12:47 |
kmlussier |
? |
| 12:47 |
gsams |
kmlussier++ |
| 12:48 |
jwoodard |
haha |
| 12:48 |
jwoodard |
I sure pinesol green would contest that title |
| 12:50 |
bshum |
I was literally typing "all hail pinesol_green, the first of his name" jwoodard :P |
| 12:51 |
gsams |
bshum++ |
| 12:55 |
jwoodard |
All hail His Grace, pinesol of House Green, First of His Name, King of Evergreen and the devs, Lord of the PINES, and Protector Library materials. |
| 12:58 |
krvmga |
ROFL |
| 12:59 |
krvmga |
kmlussier++ |
| 12:59 |
krvmga |
bshum++ |
| 12:59 |
krvmga |
jwoodward++ |
| 13:04 |
Dyrcona |
Doh! It helps to have the right branch checked out when you're trying to cherry-pick. |
| 13:07 |
Dyrcona |
I mean, it doesn't work if you have the branch you're cherry-picking from checked out, instead of the one you want to cherry-pick into. |
| 13:07 |
|
berickm joined #evergreen |
| 13:21 |
csharp |
@quote add < jwoodard> All hail His Grace, pinesol of House Green, First of His Name, King of Evergreen and the devs, Lord of the PINES, and Protector Library materials. |
| 13:21 |
pinesol_green |
csharp: The operation succeeded. Quote #145 added. |
| 13:28 |
Dyrcona |
@quote random |
| 13:28 |
pinesol_green |
Dyrcona: Quote #72: "<RoganH> gmcharlt: just because it got warmer in Niflheimr doesn't mean you're in Vanaheimr yet." (added by gmcharlt at 10:27 AM, January 07, 2014) |
| 13:44 |
|
mmorgan joined #evergreen |
| 14:06 |
|
rlefaive joined #evergreen |
| 14:41 |
|
remingtron joined #evergreen |
| 14:45 |
|
mmorgan1 joined #evergreen |
| 15:06 |
|
jvwoolf1 joined #evergreen |
| 15:07 |
|
jvwoolf1 joined #evergreen |
| 15:09 |
|
mmorgan joined #evergreen |
| 15:21 |
|
berickm joined #evergreen |
| 16:00 |
kmlussier |
miker: Thinking back on something you said earlier, in terms of using record quality for relevance, are you thinking of the record quality configuration we use in Vandelay? |
| 16:01 |
|
jlitrell joined #evergreen |
| 16:01 |
miker |
kmlussier: no, I'm thinking of biblio.record_entry.quality |
| 16:04 |
miker |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/030.schema.metabib.sql;h=f7aa05a631cb26c8077192956aba00e4c81ac9cd;hb=HEAD#l952 |
| 16:06 |
miker |
kmlussier: main things that code cares about are tag count and record type. |
| 16:06 |
miker |
and language |
| 16:06 |
kmlussier |
miker: Thanks for the link. You anticipated my next question. |
| 16:07 |
miker |
like I did to fingerprint back in the day, a niceness would be making that configurable |
| 16:09 |
Bmagic |
did any one see bug 1552409 or have a chance to consider it? |
| 16:09 |
pinesol_green |
Launchpad bug 1552409 in Evergreen "Invent a page in the OPAC for redirection to referring URL based authentication on external services such as EBSCO" [Undecided,New] https://launchpad.net/bugs/1552409 |
| 16:09 |
miker |
having that already separated, though, would let us make use of the field in interesting ways |
| 16:10 |
miker |
**cough**badges**cough** |
| 16:11 |
kmlussier |
miker: Speaking of badges, I did a speedy five-minute badge recalculation this morning. :) |
| 16:13 |
JBoyer |
Bmagic: I thought it looked like a good idea and I think it would be really simple unless I've misunderstood something about how those auth pages work, but I haven't had time to look at it at all. |
| 16:13 |
Bmagic |
JBoyer: right on - just making sure I didn't miss some other option |
| 16:14 |
Bmagic |
Before I spend time pursuing this avenue |
| 16:14 |
miker |
kmlussier: rock! |
| 16:15 |
miker |
Bmagic: not much chance of getting them to use our safe-authtoken verification API, eh? |
| 16:16 |
jeff |
miker: "we support both kinds of patron authentication -- SIP2 *and* PatronAPI!" |
| 16:16 |
Bmagic |
miker: I don't think little old me(small library group) can cause much change in such a giant |
| 16:18 |
Bmagic |
I know there was some conversation about Evergreen+Shibboleth ? |
| 16:19 |
miker |
for ref, the statewide database system in GA implemented it in a matter of weeks... csharp is a better contact for them, but they wouldn't be alone even in this specific use case |
| 16:19 |
Bmagic |
miker: implemented what? |
| 16:19 |
miker |
I don't recall a shib conversation |
| 16:20 |
miker |
implemented the auth verification stuff we already have |
| 16:20 |
Bmagic |
oh? With Ebsco? |
| 16:20 |
csharp |
safe auth is used for GALILEO (Georgia's online content provider) |
| 16:21 |
miker |
I'm pretty sure they have ebsco content behind the service |
| 16:21 |
csharp |
I know about the EG side, but not much about the GALILEO side |
| 16:22 |
csharp |
we pass them the "safe" authtoken when a user logs in |
| 16:23 |
Bmagic |
forgive me - what is PatronAPI? OpenSRF? |
| 16:23 |
miker |
I think Jeff is referring to an ncip message |
| 16:23 |
jeff |
PatronAPI is a III thing. |
| 16:24 |
miker |
oh, even better! ;) |
| 16:24 |
jeff |
We had a vendor that supported SIP2 or PatronAPI. We made a PatronAPI shim for Evergreen because $REASONS |
| 16:25 |
Bmagic |
ok - so, the referring URL idea isn't a waste of time? |
| 16:25 |
jeff |
I have ideas of making a "reference good guy vendor implementation" to demonstrate how some of this could work a lot better. |
| 16:27 |
miker |
Bmagic: will it force auth on every link, or only when not already logged in? |
| 16:27 |
Bmagic |
if they are authenticated to the OPAC, it shouldn't ask for another login |
| 16:29 |
Bmagic |
EGCatLoader.pm sub load contains a list of URL's - this would be one more in the "requires authentication" section |
| 16:31 |
miker |
probably not a waste, then, but I'd personally love to see a way to do it without modifying the in-record URL... |
| 16:32 |
Bmagic |
oh totally, that would be sweet! |
| 16:33 |
Bmagic |
editing the $9 is fine with me. (at least I can see some light at the end of that tunnel) |
| 16:33 |
miker |
maybe the use-restriction subfield could inform the need -- that's captured in located URIs |
| 16:35 |
Bmagic |
you mean manipulate the URL during template load time based on some criteria embedded elsewhere? |
| 16:36 |
dbwells |
We currently manipulate URLs within the template to redirect things through our proxy server. Probably a simpler use case than what you guys are talking about, though. |
| 16:37 |
miker |
Bmagic: that's my thought, half formed as it is, yep |
| 16:38 |
Bmagic |
miker: That is a good idea! I will think about that a bit |
| 16:38 |
Bmagic |
The ten thousand dollar question is - does this sound like a feature that anyone else would use? |
| 16:39 |
dbwells |
Actually, we route all outbound clicks through an independent script which does stat keeping, redirecting, etc. It's a system we carried over from pre-Evergreen, but it still does what we need. |
| 16:39 |
miker |
Bmagic: it does to me. see: most ezproxy users :) |
| 16:40 |
Bmagic |
dbwells: does it authenticate the patron? |
| 16:41 |
dbwells |
Bmagic: Yes, via ezproxy, as miker supposed |
| 16:41 |
Bmagic |
ah yes, ezproxy |
| 16:43 |
Bmagic |
we considered that option, but there is a cost, and each library would need to maintain it. To many issues to overcome there. Money is probably the real show stopper though |
| 16:43 |
miker |
Bmagic: trick would be making the proxy URL configurable, not just the shim you're planning for ebsco |
| 16:44 |
Bmagic |
your idea with the template URL manipulation has some potiential for sure. I was just going to update all of the $9's with a script... but your idea is better |
| 16:45 |
dbwells |
We're not too eager to use EZProxy indefinitely with the new subscription model. Better alternatives are not obvious, though. |
| 16:47 |
jeff |
and of course status_changed_time and edit_date remain untouched when a copy moves from Reshelving to Available |
| 16:47 |
* jeff |
frowns |
| 16:51 |
dbwells |
Bmagic: You say update $9, but do you mean $u? I am trying to figure out if there is some way to use $9 I don't know about. |
| 16:51 |
miker |
jeff: an argument could be made for stsus change time, I think. LP? |
| 16:52 |
miker |
@marc 856 |
| 16:52 |
pinesol_green |
miker: The information needed to locate and access an electronic resource. The field may be used in a bibliographic record for a resource when that resource or a subset of it is available electronically. In addition, it may be used to locate and access an electronic version of a non-electronic resource described in the bibliographic record or a related electronic resource. (Repeatable) (1 more message) |
| 16:52 |
Bmagic |
dbwells: oh right, yeah $u (im thinking in terms of the $9 because that is what so many of my scripts use) |
| 16:52 |
jeff |
miker: yeah, giving it a little more thought and at least a quick check to see that this isn't something that's changed 2.7... |
| 16:52 |
miker |
@more |
| 16:52 |
pinesol_green |
miker: [a,b,c,d,f,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,2,3,6,8] |
| 16:52 |
miker |
arg |
| 16:52 |
jeff |
miker: also, i think one/both of those fields are left untouched when a bib merge results in a deleted bib. |
| 16:52 |
jeff |
heh. @more on a tag like that should probably also just offer a link to loc. ;-) |
| 16:53 |
jeff |
http://www.loc.gov/marc/bibliographic/bd856.html |
| 16:53 |
miker |
jeff: well, that's bib level... what should change? |
| 16:54 |
jeff |
miker: sorry, think-o. bibs don't have status_changed_time, but i think (unconfirmed) that the bre.edit_date on the losing bib might not be set when it's deleted. |
| 16:55 |
jeff |
miker: iirc, acp objects get their edit_date bumped when deleted, though i could be wrong there also. |
| 16:55 |
dbwells |
Bmagic: okay :) Looking at what we did, it just amounted to a couple lines in misc_util.tt2 (one for normal 856s, one for located URIs (we still use both)). If you search for 'href' in there it should be pretty obvious where to wedge things in. |
| 16:56 |
Bmagic |
dbwells: cool |
| 16:57 |
miker |
for use-restriction, I'm thinking of z, 2, or n. in that order, per the code |
| 16:58 |
miker |
jeff: thanks for the link, BTW! |
| 17:06 |
dbwells |
We've got it pretty easy re: forced-authentication; if you are on campus, you don't need to authenticate for anything, if you are off-campus, you authenticate for everything :) |
| 17:06 |
|
mmorgan left #evergreen |
| 17:33 |
|
Christineb joined #evergreen |
| 18:31 |
|
geoffsams joined #evergreen |
| 18:31 |
|
rlefaive joined #evergreen |
| 20:38 |
|
stephengwills joined #evergreen |
| 20:40 |
|
stephengwills joined #evergreen |
| 20:48 |
|
berickm joined #evergreen |
