Show pending plugin update count on collapsed admin menu

[bhelms]

I would like the ability to see that new plugin updates are available even when the admin menu has been collapsed to the mini version.

[johnonolan]

Related: #12517

[mitchoyoshitaka]

mockup

[danapalooza]

Simple red "glowing" background indicating update(s) available. Preserves simplicity explicitly requested by user by choosing collapsed menu while still indicating that attention is required.

[danapalooza]

Simple switch to a red pug icon indicating update(s) available. Preserves simplicity explicitly requested by user by choosing collapsed menu while still indicating that attention is required.

[danapalooza]

Please excuse the deluge of mockups. As indicated in the three, I suggest that a simpler presentation might fit better with the user's explicit request for the simplicity of the collapsed nav menu.

Also: "updates-to-plugins-collapsed.png" is an unintended duplicate of "updates-to-plugins-collapsed.2.png".

[nacin]

I've deleted the duplicate image.

[westi]

Personally, I think the background glow might work better as the colourisation of the icon just makes it look like its the current page.

Alternatively could we not put the number in the corner like on an iPhone or would it just end up too small?

[johnonolan]

Dan/Mitch - Please post mockups to the UI group, Trac is for code. ​http://make.wordpress.org/ui

[dremeda]

WP-Plugin-Updates-Condensed-Images

[dremeda]

I disagree that Trac should be for just code. In my opinion, it is for changes/additions to WP. Or, even potential changes(not every diff I submit is excepted right?).

If we were adding a Monkey to the WP admin area, people working on and developing that Monkey should be "Trac"ing changes here, irrelevant of what the changes are right?

Think about what your request implies:

Don't upload iterations of design to your change management software solution, rather segment them off, keep them hosted separately from all other changes(potential changes) you're making to the project.

In my opinion, this is fundamentally distorted. If this is how we should handle mock-ups, there should be an area in Trac to host them for official reference at minimum.

Just my two cents :)

I've included a sample with the same circle update call that's in the expanded version, except smaller to fit into the condensed menu.

​http://core.trac.wordpress.org/attachment/ticket/13236/WP-Plugins-Updates-Condensed.png

[johnonolan]

dremada, the whole point of the UI group is that people who specialise in design are able to contribute to the design of WP. Posting mockups to trac means that a.) designers inside or outside the UI group don't see it, most designers don't even know what trac is - and b.) mockups are critiqued by developers, who specialise in code, not graphics.

The design side of WP is not the same as the development side, there is a single point of signoff for design decisions (Jane Wells). Only when that happens should it be brought across to trac to be developed.

This has nothing to do with segregation, core designers and developers are able to communicate with eachother where required about all issues extremely easily through a number of different open channels including several IRC chat rooms and dedicated mailing lists.

[dremeda]

This now becomes a topic of discussion, not changes or potential changes to core. This is the type of thing that should be carried out with the discussion tools you've mentioned. :)

In my opinion, this ticket has a valid approach. If this ticket is excepted as a valid recommendation to change core, it would require UI suggestions and changes to make it happen right? If that's the case, just like code, the changes or recommendations should be submitted by contributors to Trac, attached to the corresponding ticket. I wouldn't typically take and post my code changes on the dev P2 would I? I would probably be told to submit a diff to the appropriate ticket.

You're quite correct in saying designers may not be aware that Trac exists. That's a visibility issue on our part, meaning that those who contribute, and/or want to ensure others do too, should be advising that the tool exists.

In regards to the other communications mechanisms you've pointed out, you're suggesting that designers realize they exist. I would argue that most designers don't know what IRC stands for, and that other "open channels" are even available, including the mailing list which is dead, and Jane herself said she's probably going to get rid of. Again, a visibility issue. At the end of the day, those other mechanisms are not appropriate to track core changes or suggested changes, whether code, or graphics, or a Monkey.

Your direction doesn't account for the fact that a mock-up is a suggested change and/or potential addition to core, which should be tracked via ticket just like our great developers do every day on Trac for code enhancements, bug fixes, and process flow changes.

I am cognoscente to the fact that the design and dev sides of WP are different. I'm also aware that Jane is the UI single point of signoff, she's pretty good at it too!

To me, in her UI responsibilities, she is no different than a core dev (or trusted committer). Changes are changes, and authority is authority.

I by no means have authority to do my own thing, I'm just a contributor, and enjoy being one :) If it's determined we don't post mock-ups here, so be it, I will follow the appropriate guideline. Just wanted to throw my two cents out.

[dd32]

In the same spirit, The downside of the UI group is that primarily code developers who may follow trac will be unaware of the UI groups workings until a 'decision' is made, as well as well meaning new contributors posting something here which they feel needs to change (such as this ticket).

This is not the place to discuss this any further, This ticket has been flaged 'ui-feedback' and come 3.1 time, the UI group can take any suggestions posted here along with their process.

I'd encourage anyone who is interested in helping out with UI/UX/Graphics to join the UI group or at least follow it.

Hopefully one day, everything will be in the same space allowing for co-developing; Right now, Trac is better suited to tracking bugs and code, which is why the UI group has been formed outside of trac. Some overlap is going to have to be expected and handled by everyone.

---

On the topic of this ticket, I'm wondering how Comments should be handled, a highlight of some form, or a number,

[dd32]

And you can completely ignore that last paragraph, I didnt mean to include that..

[dremeda]

Fair enough.

A highlight may be appropriate, but I think a number would give a better idea of what you need to accomplish a lot quicker. There are examples of both directions already which is great. I do think it is a valid request to look at as a UI enhancement down the road.

[dd32]

This is not the place to discuss this any further, This ticket has been flaged 'ui-feedback' and come 3.1 time, the UI group can take any suggestions posted here along with their process.

Just to clarify that, I meant discussing of the Trac vs. UI group line.

[jane]

Irrelevant now as the Updates are persistent in the toolbar.