create UX design for "missives" index page

[onezerojeremy]

Based on some great feedback, revise the ux design for the "missives" index page.

[onezerojeremy]

Uploading a new draft with some options for discussion next week wireframe-desktop-missives-index-flow.pdf

[jenniferthibault]

@onezerojeremy what kind of feedback would be helpful? Are there specific points that should help guide us to the best option?

(^ those are assuming you wanted our review before FEC review, but if there's a different order for this task, lemme know!)

[onezerojeremy]

@jenniferthibault Would love for you review before we show & tell!

I think it might do best in synchronous, but a couple conversation guiders that I should've attached (but was trying to get it in front of our eyes before heading out on Friday)

• i am good presenting both options to FEC and having a conversation with them about it unless there are non-starters in one of the options from @jenniferthibault @emileighoutlaw or @noahmanger
• I would like @jenniferthibault your eyes on the touch of organization specific styling/branding (embodied in the small " :icon: from Public Information" or " :icon: from Press Office" and react. But again, I think there's a lot of context that is hard to capture in the issue that might make that reaction easier in a quick synchronous session.

[jenniferthibault]

Yeah let's sync up! Please go ahead and find a time that suits

[onezerojeremy]

Updated, based on discussion today!

wireframe-desktop-missives-index-flow.pdf Changes to the "big button" variant

• adding back in the ability to filter for individual content types
• moving that and other presumably advanced filtering options into a collapsible filters bar

[jenniferthibault]

So that I'm on the same page before we move fwd with a demo—noticing the horizontal filter panel here, I'd like to hear your thoughts on that format vs the vertical panel we've been using @onezerojeremy

If we can keep consistent with one filter panel format that's preferable for a more simple system, but if there's interaction points here that make the existing vertical panel not a good fit, I want to get a head start on thinking about this new pattern!

[onezerojeremy]

It's a good question and the departure was intentional, but in the interest of keeping this moving I don't think we need to reschedule today's demo and sort it out. I've tried to be clear in these demos that these are wireframes and thus subject to change, and I will certainly reinforce that today.

As to why the departure: From a ux standpoint the data filtering is a much different, and much more robust experience, undertaken by largely a different audience than the winnowing some users might do here. A side panel makes more sense when the result set is really only likely useful after a user has engaged one or (more likely) more filters, and may try different combinations before the desired result is achieved.

On the latest updates page, by contrast, only a few ways of filtering are even possible, it's likely a one-and-done filtering situation, and the feed is immediately useful without filtering. Having no signal that the filters here will be used frequently, it felt better* to have them in a small horizontal panel, that even when invoked, took up minimal page real estate, rather than our more robust vertical display.

(*- Working under the principle that any feature that is prominently displayed but not needed by a user is distracting and therefore a detriment to that user's experience.)

On Tuesday, August 23, 2016, Jennifer Thibault notifications@github.com wrote:

So that I'm on the same page before we move fwd with a demo—noticing the horizontal filter panel here, I'd like to hear your thoughts on that format vs the vertical panel we've been using @onezerojeremy https://github.com/onezerojeremy

If we can keep consistent with one filter panel format that's preferable for a more simple system, but if there's interaction points here that make the existing vertical panel not a good fit, I want to get a head start on thinking about this new pattern!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/18F/fec-cms/issues/443#issuecomment-241716385, or mute the thread https://github.com/notifications/unsubscribe-auth/AAc_JK6UqhegCjy0T75_7my3m6pxZog_ks5qiukugaJpZM4Jo7r6 .

[jenniferthibault]

Ah sorry, yet another poor expression of thoughts on my part. I wasn't intending to reschedule the demo, but I did want to understand what you posted above (namely, the intentionality) beforehand.

Thanks for the logic—I know a bit off topic from the main goal of this issue, but it helps me understand how this pattern is extending right at the moment of conception, and I can see some hints of where this might be useful on the legal side.

[onezerojeremy]

ah, my bad Jen! My reading comprehension this morning is not great.

I'm totally game to chat about it more!

[onezerojeremy]

Ok posting an update, hopefully we can talk about this at our afternoon design sync!

At our sync last week, we decided to go with Option A, the drop-down list (over the "big button approach), citing it's more extensible design. This update focuses on trying to lay out some of the filtering options for that design. Specifically, the design problem we're trying to solve here is to incorporate category filtering for some of the update types.

I have 3 filtering options in the image below, each with trade-offs. If there's time at this afternoon's sync, I'll dig in to each, but briefly:

Option A: drop down that drills down.

• Essentially, if the user selects a update type that has categories, they are presented with a list of categories, from which they can select one, or select all.
• I believe we used this pattern somewhere on data, but either I'm wrong or we haven't implemented it yet.
• It is probably the most space efficient, and probably nearly the most intuitive.
• On the downside, it gives a lot of emphasis to the category selection (by placing it in the flow of the content type decision), essentially requiring the user to make a choice (or choose all).

Option B. Show category drop-down on selection of a update type with categories

• Just what it sounds like. If you select an update type with categories, a brand new drop down appears beside the update drop down with the list of categories.
• Probably the most intuitive.
• Doesn't force the user to choose one or none, which is probably the right level of emphasis.
• On the downside, it's not very space efficient and may yield some visual design hurdles in having an extra dropdown in that line without making it feel cluttered or compressed. I also seem to recall that adding and removing elements may have technical implementation and accessibility hurdles, but I'm not sure I'm remembering that correctly.

Option C: Combine with search box, using Data table "committee look-up/name search pattern"

• Here, you'd either start typing in the box and the list of categories would winnow as you typed, or if you just clicked the button you'd see the list of categories for the update type you'd selected.
• It's very space efficient, and doesn't over-emphasize the category selection.
• Downside here is that it is probably the least intuitive option and I'm not sure people will get it.

tagging designers @noahmanger @jenniferthibault @nickykrause and @emileighoutlaw for thoughts, though happy to wait to chat about it at our sync this afternoon

[onezerojeremy]

oh, and these are but three options, none of which I am frankly all that happy with! I hope yous have other options which I am eager to hear!

[nickykrause]

@onezerojeremy: This is an interesting problem! I enjoyed reading through your thinking on it. I believe that I missed all previous discussions about this, so it is also interesting to see the evolution (including the big filter options that we opted against).

I am noting some initial reactions here, but I am happy to discuss everything at the FE/Design sync. (Also, keep in mind that that I am aware I may be inquiring about things you've already worked through in previous conversations - just let me know!)

I am basically just thinking out loud here:

• I am curious about the thinking/history behind the "user type" organization within the drop-down menus (e.g., "for press," "for filers"). I wonder if it this "layer" of info is necessary, and I'd be interested to hear people's thoughts on the utility it offers v. the possible visual complexity it presents
• This experience (i.e., filtering data elements) seems similar to the filtering experiences we have designed elsewhere for the data browsing sections, so I wonder if some of the same conventions we have there could be applied here? I was specifically thinking of things like the exposed "filter tags" with an "x" in them
• For the existing designs, I agree that Option B (having the other drop-down appear) feels the most intuitive, and I agree with not having them choose one or none
• I haven't reflected on this much yet, but I am wondering what the experience looks like in some of these options for users who want to edit their filters. It seems like Option B would make that use case easier than Option A

[onezerojeremy]

Ok after our inaugural weekly design sync-up yesterday afternoon, we seem to land on three things:

1. the option with the second drop down appearing for update types with categories is probably the best way forward, citing it's ease of implementation (no new patterns) and balance of emphasis on categories without forcing users to choose a category (or now).
2. we also came to the realization that search has a relatively heavy design and implementation lift not indicated here, so for the sake of expediency we may want to start with a version that doesn't have it and implement it later
3. we wanted to see what a browsing version of the above might look like.

Those changes are in screens on this invision mock-up: https://gsa.invisionapp.com/share/VN8GGW3AQ

[emileighoutlaw]

Thanks for sharing, Jeremy

[noahmanger]

What's the next step on this before @jenniferthibault can start working her magic?

[onezerojeremy]

I think we just need to decide if we want to pursue the browse pattern (in the linked mock-ups, but I'll include a sample below to save a click) or push to @jenniferthibault's 🐇 🎩 with the double drop down pattern.

browse pattern (first attempt)

double drop down

[jenniferthibault]

I'm interested in exploring the browse pattern, but before 🐰s and 🎩 s, I want to make sure I understand how it's gonna work & new changes I see here.

1. Question ❓: Are we dropping "For filers" as a top-level category, making our three lop-levels
   • All updates
   • For press/journalists
   • The record
2. Question ❓: It looks like when you click a section/content type that has categorized content, the categories expand/somehow appear as a list beneath that section/content type. Does this happen for both Press releases and the Record? Or just the Record?
3. Question ❓: What happens when you click the date? (it looks like a link now, is it?)
4. Question ❓: What happens when you click Public Information Office? (it looks like a link now, is it?)

If other folks prefer we start with the double drop-down, I think question 3 & 4 above still apply

[jenniferthibault]

I now see @emileighoutlaw 's content thoughts over in https://github.com/18F/fec-cms/issues/461#issuecomment-243941683 :: If answer to Question 1 is that you are wanting to drop "For filers", you might want to head over there to discuss!

[onezerojeremy]

1. This was an attempt to move us away from the strict audience categorization, given the noted problems of extensibility raised with that pattern. Will move the convo over to #461 (thanks for the heads up!)
2. Should happen for both. Also we'll need some visual designation indicating that categories exist below, but that's not included.
3. Apologies... fast IXD'ing = sloppy IXD'ing! Good catch. I had this in when "tips for treasurers" was still part of the feed, and since those didn't necessarily open separate from the feed, I was giving them a discoverable way to link to them (stealing the pattern from twitter). I think we don't need it, which is to say it shouldn't be or look like a link.
4. Similar to 3, I don't think it should be a link. Press Office probably should be, though! Right?

[noahmanger]

Down to start with a browse pattern if you think it's better. We're going to get started on basic implementation of the backend of this while we sort out these questions (which will have no impact really on how it's all wired up).

If we're doing categories with expandable sub-categories, what about using the accordion pattern?

[onezerojeremy]

I don't necessarily think the browse pattern is better, but I'm game to go whichever way yous think will work. @nickykrause, curious if you have any thoughts between browse and filter?

and yeah, the accordion probably makes sense if we're doing the sidebar with expandables.

[noahmanger]

Reached a decision in sprint checkin: we're going to go with the dropdown style. Moving to visual design.