WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Updates from September, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 9:16 pm on September 4, 2013 Permalink
    Tags: ,   

    CEUX, Sept 3 Chat Notes + Wireframes 

    This week’s chat was uneventful — not a lot of progress this week as people continue to work on wireframes.

    This morning, I touched base with @jenmylo to get her feedback on some wireframes I’ve been working on. She had a lot of great UX, usability and accessibility feedback that’ll help shape how we move forward with this project. She plans on typing up her notes and posting them here when she has a chance.

    One thing we quickly figured out was wireframes are a really bad method for communicating interaction. She suggested I join forces with a developer skilled in jquery to quickly prototype our ideas instead of trying to wireframe them moving forward. Any jquery-savvy developers interest in pairing up? Otherwise, I’ll look into storyboarding as a method for communicating interactions.

    If anyone else has worked on some wireframes, this would be a great place to post them.

    Next chat will take place next Tuesday, 17:00 UTC in #wordpress-ui, but please feel free to post and comment here if you have ideas or questions.

     
    • Diego de Oliveira 9:59 pm on September 4, 2013 Permalink | Log in to Reply

      Great idea to work on prototypes instead of mockups! I think that this way its easier and quicker to make changes and bring ideas together!

      My suggestion is to setup a repository on GitHub to deal with this project prototyping workflow. The repo could contain some files to help people getting started with prototyping it (some files for basic layout, images, css, etc) maybe even with an starter html file. Then, people could fork it, make changes, build their own versions (or help building another versions based on other people’ wireframes) and quickly test it.

      I’m not an javascript expert, but I will experiment with some code for a prototype suggestion and post it later here.

    • Matt McLaughlin 12:13 am on September 5, 2013 Permalink | Log in to Reply

      Not having the skills to create a prototype here are some wireframes: http://mattnamclaughlin.wordpress.com/2013/09/05/illustration-not-building/

      I remain unconvinced of the Content Blocks as building blocks concept so I mockup up a slightly different Content Blocks as insertions into a base text layer concept. While I really like the idea of making the addition of content quick and simple, I just don’t think about posts as a collection of blocks. I think of posts as narrative stories illustrated with different pieces of content (images, maps, etc. etc.). I don’t want to loose the ability to function in that mode.

    • gregtyler 5:10 pm on September 5, 2013 Permalink | Log in to Reply

      I might be game to help with some javascript/jquery stuff with this. I’m new to CEUX contribution but I’m interested in getting involved. If, as Diego suggests, there’s a public GitHub repo, I’d love to grab that and have a fiddle!

      • Mel Choyce 2:34 pm on September 6, 2013 Permalink | Log in to Reply

        Boom: https://github.com/melchoyce/CEUX

        What’s your github username? I can add you as a collaborator.

        • gregtyler 9:53 am on September 7, 2013 Permalink | Log in to Reply

          It’s “gregtyler”. Thanks!

          • Mel Choyce 2:02 pm on September 9, 2013 Permalink | Log in to Reply

            Added! Let me know if you want to get together in IRC and chat about starting to build out a prototype. Same for @diegoliv.

            • Diego de Oliveira 2:55 am on September 10, 2013 Permalink

              I’d like to participate in the IRC chat! I don’t know if I can show up at the right time tomorrow (I’ll be at work) but I will try! Also, I should make some modifications on my current code and publish tomorrow on github a live demo from the initial state of the prototype – just a rough start, but at least we will have some sort of starting point.

    • Diego de Oliveira 11:34 pm on September 5, 2013 Permalink | Log in to Reply

      I started some work to help develop some prototypes. I did a simple layout for the feeling of a wp admin area and started some work with jquery/backbone code. If it helps someone, feel free to check, grab the code, change it, etc: https://github.com/diegoliv/wp-contentblocks-prototype

    • Paal Joachim Romdahl 5:14 pm on September 9, 2013 Permalink | Log in to Reply

      Perhaps a side note, but I went to Daryl Koopersmiths web site: http://darylkoop.com/
      He has earlier been working on a Visual Theme Editor and a Visual CSS editor. So there is some information there, and I am thinking that he could perhaps could share some information on the projects he has worked on.

      • Jen Mylo 3:05 pm on September 10, 2013 Permalink | Log in to Reply

        Those were his GSoC projects from years ago. The work he’s done since then on core with the custom menus, theme customizer, etc is likely more relevant.

    • Jen Mylo 3:33 pm on September 10, 2013 Permalink | Log in to Reply

      Here are the notes from my chat with @melchoyce baed on the wireframes. Numbers refer to the screens as they were numbered when we chatted.

      1.

      • “Add Content” below editor is confusing, since the post content is already content. If it means “content block” then say that. Try to only ever use a label to mean one thing rather than reusing it for different meanings (same goes for icons, ftr).
      • Having it (the “add content”mechanism) at the bottom is generally not as usable as somewhere the user can see before they finish writing based on tests where things like tags etc were positioned in that space. Also becomes an issue if user has resized the editor and pushes it offscreen.
      • There’s no division between post content and title but they are different elements. There are some usability and accessibility issues with this. Possibly achieve the goal by having title box fade away after entered rather than making title part of content box?
      • Giant font disparity between title and body text doesn’t make title stand out more, it makes body text look too small. Font used for title should be bigger, but not by such a big difference.

      2.

      • Popup editing toolbar instead of stationary buttons means losing the usability gained with muscle memory for hitting targets, can also be issue for manual dexterity accessibility.
      • Popup editing toolbar means you have to write text to select before beginning to format, but many people format as they go, before typing characters to select (such as with bulleted lists, headlines, etc), so before typing has begun this will mean more clicks, and a different flow to start than once begun, not ideal since documentation would have to outline both ways, likely to confuse new users.
      • The popup editing toolbar obscures the lines of text previous. This is very bad. The whole idea of “WordPress gets out of the way so you can focus on your content” is literally overridden here. Covering content means someone can’t re-read a sentence to edit it. Ack. :)
      • Probably worth creating personas to account for different ways people compose with WP and to also account for various disabilities that affect how well people can use some of these things, to be able to test against them.

      3.

      • The giant add content popup obscures the text, see previous note about this.
      • Unclear that this is for blocks, looks like postformat or insertion thing, makes it confusing about what is happening.
      • Recommend storyboarding this flow.

      4.

      • Clicking to create an image drop zone reinforces confusion around what’s happening right now, blocks seems no different than adding an image regularly, but it’s taking more clicks.
      • Make “add from media library” an underlined link and drop the “click to.” “click here” is something we try not to do in text links, as it’s considered a bad practice in ux circles.

      5. Just a loading graphic, no comments.

      6.

      • Strip of icons on top of image for editing looks nice when image is that size, but what about an image that is small?
      • What happens when I click an icon?
      • Where’s the default metadata that gets entered when adding an image?

      7.

      • Confusing flow here. Shows a drop target, add content is missing from bottom, not sure what’s happening.

      8/9.

      • The lines by each paragraph seem to be handles. The idea is that people want to move paragraphs without having to highlight the paragraph. Is that really a big problem for our users? What other complexity might this introduce that needs to be accounted for? Don’t forget manual dexterity disabilities that require all editing functions to be keyboard-accessible.

      10.

      • Can see now that it made a bottom section in the post layout. That didn’t get identified in the wireframes (though layout tab in the add content popup seems likely place it would be).

      11.

      • Not sure where the horizontal rule came in. Again assuming it’s that layout box, and at this point it’s clear that this interaction is being shown in detailed wireframes rather than a form to show interaction. would be easier to get the interaction down in storyboards or blocky clickthrough and leave the specific layout/placement/label details until after the “big idea” is solidified in action.

      12.

      • Why did the image change to a different size/orientation?
      • What happens with a small image? How does the icon strip work then?

      General:

      • Why using the word curate? Generally means to bring together other things into a group rather than creating your own stuff.
      • Why is presentation being taken away from the theme? It seems like this is really looking for magazine-level layout control, and that seems less important on a in-post basis than on a page basis… has there been any talk about real content blocks that can go other places in theme so it’s not dozens of text widgets and plugins as a workaround to achieve a similar end? Would it make sense to think bigger instead of smaller and look at content blocks as all content on the site, not just within a single post?
    • Diego de Oliveira 4:09 pm on September 10, 2013 Permalink | Log in to Reply

      Sorry guys, I think I can’t show up on today’s chat, I have an appoitment. :(

      I published the initial prototype that I was working on: http://diegoliv.github.io/wp-contentblocks-prototype/

      • Mel Choyce 4:15 pm on September 10, 2013 Permalink | Log in to Reply

        This is an awesome start! I’ll share it during the meeting today so people can play around with it.

    • Paal Joachim Romdahl 12:11 pm on September 13, 2013 Permalink | Log in to Reply

      I have created another wireframe: http://easywebdesigntutorials.com/wordpress/frontend-and-backend-editing-wordpress/
      TinyMCE buttons on the top with featured buttons visible (I just added some simple buttons).
      Fixed content editing box on the right side with a Publish button with a drop down below.
      Grid view to where one can see all edges of all the content and drag them around to move them to another location, create columns etc.
      I have added widget locations used on the specific page (perhaps a Jetpack feature can be added here?)
      Bottom I added an area to where there can be icons for mobile, Ipad and desktop.
      So many ideas as to what can be added..:)

  • Mel Choyce 7:40 pm on August 16, 2013 Permalink
    Tags: ,   

    Content Editing User Experience (CEUX) 

    Howdy folks!

    This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start. Here’s the plugin we’ll be building.

    Our first CEUX meeting will be taking place on Tuesday 17:00 UTC in #wordpress-ui. Providing this works for most people, we’ll continue meeting at this time each week.

    During our meeting, we’ll elect a team lead and discuss our process moving forward.

    Current team
    Our initial team is: @melchoyce (me!), @wonderboymusic, @saracannon, @DavidHickox, @georgestephanis, @helen, and to a lesser extent, @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team as content blocks move into pages. @jenmylo has graciously agreed to advise this group. If you’re interested in getting involved, come by on Tuesday!

     
    • bradparbs 8:55 pm on August 16, 2013 Permalink | Log in to Reply

      Such an awesome project!

      Shout out from #wcpvd where we’re doing some work on this now!

    • jayarjo 7:45 am on August 18, 2013 Permalink | Log in to Reply

      Providing a way to extend “insert block” module with user-defined blocks would be great. Also ability to edit the content directly on the site without moving to backend can be a lot user-friendlier, since simpler or not backend view of the content still differs from what user actually gets in the end. Have heard multiple complaints from users in this direction, even though I had a editor-style.css in place with all the site-wide stylings activated (including fonts and other subtle things).

      In case you lack someone to actually code this, I’m ready to participate (@jayarjo).

      • paaljoachim 12:36 pm on August 19, 2013 Permalink | Log in to Reply

        I have noticed that http://www.wix.com is becoming more and more popular. Just check out the quick tour video. Many templates that are easy to customize on the frontend. Perfect it seems for the non designer/developer. It would be good to learn from them and incorporate similar aspects of easy to edit frontend into WordPress. Taking certain aspects from the backend and also adding them to the frontend.

        • Easy to cumstomize templates (backend&frontend). Save a page/post as a template to be reused.
        • Drag & drop elements (main elements and widgets) into a grid that can be adjusted in a simple way.
        • Mel Choyce 1:07 pm on August 19, 2013 Permalink | Log in to Reply

          Wix was actually a service I explored (alongside Squarespace and Weebly) when I first looked into improving content editing, and I actually found it to be the least intuitive and most frustrating experience out of those web building services.

          Sounds like @ubernaut‘s going to be working on a front-end editing project: http://make.wordpress.org/core/2013/08/14/present-your-3-8-feature-idea-at-tomorrows-meeting/#comment-9950 You should touch base with them about that, since it’s out of scope for this particular project.

          • paaljoachim 3:00 pm on August 19, 2013 Permalink | Log in to Reply

            Wix is great for beginners when a person has gone one step further then WordPress is great. I helped a friend edit a few things using the frontend editing in Wix. It was not that bad. Certain things were not intuitive though but I helped him figure it out.

            There needs to be close interaction between the groups though (backend content editing and the frontend editing group). As it would be great to have block elements added to a page on the backend as well as the frontend.

            Of course a more advanced approach on the frontend is this: https://webflow.com/

            • Mel Choyce 3:17 pm on August 19, 2013 Permalink

              I agree that there needs to be a lot of communication between groups. Widgets is also interested in exploring the idea of content blocks, so we’ll be in close communication with them as well. I think with these beginning stages it’s okay to play around and try out lots of ideas, but as we refine our concepts more we’ll need to come together to make sure everything is cohesive.

          • @ubernaut 3:42 pm on August 19, 2013 Permalink | Log in to Reply

            we don’t have a p2 yet but i have a few (3) rough mockups i put together yesterday so will try to get some helping posting a p2 asap. i think the ultimate goal here should be what video games strive for a UI/X that requires no explanation or instruction maybe thats a pipe dream but hey i like to shoot for the stars what can i say? Even if we can’t get all the way there any closer we can get to that ideal will be i think greatly beneficial to new users.

            • @ubernaut 3:43 pm on August 19, 2013 Permalink

              oh yeah i also dig your mockups for the new post edit ui mind if i borrow a piece or two for my mockups?

            • Avryl 3:50 pm on August 19, 2013 Permalink

              By front-end editing, do you mean editing posts and pages or the whole site (title, header, footer, design etc.)? I’m making a few mockups as well, but they’re focussed on editing posts. I’ll share them today or tomorrow.

            • Mel Choyce 3:53 pm on August 19, 2013 Permalink

              Feel free to snag anything, just know that it’s probably going to change pretty dramatically in the next couple weeks. Here’s my psd: http://cl.ly/2h1n2W2D2y3r

            • @ubernaut 4:22 pm on August 19, 2013 Permalink

              well posting is the primary thing which effects almost every user role and as such i think deserves the most attention but in terms of new users i’d say a good chunk of those people are admins setting up their first blog/site. i think the logic can be applied to many aspects of editing (content and structure)

              i think the main aspects of admin that do not translate well to a front end experience are the various list screens and general/plugin settings pages. i think even those cases making it seems as if your not in some entirely different world will make the experience more friendly for new users.

              i need to try to get someone to give me a p2 so we we can stop going on a complete tangent from this conv though and thanks Mel i really like your dark version of the editing tools for what I’m doing and my shortcut version would have bee just invert the existing things :P

            • @ubernaut 10:22 pm on August 19, 2013 Permalink

              For anyone who wants to continue this conversation regarding the other idea conversation it’s here:

              http://ubernaut.wordpress.com/2013/08/19/combined-frontback-end-ui/

    • ryanrampersad 5:52 pm on August 18, 2013 Permalink | Log in to Reply

      The mockups look fantastic. I really like the look of “fieldless” fields.

    • JakePT 3:14 am on August 19, 2013 Permalink | Log in to Reply

      I love the look of the mockups!

      My only issues is that I wish there were a way to do blocks in columns, and I’m unclear on how image alignment works when in a block.

    • shaunandrews 4:50 pm on August 19, 2013 Permalink | Log in to Reply

      I’ve mentioned this to you a few times on Skype, but I want to make sure I mention in on a Make blog, too: I keep coming back to the idea of widgets-as-content-blocks. Imaging if all widgets are really just content blocks. You should be able to drop a widget into a post, page, or sidebar, just as easily as a content block into your post.

    • Azizur Rahman 11:30 pm on August 19, 2013 Permalink | Log in to Reply

      This is really great UX. What does concerns me is how this blurs the separation of presentation from data architecture.

      I am interesting in seeing how the actual data will be architect-ed. Would we have all the block some how composed into a single field (ie: post_content) or would the block themselves be stored such a way that it can be re-used and re-purposed for a different presentation?

      I am interested in this project so if you are looking for another team member to help let me know.

    • hearvox 9:29 pm on August 21, 2013 Permalink | Log in to Reply

      The mockups look great, MP6-like and very inviting: will encourage people to write. Assume these are of the Visual editor (don’t see the button for the Text editor).

      The Content Blocks idea make lotsa sense. I work w/ several national journalism sites, and we end up creating the equivalent, usually thru a homemade plugin that generates HTML w/ classes for things like Audio, Layout. (Will site-owners be able to define custom Blocks, as is possible w/ Post Types, Post Status, etc.?)

      The biggest problem all these sites have is the way TinyMCE wreaks having on HTML entered in the Text editor. For some sites we end up avoiding the WYSIWIG, and for others we extend the HTML that TinyMCE allows, and try to turn off most of its HTML reformatting: but this always seems like a battle.

      Most of the better articles in these journalism sites require HTML — some quite a bit of it. But any writers, and even coders, find a lot of editing/re-writing easier in Viz. So we’re constantly correcting the HTML mess TinyMCE leaves in its wake — aka, not optimum workflow.

      Anyroad: off to install the plugin on a dev site. Thanks for everyone’s work.

    • Michael Arestad 5:28 am on August 24, 2013 Permalink | Log in to Reply

      I love the idea of content blocks! I’m a little late to the party, but I’d love to help out with any design/CSS or icons if needed.

  • Helen Hou-Sandi 10:26 pm on January 21, 2013 Permalink
    Tags:   

    3.6 Core Development Cycle 

    If you’re looking to contribute to core UI, you’ll want to keep an eye on Make/Core, as we’re shifting our thinking of core UI contributions to being an integral part of various areas of core rather than a separate group/workflow/etc. All of the planned features for 3.6 include UI components and participation in them is highly encouraged. Office hours are either set or being set for each team and will be held in #wordpress-dev, so as always, feel free to join discussions as they’re held, whether in IRC, on the Make/Core P2, Trac, or elsewhere. Regular updates/summaries will be posted on that P2.

    Also, as you’ve probably noticed, we haven’t been having weekly UI group chats, due to a combination of the end of the 3.5 cycle and a shift in how we’re thinking about this group. For more, see @jenmylo‘s comment: http://make.wordpress.org/ui/2012/11/16/coming-soon-weekly-updates/#comment-22558. The #wordpress-ui IRC channel is always open, and we can use it for UI-focused discussions if #wordpress-dev is otherwise focused on something, but let’s all get comfortable in #wordpress-dev, too :)

    One last thing: this shift in thinking also applies to Trac. Right now there is a “UI” component, which is a bit of a mess and ultimately not a great help for watching for tickets of interest, as UI-related items are just as often found in other components. We’re working on emptying the component out by moving things into more relevant components (Administration is a good fallback if you don’t see another) and, for the time being, adding a manual keyword of “ui-focus”. In moving things, it’s also good to just be reviewing the issue the ticket raises and testing any patches provided, marking as needs-refresh if it doesn’t apply or closing the ticket (or making it with the close keyword) if it’s no longer relevant. There are almost 3500 tickets open right at this moment, which is an unmanageable number that leads to things getting lost. Let’s help get that down while we get Trac organized. Here’s the list of tickets in the UI component, and the newer list of things tagged ui-focus. If you’re not Trac-minded, don’t worry. If you are, we’d appreciate the help!

     
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