Post Formats, Schedules, and Philosophy

Post Formats UIUI User interface is looking like this right now:
Screen shot 2013-04-23 at 9.05.04 AM

This seems confusing, because it looks like they are icons to insert something (Image, Gallery, Link, Video, etc), but instead of launching a popup to insert a link or an image, the screen changes and the navigation that was just used to choose disappears completely. (Note: If Standard had some indication of being the default/current selection it wouldn’t be as confusing)

Clicking on one — say Link — makes the UI change, the big icon row go away, and a format switcher link drops below the title rather than keeping its visual hierarchy above the post stuff, and it’s generally disorienting.

Screen shot 2013-04-23 at 9.09.35 AM

If the user thinks, “Whoa, what happened, I better change format again,” and they click on the “Change format’ link under the title field and next to the “Enter URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org” instruction, the screens morphs again to this:

Screen shot 2013-04-23 at 9.12.41 AM

Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing. Does it still think it is a link bc they didn’t actively choose to return to standard, they just chose to see the options? If that’s so, why did the url field disappear?

Looking at the release schedule:
Screen shot 2013-04-23 at 9.40.18 AM
We launched BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 on April 4, and it’s been almost 3 weeks without a follow-up beta 2.
…I am wondering if the post formats ui is really prime time ready, or if it should be one of the very first thing sto land in a 3.7 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". so we can get the things that are completely ready into the hands of users sooner rather than later?

Since I’m outside the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev group now, I’ve been on both sides of the deadline delay dance. I know how hard it is to let go of something that feels like it is thisclose to done. And I know that just about everyone on the core team will be thinking right about now that I should shut up (and I’m okay with that, because it used to be my first response to deadline questions to core, too). But we have this philosophy posted on wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/:

Deadlines Are Not Arbitrary

Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.

Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

I’m not trying to be a troublemaker or imply that anyone isn’t doing everything they can — I know for a fact that people are working themselves into the ground on this release. Nor am looking to incite a debate about deadlines or all the explanations of how we fell behind this time (I’ve been following along, everything is really pretty normal). But would it be better to not try to squeeze it all in, get out what we can ship now (including the awesome 2013 theme that regular people still don’t have access to), and take a quick breath to relax before diving back in on a new cycle? Shipping is a feature, too. 😉

#3-6, #deadlines

Post Formats UI Update, 3/14

As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UIUI User interface/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help 🙂

Continue reading

#3-6, #post-formats

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

  • Menu items as accordion (@jkudish)
  • Show the menu select area at all times (@DrawAPicture)
  • Additional menus accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) (@lessbloat)
  • Menus help text changes (@DrawAPicture)
  • Test delete link at the bottom (@lessbloat)

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

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 CSSCSS Cascading Style Sheets. in latest patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. (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 JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) work
  • Additional code refactoring
  • Am I missing anything?

p.s. @DrewAPicture, I added a title this time just for you. 😉

#3-6, #menus

Revisions Update, 2/5

Yesterday’s meeting focused on revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. to the revisions interface :). @lessbloat joined us to ask some great questions, and helped refocus the UIUI User interface changes that have been proposed and mocked up so far. We started off by trying to identify the major uses of revisions, and settled on two primary cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow.

In light of those focuses, we’ve decided to revisit the UI mockups we’ve (namely, @karmatosed and @adamsilverstein) worked on so far. The general consensus is that they’ve become overly complicated, and led to feature creep (looking at you, line-by-line accept/reject capabilities). @karmatosed is working on some new mockups for Thursday’s office hours. One possible source of inspiration may be @benbalter’s post forking plugin.

On the code side, @mdawaffe worked out a pretty comprehensive patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. for the display of incorrect authors on revisions (#16215). We’ll be reviewing that, along with the patches added to the other tickets we’ve scoped for 3.6. As was the case when I last posted, progress is slow at this point due to travel and the ongoing UI discussions.

[IRC log]

#3-6, #revisions

We had a great discussion yesterday during office…

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 ​https://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture will oversee this)
  • Updated copy for ​https://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 customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.).
  • Code reviews (multiple people please :-))
  • RTL testing
  • Browser compatibility testing
  • No JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. testing

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

#3-6, #menus

Post Formats UI Update, 1/28

@lessbloat has started new rounds of user testing – one with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as-is, and one using the Crowd Favorite code and San Kloud for the theme so that all formats are enabled. Will be reviewing and posting those when they come in.

We’re going to go ahead and get patching so we can test and iterate, and still looking for somebody interested in creating icons. @rachelbaker will be working on the form itself and switching. Would love a volunteer or two on data retrieval and theme usage functions, but will likely be looking at that myself in the next couple of days.

Office hour log

#3-6, #post-formats

Post Formats UI Update, 1/24

Apologies for the late update – helps if you actually publish the post! 🙂 We were in #wordpress-ui due to a little scheduling conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. – we’ll hopefully be back in #wordpress-dev next week, and are sorry for any confusion.

Discussion point 1: format switcher, with an example from @lessbloat: http://f.cl.ly/items/1t09071U2v1E2x2s3X2i/post-formats.png (we would use “Standard” as opposed to “Text” for that label). We will not be blocking the current behavior/ability to just start writing a post when you enter the add new screen, i.e. no forced selection of a post format before you can start writing. There is some concern about user confusion in that one might think that you can/should specify data for multiple formats in a single post if the switcher is always viewable. A viable idea seems to be that all formats are shown when you load the add new post page, which then collapse into one item (the selected one) upon a specific selection. Editing an existing post, including drafts, will only show the one format selected. Clicking on the selected format would allow for switching of the format via a to-be-determined interaction. There’s also the idea that a screen option would be provided to turn off the switcher entirely should the user so desire, just as the “Format” metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. can be turned off now.

Action: Call for icons, one per post format. No dimensions determined yet; keep in mind that 2x versions will be needed.

Discussion point 2: data structure needs, based on this really great start on wireframes by @melchoyce: https://make.wordpress.org/core/2013/01/22/post-formats-ui-update-121/#comment-7674. Proposed:

  • Media URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org/embed code/shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. (basically, text), to be shared between audio and video
  • Link URL, to be shared between link and image
  • Quote content
  • Quote source
  • Gallery, which would be a shortcode that likely needs to default to [gallery] for backcompat; would use shortcode with list of IDs for new style
  • Image, which could be an attachment ID or URL (this is separate from featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.)

Sharing data fields (storage TBD, likely post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.) would mean that switching between formats that are similar in data needs would retain that field. Action: discuss proposed data structure in comments; pros/cons of sharing fields between formats, anything missed, etc. Also discuss anything related to the wireframes; @melchoyce was working on some discussed tweaks (although she may be understandably behind due to computer theft 🙁 ), and there will likely be more that we’ll want to do.

Finally, as a tightly-related item, @wonderboymusic started work on the possibility of an HTML5 audio/video player in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.: #23282. Testing and feedback more than welcome.

Full chat log

#3-6, #post-formats

Post Formats UI Update, 1/21

Still looking for wireframes/storyboards for possible UIUI User interface ideas for each post format. To put it succinctly, we are looking to address discoverability, value, and usability, approximately in that order. We will at some point need to talk about how users get there in the first place, but again, for now let’s focus on the add/edit post screen. We briefly touched on what would happen to the UI if the theme doesn’t support the post format – there seems to be early consensus that the UI itself stay altered (e.g. if there were a separate input for a link URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org) but there would be a warning of some sort about the lack of theme support.

A large portion of our office hour today was spent discussing a script for user testing that we can use throughout this process to help us evaluate the changes proposed. We need to use a theme that includes all ten formats, doesn’t do anything to the adminadmin (and super admin) UI, and preferably does something to the front end display for each. One that I know of is San Kloud, although it has some deprecated function usage (hey @kovshenin – want to fix that? 🙂 ); other suggestions welcome.

Since the first part of the issue here is discoverability, the script needs to not hand-hold the format selection or entry process. Here’s a rough outline of what it might look like – discuss any changes in the comments, and @lessbloat will help us get testing. Some of these are particularly difficult to describe in a non-leading manner. Through each of these, it would be good to have the user narrate what they want or expect will happen for each of these formats. A little fuzzy since we’re not going to point them at the format picker and a given tester may not be used to blogging, but the more narration of thinking/expectations, the better.

  • Standard/text: Add a blogblog (versus network, site) post entitled X, with the following text. Publish and view the post.
  • Aside: Add a brief blog post without a title, or what might be referred to as an “aside”. Publish and view.
  • Status: Add a blog post that represents your current status as (provide text), the way you might on a site like Facebook or Twitter. Publish and view.
  • Chat: Add a chat blog post where the content is a chat transcript (provide something to copy-paste). Publish and view.
  • Quote: Add a quote blog post with X quote attributed to Y. Publish and view.
  • Link: Add a link blog post with X text linking to [URL]. Publish and view.
  • Image: Add an image blog post and insert X image into the content editor. Publish and view.
  • Gallery: Add an image gallery blog post with X images (this probably needs step-by-step instructions for creating a gallery). Publish and view.
  • Video: Add a video blog post with [something from YouTube]. Paste the URL on its own line without linking it. Publish and view.
  • Audio: Add an audio blog post with [something from SoundCloud]. Paste the URL on its own line without linking it. Publish and view.
  • View your site. (If they chose formats, it should show the differences pretty clearly in a post archive view, hence the importance of choosing an appropriate theme.)

Full IRC chat log

#3-6, #post-formats

Here’s a quick update on the 3.6 menu…

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

Last week we:

  • Merged the the UIUI User interface 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 P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs.).
  • Improved & simplified some copy
  • Added a new hookable “common links” metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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

  • Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture volunteered)
  • Updated copy for https://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture volunteered)
  • Updated copy for https://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture volunteered)

TESTING

  • Once the code items are complete, I’ll run another round of user tests (@lessbloat)
  • RTL testing
  • Browser compatibility testing
  • No JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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. 🙂

#3-6, #menus