Unify update pages

Surely this isn't limited to the Seven theme. It's the fault of the update manager itself. Moving component accordingly....

In theory I support this ticket. Some of the specifics of the error messages are insane, and I'm definitely not a fan of having 3 menu paths that all give you the same page. However, in practice, it's not quite so simple. Complicating factors:

A) We were trying to keep module-related activities "close" to each other, so when you're looking at the modules page, it was easy and obvious to find out about available updates and to initiate the update manager to update them.

B) Not everyone wants to use the update manager. Many people just want the status page but not the upgrade-in-place stuff. There's a kill-switch for this. Merging the available updates report and the update manager UI itself will make it harder (or impossible) to get the status without also getting the manager.

C) There's a lot of useful info (at least to some people) in the available updates report that doesn't fit into your wireframe. Stuff like "Also available", info about what modules are included in each project, etc, etc. My sense is that the available updates UI is already bursting at the seams just trying to fit all the data into one table -- if you also merge all the update manager UI into the same screen, it's either going to be totally overwhelming or it's going to have to be simplified so much that it's no longer valuable to many users.

D) I don't really understand how this belongs in "config," but I've never been particularly clear on the whole IA for the admin section, and the criteria to decide what makes something "config" vs. "structure" vs. whatever.

All that said, I *would* love for this mess to get cleaned up. I'd just like to see the discussion/design fleshed out to address these other points before I'd get too excited about trying to implement any changes.

Thanks,
-Derek

To clarify C: the available updates report (admin/reports/updates) has a lot of info that the update manager UI (admin/reports/updates/update) does not. Stuff like all the modules included in each project, other available branches/releases (e.g. when views goes from 7.x-3.3 to 7.x-4.0), release dates, special handling if you're using a -dev release, etc, etc. I don't know how to fit any of that into your wireframe, but all of it is (potentially) useful to the people reading the report. That's what I meant. Hope that helps...

I think the wireframe looks good, and is definitely much more compact and easy to process compared to admin/reports/update now.

Some specific feedback:

- Big +1 to limiting this screen to only the projects you care about. That massively cuts down on all kinds of visual cruft. I think removing the LOUD BLINDING COLOURS except if there's something to worry about is also a good step.

- I'm not sure I like centralizing this under reports (or wherever it's intended to go), rather than hinging it off of the modules/themes pages themselves (as the page is currently). It's very natural to view "Update" as a natural task alongside "List" and "Uninstall" as it relates to these things. We should at least make sure it's an action item at the top of the page to call attention to it (and it should mention that we AUTOMATICALLY UPDATE YOUR STUFF! How cool is that? :))

- I'd like to see a mock with the modules/themes/translations/profiles tables all together. My hunch though is that's going to look pretty cluttered, though. :\ Put them on different tabs, maybe? (like JS quick tabs inside the window?)

- The "Operations" column should have verbs in it. So "Views details" or "Read release notes" or similar.

- One thing we talked about on IRC for awhile is the fact that currently, Update Status gives you a heads-up that there's a 3.x version of a module coming down the pipeline with a "Also available: 6.x-3.0-alpha1" line. This is nice, because you can start playing around with it ahead of time and be appraised of any weirdness you need to do on upgrade. With this mock though, you wouldn't know about this until Views 3.x-1.0 was out and you were basically forced to do a major version upgrade, with no forewarning. I'd say this is a 10% case rather than a 80% case, but we'd need some means of replacing that functionality (could possibly be another screen, or "update advanced" in contrib?)

- What happens for people who have the "update manager" feature of update manager disabled? Do they see download links to the projects instead?

As far as I can remember, the original impetus for the multiple URLs was so that there is an "Update" tab on each of the module, theme, etc pages.

Subscribing for now, I'll look the rest of this over when I get a chance.

I'm not sure I like centralizing this under reports (or wherever it's intended to go), rather than hinging it off of the modules/themes pages themselves (as the page is currently). It's very natural to view "Update" as a natural task alongside "List" and "Uninstall" as it relates to these things.

A) We were trying to keep module-related activities "close" to each other, so when you're looking at the modules page, it was easy and obvious to find out about available updates and to initiate the update manager to update them.

Why do we list "Update" as a tab, but "Install new module" as only a local task?

I think we might need to drag the "Install new ..." pages into this discussion as well. Suppose, for example, I have Views 7.x-3.0-beta1 installed and I want to update it to 7.x-3.0-rc1. Why shouldn't I just be able to paste the URL into the "Install new module" page and have it update views? Instead I get a "Views is already installed" message (and without any link to the updates page).

D) I don't really understand how this belongs in "config,"

Ditto, but I don't know where else it fits either.

- Big +1 to limiting this screen to only the projects you care about.

I've never understood why we list "Up to date" projects on the "Available updates" tab.

Generally I like the vertical accordion UI. If it's easy to do this both with and without the checkboxes on the left that'd be a pretty wonderful way to deal with users who do not want the update manager.

Also this would the often requested feature of allowing updating to a development release by including radio buttons next to the recommended release and development release within the accordion fold.

Lastly we should consider the "release notes" link. Naively I think it'd be great if they could be included inline (since they occasionally contain some pretty big caveats), but their length and technicality would preclude this.

Regarding dev releases:

There is an issue going already: #750352: Provide an option to also offer dev builds as updates if they are newer - for advanced users & beta testers. And of course other issues against even allowing installation of dev releases through the UI: #1072176: Module Installation UI should not allow installation of -dev versions..

Clearly there isn't clarity about how to please both new users and power users.

We do currently show available dev releases on the "available updates" page:

If we are planning on merging the list updates page with the install updates feature (via checkboxes on the left hand side and a collapsible ui), we will need to figure out how to account for the dev releases.

I think some more mockups will help move this along. :)

Note: we only show you info about -dev releases (e.g. the date they were last rebuilt) if you're currently running a -dev release. Generally, we want to discourage them. But if you've got one, we try to let you know if a newer tarball is available. I agree -dev is tricky. It really complicates the code too. Sadly, plenty of projects rely on -dev so we kind of still have to support them. :/

Correcting issue summary input format.

Can't find the similar issues but I know there are at least a few for improving the UX of this, so I wonder if they can be merged.

Replacing the "update manager" pages entirely via autoupdates and project browser would help. Then we'd be back to a single "Available updates" report. I'm not keen on spending any energy improving the UIs that should be deprecated and removed.

And yeah, there are a bunch of issues to improve the UI of just the available updates report itself...

Tempted to call this "outdated" at this point, although neither project browser nor autoupdates are actually ready to add to core, so it's a murky area.

With #3491731: [META] Remove the ability to update modules and themes via authorize.php and child issues complete, we're back to a single "Available updates" report, so closing this as "outdated".