If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Gary Geisler ggeisler Stanford University Stanford, CA

ProjectMirador/mirador 405

An open-source, web-based 'multi-up' viewer that supports zoom-pan-rotate functionality, ability to display/compare simple images, and images with annotations.

geoblacklight/geoblacklight 117

Discovery platform for GIS data.

ovdlt/open-video-digital-library-toolkit 20

Project to develop a toolkit for producing digital video libraries

projectblacklight/blacklight-gallery 12

Gallery views for Blacklight

ProjectMirador/mirador-design 10

A place for design artifacts, stories, and feedback pertaining to Mirador ecosystem tools (especially Mirador 3).

ggeisler/responsiveTruncator 0

A responsive truncation jQuery plugin.

ggeisler/wayback 0

IA's public Wayback Machine (moved from SourceForge)

issue commentprojectblacklight/spotlight

Store publication date

@elrayle Okay, great. I think if we can avoid the manual publish date setting that alleviates a lot of my concerns around complicating the General settings page. From a Stanford perspective I don't think we'd have use for more than the first_published_date field, but I do understand how your Featured Exhibits use case might benefit from the last_published_date field so you can surface updated exhibits.

It would be good to get another developer viewpoint on this, though. I think @cbeer might have some thoughts.


comment created time in 2 days

issue commentprojectblacklight/spotlight

Store publication date

@elrayle Another question I forgot to ask above, aside from using a published_date field for exhibit sorting, do you plan to expose that value anywhere in the UI (either at the site or exhibit level)?


comment created time in 3 days

issue commentprojectblacklight/spotlight

Store publication date

@elrayle Thanks for writing up the detailed options. I do agree we can do something useful here. My main concerns (which are relevant to either option) have to do with allowing the curator to manually set publish dates and adding a new UI element to support that action. So my first thought is that if we go with Option 2, then at least we could ensure (for exhibits added after the feature is enabled) that we have one date (first_published_date) that is not controlled by the curator and is an accurate reflection of when the exhibit truly was first published.

I do get the idea that in some cases an exhibit curator might want to indicate a major new version without unpublishing and re-publishing the exhibit. And you bring up a good point that all of our existing exhibit would have null values that might need to be populated in some way. But here are some things that concern me about the manually populated aspect of the options:

  • This would mean we have to add a new field on the General settings page, and we'd probably have to add extra instructions to explain what it's for, as well as error checking to make sure it’s a valid date. Are we sure that there are enough real use cases where an exhibit curator wants to indicate a major new version without unpublishing and re-publishing the exhibit to justify making the General settings page more complicated for all curators (the vast majority of which, at least at Stanford, publish their exhibit once and thereafter only make minor updates, if any, and thus don't care about indicating a last published date)?

  • If the number of expected use cases is small, perhaps we could we solve it by just having some documentation that tells curators that if they want to update their exhibit’slast_published_date value, they can do so by unchecking and rechecking the “Publish” checkbox? That’s admittedly kind of kludgy, but if the scenario is rare, I wonder if that’s better than displaying a new form field to every curator, even though very few curators will care about it? (Not to mention it would eliminate a lot of the work necessary to implement the UI part.)

  • Are we okay with accepting potentially untrue values for the last_published_date? If you intend to use this field as a sorting field, I wonder if making it a manually-updated field is wise, since curators could in theory game the system by giving their exhibit a more recent published date in order to get their exhibit to show up higher in the sort order. (They could also do so with the automated approach, but that might be less obvious than a field where they actually enter any date they want.)

I guess where I'm at is I do agree we can do something useful here, but I’m wondering if we are better off (at least with a first pass at it) making it an entirely automated thing based on the Publish checkbox (Option 2 without the third workflow step), rather than getting into all of the concerns and extra work that come up with making it a user-controlled thing. But I'm interested to hear your thoughts.


comment created time in 3 days

issue opened2SC1815J/mirador-annotation-tooltip-plugin

Change the label of the show/hide icon to sentence case

This plugin is a nice option for cases when displaying the annotation text directly over the canvas is not likely to negatively affect the user experience.

One very minor suggestion: For consistency purposes, I suggest you update the label text for the show/hide icon to use sentence case, rather than the current title case:

Screen Shot 2021-07-30 at 3 59 45 PM

So where the current labels are Show Annotation Tooltip and Hide Annotation Tooltip, they would be changed to Show annotation tooltip and Hide annotation tooltip.

This change would make the label consistent with the rest of the Mirador UI, which uses sentence case (for English).

created time in 6 days


issue commentProjectMirador/mirador

Custom message in error dialog

@jbaiter @greenenvy I agree we should present more user-friendly error messages. From a UX perspective we didn't get that far when the Mirador 3 team was doing the bulk of our design and development work, so no, to my knowledge there's never been any discussion focused on how to provide better error messages. But this definitely seems like a good area to improve.

I'd be happy to help with this as I can find the time. Perhaps one way to proceed would be for any developers who notice error messages that need to be made more user-friendly (such as the examples @greenenvy and @jbaiter have noted above) could, for each distinct case you come across, post (either in this issue or a new one):

  • A screenshot showing the error message in context (by this I mean capturing the entire Mirador window, rather than just the area directly around the message as in @greenenvy's example above -- not being critical it's just that it can be hard for someone who isn't actively working on Mirador to figure out exactly where in the UI the error is occurring without a broader context).
  • If the error occurs in an application that is publicly accessible, a link to the application so we can trigger the error condition directly. If this isn't possible (because the application is still under development, for example), if there's a way to trigger the same error in the Mirador 3 demo app (using a specific manifest, for example) an explanation of the steps necessary required to trigger the error would also be great.

As we gather these examples I can offer some suggestions for more user-friendly error messages and we can also see if there are any larger patterns that might enable us to generalize how error messages can be better presented to the end-user.


comment created time in 15 days

issue commentsul-dlss/dlme

Add bulk tagging feature to admin panel

@jacobthill Maybe? Spotlight now has two approaches to bulk tagging:

  • Add and remove tags through the exhibit UI
  • Add and remove tags by downloading/uploading a spreadsheet through the admin UI

Add and remove tags through the exhibit UI

Available now in DLME. Note that the Bulk actions affordance is not available for browse category results, just search results generated by using some combination of facets and search terms (so you could still get the same results as a browse category, you'd just have to generate it by hand):

Screen Shot 2021-07-12 at 9 19 34 AM

Add and remove tags through a spreadsheet via the admin UI

This is available in Spotlight but not DLME. I don't remember if there is a specific reason for this, or if we were just waiting to a future workcycle to add it to DLME.


Screen Shot 2021-07-12 at 9 18 57 AM


Screen Shot 2021-07-12 at 9 20 19 AM

So maybe you can close this ticket and if you think we need to add the spreadsheet option to DLME, create a new ticket specifically about that, and if the developers know of a reason we couldn't do that for DLME that I don't recall, they can tell us there. (Though I think it might just be because we implemented it after the DLME workcycle and it requires custom work beyond just updating DLME to the latest Spotlight version.)


comment created time in 24 days

pull request commentsul-dlss/course_reserves

Update CREZ form and mailer for Fall 2021

Alignment and spacing looks good 👍 (I assume 32a5699 is to make the row counter top-aligned with the title.)


comment created time in a month

issue commentProjectMirador/mirador-annotations

Update Save annotation behavior

@cbeer I think Cancel should still close the anno editing panel. I could see a case either way, but this way we can be consistent about what action the Cancel button performs without having a situation where the Cancel button feels like it is inoperable (when you initially open it but haven't done anything in it yet).

And it seems like the worse case with that approach is the user is making a series of annotations and just wants to reset what they've done in the current edit -- we'd force that user to re-open the annotation edit panel (and possibly reposition the canvas area in view), but otherwise no harm is done.


comment created time in 2 months

issue openedsul-dlss/mise

Remove "exit workspace" part of the Save workspace button action

I'm a little on the fence with this one so if anyone has thoughts contrary to what I'm proposing, feel free to say so.

Currently when the user selects the "Save workspace" action (when working in a Mirador workspace) that action does two things (from the user perspective):

  • Saves the current workspace state (snapshot)
  • Exits the workspace and redirects the user to the details page of the workspace

I think we should only do the first of those -- update the workspace snapshot -- but not the second. We should remain in the workspace.

My concern is that especially when doing real annotation editing, users are likely to select the "Save workspace" button at times when all they intend to do is the labelled action: save the workspace. Based on how many software applications work, when users see a "Save workspace" button they are likely to use it just to make sure they don't lose work they've been doing (even though in Mise they are not really in danger of losing annotation editing work that way). And if they're not really done with their workspace work, it's pretty annoying to find yourself on the Workspace details page and having to open the workspace again.

The tradeoff is sometimes a user will want to do what the current action does do: save the workspace state and exit the workspace. In that case, we'd be requiring an extra action, since they'd have to select the "Back" action after the "Save workspace" action. But that feels to me like a more expected flow than the "Save workspace" button doing both things at once.

created time in 2 months

Pull request review commentsul-dlss/mise

Support user-favorited workspaces in DB and model

 def explore   end    def dashboard-    @favorites = Workspace.accessible_by(current_ability, :update).favorites.order(updated_at: :desc).limit(3)+    @favorites = current_user.favorited_workspaces.order(updated_at: :desc).limit(3)

Yeah, my earlier comment was ideally we should continue to track that a user favorited a given workspace, even if it has been made inaccessible to them (in case it later becomes accessible).

But definitely a second part of that is do we alert the user to the situation, and if so, how?

I don't know. Ideally, I guess some sort of notification might be helpful. But I'm also not sure it's a frequent or significant enough case to worry much about at this point. I'd suggest we go with "just hide non-accessible workspaces" and I can create a design-needed ticket to remember to think about this further and maybe do something more sophisticated in the future?


comment created time in 2 months


issue commentProjectMirador/mirador

Hide paging navigation area

Note that we also need to support keyboard-only accessibility for this. For example, when using only a keyboard to navigate the page at, you have to know when you are on the image window (which is not visually indicated, but could be) and then have to know you can use the plus and minus keys to zoom. They offer no visible indication to the user that you can zoom. And we have the additional concern that what we would be hiding from the user is not only the zoom controls but also the canvas title and canvas pagination elements.

I don't think this is impossible to solve (Wikipedia shows hover-only elements to keyboard users) but I do want to note that it isn't as simple as doing what OSD does.


comment created time in 2 months

issue closedProjectMirador/mirador

metadata slideout area

User comment: The metadata area (opened via the hamburger menu at top left) is rather narrow. Could it be slightly wider? Or could the width respond to user adjustments?

closed time in 2 months


issue closedProjectMirador/mirador

Not intuitive to click escape button to exit

User comment: Once a user clicks on the "Window views & thumbnail display" (second from top right) there seems to be no way to exit the menu without selecting a change. Escape button does this, but is not intuitive.

closed time in 2 months


Pull request review commentsul-dlss/mise

Support user-favorited workspaces in DB and model

       <p class="fst-italic">There hasn't been any recent workspace activity in this project.</p>     <% end %> -    <% favorites = @project.workspaces.favorites.accessible_by(current_ability) %>+    <% favorites = current_user.favorite_workspaces %>

Not sure if this is relevant or not, but if a user favorited a workspace that they then lose access to, I think it would be fine to still keep track of the user's favorite status of that workspace. The user shouldn't see a favorited workspace if they don't have access to it, of course, but if they are later re-granted access to it, it does seem reasonable that upon re-access it is shown to that user as one of their favorite workspaces (since it was before and they never said it wasn't).

This might already be how things work, or might not be possible with the way things are stored in the database, but I just wanted to offer that opinion on the general workings of things.


comment created time in 2 months


pull request commentProjectMirador/mirador

Wrap the export json in an accordion; fixes #3440

Someone else should probably approve the code, but visually this looks good to me. 👍


comment created time in 2 months


issue commentsul-dlss/mise

Auto-save workspaces or enhance the Save workspace button

@mjgiarlo No need, I don't think, it looks fine to me. Ideally we'd obviously rather present the user with a more Mise-specific message (which I see is in the code) but I guess we're at the mercy of the browsers for this.


comment created time in 2 months

PR opened sul-dlss/mise

Remove last edited text from workspace card

The "Last edited" text on the workspace card increases the height of the card and makes it generally less compact than it could be, arguably contributing to a somewhat disjoint arrangement of card elements. Since finding out when a workspace was last edited is still possible (from the workspace details page) and I'm guessing isn't something that is super important to know most of the time, this PR removes it from the workspace cards.

Before - with the "Last edited" message

Screen Shot 2021-05-27 at 10 49 35 AM


Screen Shot 2021-05-27 at 10 49 17 AM

+5 -6

0 comment

1 changed file

pr created time in 2 months

create barnchsul-dlss/mise

branch : workspace-card-layout

created branch time in 2 months

issue commentsul-dlss/mise

Auto-save workspaces or enhance the Save workspace button

Sure, B seems much simpler. Perhaps we could just go with the standard browser prompt dialog with the text You have unsaved changes to your workspace. Are you sure you want to leave this page?, along with the standard Cancel and OK buttons.

It's pretty generic but should be relatively easy to implement and would ensure Mise users aren't accidentally losing workspace work due to forgetting they need to save the workspace.


comment created time in 2 months

issue openedProjectMirador/mirador

Update Export workspace modal to hide JSON in an expand/collapse section

On a IIIF call I heard the Export feature referred to as "clunky" and I believe the display of the configuration JSON was at least part of what led to that impression (because using the Export feature is simply a matter of selecting the Copy button, which doesn't seem very clunky to me). While I don't think we want to get rid of the JSON in this modal (it can be handy to copy and paste sections from, for advanced users at least), perhaps we can make the feature feel simpler but putting the JSON in an expand/collapse section, and hide it in the initial state.

For example, this could be how the modal looks when initially displayed:

Screen Shot 2021-05-26 at 2 44 31 PM

This would involve:

  • Put the existing JSON code section into an expand/collapse (similar to what we do in the Window sidebar panel, About section) with the text label View workspace configuration (as an <h3> but with the MuiTypography-h4 class to style it as an <h4>)
  • Update the label of the primary button to Copy configuration , which is long and sort of awkward but does make it more clear what you are copying, since you won't initially see the JSON

When the collapsed section is expanded:

Screen Shot 2021-05-26 at 2 47 52 PM

  • The JSON section is displayed as it currently does, with the toggle icon updated to reflect the current expanded state

created time in 2 months

issue openedsul-dlss/mise

Update top navbar for non-logged in users

The idea is to offer non-logged in users with some additional context about IIIF and Mirador in the top navbar (rather than add links to the page text where it references those), plus offer an email link so those users have a way to ask questions.

Screen Shot 2021-05-26 at 11 54 19 AM

I think this involves:

  • Hide the topbar Login link
  • Add links for IIIF (, Mirador (, and Questions? (mailto link to
  • Make the link color of those new links text-light (I think we might want to do this for the current Login | username link as well; it has sufficient contrast for a11y but feels just a tad dark to me)

I think we only want to show these new links in the logged-out context, rather than adding them to the navbar regardless of context, since an existing Mise user probably knows enough about them to not need them and they'd just be distracting. But I don't feel super strongly about that.

created time in 2 months