New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for wide widget form controls #18

Closed
westonruter opened this Issue Sep 25, 2013 · 20 comments

Comments

Projects
None yet
3 participants
@westonruter
Contributor

westonruter commented Sep 25, 2013

Widget form controls are able to specify their widget, like if a widget's form needs extra space to be able to fit the fields inside of it. We should allow customize widget form controls in the customizer panel to expand outside of the sidebar area when they are expanded.

But how can a wide widget control expand over the preview?

customize__wordpress_develop___just_another_wordpress_site_and_widgets__wordpress_develop__wordpress-3

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 22, 2013

Contributor

Actually, the consensus may be to eliminate support for wide widget controls altogether.

Contributor

westonruter commented Oct 22, 2013

Actually, the consensus may be to eliminate support for wide widget controls altogether.

@shaunandrews

This comment has been minimized.

Show comment
Hide comment
@shaunandrews

shaunandrews Oct 22, 2013

Contributor

We should allow customize widget form controls in the customizer panel to expand outside of the sidebar area when they are expanded.

No, we shouldn't.

Contributor

shaunandrews commented Oct 22, 2013

We should allow customize widget form controls in the customizer panel to expand outside of the sidebar area when they are expanded.

No, we shouldn't.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 22, 2013

Contributor

@shaunandrews 😄 OK! 👍

Contributor

westonruter commented Oct 22, 2013

@shaunandrews 😄 OK! 👍

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 28, 2013

Contributor

@shaunandrews here's another instance of wide widgets: the Jetpack Widget Visibility module.

customize_twenty_thirteen__wordpress

See the relevant code in widget-conditions.js which tries to force a widget form control to be wide:

// The expanded widget must be at least 400px wide in order to
// contain the visibility settings. IE wasn't handling the
// margin-left value properly.

if ( $widget.attr( 'style' ) )
    $widget.data( 'original-style', $widget.attr( 'style' ) );

var currentWidth = $widget.width();

if ( currentWidth < 400 ) {
    var extra = 400 - currentWidth;
    $widget.css( 'position', 'relative' ).css( 'left', '-' + extra + 'px' ).css( 'width', '400px' );
}

I've added a commit (5d6dd72) to try to prevent plugins from forcing widgets to be wide in the customizer and break the layout, but doing so could break the layout of the control's contents.

/cc @cfinke

Contributor

westonruter commented Oct 28, 2013

@shaunandrews here's another instance of wide widgets: the Jetpack Widget Visibility module.

customize_twenty_thirteen__wordpress

See the relevant code in widget-conditions.js which tries to force a widget form control to be wide:

// The expanded widget must be at least 400px wide in order to
// contain the visibility settings. IE wasn't handling the
// margin-left value properly.

if ( $widget.attr( 'style' ) )
    $widget.data( 'original-style', $widget.attr( 'style' ) );

var currentWidth = $widget.width();

if ( currentWidth < 400 ) {
    var extra = 400 - currentWidth;
    $widget.css( 'position', 'relative' ).css( 'left', '-' + extra + 'px' ).css( 'width', '400px' );
}

I've added a commit (5d6dd72) to try to prevent plugins from forcing widgets to be wide in the customizer and break the layout, but doing so could break the layout of the control's contents.

/cc @cfinke

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Oct 28, 2013

Contributor

As noted in #39, here's how the Widget Visibility controls now look when rendered in the customizer:

customize_twenty_thirteen__wordpress

Contributor

westonruter commented Oct 28, 2013

As noted in #39, here's how the Widget Visibility controls now look when rendered in the customizer:

customize_twenty_thirteen__wordpress

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Nov 7, 2013

Contributor

@shaunandrews here's an extreme example of wide widget form controls: http://wordpress.org/plugins/black-studio-tinymce-widget/screenshots/

image

Contributor

westonruter commented Nov 7, 2013

@shaunandrews here's an extreme example of wide widget form controls: http://wordpress.org/plugins/black-studio-tinymce-widget/screenshots/

image

@westonruter westonruter reopened this Nov 7, 2013

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter
Contributor

westonruter commented Nov 7, 2013

westonruter added a commit that referenced this issue Nov 8, 2013

Squashed 'bin/' changes from 86d46a9..894d120
894d120 Merge pull request #18 from x-team/issue-16
de1db88 Remove wordpress- from url
5581e97 Get latest trunk file from github
9d1d025 Add base phpcs ruleset for plugins
5de1b8e Update .jshintrc to match new in core
ab7b9cd Update .tavis.yml to check against master and latest. This closes #16 and #15
9aa3e33 Merge pull request #17 from jonathanbardo/master
63a11a4 Correct small typo
8e3bab1 Merge pull request #15 from jonathanbardo/master
ed0b379 Update WP version to latest stable release
6956ba1 Merge pull request #13 from jonathanbardo/master
a864385 Update WP_VERSION to 3.7
4cd538f Merge branch 'master' of github.com:x-team/wp-plugin-dev-lib
258cdf9 Fix reference from jshint to phpcs
c9f45eb Add formatting
7d26511 Add git-subtree instructions
9c1e6ea Update svn-push to work with svn repo out of git repo

git-subtree-dir: bin
git-subtree-split: 894d120dd0047c75076df7d37a8d9b81bb15aa41
@westonruter

This comment has been minimized.

Show comment
Hide comment
Contributor

westonruter commented Nov 25, 2013

@PeterKnight

This comment has been minimized.

Show comment
Hide comment
@PeterKnight

PeterKnight Dec 9, 2013

Right now it's pretty difficult to expand the width and have it expand outside the side panel, at least not without a bunch of js trickery. I've tried floating a widget outside the side panel altogether but that comes with a usability cost.

Any thoughts on displaying the widget controls floated next to the actual widget in the page?

PeterKnight commented Dec 9, 2013

Right now it's pretty difficult to expand the width and have it expand outside the side panel, at least not without a bunch of js trickery. I've tried floating a widget outside the side panel altogether but that comes with a usability cost.

Any thoughts on displaying the widget controls floated next to the actual widget in the page?

@shaunandrews

This comment has been minimized.

Show comment
Hide comment
@shaunandrews

shaunandrews Dec 9, 2013

Contributor

I've been thinking about this, and I'd like to avoid covering the preview if it all possible.

Shaun

On Dec 9, 2013, at 9:04 AM, PeterKnight notifications@github.com wrote:

Right now it's pretty difficult to expand the width and have it expand outside the side panel, at least not without a bunch of js trickery. I've tried floating a widget outside the side panel altogether but that comes with a usability cost.

Any thoughts on displaying the widget controls floated next to the actual widget in the page?


Reply to this email directly or view it on GitHub.

Contributor

shaunandrews commented Dec 9, 2013

I've been thinking about this, and I'd like to avoid covering the preview if it all possible.

Shaun

On Dec 9, 2013, at 9:04 AM, PeterKnight notifications@github.com wrote:

Right now it's pretty difficult to expand the width and have it expand outside the side panel, at least not without a bunch of js trickery. I've tried floating a widget outside the side panel altogether but that comes with a usability cost.

Any thoughts on displaying the widget controls floated next to the actual widget in the page?


Reply to this email directly or view it on GitHub.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Dec 9, 2013

Contributor

What about if we open the wide-widget control in another monitor!? If they lack another monitor, the control can pop-up on their smartphone or tablet 😉

All joking aside, this is a tough issue.

@shaunandrews @PeterKnight Here's an idea that just came to me: just as the new widget addition panel shifts in from the left, what if wide widget controls were placed inside of a panel that shifts in from the top (or from the bottom?

Contributor

westonruter commented Dec 9, 2013

What about if we open the wide-widget control in another monitor!? If they lack another monitor, the control can pop-up on their smartphone or tablet 😉

All joking aside, this is a tough issue.

@shaunandrews @PeterKnight Here's an idea that just came to me: just as the new widget addition panel shifts in from the left, what if wide widget controls were placed inside of a panel that shifts in from the top (or from the bottom?

@PeterKnight

This comment has been minimized.

Show comment
Hide comment
@PeterKnight

PeterKnight Dec 9, 2013

It's definitely a tough one.

I think there would be problems with having another panel slide in from the top or bottom, the widget itself might get obscured or the viewing area would be too small. Then there's the issue that some widgets controls take up a lot of height, and some take up more width.

One advantage of having a floating widget panel that hugs the edge of the widget: the JS can figure out what the best way to display the widget settings panel and keep the widget that is being changed in view. After all, when in widget edit mode, all that matters for the task at hand is seeing the widget and changing it's settings. The main panel on the left could even be collapsed while in widget edit mode.

PeterKnight commented Dec 9, 2013

It's definitely a tough one.

I think there would be problems with having another panel slide in from the top or bottom, the widget itself might get obscured or the viewing area would be too small. Then there's the issue that some widgets controls take up a lot of height, and some take up more width.

One advantage of having a floating widget panel that hugs the edge of the widget: the JS can figure out what the best way to display the widget settings panel and keep the widget that is being changed in view. After all, when in widget edit mode, all that matters for the task at hand is seeing the widget and changing it's settings. The main panel on the left could even be collapsed while in widget edit mode.

@shaunandrews

This comment has been minimized.

Show comment
Hide comment
@shaunandrews

shaunandrews Dec 13, 2013

Contributor

A floating panel is likely the best solution. My biggest concern with this is that it add a whole different level of UI for managing content in the customizer. I'm not against it (in fact, some of my sketches show this exact solution), but I worry about how it would be perceived with the core developers — also it seems like a lot of work.

Contributor

shaunandrews commented Dec 13, 2013

A floating panel is likely the best solution. My biggest concern with this is that it add a whole different level of UI for managing content in the customizer. I'm not against it (in fact, some of my sketches show this exact solution), but I worry about how it would be perceived with the core developers — also it seems like a lot of work.

@shaunandrews

This comment has been minimized.

Show comment
Hide comment
@shaunandrews

shaunandrews Dec 13, 2013

Contributor

For reference, check out #17

Contributor

shaunandrews commented Dec 13, 2013

For reference, check out #17

@PeterKnight

This comment has been minimized.

Show comment
Hide comment
@PeterKnight

PeterKnight Dec 13, 2013

I think the screen you have at #17 looks great. Wouldn't positive user tests make it hard for core devs to deny the approach? IMO it's the most elegant solution, I do get the work portion of it though because of the extra moving parts. I don't think there's a downside though, even if it doesn't land in core, it will become the best way to modify widgets.

Scribu's front end editor has a widget editor (you've probably used it), his version loads the widgets panel in place but obscures the view of the widget (temporarily exchanging the widget contents with the editing panel). It's intuitive but limited and also suffers from css conflicts because unlike the customizer, it doesn't benefit from the iframe isolating the stylesheets. But it does demonstrate the value of having the options panel right there on the live page.

What I do like about this and other developments across the core code base is the ability to invoke individual UI components anywhere. We can now get the wp_editor anywhere, the media dialog anywhere and so forth, image editing is going in that direction too I think. I think the only way to figure out if this approach will work as well with widgets is to attempt it.

PeterKnight commented Dec 13, 2013

I think the screen you have at #17 looks great. Wouldn't positive user tests make it hard for core devs to deny the approach? IMO it's the most elegant solution, I do get the work portion of it though because of the extra moving parts. I don't think there's a downside though, even if it doesn't land in core, it will become the best way to modify widgets.

Scribu's front end editor has a widget editor (you've probably used it), his version loads the widgets panel in place but obscures the view of the widget (temporarily exchanging the widget contents with the editing panel). It's intuitive but limited and also suffers from css conflicts because unlike the customizer, it doesn't benefit from the iframe isolating the stylesheets. But it does demonstrate the value of having the options panel right there on the live page.

What I do like about this and other developments across the core code base is the ability to invoke individual UI components anywhere. We can now get the wp_editor anywhere, the media dialog anywhere and so forth, image editing is going in that direction too I think. I think the only way to figure out if this approach will work as well with widgets is to attempt it.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jan 23, 2014

Contributor

Closely related to #26701 Text and RSS Widgets Unusable on Mobile, a fix in WordPress 3.8.1

Contributor

westonruter commented Jan 23, 2014

Closely related to #26701 Text and RSS Widgets Unusable on Mobile, a fix in WordPress 3.8.1

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jan 29, 2014

Contributor

Here's a few more mocks from @MichaelArestad: https://cloudup.com/iqH4tGUbQPn

Contributor

westonruter commented Jan 29, 2014

Here's a few more mocks from @MichaelArestad: https://cloudup.com/iqH4tGUbQPn

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Feb 4, 2014

Contributor

Today on #wordpress-dev, I mentioned to @nacin in response to his request for a status update:

we're still stuck on a good path forward for handling wide widget controls

He replied:

let's assume we just made wide widget controls wide, no matter how ugly it is
we can't make it extend out over the panel?
honestly, what to do with wide widgets seems like very low priority.

I said:

it seems I can only get the control to break out of the customizer panel with a position:fixed
I tried position:relative with a z-index:infinity, but it doesn't work
ok, I think position: fixed will work nicely actually for a quick solution. I'll follow that up separately.

So I think the quickest solution will be to apply a position:fixed on the contents of the widget control. This will allow the widget to appear over the panel and it can be dragged around with some.

See full transcript.

Contributor

westonruter commented Feb 4, 2014

Today on #wordpress-dev, I mentioned to @nacin in response to his request for a status update:

we're still stuck on a good path forward for handling wide widget controls

He replied:

let's assume we just made wide widget controls wide, no matter how ugly it is
we can't make it extend out over the panel?
honestly, what to do with wide widgets seems like very low priority.

I said:

it seems I can only get the control to break out of the customizer panel with a position:fixed
I tried position:relative with a z-index:infinity, but it doesn't work
ok, I think position: fixed will work nicely actually for a quick solution. I'll follow that up separately.

So I think the quickest solution will be to apply a position:fixed on the contents of the widget control. This will allow the widget to appear over the panel and it can be dragged around with some.

See full transcript.

@westonruter westonruter self-assigned this Feb 4, 2014

fnakstad added a commit to knishiura-lab/wp-widget-customizer that referenced this issue Feb 5, 2014

@PeterKnight

This comment has been minimized.

Show comment
Hide comment
@PeterKnight

PeterKnight Feb 5, 2014

Why not use jquery UI position to float the controls next to the widget in the preview and use it for both narrow and wide widgets so it is a consistent experience?

I don't see how the alternatives would work much better. Seems like Nacin was for making the panel wider, but that brings up the issue of triggering responsive layouts. Using position fixed the controls might clip or hover over the preview area which might obscure the widget you're editing. When I tried this a few months ago with twenty fourteen that's the issue I had because of the left sidebar.

PeterKnight commented Feb 5, 2014

Why not use jquery UI position to float the controls next to the widget in the preview and use it for both narrow and wide widgets so it is a consistent experience?

I don't see how the alternatives would work much better. Seems like Nacin was for making the panel wider, but that brings up the issue of triggering responsive layouts. Using position fixed the controls might clip or hover over the preview area which might obscure the widget you're editing. When I tried this a few months ago with twenty fourteen that's the issue I had because of the left sidebar.

@westonruter westonruter referenced this issue Feb 7, 2014

Merged

Proposal for supporting wide widget controls #89

4 of 6 tasks complete

@westonruter westonruter closed this Feb 9, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment