Users confronted with too many identical-looking buttons when choosing assignment content

[lyzadanger]

As we continue to expand the kinds of content that can be used for assignments, we're starting to get to a place where the buttons presented for content-type selection are numerous and undifferentiated:

This interface needs another design pass, and possibly some icons introduced.

[lyzadanger]

I spent some time thinking about this design problem on the afternoon of Jul 15 (yesterday). I’d summarize my outcome as:

• I have a few ideas;
• These ideas are hamstrung by a few missing design foundations (already tracked and on the short- to medium-term list) that I’d propose getting in place before diving in on this

What follows are some notes, with no specific recommended course of action at this time.

Complexity arises here because we're trying to communicate three different things in each one of these buttons (and given that, I think we're actually doing a decent job!):

• The "name" of the content source (e.g. Google Drive, VitalSource, Canvas, or the Web as a whole)
• The document types available in each source (e.g. web page, PDF, book or chapter)
• The mechanism for locating content (enter a URL, Select [from a picker])

With that in mind, we might consider a composite UI pattern—perhaps, semantically, a label for an associated, non-visible radio button input. We might lay this out in a grid, to allow for the set of options to grow and shrink more comfortably. And we might need to handle overflow in that grid.

I did a little in-browser sketching using our design patterns. I feel the need to disclaim before sharing anything here: this is fugly and sketchy. There are inconsistencies in spacing, font treatments; there are too many lines, and the icon is just random. The goal is just to try to show what I mean by a “composite” UI pattern:

In the short term, we might be able to relieve a little visual pressure by removing the “mechanism” wording from the buttons, e.g.:

• Enter a URL of web page or PDF -> URL of web page or PDF
• Select PDF from Canvas -> PDF from Canvas

etc.

With this change, however, these feel more like radio buttons than buttons, semantically, in that a button is more comfortable when it includes an action (verb).

Another visual issue is the contrast-weight of these buttons, which are all of primary variant. All of our button patterns at present use bold text, as well.

[robertknight]

The assignment picker, with all the available types enabled, now looks like this:

Given the default sizing of this dialog in Canvas, we're now out of space for any new options unless we make the user scroll.

[dwhly]

Noting Lyza's short suggestion above:

In the short term, we might be able to relieve a little visual pressure by removing the “mechanism” wording from the buttons, e.g.:

Enter a URL of web page or PDF -> URL of web page or PDF Select PDF from Canvas -> PDF from Canvas

@jaredpdesigns and I took a crack at what a re-imagining of this interface might look like. The concept here leverages the fact that behind many of our buttons is some sort of text entry field to drop a URL. So-- why not bring that entry field forward as a universal "one box" for pasting input. The "Learn more" link would go to a kb page with the detailed list of URL types and whatever special considerations there might be for each. In this concept, the lms service would detect with some regex magic which type of URL you were adding and switch accordingly.

https://www.figma.com/file/Kgeolf4zDtQDKQfzXtEvyL/Hypothesis---EBSCO-Integration?node-id=0-1&t=QhWunT2IoOaEdKa5-0

It should be noted that this design is entitled "EBSCO integration" because its possible that we will be exploring integration with the EBSCO service, which is a nearly universally licensed content aggregation service used by the world's higher ed institutions that powers content search and delivery for most digital things that libraries deliver to students and faculty. With an EBSCO integration you'd be able to search for "Freud 1935" and get a list of (and access to) documents, articles, books etc matching those terms. In the conceptualization, the search would also be overloaded into this one box implementation so that it would accept either URLs or search terms.

There is a "no-EBSCO" flavor of this (screenshotted above) which drops the suggestion that a search term can be added, which would be more suitable in the interim. Also, several other of the underlying screens are mocked. It's possible this mock may be a bit wide for the desired real estate inside a Canvas (e.g.) implementation.