WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Tagged: ceux Toggle Comment Threads | Keyboard Shortcuts

  • Mel Choyce 6:45 pm on November 11, 2013 Permalink
    Tags: ceux   

    Since there have been some questions about CEUX recently, as announced in our 10/22 meeting, CEUX has been put on hold until there are more available developers interested in working on the project.

    Thanks to @joen for collaborating on concepts with me, everyone who pitched ideas here and in our weekly chats, and @diegoliv and @briandichiara for their hard work on the CEUX plugin. Diego has expressed interest in working on the plugin some more in his spare time. If anyone else is interested, I’m happy to give commit access.

    ’til next time. See you, space cowboys.

     
    • julianprice 3:30 am on November 16, 2013 Permalink | Log in to Reply

      Hi @melchoyce looks awesome thanks you guys for all your hard work. First of all I am newbie here commenting but for some time I have been wanting to find away to contribute to the wordpress community even though I do not have has much web exp at all but have been learning … I guess :) who knows…

      Anyway I was unsure where to post so you the first I came to just for user experience and have followed you and Helen tuts from word camps on .tv.

      I will cut to the chase now in part to vent that word camps video sessions are constantly talking about engage in the community contribute make WordPress better. In my opinion though and certainly know this is all voluntarily contribution but you have engage perspective of others that are not remotely in your business.

      So my means of engaging contribution was as follow: http://wordpress.org/support/topic/suggesting-box?replies=1

      No replies no engagement nothing from someone that is a complete outsider trying to contribute. I know this probably should be in support or plugin ; bottom line I consider this u/x on the overhaul of wordpress.org usability especially with plugins in catgorories of functionality, requirements for plugin in developers to at least place in 1 cat no more than 3 & no more than 5-10 tags.

      I see the plugin repo as a pin board with catgories of functionally: sliders, galleries, content types, social media tools, admin tools, styling tools, short codes,…you probably know best how to categorize than I do.
      In addition ensuring tags on the submissions. On top of bringing to front by 6 months updated, 1 yr updated and removing all others.

      I certainly giving suggestion in addition I am happy to go in start catgorzing/ tagging them in right format or even better I am pretty sure there could be a user suggest script to place in cat and/or tag.

      That’s all I have at this to contribute to make.wordpress.org better.

      • Mel Choyce 5:27 pm on November 20, 2013 Permalink | Log in to Reply

        Hey! Glad to see you’re interested in getting involved in improving WordPress UX and usability. From your post, it sounds like you’re interested in improving WordPress.org itself. The best place to get involved on that front is http://make.wordpress.org/meta/, the Make subgroup that helps tackle the WordPress community websites and tools. They have their own track, where you can bring up usability and UX issues: http://meta.trac.wordpress.org/

    • Leah 12:52 pm on November 18, 2013 Permalink | Log in to Reply

      Perhaps something to check out: http://madebymany.github.io/sir-trevor-js/

    • roodlicht 4:35 pm on November 20, 2013 Permalink | Log in to Reply

      And here is the English version of the last URL regarding TYPO3 Neos: http://www.roodlicht.com/typo3-neos-or-typo3-cms/3364?lang=en

  • Mel Choyce 9:25 pm on September 23, 2013 Permalink
    Tags: , ceux   

    CEUX, Sept 17 Chat Notes 

    Couldn’t make it last week? Check out the chat log.

    Design updates

    This past week, we’ve had some new designs pop up:

    UX feedback is welcome, though keep in mind these are still ideas. We’re looking for big-picture issues. :)

    Getting stuff done

    We’re going to continue to work on smoothing out these ideas, then will need some people to help us prototype them. To help that along, we’ve put together a spreadsheet of tasks. If you’re interested in claiming a task, let me know.

    CEUX Poll

    We’re pretty deep into various design concepts, but I think I want to also take a step back and evaluate what we’ve done so far. Are we on the right track? To help this, I’ve put together a survey:

    Writing Posts in WordPress

    Please take this when you have a moment and share it along. The results will be used to help us figure out if we’re solving the right problems, or if we need to step back and try out some different ideas. It will also help us determine if there are any “quick wins” we can implement prior to adding content blocks.

    Chat is tomorrow, Tuesday the 24th at 17:00 UTC in #wordpress-ui. I’ll be on a plane, so I might not be able to make it, so @joen has agreed to lead in case of my absence.

     
    • mrwweb 11:34 pm on September 23, 2013 Permalink | Log in to Reply

      A few thoughts/ideas (and sorry if this has been covered previously).

      1) I can’t help but notice how similar this feels to the Post Formats UI (particularly in iconography). I’m super bummed that that project seems completely abandoned, but should it ever come back to life, thinking about putting these two things together is pretty mind-blowingly confusing.

      2) The UIs where the buttons are in the editor seem clearer that you’re adding content to the body of the post. I think this might be even clearer if you outlined the options in a dotted line to denote the potential for additional content. Here’s a concept that merges some things from a couple of the posted ideas: http://mrwweb.com/wp-ceux/mrw-ceux-concept-092313.jpg To be clear, I make the assumption that the new feature is prominent enough that people will discover it whether or not they understand it at first.

      3) Given the direction of WordPress (and the web), making sure the tool and content layouts themselves are responsive seems very important.

      4) I’ve noticed some concepts have a “Text” block and others don’t. The inclusion of a text block feels a bit confusing to me. If I add an image, for instance, do I have to add a Text block afterwards to continue writing or is text the default state of the editor after a block is added and configured?

      • Diego de Oliveira 12:57 am on September 24, 2013 Permalink | Log in to Reply

        Hey, mrwweb, nice thoughts! First, I think that the Content Blocks plugin is definitely an evolution of the idea of Post Formats. In my opinion, that’s the initial reason that the mockups and prototypes use the same icons.

        What I like about your concept is that it has an area that looks like a placeholder, and it made clear that it is a place to put something else (content, in this case). Maybe this could be a more intuitive approach.

        About the “Text block”, It is there because we’re still trying to figure out how to deal with content. For example, if we think about blocks like pieces in a grid layout, then I think that every piece of content should be a block, including text. But, if we think about the use of blocks in an “editorial” post with a linear content, for example, then maybe a grid wouldn’t be much necessary, and maybe the use cases of Content Blocks would be more limited. I think that the point of Content Blocks is, in first place, help build any type of content, without depend on a selection of a post format (you can build any format of post, at any place), and, in second place, let the user free of the linear approach of build a page.

      • Joen Asmussen 6:44 am on September 24, 2013 Permalink | Log in to Reply

        I really dig your mockup. I think the dotted line may be a tad weighty, but that’s definitely workable. It keeps things clean while still showing recently used blocks on hover. Good job.

        About post formats — the inception of content blocks is to subsume the post format concept altogether. If you only add a single content-block, video for example, that defines your post format.

        • mrwweb 3:41 pm on September 24, 2013 Permalink | Log in to Reply

          No problem on the line weight. It was a quick mockup and certainly worth evolving :)

          If you only add a single content-block, video for example, that defines your post format.

          Do you mean that in a literal technical sense or just in the abstract? Would post formats be deprecated if this feature gets into core? What if you mark a post as “Audio” and then put only a “Video” in it? (That wouldn’t make sense, but I don’t think an interface should even allow that type of confusion.)

          • Joen Asmussen 4:45 pm on September 24, 2013 Permalink | Log in to Reply

            There were many reasons for post formats being separated from core. The added UI was one of the reasons. And so part of the genesis of a block-based editor was indeed a yearning for a post formats alternative. So yes I mean that in a technical sense: there’s no reason WordPress can’t add “format-video” as a CSS class to a post that only has video-blocks. So the post format is automatically detected by WordPress based on what blocks you use. It’s not something you pick.

            As always, we’re exploring here. Nothing is set in stone.

    • gregpabst 1:22 pm on September 24, 2013 Permalink | Log in to Reply

      These concepts are coming along nicely. I lean more towards @joen‘s concepts as I think having the common content types easily accessible inline would make it easy to add content blocks as you are composing a post. I do appreciate the more robust options and search shown in your and @diegoliv‘s wires. The main issue I see with those options is that the common content types aren’t as easy to get to. For example, the search is shown first. Maybe a hybrid could be done where the common content types are shown at the top of the modal or inline with the composed post like the first concepts then the robust modal with additional content types and a search are shown for the “More…” menu.

    • Edouard Duplessis 12:41 pm on September 26, 2013 Permalink | Log in to Reply

      Did you look guy at what they do on Squarespace http://vimeo.com/45734056, I dont really like the implementation of adding stuff, but for the layout thing, I think it’s pretty nice. It’s like an automatic column layout.

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

      Yeah, It’s pretty awesome! I tested it some weeks ago, and the way that the Squarespace’s editor handles layout is really good. Personally I think that if we could achieve something like that, we would have a powerfull new way to handle content and layout. We just need to figure out how to handle it, and think about the use cases and possible issues.

      We’re still discussing at the CEUX Chat some initial concerns of the project, like the blocks menu UI and the implementation of TinyMCE, but content layout will be probably a discussion we’ll have after we solve this initial challenges.

    • Manuel Schmalstieg 5:17 pm on September 27, 2013 Permalink | Log in to Reply

      I am extremely excited by all the CEUX prototyping so far. My main comment is pretty close tho what Jen Mylo has been saying (last paragraph).

      In short: I think this is an amazing opportunity for improving the handling content blocks, not only *inside* the main text container, but also extending to several separate content blocks. I am thinking mostly about a picture gallery that sits *above* or *aside* editorial content, rather than being embedded in the body text. This is so far solved by custom meta boxes, or plugins like the (excellent) Advanced Custom Fields.

      It’s a bit lengthy to explain in full, so I wrote a detailed and illustrated post. Waiting for your feedback :)

      • Edouard Duplessis 3:08 am on October 1, 2013 Permalink | Log in to Reply

        Nice post, I gonna try to make some sketch about it and the best simple way for the user to use this.

      • Steven Jones 2:58 pm on October 11, 2013 Permalink | Log in to Reply

        “I am thinking mostly about a picture gallery that sits *above* or *aside* editorial content, rather than being embedded in the body text”

        I think we need to get away from the thought that the main editor has to exist. Editors (multiple) can fit into the flow of the blocks, whether they are full width or half the page.

    • Paal Joachim Romdahl 2:02 pm on October 7, 2013 Permalink | Log in to Reply

    • Paal Joachim Romdahl 9:27 am on October 14, 2013 Permalink | Log in to Reply

    • Edouard Duplessis 7:52 pm on October 15, 2013 Permalink | Log in to Reply

      In my other comments i’ve talked about about some inspiration from Squarespace http://make.wordpress.org/ui/2013/09/23/ceux-sept-17-chat-notes/#comment-23949

      And I’ve seen in the past another cms more lightweight but the implementation of the region is very nice
      http://grabaperch.com/

  • Mel Choyce 7:48 pm on September 16, 2013 Permalink
    Tags: , ceux   

    CEUX, Sept 10 Chat Notes 

    We had a pretty exciting chat last week! Here’s what happened:

    This upcoming week sounds like it’ll be a work week, so I’m thinking the meeting will just be a check-in. Come with your questions, comments, and any progress you’ve made with sketching or developing. As always, chat is Tuesday at 17:00 UTC in #wordpress-ui.

     
    • Paul 10:17 pm on September 16, 2013 Permalink | Log in to Reply

      Absolutely love the WIP prototype, definitely a win and a great way of handling a variety of post content, (re – pot format debacle) This is definitely what I want to see in the next iteration of the WordPress Admin. A great addition would be a preset responsive grid allowing you to set a column width for a content block.

      I assume the idea would be for the the_content() to do all the heavy lifting in outputting the various types…. my themes are bloated with a lot of logic ands various views. The ability to control the content layout like this would be AMAZING!!!!!!!!!!!

      Bring it on – as a professional WordPress developer this is what I, and my client,s have been gagging for.

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

        Hi, Paul! The idea of handling columns and grids right at the post editor is definitely a feature that we need to discuss, I agree that it will be a great addition!

        And I was thinking the same as you about the use of the_content() to handle all the content blocks. I think that we could print all the content using just the_content, and we could get a particular block using something like the_content(array(‘block_id01′, ‘block_id02′).

        • Paul 7:06 pm on September 17, 2013 Permalink | Log in to Reply

          Awesome, yeah love the idea of extending the content, I don’t want to jump ahead too far, but the other ‘concern’ or point of interest for me would be how we eventually handle custom content blocks.

          Currently, other than using the post formats fairly extensively with my own custom meta boxes (I like to use them for pages as well) which this would totally handle (woop!) I usually create fairly extensive meta-boxes for specific content areas on a template or site as well…. any thoughts – leave them as they are for now ? or would the goal be to integrate those as well….

          • Mel Choyce 7:11 pm on September 17, 2013 Permalink | Log in to Reply

            It’s too early to worry about this yet, so I’d leave them as-is for now. We plan on making the blocks in such a way that it’s easy for developers to be able to add custom blocks, but how that’ll be implemented is still up in the air.

    • Grant Palin 11:24 pm on September 16, 2013 Permalink | Log in to Reply

      Really like the prototype. I’ve been using Advanced Custom Fields to add extra fields to certain content types, but it would be super to get some similar functionality into core, or at least a “core” plugin similar to the post formats one. It would be fabulous to be able to distinguish blocks of content within a single post or page, instead of having them all together in one text editor.

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

      Yay, I’m happy that everyone’s enjoining the prototype! :)

      @melchoyce just for the record, I’ve just pushed some commits that fixes the prototype markup and styling, now everything including Dashicons should work properly.

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

    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 9:05 pm on September 2, 2013 Permalink
    Tags: , ceux   

    CEUX, Aug 27 Chat Notes 

    Sorry guys, I’d meant to get this out earlier. Here’s last week’s meeting log.

    Chat notes

    • Chatted a bit about embeds WordPress core currently supports, and how we can start grouping similar content types together
    • Decided on including a generic “embed” block
    • Explored different ideas for how you could move blocks around
    • Talked about using an “agile” development approach

    For this week

    • Start wireframing out block scenarios (for example, what happens when I click a video block? What pops up? etc.) and then present them during chat
    • Explore text as “just another content block”
    • Continue developing the initial plugin functionality

    Next meeting is tomorrow, 17:00 UTC in #wordpress-ui. Bring your wireframes. :)

     
    • Avryl 11:04 am on September 3, 2013 Permalink | Log in to Reply

      Wish I could join today, I’ll definitely read the logs!

    • Paal Joachim Romdahl 2:58 pm on September 3, 2013 Permalink | Log in to Reply

      Here are some options for various module options that Themify Page Builder uses.
      http://easywebdesigntutorials.com/wordpress/themify-page-builder/

      A few things:
      At the bottom of each module option is an area to add a CSS class.

      Nesting content blocks. For instance as in content box (adding a box with a color behind some content to create a frame around the content. As I have done so in the above page behind the default gallery.

      Saving the page and reusing it elsewhere. How should this be handled? Should there be an duplicate underneath the post/page in the all page/post listing? (Quick bar I think it is called.)

      Have a great chat! I am not able to make it this time.

    • diegoliv 8:37 pm on September 3, 2013 Permalink | Log in to Reply

      I know that this discussion is in it’s initial stage, working on mokups for the best UX, but I saw a resource today that I found interesting and I think that it could help to build the functionality of the project.

      We know that Backbone is now part of the WordPress Core, and is the base of the awesome new media uploader/editor (added in version 3.5). So, i think that in terms of development, it’s the right tool to build this project. So, I saw this Backbone plugin that reminds me some mockups that I saw here: http://etchjs.com/ (made by Josh Nielsen).

      Anybody knows this plugin? I saw the demo and it looks very promissing. I don’t know if it fits exactly the needs of this project, but at least it’s a good resource for inspiration.

      • Helen Hou-Sandi 8:41 pm on September 3, 2013 Permalink | Log in to Reply

        Very cool! Even if it’s not a perfect fit here, it’s a good thing to know about. Also: looks like license is compatible, yay.

    • Manuel Schmalstieg 11:04 am on September 4, 2013 Permalink | Log in to Reply

      I’m very very excited by this project!

      One thing that strikes me when seeing the mockups at http://moc.co/sandbox/post-formats/ is the new placement of the “Publish” button: to have the Publish/Update button always visible would be sooo useful!

      I’m a heavy user of AdvancedCustomFields, so I often face the problem that after updating a content field below the fold, a lot of scrolling is necessary to get to the Publish button. This is confusing for new users, and a hassle for experienced ones.

      Making that button *always* accessible in some location of the screen is a great usability improvement. The same goes for the proposed selector for categories / tags, placed in the footer bar.

      Are those improvements considered for being included in the scope of CEUX, or some other UI project?

  • Mel Choyce 9:45 pm on August 25, 2013 Permalink
    Tags: , ceux   

    CEUX, Aug 20 Chat Notes 

    We kicked off CEUX with our first meeting this past Tuesday, August 20th. Couldn’t make it? Check out the IRC logs.

    Some meeting notes:

    • We elected a team lead (me)
    • We defined the objective of this project, which is improving the user experience around adding content to posts and pages.
    • Next, we chatted about scope, and determined the following items are in scope:
      1. Improved text formatting (aka making changes to the format bar and how users select things like bold or italic, make lists, add links, etc.)
      2. Content blocks
      3. Improved html mode with syntax highlighting (later iterations)
      4. Autodetection of post formats based on post content (later iterations)
    • We also talked about what is not in scope:
      1. The publishing experience (saving a draft, scheduling, etc.)
      2. Creating advanced page layouts (like defining widget areas on your page, etc.)
      3. Widgets, menus, appearance, etc. Anything that isn’t specifically about writing or editing posts and pages.

    @wonderboymusic has set up a plugin for us here. Feel free to install it and start playing around. You can also check out our initial mockups here. Please remember both of these are very much early stage works-in-progress, and that nothing is final yet.

    Additionally, @wonderboymusic will be acting as the team’s developer lead. This means that he will have the final say on all development matters moving forward.

    For next week:

    • I’d like us to start putting together a list of all content blocks we should include by default. I’ll get us started thinking about these in the comments.
    • Once we start getting a list together, I want us to start sketching or wireframing what each of these blocks will look like — what fields do we need for each? How should they be displayed in the post? Etc. In addition to our starting mockups, @joen has some great mockups which we can liberally steal from. :)
    • @wonderboymusic will take a chunk of our meeting to go over how plugin development will be structured.

    Our next meeting is Tuesday 17:00 UTC in #wordpress-ui. Hope to see you then!

     
    • Mel Choyce 9:53 pm on August 25, 2013 Permalink | Log in to Reply

      Potential default content blocks:

      And, if we want to have format blocks:

      • Columns
      • Horizontal Rules
      • Read More
      • Edit: Tables

      Any more?

      • Avryl 9:57 pm on August 25, 2013 Permalink | Log in to Reply

        Maybe tables could also be a (default) content block?

      • Mathias Gomig 10:01 pm on August 25, 2013 Permalink | Log in to Reply

        Maybe Google Maps, where you can pick a place and set a zoom level… ?

        • Ipstenu (Mika Epstein) 10:19 pm on August 25, 2013 Permalink | Log in to Reply

          As long as the blocks are filterable/hookable, plugins would be able to add in their own blocks as needed. And Maps would totally be plugin territory :)

      • Matt McLaughlin 3:32 am on August 26, 2013 Permalink | Log in to Reply

        A couple comments/questions/observations since I have a conflict with the IRC time:

        1) It seems like there are two types of Content Blocks that we would want to behave differently. The first are “Insertion Blocks” like Images, Maps, whatever. These things clearly are inserts and if you had a bunch of text highlighted and hit Image, the expected behavior would be for it to overwrite. The second are “Style Blocks” where the contents of the block is specifically styled text. There, if you had some text highlighted in the body of the post and clicked “quote” the expected behavior would be to style that text, not delete it and insert an empty quote box.

        2) Does quote (and the other style boxes) insert a text box within which the styled text lives? Or does it style the text in the body of the post? Or some hybrid of the two where it acts like styled text for the purpose of selection (you can click and drag from the paragraph before the quote into the middle of the quote) but click and drag anywhere within the quote and it acts like a text box and moves as a unit.

        2a) Related to the above, what is the relationship between Content Blocks that style text and the styles drop down in the formatting menu? If an existing theme has a quote style, will that be confusing? Generally I think the relationship between Content Blocks that style text and the styles menu needs a thorough examination to make sure we get this right. I might even be in favor of NOT including as Content Blocks anything that just styles text, and rather include some “special” styles in the formatting menu styles drop down.

        3) Will there be a concept of “parent content block” within which other content blocks could live? I’m specifically thinking about the gallery. It would be really nice if we could set up a structure that would encourage developers to put all their various takes on a gallery within the Gallery Content Block itself rather than separate Content Blocks. Go into the gallery, chose your images and then chose Joe’s Slider or Supa-Dupa 3D Image flipper gallery or whatnot.

        3a) In relation to the above I actually think there should be a core default Map Content Block that has a dead simple OpenStreetMaps insert. But more importantly it offers a standard place for other map plugins to put their maps without proliferating the formatting bar with multiple map Content Blocks

        4) I would like to see a Downloadable File Content Block that allows you to insert a file (either for download from WP or as an embed) as standard. I know there are a ton of file vault plugins, but WP really needs a core implementation.

        5) Despite there being good table plugins I agree that tables should be default. Maybe get one of the plugin devs on the CEUX team and integrate it. Similar to the above if you have multiple table plugins it would be nice if they were under one table button in the format bar (or wherever Content Blocks end up living…)

        5) Lastly, despite not being in scope for this project, I hope that an eventual merging of the Content Block concept and the Widget concept is in the back of people’s mind and that when it doesn’t distract from the immediate task we lay the groundwork for that. The widget experience is awful and a big part of that is people not being familiar with it. To the extent that people could get familiar with Content Blocks in the heart of WP (the posts) and then transfer that understanding to the widgets page to lower the learning curve… that would be a big win.

        • doughamlin 2:58 pm on August 26, 2013 Permalink | Log in to Reply

          To your first point, I would think for text blocks we would keep some sort of style drop-down a la TinyMCE, but instead of paragraph, H1, H2, etc. we could list theme-defined styles.

          • Matt McLaughlin 3:32 pm on August 26, 2013 Permalink | Log in to Reply

            My concern is that conceptually, styling text is different than inserting. For someone used to styling text, they would go to that drop-down first. If “Code” and “Quote” are in the Content Block area instead, that ‘s confusing.

            But, and this is an important distinction I think, some of the text styling we’re talking about here is fundamentally different from other text styling in that it has associated meta-data. Quote has a quote author. Code might have a language specified in metadata. One can imagine other similar style/blocks with metadata for something like hover help text – styling indicates that the help text exists and the help text is metadata for the word(s) being defined.

            Essentially what we’re talking about is a hybrid of a style and a Content Block. I can imagine a UI where, for some reserved styles, when you chose the style from the style drop down it pops up a modal that allows you to input the meta-data.

            On the other hand we have an example of styling that doesn’t live in the styling menu in links. That’s already a “Content Block” that applies style to text as well as metadata.

            I’m not sure I have a solution here, just want to bring up that the relationship between styles and content blocks needs to be clear.

            • acsearles 2:01 pm on August 27, 2013 Permalink

              Another interesting example that I might have missed us talking about is lists. Would that live in the Content Block area or would it be added. There’s meta data that can be associated and changed on a whim if needed.

            • Mel Choyce 2:28 pm on August 27, 2013 Permalink

              You have a good point, and it’s something we’ll have to make sure to test going forward. I’d like to keep elements that are strictly text formatting in the format bar, and items with meta-data in content blocks, but will our users understand that distinction? Thanks for calling this out.

        • acsearles 2:04 pm on August 27, 2013 Permalink | Log in to Reply

          to 5) It’s out of scope, I know, but would it be a possibility to add widgets to a post/page in the future. If the UIs are the same wouldn’t it make sense to add in a widget as a block? Widgets could be used interchangeably in that way.

          • Mel Choyce 2:04 pm on August 28, 2013 Permalink | Log in to Reply

            Anything’s possible in the future, but for now we need to focus on getting a really tight product out. Widgets in posts/pages adds an extra layer of complexity that we’re not going to tackle in v1.

      • ckluis 11:57 am on August 26, 2013 Permalink | Log in to Reply

        Widget Block.

        If you are going to have format blocks It offers the ability to have a “widget block” which could be tossed directly into the page.

        From there – click a button select the widget and BOOM! custom design.

        • Matt McLaughlin 2:30 pm on August 26, 2013 Permalink | Log in to Reply

          That will work as a temporary band-aid, but it’s not a long term solution. If plugin A creates a Map widget and plugin B creates a Map Content Block, that’s a piss poor experience for the user trying to manage both concepts.

          The ideal is that widgets that can work in a page be able to declare themselves as Content Blocks in their own right.

          And the long term goal is to erase the semantic difference between “Widgets” and “Content Blocks” both of which on a conceptual level are parts of a web page that have specific types of content in them.

        • Mel Choyce 2:29 pm on August 27, 2013 Permalink | Log in to Reply

          I’m going to go ahead and veto this for now, because I feel like it’s something the widget group could explore. @shaunandrews, thoughts?

          • ckluis 11:47 am on August 28, 2013 Permalink | Log in to Reply

            If widgets become content blocks and content blocks are able to be selected as part of a page template, as well as, within the page content – it would be the best solution to both problems.

      • acsearles 2:24 pm on August 27, 2013 Permalink | Log in to Reply

        if Quote and Code than Lists?

        • Mel Choyce 2:13 pm on August 28, 2013 Permalink | Log in to Reply

          Quote and code can have associated metadata — quotes have authors and sources (interview, speech, book, movie, etc.), while code can also have a source or a language (and wouldn’t it be fun if themes could style code with different syntax highlighting based on the language included?). Lists, however, are definitely text formatting.

    • paaljoachim 1:23 pm on August 26, 2013 Permalink | Log in to Reply

      Format Blocks:
      A Box – background color, curve, border, etc. Other content inside.
      A menu – add a menu anywhere and dialog box opens to a drag&drop of menu structure.
      A Post Category listing – List categories and certain number of posts.
      A Html 5 grid/table.

      For additional blocks check out Visual Composer content blocks: http://demo.wpbakery.com/?theme=visual-composer.
      Do also take a look at themify Page Builder: http://themify.me/
      Download one of their free themes and check out how the Page Builder works on the Back and Front end.

      • ckluis 2:01 pm on August 26, 2013 Permalink | Log in to Reply

        @paaljoachim for the record a widget block would handle the menu & post category listings

      • Matt McLaughlin 3:36 pm on August 26, 2013 Permalink | Log in to Reply

        Those concepts are great for building, but its only a few key pages that are “Built”. The majority of our content is “Illustrated”. That is, the narrative content is the base and different content blocks are inserted inline in that text to illustrate specific parts of the narrative.

        Writing the text then illustrating it with media, etc. is a very standard workflow that absolutely needs to be supported.

      • Paal Joachim Romdahl 8:24 am on August 31, 2013 Permalink | Log in to Reply

        Regarding the Themify Page Builder. Check out their documentation on their modules and the options they contain. http://themify.me/docs/builder
        One question arises…. With blocks how will we reuse the content of a post or page in another post/page? (Today we can select all of the content copy and paste it into a new post/page.)

    • doughamlin 2:53 pm on August 26, 2013 Permalink | Log in to Reply

      What are pros/cons of making tweet and other third-party embeds their own embed type? Seems like that makes more sense for a custom block type added via plug-in. Otherwise where do we draw the line between which third-party services are included and which are not?

      Do we want an IFRAME block (mostly for users who need to be guided as much as possible when using snippets of code)?

      • Matt McLaughlin 3:12 pm on August 26, 2013 Permalink | Log in to Reply

        The thing I’m most afraid of is a difficult to navigate profusion of plugin+theme created Content Blocks. One way to avoid that is to have sensible umbrella Content Blocks within which other Content Blocks could live. It seems like Tweet (and FB, Pinterest, etc. etc.) should all live in a Social Media Content block. It would make sense to have 1 or 2 – maybe FB and Twitter – available from day one as an example to plugin creators of UI for integrating into the Social Media Content Block.

        • acsearles 2:14 pm on August 27, 2013 Permalink | Log in to Reply

          Could we allow plugins to add lesser known Social Networks into the mix within that content block? Would keep things clear when trying to add new blocks.

      • Mel Choyce 2:56 pm on August 27, 2013 Permalink | Log in to Reply

        We already support them in core. Would be nice to expose these services somehow. For example, letting people know when they can add a link from youtube, vimeo, wordpress.tv, etc. when they go to add a video. Depending on how much we want to support social embeds moving forward, we could create a social tab, or just a social block with a couple different services to chose from. Lots of different ideas we could explore. :)

    • Michael Arestad 6:57 pm on August 26, 2013 Permalink | Log in to Reply

      Riffing on the mockups @melchoyce created, I put together some mockups and bare minimum use cases for custom content blocks. Custom content block functionality would make it extremely easy to put together things like Twitter, iframe, or maps blocks without the use of plugins. I imagine this might be out of scope for the project, but I think custom block functionality will add value down the line.

      http://michaelarestad.com/ceux/custom-blocks/

      • Ipstenu (Mika Epstein) 7:56 pm on August 26, 2013 Permalink | Log in to Reply

        Suggestion: ‘Add Block’ makes me think “Add a block to my post!” I think ‘Create New Block’ would be better, though I wonder if this is something that most users would use (or rather: use well). Having them add code in a post-edit section feels like a dangerous idea. Restricting it to plugins/functions would be safer, and prevent people from shooting themselves in the foot :)

        • Michael Arestad 8:14 pm on August 26, 2013 Permalink | Log in to Reply

          ‘Create New Block’ is definitely clearer.

          Using it well is a valid concern. My hope is that most users would likely ignore it or use it as a quick fix for adding content like a map. Realistically, however, there are any number of ways users could shoot themselves in the foot with custom code.

          I’m foreseeing it more as a plugin with a setting enabling the admin to lock/unlock the block creation functionality. It could be accompanied by a link to a recipe library of well-written custom blocks that users could copy/paste/tweak.

      • acsearles 2:22 pm on August 27, 2013 Permalink | Log in to Reply

        Would that created block be site wide after creating it? It seems like a function like that would need to be hidden somewhere in the appearance section. Once created there it could be used anywhere. Of course that than leeds me to think that it would be better merged with the widgets area.

    • acsearles 2:27 pm on August 27, 2013 Permalink | Log in to Reply

      I have a bigger question about the action of adding a new content block. What happens if I write my post and then decide to add an image in the middle of the text? As it stands now, I would assume that inserting a content block would only be after the last on you created. This assumes a very liner post creation process. I guess copying and pasting isn’t to difficult but it would be nice to have an option to separate a “Text” content block into pieces.

    • DavidHickox 2:38 pm on August 27, 2013 Permalink | Log in to Reply

      I keep seeing mention of adding columns as a text formatting option. I see how platforms like squarespace are using columns, and how that seems like a nice bell or whistle to add, but I don’t understand how that’s practical for WP content. In squarespace (and presumably the like), you’re using columns to lay out the page. In WP, this is primarily done through the theme layout and sidebar widgets.

      Can you give me some idea of how columns might reasonably be used to create content for WordPress? It seems like adding this type of layout-based formatting is a step backwards toward the WYSIWYG/document page model instead of step forward towards fluid content that will be flexible in a variety of formats–from mobile on up to desktop.

    • Erlend Sogge Heggen 10:37 am on August 28, 2013 Permalink | Log in to Reply

      Might I propose this use case challenge to the CEUX developers?

      Try to recreate one of TheVerge’s feature articles in (vanilla) WordPress:
      http://www.theverge.com/2013/8/20/4639110/the-optimist-disney-imagineerings-push-to-bring-alternate-reality

      I think you’ll run into some snags that CEUX should aim to alleviate.

      Bonus challenge, recreate this one (although this is probably custom post format material):
      http://www.theverge.com/2013/8/22/4645454/back-to-school-2013-the-verge-guide

      TheVerge is just one example site of clean yet challenging post formatting. I would suggest you ask all prospective CEUX contributors to find their favorite article with advanced formatting and try think about how the ideal WordPress editor could accommodate such a format.

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

    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.

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