Hey Sean! A few years ago we created a staff directory application using Drupal 7, LDAP and Search API Solr. Basically we import some LDAP into a content type called Person. We use this data as the basis for what we display on staff profile pages, then we add more data like a picture and subject of expertise. With this data we made a directory search using Search API Solr Index View. Maybe a bit overkill for only a few hundred nodes, but, Solr isn't that bad to setup and is a heck of a lot better then exact match default Drupal search (plus I'm sure y'all are already familiar with it). Another benefit of having your staff pages in Drupal is that if you have another Solr search for your site (could easily use the same core) as we do all those staff nodes are going to show up there too because the Drupal Search API Solr integration relies on each piece of content being a node. What I'm saying is that if you want a turnkey Drupal site solution, this approach makes it easier, less having to integrate external applications. Of course another benefit is being able to build other views and relationships with your other content. We recently (a year ago?) launched an "Expert Finder" kind of thing from our homepage that relies on this data. We also wrote a Bento search in Drupal that pulls this expert data into its own box. We have some ideas about expanding what we do with our profiles as well, but that's not really fleshed out yet.
I'd be happy to share our code with you if you'd like, though it is littered with things that are pertinent to our local installation that would likely be different at Duke, but, again happy to share if it'd be a good starting point. -Charlie Penn State University Libraries On Thu, Apr 4, 2019 at 7:07 PM Cary Gordon <listu...@chillco.com> wrote: > Drupal, like CMSs, is at its core, a report writer and CRUD system that is > well suited to building a staff directory. The hard part is determining > what you want. The execution is quite straightforward. > > Cary > > On Thu, Apr 4, 2019 at 1:12 PM Sean Aery <sean.a...@duke.edu> wrote: > > > Hello Code4Lib, > > > > At Duke University Libraries, we are planning to design/develop a new > > staff directory application this spring. It seems like this would be a > > fairly common area of need, but there don’t appear to be any > widely-adopted > > solutions out there. So we’re interested in learning more about what our > > peers (y’all) do to power their staff directories. > > > > For some added context, we use Drupal 7 for our website and a growing > > percentage of the applications we support use Ruby on Rails. We don’t > have > > much in-house experience with JS frameworks like Vue or React. Whatever > we > > use to build the directory, it should be able to represent people (with > > photo, contact info, bio, etc.), display a browsable hierarchy of > > organizational units, and be widely discoverable and accessible. > > > > Does anyone have a solution they like for their staff directory? What > > tooling do you use and why? Any words of advice you could share? > > > > Many thanks, > > Sean > > > > ~~~~~~~~~~~~~~~~~~~~~~ > > Sean Aery > > Digital Projects Developer > > Software Services > > Duke University Libraries > > 030U Bostock Library Box 90198 > > Durham, NC 27708 > > sean.a...@duke.edu > > > > ~~~~~~~~~~~~~~~~~~~~~~ > > > > > -- > Cary Gordon > The Cherry Hill Company > http://chillco.com >
