UX/UI and FM - notes, September 28, 2016

 

Participants: Cate Boerema (EBSCO), Index Data, Andrea Loigman (Duke), David Larsen (Chicago), Filip Jakobsen, Jack Hill (Duke), Jesse Koennecke (Cornell), Lisa McColl (Lehigh), Maike Osters (hbz), Maria Grezschniok (GBV), Michael Winkler (OLE), Rameke Barnes (??), Texas A&M, William (??)

 

  • Wiki Page
    • Did everyone get access to the wiki page?  Yes, a couple of people have gotten access
    • Can we add a link to the FM from this page? 
      • Charlotte will do this
    • Where is the agenda for these meetings?
      • Agenda is posted to the UX channel, as well, because there are many people on the all
    • Wiki page requires a password but Discuss doesn’t (at least just to view)
      • They don’t use the same username password – Charlotte will talk to Peter
      • If we want our meeting minutes to be open, we should have the somewhere that doesn’t require a password
      • Wiki seems like the right place for this info – Charlotte will talk to Peter about removing password requirement
    • Can we link to the list of different groups from the wiki landing page?
      • Charlotte will do this
    • Charlotte is going to put the most recent minutes and agenda at the top (switch the order)
  • Functional Matrix Review 
    • Entry 205 
      • We are not dealing with the OPAC now
      • But, this is not about the OPAC
      • There needs to be an API that and OPAC can leverage
      • Set of APIs is needed
      • The API will enable the OPAC developers to talk to the data
      • We need to be able to access: patron info, loans, fines, payments, request renewals
      • Should we be able to go directly to the tables?
        • If the tables aren’t accessible or readable, we won’t be able to work around things that don’t function
        • Maybe this is a new number in the matrix that we need direct access to the tables?
        • Direct read/write access to the database is usually used in the library to do something there isn’t  feature for
        • If we don’t need direct table access because we can perform all the functions via API, we don’t need it
        • Charlotte will make sure this entry is passed on to the developers
        • Need to discuss
    • Entry 206
      • If this is web-based, it is sometimes very hard to print
      • Routing slips and hold slips need to print directly
      • System sends it directly to the printer rather than printing from the browser
      • We need to make the description clearer
      • Typically this functionality needs to be print command coming from the local computer to the printer – can’t go to remote server.  There may be firewall issues in that case.
      • We need to be able to format these so they put in the information how we want it
      • How it is layed out on the screen can be completely isolated from how it’s printed
    • Entry 207 is being moved to ID407
    • Entry 208
      • Have we already covered remote storage requests?
      • Or is this about paging?
      • What does journal item level mean?  Bound volume.Not clear what is meant by this item…ID481 covers some parts of what we think this item isThere needs to be something that helps staff to fill the requests?
      • David and Andrea will rewrite this item
      • Suggestion to search the FM for “request” to see what is already there
    • Entry 209
      • Highest priority is lending because that’s where patrons are standing there needing help
      • Overall, Cornell needs some ability to do this
      • Other library has written an Access database to do thisIt would be nice to do something, but could be scope creepKeep track of check-ins and check-outs during an offline period
      • Low priority
      • Worst case scenario, you can always save in Excel and add later
      • Let’s lower the priority
    • Entry 210
      • In our current system, we have tons of performance issues
      • I would assume this may happen in FOLIO
      • How does one monitor what is hogging all the resources etc.
    • Entry 211
      • This is similar to 205
      • This goes beyond collections development
      • Applies to all underlying data store
      • We use this for staffing (how many items did we check out)
      • We are writing these things all the time – ad hoc needs
      • Makes me nervous to think they can be canned/pre-defined
    • Entry 212
      • Individual user preference for language is not super important, but, per Filip, this is important and not technically difficult to do at the user lever
      • Alma doesn’t have a German interface
      • German libraries sometimes live with an English interface
      • Institution-level language preference is 1
      • User level is 2
    • Entry 213
      • I believe this belongs to RM
      • Charlotte will put this on the list for the group which is meeting Friday
      • Is there anything about creating new item statuses or patron types?
      • We need to be able to configure our own item status values
      • Charlotte will look for whether there is an existing one
      • If she can’t find one, Andrea and Filip will write a description
      • Line 12 covers this for Patron Types
      • Row 188 is in the neighborhood, but not close enough
  • Other
    • Filip asked if anyone saw the post about the Proto.io starter project
      • Some have seen
      • Idea is that, if you want to make an app, you can make an interactive demo of your idea
      • We got a request from someone who wanted to do this
    • Charlotte announced there will be a presentation in 2 weeks to this group of the HBZ and GBV requirements catalog