As you know part of the scope for 3.3 was a revised admin bar that would reduce duplication in the admin header. The first draft of it has been posted to Trac.
It needs a color refresh, some optimization, some decisions about which links going where, etc, but is the starting point we are using. Would like to get it back toward the lighter gray we used in the header before, but with some border maybe so it doesn’t look like browser chrome. Fiddling with the links and stuff will happen on Trac, but if anyone wants to mock up some color variations, we have until Sunday.
Need a better label for email field in default theme comment form so it doesn’t sound like it’s promising peace, justice, and respect for email address privacy by blog author/owner.
Goal of this ticket is to make it faster and easier to activate themes in multisite installs. See my comment on the ticket. Looking at a) possible label change, b) adding a highlight state to the themes list table, and/or c) any UI suggestion that would make this process easier. Let’s hash out early ideas and/or mockups here, and when we’ve got something solid, move over to trac.
This thread is for suggestions/questions about the UI decisions in the 3.2 style update, so the trac ticket can be kept clean for ‘this needs to be done’ tasks identified by leads and/or bug reports related to the style code.
Storage Space 100MB Space Allowed 0MB (0%) Space Used
…and “Space Used” is green by default. It should be gray since it doesn’t denote an action has applied a positive status. Gray until the ‘almost near limit’ color kicks in.
The “View All” buttons on the dashboard boxes are weird b/c they are buttons, but they aren’t actions, they are links. Would like to start switching over to a standard where buttons are mostly reserved for action/commitments, not just links to another screen.
Suggestions for Recent Comments box: instead of “View All” button, replace with links to the various views of the comments screen. So:
View All | Pending (24) | Approved | Spam (6) | Trash (3)
…where the link styles are the same as on edit-comments.php
Trac UI challenge:
Probably not that much of a challenge, necessarily, but would need approved mockups for someone to want to start a patch. Collapsible page hierarchy on edit.php?post_type=page.
Made a ticket for something that has been on our radar since 2.7 was in development, but just never got any kind of prioritization because it was minor compared to more serious UI things. That said, since it’s kind of minor, would be a nice thing to whip out.
Ticket #17028 – Move the “last edited at” text and saved/updated/published notices in post/page editor
1. The timestamp of the last save is currently displayed at the bottom right of the editor box. It would make more sense for this information to be tied to the Publish box instead.
2. The yellow alert boxes that appear at the top of the page are weird. a) They should appear closer to the button that caused the action (general usability/accessibility best practice), so probably by the Publish box. b) Once you edit anything on the screen, the “post updated” (or saved, etc) text should go away, because it is no longer current.
Am thinking we could combine these two things into one flexible status message that’s located in or adjacent to the Publish box.
#16068 – Reverting from Scheduled post to Publish Immediately.
Related older ticket: #8368 – Scheduling post time behavior and language refinements
See ticket for description of problem, pro/con of implementing. The Publish box is kind of a mess that we want to look at in 3.2 anyway, so it wouldn’t hurt for people to start playing around with the best way to incorporate a ‘reset’ feature if we decided 90% of users really need it.
Ticket #15942 – Username vs. Email for Identifying Users
Reported Problem: “When I create a new blog in a network, I am asked to enter the Admin Email. This is rather useless to me because all our accounts come from an LDAP directory. So I have to remember the site admin’s email address, which is not always consistent across my organization. It would be nicer if I had an autocomplete-style field where I could enter the user’s ID.”
The issues of selecting existing users vs. adding new users and doing so by email address vs. username touches more admin interactions than just this one. We’ll need to address it as a whole rather than just focusing on this one person’s complaint, but using this ticket as a starting point for discussion.