Opened 3 years ago

Last modified 7 months ago

#13313 new defect (bug)

WP import: "Upload file and import" should be deactivated until a filename is entered

Reported by: lloydbudd Owned by:
Priority: low Milestone: WordPress.org
Component: Import Version: 3.0
Severity: minor Keywords: ux-feedback ui-feedback has-patch
Cc: dangayle, fandasson

Description

WP import: "Upload file and import" should be deactivated until a filename is entered

ENV: WP trunk 3.0-beta2-14526
Mac OS / Firefox 3.6.3

Additional Details

Same issue with wp-admin/media-new.php (browser upload)

Attachments (1)

common.dev.js.diff (528 bytes) - added by fandasson 12 months ago.
I'm not sure wheter common.js is the right place for this. But I didn't want to put it directly into template.php

Download all attachments as: .zip

Change History (12)

  • Type changed from defect (bug) to feature request

-1:

Can't find a good reason for that. Rather a useless line of javascript than an advantage. And then we need a JS and no-JS version.

  • Type changed from feature request to defect (bug)

ocean90, thanks for the feedback.

You think it is a good user experience to have enabled a button that shouldn't be clicked? (bug)

Maybe, I'm missing an implementation detail, but the improved experience would only be appropriate for JS enabled, and it would be trivial to degrade gracefully (the current behavior).

comment:3 follow-up: ↓ 4   ocean903 years ago

  • Keywords ux-feedback, ui-feedback added; import, wxr, file selector removed

Then we should use it on every page.

  • on Updates page, don't show the button Update plugins, if no plugin is selected
  • on pages with a search, don't show the button Search, if nothing is typed in for a search
  • on Add new (post/page), don't show the button Publish/Updaten, if noting has changed
  • ...

So it's not really a bug, that's the UI.

comment:4 in reply to: ↑ 3   lloydbudd3 years ago

Replying to ocean90:

Then we should use it on every page.

  • on Updates page, don't show the button Update plugins, if no plugin is selected
  • on pages with a search, don't show the button Search, if nothing is typed in for a search
  • on Add new (post/page), don't show the button Publish/Updaten, if noting has changed
  • ...

Those are interesting ones as well, though don't stand out for me in the same way because those are all pages with many potential work flows. If disabling there could be done *extremely* elegantly as well, then it should -- but I suspect the current browsers would result in a sometimes less than polished experience.

comment:5   jane3 years ago

This is already marked as future release, so we can look at the overall experience issue and try to fix it across the board. We're trying to hit RC1 in 2 days, and I wouldn't call this a blocker.

comment:6 follow-up: ↓ 7   dangayle3 years ago

The "disabled" HTML form attribute exists exactly for this, and should be a trivial bit of js to add. The disabled attribute is supported in all major browsers.

W3C HTML 4.01 - 17.12 Disabled and read-only controls

In contexts where user input is either undesirable or irrelevant, it is important to be able to disable a control or render it read-only. For example, one may want to disable a form's submit button until the user has entered some required data.

Note. The only way to modify dynamically the value of the disabled attribute is through a script.

comment:7 in reply to: ↑ 6   dangayle3 years ago

Replying to dangayle:

The "disabled" HTML form attribute exists exactly for this, and should be a trivial bit of js to add. The disabled attribute is supported in all major browsers.

Sorry, I should have said disabling a form element is trivial. Determining if it should be disabled is another thing altogether.

  • Cc dangayle added

I'm not sure wheter common.js is the right place for this. But I didn't want to put it directly into template.php

  • Cc fandasson added
  • Keywords ux-feedback has-patch added; ux-feedback, removed
  • Milestone changed from Future Release to WordPress.org

For importers, moving to WordPress.org milestone.

For similar behaviour throughout the core UI, #20855 should handle that.

Last edited 7 months ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.