WordPress.org

Ready to get started?Download WordPress

Forums

Redundant "New Post" links are redundant (6 posts)

  1. Aaron Hockley
    Member
    Posted 2 years ago #

    While in the "Edit Post" screen, I noticed that I have three different links for adding a new post, all clustered in the upper left area of the screen.

    Seems redundant. The one that really seems out of place is the "Add New" link to the right of the "Edit Post" screen title. See this screenshot, I've circled the three links and indicated in red the one that's bugging me:

    http://www.mobypicture.com/user/ahockley/view/11619351

    Seems like the toolbar makes the link to the right of the page title redundant; perhaps this could be removed. Heck, I'd even write that patch.

  2. Make it so!

    Post it in core.trac.wordpress.org :)

  3. Jen Mylo
    Key Master
    Posted 2 years ago #

    Actually, UI suggestions are better off not being put into Trac, because Trac is meant for development, not design debate. This requests & feedback forum or the Ideas forum are the places I send people with requests that fall into the categories of:

    • UI - I don't like this
    • UI - I think x would be better

    UI things that should go straight to Trac are bugs:

    • Bad alignment
    • Color is off
    • Buttons don't match

    For other things we try to route UI things through the UI group and/or the lead team before it gets a trac ticket because a conversation on a single trac ticket can cause dozens of people to lose a lot of time following the comments on something that isn't really a development debate.

    In this case the UI redundancy is intentional, and though it may be annoying in that particular view, in other views (nav menu folded to icon strip, screen scrolled up on a list table, being in a section not included in the + New admin bar menu, etc) they serve a purpose. The experiment on the Themes/Add New screen of tabs was an early attempt to try something different here that needs to be revisited, but in the meantime it's unlikely we'll remove one of those three links before we've accounted for those other situations. In the meantime a plugin to get rid of those links next to the headers wouldn't be amiss -- I don't really like them myself but they were added back in after they were removed a few release cycles ago because a number of the project leaders felt they were still needed (contextual vs permanent navigation).

  4. Aaron Hockley
    Member
    Posted 2 years ago #

    Thanks for the backstory Jane. Perhaps I'll implement this as a plugin.

  5. In my head, this fell into trac because two things:

    1) Accidental redundancy (a quick search of trac had nothing)
    2) He said 'patch'

    It felt slightly questionable as if it were a UI 'I don't like' vs a UI inconsistency (the latter of which would be 'buttons don't match' etc), but I agree to the point easily :) I'm easy going, really, it's not just the pain killers!

  6. Jen Mylo
    Key Master
    Posted 2 years ago #

    Saying "patch" doesn't mean it should go straight to Trac. The fact that there are 1100 tickets with a patch on them but no action (and that's just the ones that are labeled, there are a bunch more that are missing the has-patch tag) makes this plain. I wish I could put a smiley-face, but that number is so depressing.

    When I said 'buttons don't match' that probably wasn't the best example. In truth, something like that is best just asked (forum, dev chat, twitter, etc) to find out if it's intentional or not. If it's not intentional, a ticket should be made. If it is intentional, a ticket might still be a good idea, but 80% of the time it's not. When someone reports something they think is not good in the UI, there are several possibilities:

    1. It really does suck, we keep meaning to fix it, and there is already a ticket for it.
    2. It really does suck, we keep meaning to fix it but keep forgetting to create a ticket for it. Please create ticket.
    3. It's exactly how we want it to be. The fact that it's not to someone's taste doesn't merit a trac ticket -- if they drum up enough community support on a forum thread first to sway our opinion then it might be.
    4. It's not perfect, but it doesn't suck, and though it doesn't suit one person's workflow, it suits the broader number that we have to serve. Ideas for improving it are welcome, but need to take into account all those other use cases, not just the reporter's. Suggestions best started in Ideas forum, then will be addressed by UI group (we'll probably start doing scrubs every other week in 2012). When a reasonable suggestion that addresses all the UI needs has been proposed, and it's generally considered superior to what we have now, it might be time for a trac ticket. But really, it's time for a plugin.

    Making UI suggestions that are just based on opinion will never get the kind of attention that a UI suggestion based on a successful plugin will get. For UI suggestions, plugins are better than patches, because regular users who have no idea what svn is or how to test patches (and don't want to) can still give the idea a try and provide feedback. As we move forward with core, this is going to be a strong recommendation, that anything that's for new UI start as a plugin, not a patch, so that it will be super easy to test/revise ideas without being tied to the core dev cycle.

    This one falls into #4. Having multiple ways to get to a primary action isn't an unintentional inconsistency, it's part of the foundation of the WordPress UI.

Topic Closed

This topic has been closed to new replies.

About this Topic