dobtco / dvl-core Goto Github PK

cf https://github.com/dobtco/screendoor-v2/issues/263

extract polyfills from Screendoor -> dvl-core (or dvl-polyfills?)

cf https://github.com/dobtco/screendoor-v2/issues/1193

This is probably a component that belongs in dvl-core, since every app we make will need one. Not to mention our current navbar needs a rewrite (according to @jrubenoff IIRC).

Most likely triggered by ad4dd95

(Storing this thought here to avoid interfering with #105)

• Stack multiple flashes instead of overlaying them
• Generate flash <div>s with js, always
• New visual style?

thoughts?

Outcome

Tables should always be readable on mobile devices.

Structure

Not really "brainstorming" so much as "research needed".

• https://github.com/filamentgroup/tablesaw
• Look into other JS-based solutions

cf https://github.com/dobtco/screendoor-v2/issues/1532

Note: Look how bootstrap does it, there might already be hooks in dropdowns.js

Made these changes in feature/project-teams-mvp, they didn't turn out to be necessary for that branch, but we might want to consider merging them anyway:

.button {
  line-height: normal;
}

.styled_select_wrapper {
  vertical-align: top;
}

This markup won't show the badge on mobile:

span.navbar_full_i {
  i(class: 'fa fa-bolt navbar_icon')
  span.navbar_badge '1'
}
span.navbar_collapsed_i {
  text 'Notifications'
}

We have a few different components for multi-step navigation. Screendoor's wizard checklist lets you navigate to any step:

I dislike this component because it takes up a lot of horizontal space. Also, the "checked" status is meaningless. Just because you visited a page, filled something out on that page, or even filled out everything doesn't mean you're done with it.

(For example, you could have a rough draft of a Screendoor project description, and the checklist would still mark it as "done".)

Screendoor's bottom status bar lets you navigate to the previous / next page:

The tabs currently in the style guide are great if you don't have to go through each step in order:

And for some flows, like when sending a message or importing responses in Screendoor, we have no components.

We probably need to come up with a few different patterns. I was thinking about switching to respondent view-style pagination for the wizard. Something like:

But this wouldn't work for a linear flow like importing responses, where it doesn't make sense to jump around between steps.

http://take.ms/FgMOU

We could fix this in #83 if we want.

Outcomes

• Make it more visually obvious when flashes contain actions.
• Give users enough time to read, understand and perform actions contained in flashes.

Structure

If a flash contains a button, that flash should stay onscreen until the user performs another action or goes to a different page.

Currently this disappears after 10 seconds:

Visual

Rough mockup:

cf https://github.com/dobtco/screendoor-v2/issues/1091

Upgrade because twbs/bootstrap#15229 has been solved?

rstacruz/sinatra-assetpack#139

Possible workaround:

touch vendor/assets/stylesheets/dvl/core.scss to force reload.

It was committed in the payments branch of Screendoor, but due to various merging stuff, it has been removed. Should we add to forms.scss?

Shouldn't this dropdown extend to take up more width? Or should the developer explicitly set a width in CSS if they want a dropdown that's wider than the current 140px?

For discussion:

I should never have to PR to more than one repo to change a UI component. Every permutation of a component's markup, styling and JS should be encapsulated in a single codebase.

Following that logic, dvl-core should only contain styles relevant to the entire application, rather than styles for just one or even a few components. This would include:

• Bare-bones HTML5 reset: remove all default styling on uls, buttons, etc. so we can style to our preference within each component
• Variables, mixins like clearfix
• Print styles
• Grid system?
• Maybe some global styling for a few elements

This means modals, tooltips, sidebar styles, etc. should go into their own separate repos. Also, we take out any default styling for elements we override in another component.

Thoughts?

I can't find it now, but Intercom had a design that I really liked -- it combined the bottom status bar with "breadcrumb" steps. I'll try to find a screenshot of it...

Here's another bug I found:

If you select "Answer for... [x field]", when you reopen the dropdown, "Answer for..." should be expanded and the field should be active.

Many of our tooltip "links" have no href attributes, so you cannot give them keyboard focus.

Continuing dobtco/screendoor-v2#926

In addition to what's in respondent view, I drew a bunch of icons last week.

I'm not sure how to reference them in the style guide's CSS.

I have a few more planned, but for some of our current icons (like the gear for settings), I'm not confident enough in my illustration abilities to create versions I'm happy with.

For now, we're using both our icon set and FontAwesome, but supplementing our own icon set with some third-party icons probably makes the most sense.

Outcome

Create a component which elegantly displays lists of sortable data not well-suited to a tabular structure.

Structure

First draft at a design. Ignore the tooltip at the bottom:
https://redpen.io/fv7a9131f73748ea98

The toggle button is supposed to be a new iteration of .dropdown_toggle_button.gray. It is below the header, because you can place something to the right of the header: a .filter_form, or a secondary action.

Breaking this out from dobtco/screendoor-v2#888.

Desired Outcome

• Create a UI component that can effectively replace the select for inputs with:
  • Many answer options
  • Long answer options that cannot be truncated
• Allow for at least two levels of information hierarchy.
• Make a dropdown control that's usable and performant on mobile devices.

It's currently being used inside of forms with a weird override...

Did we actually design this? I think it might be a relic of cardinal (the CSS framework). It's ugly and distracting IMO.

http://take.ms/xZBof

screencast: http://dobt-captured.s3.amazonaws.com/ajb/screencast_2015-04-20_15-44-47_0_edited.mp4

I'm not sure how big of an issue this is, but I wanted to flag it since I originally thought it was a glitch of some sort.

It looks like due to our new styling of the :focus states in the navbar, it looks like the hover state is persisting after the nav links are clicked. Does that make any sense?

Kinda throwing me off... should we remove it?

The "chevron" is not vertically centered here:

Problem

I see things like this pretty frequently:

Pretty cramped.

Proposal

Textareas that automatically expand as you add more text.

I've only seen this implemented in super-hacky ways (like a duplicate textarea positioned -1000px offscreen). @dobtco/dev, any alternatives you've seen?

This is what we use on admin:

https://github.com/corysimmons/lost looks promising

Didn't want to make the change globally, as I'm not sure if we want this behavior in other dropdowns.

• Accessibility testing? https://github.com/Casecommons/capybara-accessible
• Interaction tests
• Visual regression tests?

(This is not high priority, but I want to track it somewhere.)

We redesigned our focus states in #69 with the following in mind:

However, I think that test is fatally flawed, because focus is not always given by a user tabbing through elements.

Can you tell what is focused here?

It's the "Confirm" button.

An ideal solution, in my mind, would be to revert back to my following proposal in #69:

We only apply subtle style changes to focus states. This can include changing the size of the focus outline, or replacing the outline with a border of similar color, but we never remove the outline/border completely.

I'm amending it, too, because I think the border should always be the same color.

I swear I've ran into more instances of this being problematic, but I can't find them right now. I'd be open to the argument that this is a one-off issue affecting the "Confirm" button, but I think that more issues will become apparent, not less.

Is it a link? is it a button? No, it's just problematic:

I take full responsibility for its wackiness.