WordPress.org

Ready to get started?Download WordPress

Make WordPress Documentation

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Chris Reynolds 7:05 pm on December 9, 2013 Permalink | Log in to leave a Comment
    Tags: , ah-o2   

    AH-O₂ Update (the project formerly known as Admin Help) — 9 December, 2013 

    The Plan

    • We’re going to shoot for WordPress 4.0.
    • I am going to implement a release schedule and base our schedule on 3.9, however, we’re going to shoot for a 6 week cycle (ideally leaving time for testing). I’ll post the schedule but it will be subject to change.
    • I am going to make an announcement/call for devs post on make/core

    Stuff that needs to be done

    This is the more immediate stuff that we need to take care of:

    @ninnypants’ repo is here https://github.com/ninnypants/WordPress-Admin-Help/tree/core_js main repo is https://github.com/jazzsequence/WordPress-Admin-Help

    After we push the plugin to wp.org, the plan is to do weekly updates to the plugin from the github repo(s) after the meeting (assuming things have been done to the codebase).

    Admin Help is now AH-O2

    “Breathing new life into admin help!”

    …so yeah, we have a codename.

    (Tentative) Schedule

    • December 12 — target release date for 3.8
    • January 6 — target date for tasks above to be completed, and AH-O2 to be added to WordPress.org/plugins
    • February 3 — (tentative) target date for first AH-O2 beta
    • Sometime in the future — WordPress 3.9 is released
    • Sometime after that — WordPress 4.0 is released (hopefully with AH-O2)

    (this schedule will be updated/changed as we know more about the release schedule for 3.9 in advance of 4.0)

    Props to @nlarnold1 for joining us today and being willing to dive in.

     

    • Shane Pearlman 7:08 pm on December 9, 2013 Permalink | Log in to Reply

      way cool – as a small comment, O2 is being used for P2 reboot and the name runs mighty close…

      • Chris Reynolds 7:09 pm on December 9, 2013 Permalink | Log in to Reply

        yeah, we talked about that, too, hence the subscript (which gets filtered out of the post title). It’s all relative anyway — O2 will be a plugin (and keep the name) whereas AH-O2 will (ideally) get integrated into core and the codename will no longer really matter.

    • Hugh 9:23 pm on December 9, 2013 Permalink | Log in to Reply

      FYI: I’m a lurker… but be encouraged it is a long haul… I’ll test and comment when you get a plugin to the repo.

    • Siobhan Bamber (siobhyb) 12:00 am on December 10, 2013 Permalink | Log in to Reply

      I’ve also been lurking and following the progress for this. Would love to help in testing it. :)

      • Chris Reynolds 12:13 am on December 10, 2013 Permalink | Log in to Reply

        We’ll definitely let people know when we’ve got something to test. Right now activating the plugin doesn’t do much for normal users. :)

  • Eric Amundson 7:32 pm on December 5, 2013 Permalink | Log in to leave a Comment  

    Docs Meetup Roundup – Dec 5, 2013 

    Howdy folks,

    This week, like last week, was relatively quiet in the chat, due largely to the US Thanksgiving holiday.

    Here’s a recap of todays chat:

    1. Docs Sprint

    There’s another Docs Sprint this Saturday, Dec 7th @ 10am Pacific and you can join us on IRC at #wordpress-sfd.

    2. Admin Screen Updates

    With the scheduled release of WordPress 3.8, which includes a makeover of the WordPress Admin, we need to work on updating the Administration Screen pages in the Codex.

    @kimparsell will post a list of pages that need to be reviewed and updated on make.wordpress.org/docs.  Please help by grabbing one (or more) pages and updating.

    3. WordPress 3.8 Codex Page

    @DrewAPicture could use some help updating the Codex page for WordPress 3.8.

    Drew usually combs through all of the change sets to find what’s new, changed, etcetera and it’s quite time-consuming.

    If you can help, please leave a comment on this post and @DrewAPicture will help provide direction.

    4. DevHub

    Still making progress on developer.wordpress.org.  There are some tickets filed and some things attached to them.

    5. Make/Docs Sidebar

    @DrewAPicture also updated and consolidated the Weekly IRC Chats widget in the sidebar of make.wordpress.org/docs

    That’s it for this week. Have a great weekend and hope to see you at the Docs Sprint on Saturday.

     

  • Chris Reynolds 6:04 pm on December 2, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Admin Help Update 

    I was there in #wordpress-sfd this morning, but no one else was. Last week I was unable to make the meeting but @trishasalas was able to step in in my stead to keep the band playing. There were a few things I wanted to talk about this week, so I’ll post them for discussion here. I should be at or around my desk for most of the day and/or week, so feel free to hit me on IRC or you can email or GTalk me at chris at jazzsequence dot com.

    WordPress 3.8 is closer than you think

    I’ve been monitoring the #wordpress-dev chatter and 3.8 is only a couple weeks away. Barring any horrible blockers, it will drop on the 18th 12th meaning that 3.9 feature plugins need to be presentable immediately following the 3.8 release because they will start to be integrated into core at that point.

    **If we want this to be included in WordPress 3.9, we need to have something to present.**

    Not only presentable, it needs to be tested. There are some things — like accessibility or internationalization or backwards-compatibility concerns that wouldn’t necessarily be blockers for integrating into core, but we need to have our stuff together. Which means, if the 18th 12th is when 3.8 drops, that should be our deadline for having the plugin done, ready to go and be tested by actual humans. If we can’t make that deadline this time around, we can continue to work on this for 4.0 (or whatever the release following 3.9 will be), but since developer resources have been our main weak point up to now, we’re going to need to do some serious recruiting.

    So where are we?

    I would like to start merging the stuff that @ninnypants has been working on into my repo so there’s a single repository that we’re using and go from there. Since I haven’t looked at his changes, or tested any of that stuff, I’d like for someone to let me know what the latest is on that front and whether we can start building on that. Also, I’m not sure how much time I’ll have to spare on that this week, so anyone’s help in this process and/or pull requests would be greatly appreciated.

    Code name

    Having a code name is something that was proposed over here that we haven’t ever had and thus far the meetings and p2 posts have been tagged with “admin help”. This is somewhat boring. @ubermaut suggested Lifebuoy. Help2 is another idea I just came up with (see, it’s squared — because some of our ideas came from how Squarespace handles help/documentation — and it can also be read as Help 2 — as in the second version of help…). Any other ideas are welcome. It seems a little late to be figuring this out now, but then, if we’re gearing for a 4.0 release, maybe having a code name will make us more distinctive and noticeable.

    Last call for 3.9

    If this week goes by with no real progress on the plugin, we should again expect this to be punted and focus on getting something ready for the next release of WordPress. It can be done if we are all able to make sprint to get it to happen, but if feature plugins are being merged into core as soon as 3.8 hits the virtual shelves, we’ll already have missed the boat.

    If there are any other folks out there interested in helping make this feature a part of core, meetup organizers, folks who just want to start contributing to WordPress core, please hit me up and let me know in what way(s) you are able to help & I can get you up to speed. This could be done in a matter of hours at a hack day or some such thing if someone was inclined to start one up.

    Thanks to everyone who has helped to get us this far. We’ll get there.

     

    • Drew Jaynes 6:27 pm on December 2, 2013 Permalink | Log in to Reply

      Hi Chris,

      I don’t really consider myself part of this initiative, though I have been monitoring it in the periphery.

      It sounds like maybe this would be a great candidate for the 4.0 release. There are certainly a lot of things left to consider and I think taking the extra time to do extensive testing and handle internationalization and run it through the paces for back-compat, etc. would be super beneficial.

    • J.D. Grimes 9:54 pm on December 2, 2013 Permalink | Log in to Reply

      I’ve been keeping an eye on this feature-as-a-plugin, and I’ve been wishing I could participate, but I really don’t know if I can spare the time. I’ll see if I can catch up with the code, and maybe I’ll jump in in a few weeks.

      I agree with Drew, I think that you should aim for 4.0. I think there is the potential here to build a very robust admin help, and that isn’t going to happen by rushing.

    • Sam Sidler 10:23 pm on December 2, 2013 Permalink | Log in to Reply

      I wouldn’t worry about having a codename. If one materializes, that’s fine, but codenames cease to exist when a feature plugin gets merged into core.

      Note that WordPress 3.8 should ship on December 12, not 18.

      I’ve seen a lot of status updates, but not much in the way of exactly what you (collectively) have now and which parts of your (collective) vision have been realized in the plugin thus far. It’d be great to see an overview (with screenshots!) of your current status and where you are in your vision. Previous groups have used a spreadsheet to give a better overview of what’s done and what needs to be done. I’m happy to help create one, if it would help.

      Outside of that, get the plugin in the plugin repository to increase visibility. That means merging from GitHub and perhaps a regular release schedule (once a week for both?).

      This is one of the few teams that’s been consistently meeting and posting updates, which is great. Looking forward to see it finished and ready for inclusion. :)

      • Chris Reynolds 11:58 pm on December 2, 2013 Permalink | Log in to Reply

        That’s weird. Not sure why I had the 18th in my head.

        The biggest thing in the way of getting the plugin in the repo is that we haven’t had anything really testable (yet). I think that’s changing, and when it does, I plan on getting it into the plugin repo. I’m also thinking of establishing some deadlines to help motivate people as a team.

        If you can point me to an example of a spreadsheet other folks have been using/have used, I’d be interested in taking a peep.

    • Matt van Andel 9:23 pm on December 4, 2013 Permalink | Log in to Reply

      I think I’m in the same camp as J.D. I’m very much interested in contributing, but this time of year is absolute chaos – professionally and personally; every waking minute is booked solid through January. :-/

      • Chris Reynolds 10:22 pm on December 4, 2013 Permalink | Log in to Reply

        That’s fair. I am planning on cooking up a post with my thoughts re: plan and future development in the next week. I think shooting for 4.0 makes a lot of sense, but I’d like to have as much as we can done early so we can spend that extra time testing and figuring out a11y and/or l10n stuff (fwiw, I don’t anticipate any issues with l10n — I’m pretty familiar with that stuff.)

  • Eric Amundson 5:51 pm on November 26, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Docs Meetup Roundup – Nov 21, 2013 

    1. Docs Issue Tracker Mockups

    @sams has the issue tracker mockups and is working on finding a developer.

    2. Docs Sprints

    Had a few new contributors to our latest Docs Sprint and are making steady progress on both Theme and Developer Handbooks.

    Next Docs Sprint is Saturday, Dec 7th at 10am PST – hope to see you there.

    3. DevHub

    @rarst and @krogsgard are both working on the theme development and are making progress.

    4. Inline Docs

    Are still making progress and passed the 100 file completed mark last Tuesday.

     

  • Chris Reynolds 6:26 pm on November 18, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Admin Help: 18 November, 2013 

    @ninnypants has been working on the js portion of the Admin Help plugin the basic framework for the javascript is here: https://github.com/ninnypants/WordPress-Admin-Help/blob/core_js/js/adminhelp-plugins.js
    This will be the format for calling in the content to display with the tooltips. The docs themselves will go into static php files so we can use normal php i18n functions. As soon as this is ready to be merged, I’ll add it to my repo so people can play with it and test it and start messing with the CSS stuff.

    the other thing that needs to be tackled is the Help Overview. This will somewhat resemble the existing help tab content but will display by default and show an overview of what’s on the page. This is controlled by the options I added last week to the user profile, so this can be thrown in now. @ninnypants made the suggestion that we could try using the admin_notice hook and style that to look like the dashboard welcome screen in mp6.

    Once @ninnypants’ code is ready, we can start hooking in the tooltip stuff. Next meeting is Next Monday 17:30UTC

     

  • Kim Parsell 12:38 pm on November 17, 2013 Permalink | Log in to leave a Comment  

    Codex: Editing wp-config.php Page Reorganization 

    mrmist posted the following to the wp-docs mailing list earlier this AM:

    The Codex page http://codex.wordpress.org/Editing_wp-config.php is really long.

    I wonder if it should be broken out into basic wp-config and more advanced stuff. Where “basic” would just include things that your average user might need.

    Currently the “Advanced” stuff occupies the mass of this page, and makes it much longer and more daunting looking than it needs to be.

    Also, if we restrict the main bulk of the page to the very basics, it could have edit protect enforced on it and prevent people posting their database credentials to it.

    Thoughts, etc…

    mrmist

    I agree with him – the whole page should be reorganized and updated. Thoughts on splitting it into 2 pages – original with the basic information, and a second page for the advanced information?

     

    • Ulrich 12:50 pm on November 17, 2013 Permalink | Log in to Reply

      I think that makes sense. So everything under Advanced_Options gets moved to a new page.
      http://codex.wordpress.org/Editing_wp-config.php#Advanced_Options

    • Rami Yushuvaev 2:52 pm on November 17, 2013 Permalink | Log in to Reply

      I’m not sure.

      WP_Query (http://codex.wordpress.org/Class_Reference/WP_Query) is long too, and we don’t split it to sub pages. I think wp-config.php page needs editing and styling. Less explanations and more code examples.

    • Marko Heijnen 3:00 pm on November 17, 2013 Permalink | Log in to Reply

      I have no problem to reorganize the current page but I disagree with splitting it in 2 pages. I don’t believe beginners will use that page often. Personally I check that page for all the options I can use. Having two pages make things complicated.

    • mrmist 4:20 pm on November 17, 2013 Permalink | Log in to Reply

      Obviously I think it needs splitting up, or – at least – heavy editing. I think in its current form it lacks use for either beginner or advanced user. I agree that beginners won’t use the page often, but probably not for the reasons Marko thinks… ;)
      Thanks to Kim for the repost.

    • rclilly 7:11 pm on November 17, 2013 Permalink | Log in to Reply

      I am always up for having basic information that applies to the ‘average’ user, and which deals with basic setting up and usage, separated from advanced information that applies only to customizing, tweaking, or developing with WordPress. In my opinion, @Rami Yushuvaev’s reference to the length of the WP_Query page is not an apples to apples comparison as that topic, in its entirety, is not something an ‘average’ user would be looking at.

      If the decision is made to keep the ‘Editing wp-config.php’ page as a single page, I suggest placing a disclaimer of some sort immediately before the ‘Advanced Options’ section telling readers that for most scenarios they won’t need to read any further.

  • Eric Amundson 6:32 pm on November 14, 2013 Permalink | Log in to leave a Comment  

    Docs Meetup Roundup – Nov 14, 2013 

    1. Docs Issue Tracker Mockups

    @sams sent a wrap-up of Docs Issue Tracker feedback to @karmatosed and she’s going to have something by early next week. When that’s ready, he’ll get a developer to work on it and we’ll have an updated timeline.

    Thanks to all who gave feedback on the mockups!

    2. Docs Sprints

    There’s another Docs Sprint this Saturday November 16th, for those who can join in person or via IRC at #wordpress-sfd.

    3. Theme Dev HB Opening

    @iandstewart gave us permission to use any of the content from the Theme Shaper tutorial in the Theme Developer Handbook.  Thanks Ian!

    @sewmyheadon will work on incorporating whatever makes sense into the Handbook.

    4. Theme & Plugin HB Spreadsheets Revamped

    Authors vs. Contributors

    In the Handbook reporting spreadsheets, we changed Owner/Author columns to read Contributors because we found that several of the original owners/authors haven’t worked on the docs in months and we don’t want to discourage other folks from contributing.

    So, we’re asking contributors to list their name in the Contributors column for future reference.

    Noting Individual Document Progress

    If you’re working on docs in the Theme or Plugin Dev Handbooks, please note the percentage complete (based on your best guess) in the % column.  This gives us a more realistic overview of each document’s progress.

    @siobhan will also add @sewmyheadon to receive emails when updates are made to the Theme Dev Handbook to better monitor progress.

    Retiring the Handbook Reporting Threads

    We’ve ditched the old Handbook reporting threads on make.wordpress.org/docs because they weren’t being updated.

    Instead, please note progress, questions, problems, etcetera in the corresponding Handbook Spreadsheets instead, or simply post comments in the Handbook page.

    5. Working Online

    In order to make sure we’re all “on the same page” (pardon the pun), we’re asking folks to post all Handbook content directly to the Handbook, rather than writing offline.  This helps contributors and editors see actual progress, so they can dive in and help without worrying about stepping on toes or duplicating work.

    To this end, we’ll be granting editor access to Handbook contributors so they can work online.

    If you are working on any Handbook content that is not yet posted to the Handbook, or if you need editor access, please contact @sewmyheadon, @siobhan, or @hanni and we’ll help get it posted right away.

    6. Team Rep Meetings

    @siobhan inquired about the status of the Team Rep Meetings that are organized by @jenmylo. While I heard talk of this a few months ago, there haven’t, to my knowledge, been any team meetings.

    7. DevHub

    @krogsgard has promised us a theme by Sunday or Monday. Getting the DevHub theme finished should spur some actions and more progress.

    Thanks folks and have a great weekend!

     

  • Eric Amundson 7:18 pm on November 12, 2013 Permalink | Log in to leave a Comment  

    Docs Meetup Roundup – Nov 7, 2013 

    Sorry for the late post, folks. Here’s a rundown of what happened in last Thursday’s Docs Chat:

    1. Docs chat time updated

    Since Daylight Savings is over, we’re now meeting weekly at 17:00 UTC, which is still 9am Pacific.

    2. Docs Issue Tracker Mockups

    @sams posted mockups of the Docs Issue Tracker and would like more feedback.

    3. Docs Sprints

    Last meetup on Nov 2 was productive and we have another coming up Saturday November 16th, for those who can join in person or via IRC.

    4. Theme Dev HB Opening

    @sams and @sewmyheadon discussed creating a new intro for the Theme Dev Handbook that gets the reader right into a theme from the start. A very basic theme that we can use to illustrate the principles of theme dev. This will give the reader a gentler intro into each main aspect of theme development, and allow us to setup the rest of the more in-depth content.

    Right now, the Handbook contains a lot of useful info, but needs to be tailored to getting new developers up-to-speed quickly without overwhelming them with jargon or specifics.

    @sewmyheadon will work on this intro for now.

    5. Theme & Plugin HB Spreadsheets Revamped – need %

    @sams revamped the spreadsheets we’re using to catalog the Handbook development progress. There’s now a % column, which we’re using to put our best guess of percentage completion for each page. So, if you’re working on either handbook, please enter in numbers for the pages that you touch, so we can get a better overall estimate of Handbook progress.

    6. Inline Docs

    Inline Docs posted a status update post, which prompted some new patch contributions.

    As of the meeting, the stats are:

    • Total: 185 files,
    • Completed: 92 files (49.72%);
    • In progress: 32 files;
    • Available to claim: 61 files.

    7. DevHub

    Is in active development now.

     

    • Siobhan 12:21 pm on November 13, 2013 Permalink | Log in to Reply

      The updated spreadsheet looks good. However, I’d like to get rid of the “Owner” column. The problem with this is that when I look at the spreadsheet it looks like all of the pages are “claimed” by someone else. This prevents me from picking something to work on – is the person working on it offline? Should I contact the page owner?

      Anyone should be able to work on any page at any time – assigning an owner to individual pages prevents that from happening.

      We had this problem with the plugin developer handbook in that lots of people assigned pages to themselves and then didn’t work on them.

    • Siobhan 12:23 pm on November 13, 2013 Permalink | Log in to Reply

      With regards to the theme handbook opening – I agree that this is a good approach. Ian Stewart has said that we can use any of the content from the Theme Shaper tutorial: http://themeshaper.com/2012/10/22/the-themeshaper-wordpress-theme-tutorial-2nd-edition/

      I suggest repurposing as much of this as possible as it’s a fantastic guide to getting started.

    • Eric Amundson 4:21 pm on November 13, 2013 Permalink | Log in to Reply

      Siobhan,

      I agree that the Owner column is confusing. Maybe we can re-title it something like “Contributors,” which would allow us still to keep a record of people who’ve added to it, in case of questions, but won’t be so off-putting.

      We could also incorporate some instructions into the spreadsheet, if that would help.

      That’s terrific about Ian’s allowing us to use content from the Theme Shaper tutorial – will definitely make good use of that. :)

      • Siobhan 4:48 pm on November 13, 2013 Permalink | Log in to Reply

        We can pull information on who has contributed to a Page directly from WordPress so I’m not sure if it’s necessary to have a Contributor column. That said, if you want a quick visual in the spreadsheet it’d be worth leaving.

        I’m working my way through editing what we have there already but let me know if there’s anything specific that you want me to look at. Am happy to knock together a step by step guide to creating a theme (based on the Theme Shaper stuff) once I get WC London out of the way (next week! yay!).

        • Sam Sidler 5:18 pm on November 13, 2013 Permalink | Log in to Reply

          How about “Lead” to indicate who’s heading up the work? Yes, anyone can contribute (if not by changing the post itself, then by comment on it) but we definitely want a person that’s overseeing the work and everyone should know who that is.

          I’d be fine with contributors too, of course.

          • Siobhan 5:21 pm on November 13, 2013 Permalink | Log in to Reply

            Lead doesn’t make sense since the people who have put their name down aren’t leading the page. We had a problem with people “leading” pages before and then disappearing. It puts other people off from contributing to that page.

            The person overseeing the work for each handbook is the editor for each handbook (currently Eric and Hanni). They are the point of contact for every page. We don’t need to complicate things by having multiple leads for each handbook.

            • Eric Amundson 5:24 pm on November 13, 2013 Permalink

              I agree. It’s hard enough to get contributors to show up, so the folks listed in the column-formerly-known-as-responsible may have contributed once or twice, but they really didn’t become responsible for the content.

              There are a lot of names listed from people who contributed > 6 months ago.

              I’d recommend “Contributors” just to keep quick track of them, and in case we want to contact them for review.

        • Eric Amundson 5:22 pm on November 13, 2013 Permalink | Log in to Reply

          I’d like to leave a column in the spreadsheet for quick reference if that’s okay.

          Siobhan, thanks for your help with this. I’ll see if I can work on incorporating Ian’s Theme Shaper content this Saturday at our docs sprint.

          • Siobhan 5:27 pm on November 13, 2013 Permalink | Log in to Reply

            leaving the column as “Contributors” works for me. I’m going to work fairly intensely on these for the next month so you can take it for granted that I’ve contributed to all of them ;)

  • Chris Reynolds 6:32 pm on November 11, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Admin Help: 11 November, 2013 

    Development has for realsies started on the new admin help feature plugin.

    (hurrah!)

    It resides here, if you haven’t been paying attention to these updates: https://github.com/jazzsequence/WordPress-Admin-Help

    Currently we’ve got 2 settings that appear in the user profile page to enable/disable tooltips and/or the help overview but neither of those have been implemented yet (though the settings do, in fact, save).

    What we have to work with

    @ninnypants and @trishasalas both looked at core and currently core puts help in the header for the page you’re on, which is highly inefficient. What this means is that we’ll be doing a lot of forging our own paths with our plugin.

    The Plan

    So, what we’ll need to do is develop a system that can be easily extended by other plugin and theme developers to allow them to add their own help to their theme/plugin.

    Documentation will ideally live in separate files for each page. There will be a function (or series of functions) to pull in the relevant documentation for the current page. We’re going to do as much as we can to include existing help documentation into this, but we’re going a completely different route in terms of handling and presenting it than WordPress core.

    Hooks will be created that developers can hook into so they can add their own documentation for their stuff.

    What’s next?

    @ninnypants is going to work on building out the architecture/framework for the plugin and use grunt to try to pull in existing help content.

    @trishasalas is going to work on pulling the help content into the places it needs to go

    @trishasalas and @ubernaut will work on ui stuff once the content is pulled in

    Concerns

    Accessibility

    @trishasalas is going to try to follow up with the a11y team and figure out what things we need to be thinking about in terms of accessibility (tests, what works, what doesn’t, resources, etc)

    Internationalization

    We, of course, need to make sure that all the strings we’re pulling in are properly i18nized. @jazzs3quence will be keeping an eye on that.

    javascript disabled/back-compatibility

    We need to look into what WordPress core does in js-disabled/non-js browser environments, how they handle it, and what we should do in those cases based on what core’s doing. Our approach is pretty js-centric and would be pretty useless if js was disabled and we didn’t have a fallback (but then, maybe core is the same…).

    Pull requests, tickets, comments, etc. are welcome on the Github repo above. I’m usually on IRC though I may not always be at my computer. If I am, I will respond to pings (just say my nick in IRC and I’ll see it). The next meeting will be next monday 10:30 MST

     

  • Sam Sidler 7:30 pm on November 4, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Docs Issue Tracker Mockups 

    Happy Monday Docs team!

    @karmatosed has started plugging away at mockups for your issue tracker and we’re ready for feedback!

    First off, here’s a mockup she’s created of the actual tracker itself, which is affectionately codenamed Documentron.

    The tracker includes columns for: reported username, date reported, type of issue (we’ll discuss which types are wanted during the implementation phase), current status, a link to the page with the problem, and a button for resolving the issue. It also includes a hide/reveal triangle for seeing the details of a particular issue.

    documentron-tracker

    Additionally, here’s a second mockup showing how hover states might work on the tracker.

    @karmatosed has also worked on a set of buttons that would be placed on documentation allowing anyone (who’s logged in) to report an issue. Which one do you like most and why? Feel free to discuss the placement of the button as well. We’ll want it somewhere consistent across all docs.

    documentron-buttons

     

    But that’s not all… Once someone clicks to report an issue, where do they go? Assuming they’re logged in, they visit this wonderful form:

    documentron-form

     

    Alright Docs team, what do you think about the mockups above? Keep in mind, they’re just mockups right now and might still need some design touch ups. Anything you think of is useful at this stage so we can get the mockups just right prior to sending them to a developer to implement.

    Thanks for all your feedback!

     

    • Drew Jaynes 7:38 pm on November 4, 2013 Permalink | Log in to Reply

      Looks great so far. Few things:
      1. I like the second report button because it fits the best with the existing theme and yet the red highlights makes it stand out. The solid grey/white blends in too well and the solid red stands out like a sore thumb.
      2. What other choices would live in the issue type drop-down?
      3. There should be some indication of who resolved an issue in the list table, as well as the ability to reopen an issue

      • Chris Reynolds 7:41 pm on November 4, 2013 Permalink | Log in to Reply

        Agree with 3. Also, an indication if someone has claimed a ticket. (and, you know, claiming a ticket at all)

        • Chris Reynolds 7:42 pm on November 4, 2013 Permalink | Log in to Reply

          …in which case the resolved column and checkbox would be hidden unless you were the person claiming it.

          …or maybe I’m overcomplicating things. But that certainly goes along with indicating who resolved the issue…

          • Sam Sidler 8:08 pm on November 4, 2013 Permalink | Log in to Reply

            On resolution, we could easily just sign the user’s name as having resolved it, but agreed that we need a way to say who’s assigned something.

            I don’t think we want to hide the resolved column and checkbox. Just because you’re assigned something doesn’t mean you necessarily should be the only one to resolve it.

      • Sam Sidler 8:03 pm on November 4, 2013 Permalink | Log in to Reply

        As far as other choices, that’s something that the docs team can discuss. It’s entirely changeable and up to you. We can add more later if needed too. As I mentioned in my post, it’s something that can be decided on during the implementation phase, but it can be discussed now or at any time.

      • Sam Sidler 8:06 pm on November 4, 2013 Permalink | Log in to Reply

        Forgot to mention, reopening an issue is on the first mockup at the bottom. :)

    • Chris Reynolds 7:41 pm on November 4, 2013 Permalink | Log in to Reply

      +like
      This would definitely help people (or me, at the very least) get involved in fixing/updating/writing docs.

      re: report an issue button — I like the second one with maybe the third as a hover. Agree with @drewapicture above, the first one blends in too much.

      I may be putting the cart before the horse, but, out of curiosity, is this going to be coded as something entirely new or is it going to be based on bbPress/Trac/etc with new stuff added in/styled?

      • Sam Sidler 8:05 pm on November 4, 2013 Permalink | Log in to Reply

        Cart before horse, but talking with the meta team, we definitely won’t be using trac and likely not bbPress. The plan a month ago was to use P2 with resolved posts and modify it visually. Of course, plans can change. ;)

        • Tony Scott 8:51 pm on November 4, 2013 Permalink | Log in to Reply

          I may be missing something here (almost certainly!), but if we’re not planning to use Trac, has consideration be given to using Github?

          • Sam Sidler 8:57 pm on November 4, 2013 Permalink | Log in to Reply

            Not at all. Nor will we. :)

            As many have said before me, if we can’t use WordPress for writing and managing content… we’ve failed. ;)

        • Chris Reynolds 8:54 pm on November 4, 2013 Permalink | Log in to Reply

          So, basically, just a custom loop displaying all the posts (tickets) and their resolved/unresolved status. Gotcha.

    • Graham Armfield 10:43 am on November 5, 2013 Permalink | Log in to Reply

      With regard to the view issues table, I like the format but the colour contrast is a bit lacking. The light blue on white and the light green on white would both fail an accessibility review – as would all the faint text in the resolved line.

      Please can the dates be less ambiguous – either 12 Dec 2013 or Dec 12 2013 – to cater for international ordering of dates.

      Re the ‘Report an issue’ button, I favour the third as it stands out more clearly than the other two.

      It may just be the quality of the screenshots but the colour contrast is an issue in the ‘Reporting an issue’ form. The light grey text would fail an accessibility review, the dark grey text is borderline.

      • karmatosed 11:16 am on November 5, 2013 Permalink | Log in to Reply

        Thanks a lot for the review, I certainly do want to make sure that it passes contrast and accessibility as much as possible. I did contrast check the colours and whilst it may be the processing, I absolutely will double check that. I’ll also note to do some date changes.

    • ← Older posts

    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