![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 17 years ago
Closed 17 years ago
#10168 closed enhancement (wontfix)
Easy to update the wrong plugin by accident, if...
| Reported by: | hakre | Owned by: | janeforshort |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugins | Version: | 2.8 |
| Severity: | normal | Keywords: | needs-patch |
| Cc: | Focuses: |
Description
The usability of the plugin interface in admin can be improved. If you have two plugins beneath each other that are updateable it can happen that you click the wrong link to update while in rush.
Being in rush only means that you do look and click faster. This is a sign that usability can be improved because it is not easy to use.
I can imagine an UNDO feature for the plugin update or the other thing would be posing question if it is really intended to upgrade _that_ plugin.
Attachments (1)
Change History (11)
#2
@
17 years ago
- Keywords reporter-feedback 2nd-opinion added; developer-feedback removed
- Milestone Unassigned → 2.9
#3
@
17 years ago
An improvement would be to pose an additional question after the click wether or not the plugin should be updated. For a straight visual improvement I do not have an idea.
#4
@
17 years ago
Having the question would mimic the same behaviour as delete. And should not be that hard to integrate.
#5
follow-up:
↓ 7
@
17 years ago
- Keywords reporter-feedback removed
The screen to enter the FTP Details could contain the package's name, though.
Except not everyone has to deal with that screen.
If people insist on a warning, Then a JS confirm is the only type I'd remotely support.
#7
in reply to: ↑ 5
@
17 years ago
- Keywords needs-patch added
Replying to dd32:
If people insist on a warning, Then a JS confirm is the only type I'd remotely support.
That is so not taking care then. As webdev you should ever take the JS=OFF route first and enhance it later. So for those who have JS=ON can save one request.
Infact, before making things complex, just go the same route as delete. For delete there actually is no JS warning. It works pretty straight forward. Because the principle of the implementation of the question is already done with the delete action and the user already knows how to deal with it, it is a strong argument _against_ doing things in a new way here. Like introducing a JS confirm.
#8
@
17 years ago
My definition of that was a JS comfirm for those with JS, a fallback should always be available for non-js users, but those with js should never see it.
IMO, the UI should make it clearer as to which plugin it is, theres a ticket on that which missed 2.8
I honestly fail to see how we could improve the above screenshot any further...
The update link could go alongside "Activate | Delete" et al, but that seems a bit wrong.
The screen to enter the FTP Details could contain the package's name, though.