| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | update.module |
| Category: | task |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed (fixed) |
| Issue tags: | Update manager, Usability |
Issue Summary
Assuming #538660: Move update manager upgrade process into new authorize.php file (and make it actually work) lands, the "Update" action page to actually update stuff could probably use some more UX help. There was a long an grizzly argument about it over at #395472: Plugin Manager in Core: Part 1 (backend), so this has a high risk of becoming a marathon UX bikeshed. To allow plugin manager in core at all, we need to postpone any other UX work on this page until post 10/15.
What we currently have is functional (see #538660-97: Move update manager upgrade process into new authorize.php file (and make it actually work) for some screenshots, especially plugin_php-538660-96.normal-case-update-page.png and plugin_php-538660-96.worst-case-update-page.png), but not great. This issue is where we'll fix it. Just not this week, okay? ;)
Comments
#1
Common don't call my profession, *bling* - thats not respectful. Renamed it - hope it fits better now
#2
Tagging for UX folks...
#3
title
#4
Sorry Bojhan, I meant no offense at all. I use "bling" all the time to refer to stuff I'm doing. I didn't mean to imply it was superficial, fake, or worthless. Not in the least. This issue is very important. I hope it doesn't get off on the wrong foot because of a title I came up with in a state of sleep-deprived delirium while trying to get all the functionality working and in core so that we'd actually have a UI to clean up. ;)
Better title still to be more specific about the scope of this issue...
Cheers,
-Derek
#5
It's oke, I think this interface is pretty far actually - it implemented my direction, I wasn't aware of that. Could you perhaps try to make a screenshot, of how this page would look on an ordinary site?
#6
Relatively normal case:
- Missing a security and non-security update for contrib
- Core also out of date (sadly, we can't update that for them at this time, see #606592: Allow upgrading core with the update manager)
#7
Two obvious problems from screenshot #6:
A) "Add-ons requiring manual updates" is listing core, which isn't an "add-on". ;)
B) The "Enabled add-ons" heading only needs to show up if there's a table of disabled stuff, too. It doesn't appear if that's the only table, but in this case of 2 tables: (auto enabled + manual enabled), we don't need it either.
I think to actually solve this (and any of http://drupal.org/project/issues/search/drupal?issue_tags_op=and&issue_t... for that matter) we desperately need to standardize on the terminology for we want to use for "projects" -- sets of modules or themes that you install in a single package...
#606646: Standardize UI language for "projects" and the generic term for a module or theme
#8
We had a long IRC chat about this tonight (see also #606646-13: Standardize UI language for "projects" and the generic term for a module or theme). The conclusion is that we don't want "add-on" here in these table labels. Instead, we want the labels to be dynamic. If there are just modules in a table, the label says "... modules". If there are both, "... modules and themes", etc. At my request, Bojhan is now going to go through all the cases and provide the exact copy we want for each table label in each case.
#9
So I am not sure if I got all the use cases, but to provide more context. We have to align these modules with the mental models of users. They expect to update their modules and themes. for sane sake we left out contrib adding any other use cases - we think in such cases they would over-write these defualts with for example "Projects".
Its important to lay out, that often the disabled tables would not exist this because it is a opt-in function. Secondly themes in general occur far less often then module updates, therefor we have chosen to put these inline in the table. Now to continue on the label they are dynamic in the sense that they depend on whatever is in the table.
Enabled Modules
Enabled Modules and Themes
Disabled Modules
Disabled Modules and Themes
Disabled Modules requring manual update
Disabled Modules and Themes requring manual update ( a bit long, but very very rarely occurs)
This should all make sense if you put it context of the user, instead with trying to come up with an all encompassing term - which is probally going to be to clever to really understand, we tried to map this to the users mental model. Without confusing him of the actual table contents.
#10
@Bojhan: Thanks, that's a good start. However:
A) Please (re)read problem (A) from comment #7. What should we call the heading on the table for "Enabled stuff you have to update manually" when it includes core?
B) Do you agree with (B) from #7 that we don't need any label at all on the first table in the screenshot from comment #6?
C) Did you really mean to capitalize "Modules" and "Themes" like that?
D) I assume we only make the "Enabled" distinction if there are any "Disabled" tables appearing, right? E.g.
E) Let's reconsider the "manual updates" case for a second. Since there are no checkboxes, it's not clear we need separate tables for enabled vs. disabled. Perhaps we should just have a single table for all manual updates with the label: "Manual updates required"? That'd immediately solve (A) and prevent the label from getting unnaturally long in certain cases. We can add a little "(disabled)" text and grey out the rows or something for any disabled stuff listed in there. Sort it to the bottom, too, for all I care. In fact, since it's not table select, we can even just add a sub-header row inside the table?
#11
A) I think we don't have to change, core is just a bunch of modules to. Perhaps it can always be on top?
B) Agreed
C) Pardon me, no - just lowercase them
D) Yes
E) Could you provide a screenshot for that usecase and solution?
#12
I'm not going to mess with (E) until #613230: Allow upgrading -dev with update manager is resolved. If that lands (and at this point, I don't see what's wrong with it), that totally simplifies this whole issue, since core will be the only thing (for now) that needs to be manually updated, and that's always enabled, so there'd only ever need to be a single "Manual updates required" table to list core...
#13
#613230: Allow upgrading -dev with update manager just landed, so #10.E is vastly easier. It now just says "Manual updates required" and is a single table, including just core. So now there are at most 3 tables, "Enabled stuff", "Disabled stuff", and "Manual updates required". Note that it's possible a contrib will extend update manager and need to add other things to the Manual updates required" table. Plus, even if it's just core, it's still nice to have the same format of the name, what's installed, and a link to the recommended version. Of course, if we manage to solve #606592: Allow upgrading core with the update manager we should just rip this table out completely -- if contrib needs it, it can add it.
I'll work on fixing the headers on the "Enabled stuff" and "Disabled stuff" tables now...
#14
Ok, this implements the dynamic labels Bojhan and I previously discussed. Here's the patch and screenshots of a bunch of different cases.
#15
It looks RTBC to me, might sound a bit complex to some - but context driven UI text is most always better.
#16
Small detail: in these screenshots, we write 'Security Update' instead of 'Security update'. Not introduced by this patch.
#17
@Dries that's already fixed at #605920: Fix all buttons in update manager workflow to use "Sentence case" labels -- eagerly awaiting your commit. ;)
#18
Is there a reason the labels have to be _that_ dynamic (vs always saying 'modules and themes')? It is nice to make them dynamic, but it also makes it hard to reference them, and to guide people. It is easier when those labels would be more static. I don't feel strongly about this though, but I wanted to bring it up because it feels like we're fixing one problem, and making another more difficult.
#19
@Dries: that was the result of a long conversation with Bojhan and #606646: Standardize UI language for "projects" and the generic term for a module or theme... I can't really answer this, other than to hope that Bojhan replies here. Technically it's obviously easy to do so. It's just a question of if the UX team thinks that static generic labels are okay for this, instead of dynamic specific labels as requested in #9...
#20
Well I think obviously it is better, to say less whenever that is possible - simply because "Modules and themes" is really not applicable that often, it is very often just Modules. Given that this change is very good, because the less we put above headers like these as this the easier it is to read. You have to remember we can have 4 titles on this screen, having long titles on all of them - can be very confusing.
@Dries I doubt that refrence will truely be a problem? You either refrence to Modules or Modules and Themes.
Eitherway, I prefer the dynamic way - but it wouldn't be a biggie either if we go with a static title.
#21
As a book author and part-time member of the documentation team, Dries in #18 makes a good point. We do not want to have to write documentation that says "Underneath the 'Modules' heading (or 'Modules and Themes' or possibly 'Themes'...), you will find..."
Additionally, while it's not currently on the roadmap for Update Manager clean-ups that I'm aware of, it should also be noted that installation profiles are another thing that can now be updated. This logic is going to be absolutely bananas when it starts having to choose one of the following:
- Modules
- Installation profiles
- Modules and installation profiles
- Modules and themes
- Themes and installation profiles
- Modules, themes, and installation profiles
And if we ever make Translations updatable through Update Manager, that'll be a whole 'nother kettle of fish. I don't really think this approach is sustainable for the future growth we want to support.
Let's go with a static title of "Modules and themes." This is not only easier on the documentation team, but it also informs users that even though they don't currently see themes there, that that's where they'll appear once they have some. If we end up adding additional types of things here later, we can discuss changing the static label to "Downloaded projects" or something and it'll be a one-line change as opposed to a 25-line one.
(Sorry, dww, couldn't bring myself to commit this the more that I thought about it. :))
#22
Since we're reopening this can, lemme add some more worms:
- The labels only show up at all if you've configured your site to fetch data about disabled projects, which is a setting which defaults to FALSE. In the common case, there's only a single table here with no label:
Or, if core is also missing an update, you'd see one of these:
http://drupal.org/files/issues/602496-13.update_selector_cleanup.just_co...
http://drupal.org/files/issues/602496-13.update_selector_cleanup.core_an...
- Thanks to #613230: Allow upgrading -dev with update manager there are now at most 3 tables (enabled projects, disabled projects, manual updates).
If we want labels that are consistent, concise, and flexible, why not just "Enabled", "Disabled", and "Manual updates required"? Trivial patch attached. Here's how it looks if you're missing every kind of update:
here's how it looks after you select all on the Enabled table, go through the update workflow, and get back to the report (so only core and your disabled stuff is now out of date):
Thoughts?
#23
p.s. I should mention that in an earlier issue, Jacob had given these tables a "Type" column for the module vs. theme info. Lots of things have changed since then, but a basic screenshot of the concept is here:
http://skitch.com/jacobsingh/bsisi/available-updates-dev7
Not sure if we want that, or stick with the slightly weird "(theme)" prefix on anything that's not a module. To address webchick's concern in #21 about extending this UI to support other kinds of things, I at least need to ask the question.
#24
Nice! I like this approach much better. I'm already at a page called "Available updates", so this is just going to inform me what the status of those updates are.
I debated about the 'type' column (which IMO is a no-go because it would say 'module' 99.% of the time, just adding visual noise), and/or how else to communicate whether these are modules or themes or whatever. But in the end, I honestly really don't think it matters to an end user where the code is coming from; it's all just code that needs updating, for the purposes of this screen.
I'm marking to RTBC, and will let this simmer for ~12 hours in case someone from the UX team wants to raise a counter-point. But I think this satisfies Bojhan's concerns as well about too much text to read; now we're down to just a single word on each heading.
#25
We do not have counter points, we knew that whenever there where other things then modules & themes - this pardigm would fall. I do not think the documentation argument really stands, we should not optimize our interfaces for documentation (sounds sillly, but yes - that is bad practice).
Obviously its a bit wierd, that you go enabled what? But with 3.5 weeks, lets just go with this
#26
I think this solution is fine.
#27
Ok, committed #22 to HEAD. I guess we'll find out soon enough if people find this terribly confusing.
#28
Automatically closed -- issue fixed for 2 weeks with no activity.