WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from lessbloat Toggle Comment Threads | Keyboard Shortcuts

  • lessbloat 7:40 pm on October 23, 2013 Permalink
    Tags: , , ,   

    DASH – 3.8 proposal 

    Prerequisite: Must have latest version of MP6 installed and activated.
    Plugin link: https://github.com/growthdesigner/wp-dash

    Visual comparison

    The existing dashboard (the page you see by default when you log into WordPress) looks like this:

    It hasn’t been touched in years, leaving it feeling a tad bloated, and dated. Here’s what the dashboard looks like with our plugin enabled:

    What’s changed?

    We tackled 5 major areas, and made them each separate includes within our plugin (separate php, js, and css files).

    • We combined “WordPress Blog”, “Other WordPress News”, and “Plugins” to form the new simplified “WordPress News” plugin.
    • We merged “Recent Comments” into the new “Activity” widget, which now also shows you any scheduled posts and your most recently published posts.
    • We converted “QuickPress” into “Quick Drafts” putting the emphasis more on drafting ideas than publishing, and we merged in “Recent Drafts”.
    • We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.
    • The Right Now widget was visually reduced.

    Here are a few extras:

    • We removed incoming links (which doesn’t seem to really work anymore).
    • We replaced the “Dashboard” H2 title with a fun group of friendly welcome text and idioms.
    • We added a bunch more hooks for greater extensibility from any of the dashboard widgets.
    • There’s a fun little smiley if you delete all posts and comments

    What problem is your feature plugin trying to solve?

    While functional, WordPress’ dashboard page hasn’t kept up with the rest of WordPress. We mean to improve the experience of the first page of WordPress. Streamline it, clean it up looking at all the widgets, and make it responsive.

    We’d also love to see future development in the new activity widget, where plugin developers can add more “activity stream” related content.

    What other potential solutions did you explore?

    If you work backwards through http://make.wordpress.org/ui/tag/dash/ you’ll get a pretty good idea. We met weekly in IRC, and brainstormed/iterated daily via our Skype channel.

    Have you done user testing?

    Nope, but if this get’s the “all clear”, we’re more than happy to do that.

     
    • Brandon Wamboldt 10:11 pm on October 23, 2013 Permalink | Log in to Reply

      Your GitHub link has no link in the href attribute and just points to the current page…

    • Mel Choyce 10:25 pm on October 23, 2013 Permalink | Log in to Reply

    • Louy Alakkad 10:24 am on October 24, 2013 Permalink | Log in to Reply

      Amazing, I like the idea. Except the H2 thing :)

    • portfola 5:21 pm on October 24, 2013 Permalink | Log in to Reply

      This is way cool, thanks!

    • memuller 6:18 pm on October 24, 2013 Permalink | Log in to Reply

      I’ve been testing this plugin on my WordPress network for a couple of weeks. I didn’t collect hard data, but I’ve heard a few things informally.

      Feedback has been, broadly, of three kinds:
      – people don’t notice the change unless it’s mentioned; but once they do, they’re happy about it.
      – people don’t notice the change, and are neutral about it – they think it’s not a significant improvement, or that they won’t use it anyway.
      – people notice the change, and are happy about it.

      I think that not noticing the change is an issue, but it’s hard to avoid that – most users in this installation are already “trained” to ignore the Dashboard, since it’s not useful for them (without custom widgets).

      Some users noticed the change due to the absence of the “Right Now” widget and its characteristic coloured numbers for comment status – apparently, they draw the eye more than I thought.

      It’s interesting to note that, once I started using MP6 in this same network many months ago, quite a few users mentioned how the dashboard looked “clunky” and outdated when compared to the much more modern interface.

      Overall, I’m quite happy with the results. I liked some of the initial ideas for this project a lot, but most of them were discarded in favor of a less groundbreaking approach – which was a good move (albeit a sad one); since the result now is a clear, faultless, solid and expansible improvement. It’s hard to argue against it.

      • lessbloat 6:49 pm on October 24, 2013 Permalink | Log in to Reply

        This feedback is amazing! Thank you for being so detailed/descriptive. I feel like you summed it up really well in your final paragraph. While I would have loved to have had some of that other stuff as well, I’m content to see this as a good stepping stone for even more awesome stuff down the line.

    • Eric Andrew Lewis 10:06 pm on November 3, 2013 Permalink | Log in to Reply

      The changes here all make sense to me.

    • demoman2k10 3:17 pm on November 22, 2013 Permalink | Log in to Reply

      Love all the changes please tell me someone is looking at an overhaul of the Plug-in… This is way outdated and would be great to have some better abilities to SEARCH Plug-in’s by Support for version, Newest and other methods. Would like to see it work and function more like one of the stores offered by Apple, Microsoft or Google even. A section for paid and free would be nice as well. As nothing is more frustrating then downloading something that doesn’t work unless you pay for it.

    • codel1417 1:36 am on November 25, 2013 Permalink | Log in to Reply

      the new dash which shows up in 3.8 beta 1 is now even more useless. at least an option to add multiple rss feeds to the dashboard in seperate boxes. i used the other wordpress news box but never cared for the wordpress updates box or the plugins and now its kinds forced apon me

    • allm 2:22 am on December 15, 2013 Permalink | Log in to Reply

      “We removed the “Number of columns” screen option. Instead the dashboard is now responsive, and shows the appropriate number of columns based on your screen resolution.”

      Well, the way it is build now does not feel like the appropriate number of colmns is chosen. If the admin-area shows up on a wide screen and there are only 2 active columns, I still see 4 columns. The 2 on the right are not used, and the 2 on the left are really narrow.

      Actually, if I decrease the width of the browser window to the point where there are only 3 columns my active columns are getting wider.

      I would propose either:

      . get the ‘number of columns’ screen option back
      OR
      . set the appropriate number of columns as is done now BUT NEVER MORE THAT THE ACTUAL NUMBER OF COLUMNS.

  • lessbloat 1:09 pm on August 13, 2013 Permalink
    Tags: , ,   

    I’m doing some quick research into the wp-admin dashboard (which I plan to look at for 3.8). I’d like to learn more about how you use the dashboard, and how you think it could be better. Please take a few moments and fill out this 5 question survey:

    Take the survey

    Thanks so much for your help!

     
    • equaliser.me 1:20 pm on August 13, 2013 Permalink | Log in to Reply

      A very simple but important thing is a notepad on my dashboard. At the beginning of my working I always use a local texteditor, but making notes online in the backend is so effective.

    • Piet 1:43 pm on August 13, 2013 Permalink | Log in to Reply

      Good survey, hope you will get lots of input/feedback!

    • WebTechGlobal 2:19 pm on August 13, 2013 Permalink | Log in to Reply

      Yes very good direction to be thinking about and something I’m keen to help with. My vision of the dashboard is different modes for different users. So one blog could offer a different dashboard. Each mode focusing on that user rather than a mix of widgets.

      Developer Mode (even if just for newer developers)
      Support Mode (possibly the default and plenty help/troubleshooting tools)
      Statistics/SEO Mode (our Google, Alex, Bing and overall SEO condition all on one screen)
      Blogger Mode (a full Edit Post screen but with a menu for selecting post type and possibly forms for subscribers to request permissions to be author and blog on that very dashboard, there is very little connection between webmaster and visitors in WordPress core other than comments)

    • vtrs 6:49 pm on August 13, 2013 Permalink | Log in to Reply

      … and please change the default color:)

    • Hassan 7:02 pm on August 13, 2013 Permalink | Log in to Reply

      Useful survey. It’s about time we give the dashboard page more love. It’s been a bit useless for a while now, except if you have some important plugin widgets there.

    • lessbloat 11:36 am on August 14, 2013 Permalink | Log in to Reply

      Thanks to everyone who took the time to fill this out. We got over 250 responses in under 24 hours. You guys rock! :-)

    • Miriam Schwab 2:12 pm on August 14, 2013 Permalink | Log in to Reply

      Just filled it out. I think the dashboard should be more actionable, with quick links to do things people do most often: write a new post, create a new page, manage comments.

      And a quick view of stats would be nice, pulled from Google Analytics, social shares etc. A snapshot of how your site is faring on the interwebz.

    • Terry Sutton 3:46 pm on August 14, 2013 Permalink | Log in to Reply

      STATS!! That’s what I forgot to put in when I filled out the survey!

    • Yaron Guez 4:11 pm on August 14, 2013 Permalink | Log in to Reply

      The thing that’s not really covered here is that there are two very different uses of WP….a blogging platform or a CMS. If you’re using it as a CMS than all the blogging tools, QuickPress, Recent Comments, Incoming Links, etc are useless. If you’re using it as a blog than they’re indispensable.

    • raygulick 4:42 pm on August 14, 2013 Permalink | Log in to Reply

      I think there should be a question that pertains to how you use WordPress. The things on my dashboard (as someone involved primarily in developing WordPress as a custom CMS for clients) is very different from the things a blogger would find useful.

    • Nashwan Doaqan 5:52 pm on August 14, 2013 Permalink | Log in to Reply

      Survey Completed :)

  • lessbloat 4:40 pm on February 27, 2013 Permalink  

    Menus Update, 2/27 

    We’ve all been distracted with other stuff these past 2 weeks. DrewAPicture put together a parent ticket for all of the remaining menu items.

    Remaining Tasks

    I’d like to try and wrap all of these up ASAP.

     
    • Travis Northcutt 4:46 pm on February 27, 2013 Permalink | Log in to Reply

      What’s the ticket?

    • Cor van Noorloos 8:00 am on March 1, 2013 Permalink | Log in to Reply

      Hi Dave, I hope it still would be OK to have a few suggestions/comments?

      The .nav-menus-php .delete-action a { color: #bc0b0b; } currently is in the wrong color (should be red) and it missing the 1px 2px padding.

      Besides that I think the new menu contains a bit to much info (or perhaps displayed at the wrong place).

      Instead of a complete walkthrough I’d prefer some strong statements like “No menu’s yet” as is done almost everywhere else.
      Or if required a general .description classed paragraph with some further explaination including some anekedote about Jazz.

      The #nav-menu-header also looks a bit awkward. Especially its height. (it always has, even though it’s looking much better now. +1)
      Have you thought about moving .button button-primary above and below the metabox?

  • lessbloat 5:26 pm on February 8, 2013 Permalink
    Tags: ,   

    Menus Office Hours (Feb 7) 

    Here’s a recap of yesterdays office hours.

    Work accomplished since last office hours

    Major items discussed

    1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.

    2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.

    On the docket

    • Refactor accordion code (@lessbloat)
    • Re-assess CSS in latest patch (currently 23119.28.1.diff), and move colors to colors.css (Looking for a volunteer here)
    • Browser compat testing (Looking for a volunteer here)
    • No JS testing (Looking for a volunteer here)
    • Code review (Looking for volunteers here – hopefully from multiple people)
    • Commit what we’ve got

    After that

    • Any additional accessibility work
    • Additional code refactoring
    • Am I missing anything?

    p.s. @DrewAPicture, I added a title this time just for you. ;-)

     
    • Drew Jaynes (DrewAPicture) 5:57 pm on February 8, 2013 Permalink | Log in to Reply

      RE: title, “He can be taught!”

      We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.

      I can start on no-js testing this weekend.

    • sireneweb 4:50 pm on February 11, 2013 Permalink | Log in to Reply

      Hi, very nice :)
      When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu

      • lessbloat 6:14 pm on February 11, 2013 Permalink | Log in to Reply

        I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:

        Excluding the menus with zero items added, the average comes out to 5.

        So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?

        I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.

  • lessbloat 4:41 pm on February 1, 2013 Permalink
    Tags: ,   

    We had a great discussion yesterday during office hours. I’m excited to say that we’ve found our direction.

    We’ll only be focusing on changes to nav-menus.php for now.

    I just posted an updated diff containing some of the ideas we discussed.

    Remaining Tasks (already assigned to someone)

    • Test theme locations as checkboxes (@jkudish volunteered to code this up). Note: we decided to leave widgets as checkboxes out.
    • Menu selection dropdown should show location(s) it is used in (@DrewAPicture offered to tackle this)
    • A round of user tests on 23119.23.diff, plus additional testing once “theme locations as checkboxes” and the accordion code is ready
    • Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture will oversee this)
    • Updated copy for ​http://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture will oversee this)
    • Updated copy for ​http://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture will oversee this)

    Remaining Tasks (still needing a volunteer)

    • Code up menu item boxes as an accordion for us to test (similar in style to customizer).
    • Code reviews (multiple people please :-))
    • RTL testing
    • Browser compatibility testing
    • No JS testing

    Comment below if you’re interested in helping out. Thanks!

     
    • Joey Kudish 4:46 pm on February 1, 2013 Permalink | Log in to Reply

      In addition to the checkboxes, I’ll help out with code reviewing and all the testing :)

    • Jon Brown 5:53 pm on February 1, 2013 Permalink | Log in to Reply

      I agree that the checkboxes shouldn’t be there for widgets, that’s be very confusing IMHO. However, maybe there should be a little tool tip or note below theme locations directing users that “Menus can also be added tomwidget areas via the custom menu widget available on the widget settings page”.

    • Travis Northcutt 12:18 am on February 2, 2013 Permalink | Log in to Reply

      @lessbloat, what is the “deadline” for getting the accordion done for testing?

      • lessbloat 1:14 pm on February 4, 2013 Permalink | Log in to Reply

        I’d like to wrap up all dev for this feature ASAP. I’ll likely pick it up if no one else grabs it by tomorrow.

  • lessbloat 2:53 pm on January 29, 2013 Permalink
    Tags: ,   

    Menus office hours recap (Jan 28) 

    We’re still in the process of determining the best direction for menus in 3.6 (mock ups and ideas welcome!).

    My hope is that we can stay true to the WordPress Philosophy by optimizing the experience for the majority of users, and leaving edge cases for plugins to handle.

    One issue at this stage is that I can only guess as to what the majority looks like. I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none. This should give us some additional insight into the best way to approach menus.

    For this weeks meeting my goal was to list out, and then (roughly) prioritize the biggest pain points associated with menus. Since I have little data at this point, this prioritization is based on the assumption that the vast majority of users have either no menus or one menu.

    Here’s how I prioritized things, please weigh in if you disagree:

    • One of the biggest disconnects I’ve seen is the concept of “theme locations”. Adding a menu, and then assigning it to a theme location seems broken.
    • Trying to have menu management + editing + theme location assignment all on the same page is overwhelming.
    • Tabs don’t work for users with lots of menus to manage, and they confuse some users (who think they represent menu items within a single menu). Side note: when we tested menu management via a drop down (instead of tabs), users didn’t notice the drop down, and wondered where the menus they had already created were. A “manage menus” tab appears to work for users, but it seems heavy for users with just a single menu.
    • Switching themes poses a problem for menus in that there is no concept of a base menu. Every theme determines their own default menu, and even though two menus may have a single primary menu, you still have to re-assign your menu to that theme location whenever you switch a theme.
    • Users have a hard time visualizing how the menu changes they are making actually impact their blog/site.
    • Having to scroll to see all of the menu item meta boxes in the left column can be annoying, and it can make discoverability for items below the fold harder.
    • If you have a long menu (with lot’s of menu items), you may be scrolling unreasonably down from the left to the right column.
    • The fact that you can add menus to a custom menu widget is not exposed anywhere.

    Did I miss anything?

     
    • cvernon 3:26 pm on January 29, 2013 Permalink | Log in to Reply

      1.
      I agree theme locations isn’t working as it is now defined and managed.

      Most sites I make & use have only one menu, so I do not declare theme locations at all in the theme. This is how it should work, that you don’t need to understand the concept of theme locations unless you have many menus and know how you want to organize them. This should all be hidden by default.

      I like the idea of have the “base menu” concept just be a single menu that is not assigned a theme location, OR no menu at all in which case the fallback is to pull from all pages structure. Then if someone wants to get more complicated there should be another level of complication with multiple menus, in which case we want theme locations.

      2.
      Also, the way the wp_nav_menu() behaves differently [generates different html, accepts different arguments] whether or not any menu is declared [just takes the existing pages], or whether the menu is assigned to a theme location. This is a template tag issue but relates to how menus are managed in the admin & database.

    • deltafactory 3:41 pm on January 29, 2013 Permalink | Log in to Reply

      I agree with every point here. Two more thoughts, based more in the plugin/api area:

      The steps required to implement a “custom menu widget” are not obvious. At first glance at the code, it seems to rely on a complex interaction of both PHP and Javascript. The solution might be in documentation rather than changes to the code, but it’s still an area I would like to see improved.

      I would really like to see some additional filters to enable better caching alternatives. Even with an object cache, constructing a large menu results in a high number of cache hits. I have seen some opportunities to cache the menu item objects or even static HTML and greatly improve that part of the page output.

      If these requests aren’t out of scope, I can assist/suggest specific changes to code.

      • Bob Gregor 10:00 pm on January 29, 2013 Permalink | Log in to Reply

        +1 on the unclear menu management API! I had almost forgotten how I had to reverse engineer the custom menu widget to create a plugin menu item interface. Not clear at all.

    • Philip Arthur Moore 3:43 pm on January 29, 2013 Permalink | Log in to Reply

      One issue at this stage is that I can only guess as to what the majority looks like. I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none. This should give us some additional insight into the best way to approach menus.

      If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner, which means that the number of users who use more than one menu should be even smaller.

      I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog, with the caveat that I’m sure the case could be made for more if a theme is more CMS-centric.

      • lessbloat 4:14 pm on January 29, 2013 Permalink | Log in to Reply

        Thanks for pulling this together Philip!

        If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner

        A couple thoughts:

        • My guess is that this is true for themes in general. So, I’m not sure how far off it is compared to wp.org usage.
        • Menus can also be added within widgets. My guess is that out of users who have multiple menus, chances are the majority of them only have one theme location menu, in addition to one or more custom menu widgets (again, just a hunch).
        • Even if all we get out of this is a better picture of how many users have no menus vs. one menu, I’d still find that hugely insightful.

        I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog

        My gut agrees with you 100%. But it never hurts to at least attempt to back assumptions up with some data ;-)

        • Bob Gregor 10:02 pm on January 29, 2013 Permalink | Log in to Reply

          My experience with theme / custom WordPress development has shown that 98% of my client sites (wp.org) use just 1 menu location / no menu widgets.

        • Ricky Lee 12:23 am on January 31, 2013 Permalink | Log in to Reply

          Having built close to 100 themes since release of Menus, I can say 1 primary and 30% of time using depth=1 for footer menu is correct. Just started using Theme Location attribute since switching to _s as our base theme before we gave clients Editor level permissions and named menu “Main”.

    • Frankie Jarrett 4:01 pm on January 29, 2013 Permalink | Log in to Reply

      Great to see this list of pain ponts in priority. The more I think about it, the more I am liking the concept of a “base menu”.

      I just have a few more to add, which could perhaps fall under something already mentioned above, but I wanted to mention them anyway.

      1. Some users are finding it difficult to figure out how to nest menu items and create levels. There is no visual representation on the Menus screen that would suggest items can be clicked and dragged to the right to perform nesting.

      2. When adding a new item to a menu it is automatically appended to the end. This can create headaches for menus that are very long. It would be great to see the UI supporting drag and drop of the items directly into the menu list, similar to how widgets are placed in a sidebar area.

      3. Requiring that users go to Screen Options in order to select additional item fields (class, description, etc.) seems counterintuitive. It would seem that a simple “view more/view less” accordion could reveal the additional fields on a per-item basis.

    • Joey Kudish 4:58 pm on January 29, 2013 Permalink | Log in to Reply

      I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none.

      I went ahead and got this data for you. I selected 4 random sets of 1000 WordPress.com blogs that have had wp-admin activity in the month of January 2013. I then calculated for each blog how many menus they have (total, so regardless of how that menu is being used) and collated the results. 75.78% of blogs have no menus; 18.23% have 1 menu; 5.925% have more than 1 menu.

      I put together the full breakdown of my calculations here: https://docs.google.com/spreadsheet/ccc?key=0AszYZoR3BU_jdHJmZHRTQ19PcGdHSWhhempWRzBDeHc#gid=0.

      Let’s keep in mind that this is WordPress.com users and not self-hosted users, and I suspect there is a significant higher amount of “power users” on the .org side, who use menus differently, via widgets (which is possible on WP.com), and by calling directly wp_nav_menu in their custom themes/plugins (which is not possible on WP.com).

      Hope this helps with deciding how to proceed.

      • lessbloat 5:48 pm on January 29, 2013 Permalink | Log in to Reply

        Very cool. Thanks so much for tackling this @jkudish! Even with your disclaimers in mind, I find this data insightful.

        Here’s a pie chart of the breakdown:

    • Jon Brown 5:50 pm on January 29, 2013 Permalink | Log in to Reply

      Maybe a crazy idea and maybe overly influenced by my personal preference for building on Genesis… But what about getting rid of theme locations all together in favor of a single primary menu location that automatic tied to the primary menu and making the rest widget areas? (note I think the widget UI is in far greater need of a make over than the menus, but that’s definitely OT here). My initial thought is additional menu areas would show up on the widget page and custom menu widget widgets could be dragged in?

      I’d thought a while back that menus should be more like links were. An interface to build the link list/menu, but not the interface that actually places menus/links on the page/theme.

      Note, don’t know that I love the idea, I typically build custom themes with 3 menu areas (above header, below header, footer), but separating placement of menus and construction of menus sounds like a great idea.

    • lessbloat 8:32 pm on January 29, 2013 Permalink | Log in to Reply

      So, what if we used the number of menus a user has to determine what they should see. Here are my latest thoughts:

      If they have 0 menus

      About 76% of users would see this (based on WordPress.com’s stats).

      They’d see:

      • We’d auto populate the “blank slate” view with all of their existing pages. However, this menu is not actually created until they click “Save Menu”. If they navigate away from this page without clicking “Save Menu”, they will still technically have zero menus.
      • If they have only one theme location, we’d just use the theme location name (i.e. primary) as the menu name, and we’d auto assign this menu to their theme location upon saving.
      • We’d hide all “manage menus” functionality
      • And test using an accordion for the menu item options on the left (vs. meta boxes).

      So, if a user (with zero menus) came to the screen above, and immediately clicked “Save Menu”, they’d see:

      If they have 1 menu

      About 18% of users (based on WordPress.com’s stats).

      They’d see

      • We’d take them directly to the edit screen for that menu.
      • We’d hide all “manage menus” functionality

      So, based on the above approach (and the stats from WordPress.com), 94% of users would never see the management screen.

      If they have more than 1 menu

      After landing on menus, they’d see something like this:

      Clicking on a menu would take them to something like:

      Clicking the blue “Menus” header link (vs. showing tabs here), or the “menus” link under “Appearance” in the left nav would take them back to the manage menus view.

      When adding a menu

      Users would see:

      and then after creating their menu, if they had a single menu:

      If they had multiple menus, we’d link up “Menus” in the header.

      Other considerations

      Switching themes

      If a user has one menu, and the new theme has one theme location, and the user has no custom menu widgets, can we just auto-assign the existing menu to the theme location upon switching?

      Long menus (with lot’s of items)

      This makes menus hard to manage because you have to scroll to see all of your menu items, and when you add new menu items, they are added to the bottom by default.

      My preference (again based on usage stats) would be to keep this in plugin territory. This seems like it would make a great little plugin that could:

      1) Add collapsable tree functionality for menu items
      2) modify the “Add to Menu” button under each menu option to be a split button “Add to top”/”Add to Bottom”, and
      3) include drag and drop of menu items from the left.

      I don’t feel like this functionality should be exposed to the majority of users.

      Thoughts?

      • Joey Kudish 8:57 pm on January 29, 2013 Permalink | Log in to Reply

        This seems like the logical way to proceed based on everything that we’ve talked about and worked on thus far. I’ll try to gather more usage stats about how users use menus from WordPress.com before our next office hours on Thursday.

        • Bob Gregor 10:17 pm on January 29, 2013 Permalink | Log in to Reply

          Thanks for those stats! Any chance you can find some stats on # of menu items?

          I think that will be very indicative of how we proceed with the UI.

          heres another view of the data you shared: http://cl.ly/image/143B0G3x2y3A definitely looks like a normal distribution.

          • Joey Kudish 2:47 pm on January 30, 2013 Permalink | Log in to Reply

            Yes, I’ll gather more stats by Thursday afternoon and will include # of menu items per menu in that stat as well. Stay tuned.

      • lessbloat 2:12 pm on January 30, 2013 Permalink | Log in to Reply

        Here’s an alternate flow that we may consider for when users have more than one menu. It ditches the management screen altogether in favor of a drop down.

        We tested using a drop down before (and it tested poorly), but I don’t think we put enough emphasis on it. It’s worth testing again, as long as it doesn’t overwhelm users (having so much on the same page).

        I also played around with adding check boxes under “use in”, as technically a user could use a single menu in multiple theme locations. I wonder if we could allow the user to select a widget placement from this screen as well via a check box. If they checked “Main Sidebar”, we’d auto-add a custom menu widget to the botom of the main sidebar widget area, and set the title of the custom menu widget as the name of the menu.

      • kwight 8:14 pm on January 30, 2013 Permalink | Log in to Reply

        Do we even need the Optional Settings part in the 0 menus layout, as that’s default behaviour anyways?

        Also, +1 for your handling of long menus in plugin territory.

    • kwight 8:11 pm on January 30, 2013 Permalink | Log in to Reply

      +1 for the Dropdown. I expect it would test better in this format, as it’s distinguishable from the other side metaboxes (by, um, not being on the side), unlike the current layout.

    • Bob Gregor 9:17 pm on January 30, 2013 Permalink | Log in to Reply

      part of the problem with the discussion is that there is a large variety of use cases. Here is a visual: http://cl.ly/image/3t0i3g2Y1G0y

      The # of menus data shows the right column to be the typical use case. # of items data is TBD

    • Helen Hou-Sandi 9:25 pm on January 30, 2013 Permalink | Log in to Reply

      As much of a problem as theme locations are, I don’t think moving the assignment into the editing of a given menu is the solution. We are then adding a problem of what happens if multiple menus are assigned to the same location, because it then becomes possible to do so.

      Have some other thoughts I need to chew on. Will comment again when I have sentences :)

      • lessbloat 3:37 am on January 31, 2013 Permalink | Log in to Reply

        I had two thoughts here. If a theme location currently has a menu assigned to it, we could :

        1) append the name of that menu (perhaps at #999), something like:

        and/or…

        2) onclick trigger a JS confirmation modal that says something to the effect of, “Are you sure you want to change your primary theme location from “Primary Menu” to “Main Navigation”?”.

    • Aaron D. Campbell 10:41 pm on January 30, 2013 Permalink | Log in to Reply

      There was plenty of discussion at the beginning of dev chat: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-30&sort=asc#m543523

      It seems like http://f.cl.ly/items/3y2I0T1q2u3d3G3O0X1h/menus-multiple-select.png is pretty close and worth testing, with the one concern being the settings where a menu is assigned to a location.

    • Robert Chapin (miqrogroove) 10:59 pm on January 30, 2013 Permalink | Log in to Reply

      It’s still difficult to add tags to a menu. I tend to fall back on making a list of custom URLs when I can’t find things. It’s usually easier and faster too.

      Assigning menus is definitely broken. Every time I activate a theme on a new site it looks messed up. There should be menus assigned by default when assignments are missing.

      • Aaron D. Campbell 11:13 pm on January 30, 2013 Permalink | Log in to Reply

        Go to Screen Options, check the “tags” box, and then add them like you add anything else (check boxes on left and use “Add to Menu” button).

  • lessbloat 7:12 pm on January 23, 2013 Permalink
    Tags: ,   

    For tomorrows “Menu” office hours I only have one agenda item: To figure out where we’re headed with menus in 3.6.

    (More …)

     
    • Devin Reams 7:37 pm on January 23, 2013 Permalink | Log in to Reply

      I like your concept.

      While it does require more screens to manage a menu (find the menu from the list, then click to edit it), I think simplifying and making the views granular is ideal:

      1. See all menus (then go edit them)
      2. Edit a menu’s contents
      3. Assign a menu to a theme location

      Some bloggers may only have one menu and this is overkill (just like those with one sidebar) but, many more complex sites may have dozens or a hundred menus, theme locations, etc. A question: what is harder and less flexible to satisfy all these possible use-cases?

      I also think a simpler, granular interface for each action may allow for better long-term goals: new enhancements, making it mobile/responsive friendly, etc.

    • Maor Chasen 8:58 pm on January 23, 2013 Permalink | Log in to Reply

      I just love the 2nd approach. Especially liking the theme customizer integration. Though, I have never seen an internal use of breadcrumbs within the dashboard. It just seems out of place.

    • mssbee 2:19 am on January 24, 2013 Permalink | Log in to Reply

      I like the first time menu screen. I am not a huge fan of more windows to open to get to what I want. Seems this whole project started from the thought that current menu screen is too difficult and even adding a home link is a challenge. I agree with Devin that the average user would probably have only one menu, as this might be overkill. Simple to me is simple interface that is intuitive that doesn’t take multiple clicks to get to.

    • Cliff Seal 2:35 pm on January 24, 2013 Permalink | Log in to Reply

      I think the flow of #2 would be most scalable and easiest for first-time menu creators to do what they want—but, can we incorporate the accordion-looking ‘Add Items…’ menu from the Nacin concept? I think all the individual CPT boxes, expanded automatically, become hard to locate at a glance.

    • iamronen 3:29 pm on January 24, 2013 Permalink | Log in to Reply

      I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).

      I’ve tried in the past to describe the problem in more detail here: http://www.odharma.com/2010/07/review-of-wordpress-menus-user-interface/

      The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.

      This discussion started in a TRAC ticket where I mentioned a few more benefits from a modified design:
      1. My main point is that the second largest (if not largest) UI real-estate area should go to the “things I can add to the menu”.
      2. The tabbed area makes it possible to allocate more real-estate to each of the “types of things” that can be added to the menu. I see no need to have on screen at the same multiple sources. If I am looking for posts – then let me see just posts. When I want to select from pages or categories or anything else I don’t need to scroll down to look for them … and to lose sight (literally) of the menu I am working on.
      3. Within the tabbed area there is then plenty of space that can be used for better search and filtering.
      4. Because the spaces are tabbed it may be possible to do on demand loading of data (instead of loading everything, everytime the screen loads). That may drastically improve page performance …
      5. AND you can use that improved performance to do a smarter load … like indicating somehow which items have already been added to the menu.
      6. You can still add checkboxes for selecting multiple items and an “add to menu” button. However what I tried to suggest was one click add instead of two click add. Instead of clicking to select each menu and then having to move the moust somewhere else AND clicking one more time “add to menu” you simply add directly. It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

      • lessbloat 2:22 pm on January 25, 2013 Permalink | Log in to Reply

        I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).

        I agree, in that it does suck to have to scroll down to get to additional menu item options. Let’s see if we can figure out a way to improve this.

        The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.

        That indeed sounds like a severe problem. ;-)

    • Robert Chapin (miqrogroove) 4:53 pm on January 24, 2013 Permalink | Log in to Reply

      So far none of these address the issue of adding Tags and Posts to menus.

      As for the screen layouts, I think two are appropriate considering there isn’t easy tabbing between menus.

    • lessbloat 2:14 pm on January 25, 2013 Permalink | Log in to Reply

      Office Hours Notes

      • See logs for full transcript.
      • We talked through likes & concerns for both options 1 & 2 above.
      • In the end we agreed to push forward with option 1.

      Next Steps

      • I plan to spend today working through all of the option 1 concerns (that we covered in office hours), and I’ll come up with another proposal for a mockup to move forward with (which I’ll post to this thread for review).
      • After that we’ll get a prototype hacked together, we’ll push a few cycles of user tests through it, and see how it performs.

      Ideas, mock ups, concerns, comments, criticisms are all welcome. :-)

    • lessbloat 2:03 am on January 26, 2013 Permalink | Log in to Reply

      Here are some updated mockups based on our discussion Thursday.

      One Menu

      This is all the vast majority of users would see:

      Multiple Menus

      Custom Menu Widget

      Switching Themes

      Adding A New Menu

      Let me know what you think. I tried to cover all of the concerns mentioned in the meeting on Thursday.

      • Drew Jaynes (DrewAPicture) 2:33 am on January 26, 2013 Permalink | Log in to Reply

        These are great! Looking through these, I have a couple of concerns:

        • “Copy items from existing menu” is interesting, but will we be able to maintain the hierarchy when the items are copied over?
        • With “Switching Themes”, it isn’t immediately clear what the process is to “reassign” a menu to a theme location (the current workflow). After a moment, I realized you would “Copy items from existing menu” via “Other menus” but we should provide some kind of contextual help for that. Maybe in the empty menu space?
        • We’ll need to be careful of not assuming too much about users, especially in terms of this “editing one menu at a time” mentality with the surrounding controls.
        • Would “unattached” menus live under “Other Menus”, or is that strictly for theme switching?
      • iamronen 6:28 am on January 26, 2013 Permalink | Log in to Reply

        well done.

        I would consider better balance between the two halves of the screen. There seems to be a lot of potential dead space on the right (menu side) and a lot of crunched up stuff on the left (things to put in menu). I would try either 50-50 or even 60-40.

      • Joey Kudish 8:01 am on January 26, 2013 Permalink | Log in to Reply

        Nice work. I really like the updated direction! A few comments:

        • I agree with Drew regarding switching themes, what happens then?
        • What happens if your theme supports several menu locations, it’s not quite clear to me from the mockups how it is that you assign menus to theme locations anymore.
        • Considering how little real estate the “add menu” button takes up and how valuable it might be to some users (especially those are now used to the current workflow) I am not convinced that hiding it by default is a great way to go about it. Could this be tested with existing users?
      • lessbloat 2:26 pm on January 26, 2013 Permalink | Log in to Reply

        So, my worry after working through all of these mockups is that by trying to be overly simplistic, we’re actually increasing complexity. :-(

        Have a peek through each of the mockups above, and I think you’ll see the same thing.

        Things I like

        • I really like the use of vertical tabs instead of meta boxes.
        • I like that for the majority of users they can jump right into building their menu, and that it is already assigned to a theme location.

        My concerns

        • The “Select a Menu” portion on the left hand side seems out of place to me. It doesn’t fit with the other two accordion options (add items, copy items). If a user is required to select from multiple menus, I still feel fairly strongly that we need to separate the “manage” functionality from “add/edit” functionality, otherwise there is just too much to take in on that single screen.
        • The concept of copying menu items from one menu to another works from a technical standpoint, but it seems overly complex.
        • To think that someone who just switched their theme will know to copy their menu items in order to bring their menu items over from their other theme is asking too much. Even if we could provide contextual help, it seems way more confusing than the way it is now (choose a menu for each theme location and click save).
        • I feel like this approach over complicates widget menu creation as well. The old way of adding a title, and selecting a menu seems like an easier flow to grok than forcing users to make a choice between creating a menu or selecting an existing one, and then switching contexts from widgets to menus and then back to widgets again in the same flow.
        • The concept of having “Menus in your theme”, and “other menus” under “Select a menu”, complicates things. It’s hard to tell the difference between the two. The user will wonder why they cannot delete the “menus in your theme” menus, but they can delete the “other menus”.
        • What happens if a user switches themes a dozen times (trying to find the right one). They’d come to menus and find at least a dozen menus from all the previous themes they tried (since the idea here is to pre-build all theme location menus for each theme). Not to mention, we’d have to write the code that pre-creates all theme location menus each time you switch a theme.
        • While, hiding the “add menu” button seemingly simplifies things for new users, I don’t think it will work. Existing users will wonder where it went. If we leave it there, new users will no doubt get lost trying to add a new menu (either following one of hundreds of existing menus tutorials on the web, or by following instructions in a book, or by just stumbling onto it), when in fact their theme locations menus are already created.
        • If we add icons for each menu item option (in the vertical tabs), what happens when you add a CPT? Would they have to add their own icon? That sounds too complex. I don’t think we can use icons here.

        In contrast

        Out of the last 3 users we tested on option 2 (see results here and here), one of them completed all of the tasks flawlessly, and the other two only stumbled on a single step (selecting a primary menu).

        After the meeting on Thursday, I was fairly confident that we could make option 1 work. After working though all of the edge cases, I’m now much less confident.

        My proposal

        What if instead of diving head first into option 1, we instead chose to keep iterating on option 2:

        • We could spend our energy iterating on the one piece that still seems broken (selecting a theme location), instead of trying to smooth out all of the complexities that come with option 1.
        • We could simplify things for users with just one menu. If they only have one menu, we could remove the tabs and the manage screen, and take them right to editing that one menu.
        • We could bring the new vertical tab menu items selection concept over (I much prefer that to meta boxes, and having to scroll if you have lots of them).

        That’s my proposal, what do you think?

        • iamronen 5:59 pm on January 26, 2013 Permalink | Log in to Reply

          I think that a lot of the complexity you mentioned is rooted in what may be a false notion that menus are a part of the site “appearance” – that they belong to a theme.

          A different view would be that menus are another means of organizing “things” in my website (kind of like categories are used to organize posts).

          Though the primary purpose of menus is for navigating in the site (indeed a thing of appearance) that is not what governs their content.

          My intuition (I have no data to back this up) tells me that most people (who have one menu) when they change themes, do not change menus. I can definitely say that in almost all of the websites that I’ve created that have had many menus – that the menus should have stayed when themes switched (the fact that they don’t has forced me to do twisted things in my theme management practices).

          I believe that the fact that menus are a part of themes is a behavior that has evolved from their technical development, not from what they are and do. Their underlying story is just now surfacing.

          If you free menus to be another organizational entity regardless of appearance (though I realize this may be way beyond the scope of 3.6) then they most absolutely should be split into the common WordPress paradigm of managed list and single-item edit.

          I also believe that presented in this way, people will more quickly understand that they can create more menus (since they know this visual paradigm intimately from working with posts and pages).

          This way:

          • menus will be more straightforward and intuitive.
          • there won’t be a need for complex behaviors such as “copying menus” which will only create useless copies of the same thing.
          • there won’t be a need for a unique and complicated interaction and relationship between menus and widgets (the current widget is fine and will be better understood once menus become more clear)

          The only apsect of menus that I can think of that should remain as part of the appearance/theme configuration would be theme locations.

          I realize this may sound radical … but I believe that the complexities you listed are telling us that the underlying story of menus has not been properly addressed and it needs to be re-examined if a good solution is to be found.

          • lessbloat 3:22 pm on January 28, 2013 Permalink | Log in to Reply

            I guess I’m unclear, where exactly are you proposing that menus should go?

            • iamronen 4:08 am on January 29, 2013 Permalink

              I can’t think of a good answer for that (though I may have inklings of a better question).

              The two options I currently see are (1) inside the “appearace” menu or (2) a separate admin-section. For now, I am indifferent to them.

              In either case, I think it would be better to have them conform to the dominant UI pattern that includes a list of Menus (where the description can be a textual preview of the menu contents) from which you can choose to edit a menu.

    • paaljoachim 12:48 pm on January 28, 2013 Permalink | Log in to Reply

      I looked at the above wireframes and created some of my own to give inspiration to others. Psd and jpg files are included in this link for anyone to continue testing out things.

      https://www.dropbox.com/sh/4vpue85dkzsrk0q/6FtXDun3QD

      Have a great day!

    • Bob Gregor 9:56 pm on January 29, 2013 Permalink | Log in to Reply

      One thought regarding copying menu items – that should be a dragabble / droppable interface. Much lessbloat (pun intended) perhaps drag / drop w/ a featured pointer?

      I like the two tab iteration better – one tab for doing the majority of the work – editing and building menus, and another tab for changing assigning / them. The non-metabox menu builder is a huge improvement, but I don’t like seeing the unrelated options of select a menu and copy menu items. Those feel out of place.

      In any case – I definitely agree we need to keep iterating. Great work lessbloat! The mockups are looking great!

  • lessbloat 1:13 pm on January 21, 2013 Permalink
    Tags: ,   

    Menus discussion today 

    I’d like to hold our first menus IRC discussion today at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev.

    Here’s a reminder of more or less where we’re at: http://make.wordpress.org/core/2013/01/16/heres-a-quick-update-on-the-3-6-menu/

    In addition to talking about the feature, we’ll figure out a good time to hold all other bi-weekly meetings. Thanks!

     
    • Alex King 3:13 pm on January 21, 2013 Permalink | Log in to Reply

      I will be on a plane and unable to attend the IRC meeting, but wanted to throw in my request for being able to filter in new “types” of menu items and fully override the output of any particular menu item. Super-useful for mega-menus, etc.

      The change to 2 screens sounds like it will address to “too many menus for the UX design” – awesome!

    • lessbloat 4:52 pm on January 21, 2013 Permalink | Log in to Reply

      Thanks Alex,

      wanted to throw in my request for being able to filter in new “types” of menu items

      Mind explaining that one a bit more, and I’ll bring that up in the meeting.

      wanted to throw in my request for being able to…fully override the output of any particular menu item

      I was thinking about this over the weekend, and I agree. I think this will go a long way towards making edge cases (collapsable trees, bulk menu item actions, etc…) easily extensible via plugins. My goal is to keep this clean, lean, and mean for the majority of users, but to also make menus easy to extend.

    • lessbloat 8:54 pm on January 21, 2013 Permalink | Log in to Reply

      Here’s the rough agenda I’d like to follow today if possible:

      • Welcome
      • Time for office hours
      • Here’s where we’re at: http://core.trac.wordpress.org/ticket/23119#comment:131
      • There was some concern in the last dev chat that the manage screen is too heavy?
      • 2 files or 1?
      • Common links name: “Handy links”, “Useful Links”, “Helpful Links”, “Quick Links”
      • Alex King’s first point: being able to fully override the output of any particular menu item
      • Theme locations
      • Linking to widgets
      • Alex King’s second point: being able to filter in new “types” of menu items (not 100% sure what he meant with this one)
      • Anything else?
    • lessbloat 4:45 pm on January 22, 2013 Permalink | Log in to Reply

      Here’s a recap of what we covered:

      • Office hours for menus in 3.6
      • Nacins menu workflow concept
      • “Common links” meta box

      Office hours for menus in 3.6

      We’ll plan on having office hours Mon & Thu at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev

      If there’s an agenda (there likely will be for the next couple), I’ll post it here on the make/core P2. Otherwise feel free to come with questions/thoughts.

      Nacins menu workflow concept

      Nacin shared the following observations:

      • The current UI is too advanced, and any workflow improvements should make it more simple for users.
      • The most common use case is having one menu.
      • The vast majority of menus are used in theme locations and widgets. We should tailor around those two use cases.
      • The current workflow: A) create a menu from scratch, and then B) assign it to either a theme location, or a widget can lead to confusion, and is quite possibly overly complex.

      And proposed a rough concept along the lines of:

      • With the custom menu widget, you’d: 1) add a custom menu widget to the sidebar 2) click a “Edit this menu” link/button which takes you to a screen where you’d edit that menu. This would likely take you to nav-menus.php?menu=that-menu-id. If the custom menu widget is newly added, it would take you to the “add new menu” screen.
      • With theme locations, instead of selecting from a drop down of menus that you’ve created, each theme location would just have a link to edit that menu. You’d 1) Click the edit link under the theme location you’d like to edit, 2) Make changes to that pre-existing menu, 3) click save, and be done.
      • We’d no longer need to display a list of menus you have, we’d just display a list of theme locations. Widget menus are represented in the widgets section, so they don’t need to be listed anywhere.

      Edge cases brought up (which we’d have to consider to make this work):

      • While theme locations and widgets cover the vast majority of use cases for menus, you can use them elsewhere. wp_nav_menu() accepts ID, slug, or name of a menu. As such, we’d still need to be able to provide a way for users to add menus outside of theme locations and widgets. How would we display these additional menus?
      • What happens to my predefined theme location menus when I switch themes to a theme which has a completely different set of theme locations? How would that work in the UI?

      “Common links” meta box

      We proposed “Common Links” meta box in 23119.14.diff. Currently it defaults to showing a “home” link, and a “log in” link. Both of which are relatively hard to add to a menu.

      The idea is to:

      • Move the ‘Home’ link out of the Pages
      • Make it easy to add a link to the login form (which many users have trouble with)
      • Make these links easily discoverable
      • Provide a filter for plugins to add/remove links to this “other” metabox

      I had hoped to settle on whether we should keep this new meta box, and if so, what we should call it. Both are still up in the air.

      Things to think about before our next office hours

      1) How can we make Nacins concept work?
      2) Should we keep the new custom links meta box? If so, what should we call it?

      • lessbloat 6:27 pm on January 23, 2013 Permalink | Log in to Reply

        I mocked up my interpretation of Nacins concept:

        A couple notes:

        • My thought was that we could add another option in screen options to show/hide the “add menu” button on the page (in the normal spot next to the header). It would be hidden by default. This way, advanced users can still add menus for the edge cases mentioned above (when added, they’ll also show up in the “Select a menu” area), but the majority of users will no longer have to deal with the complexity of adding a menu and then assigning it to a theme location.
        • When you switch themes, any menu which was assigned to a default menu, would just become an unassigned menu. You could then click to edit the unassigned menu, and then assign it to a theme location in the new theme (through a drop down or something – perhaps at the bottom of the right column). Widget menus would just transfer over.
        • Upon adding a custom menu widget, you’d see this:

        Or something similar, which would take you back to nav-menus.php.

        What do you think? Could this approach work? If not, why?

        p.s. Please don’t focus on the aesthetic of the design at this point. This is just a rough mockup. If the concept works, we can focus on improving the way it looks next.

        • Aaron D. Campbell 6:50 pm on January 23, 2013 Permalink | Log in to Reply

          My first thoughts:

          The things I like:

          • I really like the way this handles new widgets.
          • I like that it feels very light weight.

          The questions/concerns:

          • I’d love to see how you’ll handle adding existing menus as a widget. For example, if you change themes and you want one of those unassigned menus to be used as a widget or if you create the menu before you add the widget.
          • Widgets save immediately, so we need to make sure that a new widget with an empty menu has no output. We also need to make sure that updating a menu used in a widget clears any cache associated with the widget.
          • If you have a decent number of menus, even just 10, then you really start pushing down that left column of items to add.
    • Robert Chapin (miqrogroove) 4:49 pm on January 24, 2013 Permalink | Log in to Reply

      A common problem with this mockup and the 3.5 system is that there is no visual indication of where to find Tags, Posts, and other menu items that are missing by default.

  • lessbloat 8:32 pm on January 16, 2013 Permalink
    Tags: ,   

    Here’s a quick update on the 3.6 menu changes we’ve been making:

    Last week we:

    • Merged the the UI into two screens. Now we have manage menus & add/edit menus.
    • Tested this new two screen approach. It went really well (we put two users through – videos are on the Make/UI P2).
    • Improved & simplified some copy
    • Added a new hookable “common links” meta box with “home” and “Log in” as the default links (both of which are fairly confusing to try and add to a menu otherwise).
    • Added keyboard accessibility for rearranging menu items

    What’s left:

    CODE

    • Break this out into two separate files 1) manage 2) add/edit (@jkudish is on this)
    • Code review everything (@jkudish volunteered)

    DOCS

    TESTING

    • Once the code items are complete, I’ll run another round of user tests (@lessbloat)
    • RTL testing
    • Browser compatibility testing
    • No JS testing

    If you’ve got some time, we’d love your help with testing the latest patch.

    Lastly:

    I’d love to hear all of your thoughts, concerns, criticisms. :-)

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel