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 <[log in to unmask]> 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 <[log in to unmask]> 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
> > [log in to unmask]
> >
> > ~~~~~~~~~~~~~~~~~~~~~~
> >
>
>
> --
> Cary Gordon
> The Cherry Hill Company
> http://chillco.com
>