WordPress.org

Make WordPress UI

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Matías Ventura 8:01 pm on September 5, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    Update on THX38 

    Things have been in motion for the themes project. I’ve been working on making the plugin prototype ready for some initial testing. It’s looking like this:

    @shaunandrews ran a test with it, and here’s the video.

    Compared to how bad last test went, it’s pretty cool to see the dramatic effect the “add new theme” block had. (Also helped by the removal of the tabbed interface and extra information.) The user grasped immediately that she was seeing some themes that were already available to her blog, and how she could add more. Fairly straightforward, which is all this test was about.

    Then, of course, as soon as she got to the filters page everything went down again, but we already expected that — still good to have one more test showing the same fundamental problem there.

    Directions

    On last Tuesday’s meeting we discussed the different mockups that were shared so far, apart from the plugin ones.

    It seems we have mostly two directions to try for themes.php. The one the plugin is building (simplify the screens, remove the tabs, but keep a distinction between “your themes” screen and “installing new ones”), and one that merges installing new themes with your currently installed themes on the same screen. As a quick analogy, themes.php as your apps folder, or themes.php as an app store. Another possible outcome is that this screen could render a specific experience for new users alone.

    Shaun is polishing his prototype so we can test it. We argued that it would be hard to know which of these two was the better one, since we would also need to test with people that already have a bunch of themes installed and don’t care much about the discovering new ones part. But having some insight is still good.

    Finally, we talked briefly about multi-screenshot support. The plugin has a proof of concept implementation, showing the screenshots on the expanded view of a theme as a gallery. To test it, add a screenshot-2.png image to the root of a theme (up to five). Also relevant core ticket: #19816.

     

    • Mel Choyce 8:05 pm on September 5, 2013 Permalink | Log in to Reply

      Is it too late to submit some wireframes? I was sketching out some ideas this morning after playing around with your prototype plugin.

      • Mel Choyce 3:56 am on September 6, 2013 Permalink | Log in to Reply

        Here’s my take:

        Theme library: http://cl.ly/image/1m1S0j1L4438
        Add theme: http://cl.ly/image/020O173Q1V3w
        Theme detail page: http://cl.ly/image/3P1S2M1x3g0y

        I can post these up somewhere with explanations/rationalizations if needed.

        • Helen Hou-Sandi 4:27 am on September 6, 2013 Permalink | Log in to Reply

          Love: “theme library” language, having upload via zip right there on the add screen, real-world theme examples (see below, though).

          Concerns: filters separated into tabs – which filters apply to the current view? Also the differently sized featured theme slot and real-world showcase pieces – both of those give me the political heebie-jeebies.

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

            Showcasing real-world theme could potentially be a nightmare. :) But I figured it would be worth playing around with.

            I was trying to mimic .com’s theme showcase filters: http://theme.wordpress.com/ Though those end up being a little different, because the filtering happens in realtime.

            • Helen Hou-Sandi 3:10 pm on September 6, 2013 Permalink

              Gotcha – so a “how many of these are applied” count appears. Interesting.

              I sort of wish we could do super simple filtering (like, a dropdown and pick one thing) but that might be taking things too far down.

            • Mel Choyce 3:22 pm on September 6, 2013 Permalink

              @helen I’ve actually found .org theme filtering to be really useless. :) Wonder if it’s worth totally reconceptualizing and going with something simpler.

            • Matt McLaughlin 3:49 pm on September 6, 2013 Permalink

              Agree that filters are useless. The UI you have below the filters reminds me a lot of the Netflix UI (which is itself imperfect but…)

              What about offering suggestions a la Netflix. That’s essentially filters, but the filtering is automated into (sometimes complex) suggestion categories:
              -Recently Browsed Themes
              -Popular Themes
              -Because you’ve liked themes with a strong female lead… errr… Because you like themes with a responsive layout and bright colors.

              • Because you’ve liked themes with 3 column layouts and a static front page

              Essentially you would pull info from the themes they already have installed and maybe some additional information from themes they chose to preview and create a user profile from which to build personalized suggestion categories.

            • Matías Ventura 5:34 pm on September 6, 2013 Permalink

              Filters are tough. I think most of the concrete ones (columns, features, colors, responsive, etc) can be elegantly incorporated to the search form — if you search for “two columns” we detect that as a tag and show it to you with autocomplete as a recognized term, for instance.

              Then that leaves us with categories (subjects on .com) which we discussed as part of the “app store” paradigm and can be displayed much more prominently (photography, magazine, portfolio, etc).

        • Matías Ventura 5:27 pm on September 6, 2013 Permalink | Log in to Reply

          Awesome, thanks, not late at all! Your mockups apply to the plugin’s current direction of separate screens, so whenever we get to refine that these will be handy.

          I like a lot of the details you introduced, and we can plan for testing some variations soon as well. I’m interested in your rationale for making the current theme so prominent? I think it takes a lot of unnecessary space that doesn’t correlate with its value (theme description, etc) at that stage. Also, from watching the first video test, I got the impression it contributed to the user’s confusion on that screen.

    • Matt McLaughlin 8:37 pm on September 5, 2013 Permalink | Log in to Reply

      Do we have any idea of how often people install a new theme without switching to it? My naive guess is that it’s not too many (but obviously data trumps…)

      I ask because the whole “Add a Theme” is tough to grok for new users. A simple change from “Your Themes” to “Recent Themes” and “Switch Theme” instead of “Add Theme” would abstract away the fact that you’re installing anything.

      I’d also be interested in how many people install themes from .zip versus through the interface. If it’s a sufficiently small number it might be good to tuck that functionality away in an “Advanced” area rather than clutter up the average user’s interface with it.

      • Chris Jean 8:45 pm on September 5, 2013 Permalink | Log in to Reply

        Please keep in mind that not all themes come from wp.org. Without trying to start a debate about paid themes, they do exist and tucking the abiltity to install them away in a low-discovery area would do much to hinder the use of them.

        • Matt McLaughlin 8:52 pm on September 5, 2013 Permalink | Log in to Reply

          I’m all for paid themes, put it’s only inertia that makes paid themes = .zip files. Why not work on making paid themes as easy to access as wp.org themes? Why not make it easy for theme creators to get their themes in front of users right in the interface?

          That could really increase the audience for (and income of) theme creators. It would also provide a much better user experience than the frankly totally hostile experience of having to upload a .zip file.

        • swissspidy 3:09 am on September 6, 2013 Permalink | Log in to Reply

          Maybe we can show the list from http://wordpress.org/themes/commercial/ to highlight some GPL compatible commercial themes?

    • Matt McLaughlin 8:59 pm on September 5, 2013 Permalink | Log in to Reply

      Here’s another naive question. Why do we separate out “Preview” and “Live Preview”? In posts and pages, when I click preview, it shows me how that post or page is actually going to look with my content. For Themes, preview shows you how the layout looks with someone else’s placeholder content. That’s inconsistent.

      I would suggest either a) getting rid of the difference and making everything a “Preview” with the user’s content – downloading the theme invisibly in order to do so and cleaning up the files later. or b) Rename “Live Preview” to just “Preview” and renaming what is now “Preview” to “See Example” or some such.

      • Matías Ventura 5:42 pm on September 6, 2013 Permalink | Log in to Reply

        We discussed this in one of the chats. We do want to make all previews work with your content. If that turns unfeasible we’ll probably call them “live demo” or something like that when you preview a theme you don’t have installed.

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

    • Matt McLaughlin 7:17 pm on September 6, 2013 Permalink | Log in to Reply

      Here’s a mockup of a single page with modals concept that abstracts away the concept of installation and renames “Previews” “More Info” and renames “Live Preview” simply “Preview”:

      http://mattnamclaughlin.wordpress.com/2013/09/06/themes/

  • Mel Choyce 9:16 pm on September 4, 2013 Permalink | Log in to leave a Comment
    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!

    • 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

  • shaunandrews 7:14 pm on September 3, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Widgets, Sept 2 Chat Notes 

    The Widgets team had a short chat yesterday: IRC logs

    bobravo2 shared his research into Joomla’s handling of “widgets:” https://docs.google.com/presentation/d/1u7NXNNNdU7dt1jE1GA4bjnfz9BQymIlavRd2PUHI95E/edit?usp=sharing

    PaalJoachim shared another mockup for a more visual way of managing widgets: http://easywebdesigntutorials.com/wp-content/uploads/Widgets-area.jpg

    Work continues on the four prototypes described in the previous meeting, with the goal of having them all ready for user testing (hopefully) in the next week or so.

    In Attendance:

    • shaunandrews
    • bobbravo2
    • helen
    • PaalJoachim
     

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

    • Jon Brown 8:04 pm on September 3, 2013 Permalink | Log in to Reply

      Great work Shaun! I’m happy you all are looking at other systems for what they do well and poorly.

      I’ve said this elsewhere but I’m a fan of standardized UIs and hence something similar to the media manager and menu manager (even if in general I still am uncomfortable with the revised menu manager).

      However… I love the visualizer mockup and am a far greater fan of the idea of having some sort of visual map to the widget areas.

      One thing I’ve brought up before that concerns me though is how any of these UIs work on mobile and it just occured to me that the widget area map I love has the additional problem that it might change responsively. I, and I assume others, have used widget areas to delineate content that gets reordered via flexbox on a page according to media queries. Asking theme devs to provide widget area maps of breakpoints might be asking a lot, it might make sense, just needs to thought about.

  • Mel Choyce 9:05 pm on September 2, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    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?

  • Till Krüss 3:02 am on August 31, 2013 Permalink | Log in to leave a Comment
    Tags: , , svn   

    MP6 2.0 

    Heya! It’s been again over a month since the last MP6 release and this version comes with some new goodness.

    General

    As usual, we made some UI improvements and fixed a few bugs. Shadows are now fewer and consistent, buttons are flatter, font sizes are more consistent, metaboxes are simpler and lighter and a couple of other improvements. You can see the full changelog here →

    Icons

    We decided on recommendations for custom icons in plugins/themes, you can read more about this and have a look at some examples are in this GitHub repository. Be default MP6 does now hide all images in admin menu item and replaces them with a generic default icon.

    Method C, using a SVG as CSS background image, works thanks to the new JavaScript SVG painter, which re-colors base64 encoded SVGs on the fly. It might not catch all SVG color markup right away, if that’s the case, please post a link your SVG file in the comments.

    Color Schemes

    We bundled this release with 4 additional admin color schemes. You can choose them under “Your Profile”. There are probably more color schemes to come.

    MP6 color schemes as made with SASS, because LESS didn’t handle default variable values. A color scheme can be as simple as this, or it could define a few extra colors for better readability. If you’re making your own color scheme, make sure you include MP6′s core color scheme file.

    Another Note

    If you want to check if MP6 is activated, use the MP6 PHP constant. In CSS use mp6 body class, not admin-color-mp6, I’m looking at you Jetpack.

    MP6 2.0 includes contributions from Joen Asmussen, Mel Choyce, Ben Dunkle, Kelly Dwan and myself.

    And as always, thanks to those of you who tested, reported bugs and contributed ideas and suggestions! Keep them coming!

    The next weekly open meeting in #wordpress-ui will be Monday, September 2 at 18:00 UTC.

     

  • lessbloat 2:47 pm on August 30, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Dashboard Plugin Update 

    Progress is slow but steady in dashboard plugin land. Here’s a recap of our activity for the past week:

    IRC chat notes

    We held our first IRC chat on Tuesday in #wordpress-ui.

    • Rather than remove both RSS widgets from core, we decided to combine them into one.
    • Transform “QuickPress” into “QuickDraft”, putting the focus on drafting new ideas quickly seemed to be a hit.
    • We are going to play with the idea of merging QuickDraft and the “Recent Drafts” widget.
    • Removing the “columns” screen option is likely something we just need to play with. If we can get the implementation right, it could be a nice win I think.
    • We dropped the “QuickLinks” widget idea. This can stay in plugin territory for now.
    • We all liked the idea of rethinking the “Right Now” widget. @joen is going to lead the work on this one.
    • If we get everything else nailed down in time, we may dig into the design for an “Admin activity” widget focussing specifically on collaboration.

    I updated the planning spreadsheet to account for these changes.

    Accomplished this week

    I started work on a patch to combine “Other WordPress News” and “WordPress Blog” over on #19239. Code reviews/thoughts are welcome and much appreciated.

    @joen shared an initial mockup in the IRC chat on Tuesday:

    And has since worked on a couple more based on feedback:

    Which would work something like this:

    Up next

    • We need your help. Especially developers interested in working on this stuff. The QuickDraft widget work looks to be a fun one to work on. Please ping me on IRC if you’re interested.
    • We’ll hold another IRC chat this coming Tuesday at Tuesday, September 3rd, 2:00pm UTC in #wordpress-ui.
    • We’ll be starting up a persistent Skype chat group to discuss all things “dashboard plugin”, ping me if you want in, even if just to lurk. All are welcome.
     

    • Joen Asmussen 3:13 pm on August 30, 2013 Permalink | Log in to Reply

      A couple of quick notes on the mockups. The feedback I mainly focused on in the new mockups were:

      • furthering the “Right Now” tweak, particularly with regards to the “Content” part
      • rethinking the prime real estate area to emphasize pending posts and drafts

      Don’t forget that these are still mockups, subject to change and more importantly: your feedback.

    • Till Krüss 1:43 am on August 31, 2013 Permalink | Log in to Reply

      I’d love to see the recent activity listed in the dashboard!

    • Hassan 10:01 am on August 31, 2013 Permalink | Log in to Reply

      These are some refreshing mockups indeed.

      What is that colored background on the dashboard? Is this part of the mockup?

      Also, I see a stats graph widget in the first screenshot, but not in the others. Please, we need a native stats graph widget… not Jetpack!

      • tobifjellner 10:08 am on August 31, 2013 Permalink | Log in to Reply

        Yes. I’d really like to see some very basic statistics (or rather counters) in the native WP. But nothing that would slow things down or create huge databases of logs.

      • Joen Asmussen 10:19 am on August 31, 2013 Permalink | Log in to Reply

        The background is an idea at the moment, and certainly part of the mockup yes. The hope is to bring some color and fun to the dashboard. We’ll see if it survives until the end :)

        Unfortunately after discussing the proposed stats in IRC during the last opening hours, we won’t be able to offer native stats. We’ll have to make room for 3rd party stats modules. The problem is indeed that it’s too heavy on the servers.

    • tobifjellner 10:14 am on August 31, 2013 Permalink | Log in to Reply

      Is it possible to allow the user to select what information he wants to see in the “right now” widget?
      Either per-user or per site? The default could be “Let WP guess”.
      WP could refresh once a day a pattern variable:
      IF (number of pages + number of posts) number of posts THEN “CMS mode”
      ELSE “Blog mode”.

      • tobifjellner 10:21 am on August 31, 2013 Permalink | Log in to Reply

        Oops. I used the characters “less than” and “greater than”, which means a substantial chunk of my comment was treated as an invalid tag…
        Try again:
        IF (number of pages + number of posts) is less than 10 THEN “Getting started mode”
        ELSEIF double number of pages is greater than number of posts THEN “CMS mode”
        ELSE “Blog mode”.

      • Joen Asmussen 10:21 am on August 31, 2013 Permalink | Log in to Reply

        Can you elaborate on this a little bit? I’m thinking a lot about how the “Right Now” widget can best serve users, and particularly the “Content” section is tricky: on the one hand it’s just a bunch of numbers that I personally find rather useless. On the other hand, I know a bunch of people who use this specific box as shortcuts to various places in the admin.

        What would you like to see?

        • tobifjellner 10:26 am on August 31, 2013 Permalink | Log in to Reply

          Different people want to see different things.
          Say, someone helps with moderation of comments but doesn’t edit posts. Then it could be nice to uncheck some options for what this widget should show.
          And there could be some overall settings:

          • Show everything
          • Getting started
          • CMS mode (More information around pages and page drafts)
          • Blog mode (More information around blog posts and their drafts)

    • tomdryan 7:15 pm on August 31, 2013 Permalink | Log in to Reply

      It would be nice to have a small dashboard widget showing a summary of any available core/plugin updates and move the “Update” section down under the Tools menu. Having Updates under the Dashboard menu choice doesn’t make much sense.

    • Turn On Social 1:17 am on September 1, 2013 Permalink | Log in to Reply

      I’ll join the skype group

  • shaunandrews 9:31 pm on August 28, 2013 Permalink | Log in to leave a Comment
    Tags: media-grid   

    Back at the first 3.8 chat I mentioned… 

    Back at the first 3.8 chat, I mentioned wanting to see a grid layout for the media library. I threw together a few wireframes and wrote out my thoughts. This is still listed as a “feature as a plugin,” but has no lead, and no weekly meeting. I’d like to change that — anyone and everyone who’s interested in improving the layout of the media library: lets meet in #wordpress-ui Friday, August 30 @ 15:00 UTC. If you’re interested in joining (and leading?) this group, please leave a message and try to join us Friday.

     

    • shaunandrews 3:50 pm on August 30, 2013 Permalink | Log in to Reply

      Had a quick chat in IRC today. @helen will be leading. Our initial goal will be to add the grid layout from the media modal, while retaining a table view. Helen will create a barebones plugin structure, and I’ll take a stab and porting the modal view into the page.

      We didn’t discuss our next meeting day/time. I’m not certain if Fridays @ 15:00 UTC is best for all. If you have a preferred time, please let us know.

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

      Great! I look forward to a grid view with 5-6 thumbnail images in a row (responsive?). To get a quick overview. (This might be outside the scope but) I would also like to see user created folders being added to the media library. Having lots of images and being able to place these into user defined folders will help a lot. Or uploading a folder and included media. This can also mean search or view by folder.

      • shaunandrews 7:54 pm on September 2, 2013 Permalink | Log in to Reply

        While I like the idea of adding folders for managing your media, that would outside the scope for this project. We’re really just focusing on bringing the grid view from the media modal over to the Media Library.

  • shaunandrews 7:06 pm on August 28, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Widgets, Widgets, Widgets Meeting – Aug 26, 2013 

    Team Widgets3 held it’s second meeting this past Monday (Aug 26) in #wordpress-ui. Feel free to check out the IRC logs.

    Spurred by the results of our initial survey results, we discussed the benefits and failings of drag-and-drop. The consensus seems to be that drag-and-drop works well for re-ordering existing widgets, but its less than ideal for placing new widgets.

    We reviewed the concepts that have been brought up so far:

    The plan right now is to build a simple prototype of each of these concepts. Keep in mind that a prototype doesn’t have to consist of working code — a clickable wireframe is a perfectly acceptable prototype, and can provide just as much data as a working plugin.

    • shaunandrews will focus on the tabbed concept
    • RichardTape will focus on the customizer concept
    • jtsternberg will focus on the menu-like concept
    • The front-end editing concept will use the plugin as the prototype

    We’ll test each prototype (and the current UI) against the same set of tasks and see which one performs best against our goals. By simply building the prototypes we’ll hopefully learn which ones “feel right” and which ones don’t. And, by performing user tests on each, we’ll hopefully see where each succeeds and fails with regards to our goals.

    This information combined will help us take the next step and either drop a concept, or rethink it and test again. We’ll continue with this process until we have something that feels “right.”

    Or next meeting is schedule for Monday, September 2, 2013 at 20:00 UTC in #wordpress-ui.

    Attendees:

    • shaunandrews
    • melchoyce
    • helen
    • jtsternberg
    • gregpabst
    • RichardTape
    • ipstenu
    • coreymcollins
     

    • gregpabst 3:07 pm on August 29, 2013 Permalink | Log in to Reply

      During this week’s widget meeting I shared screenshots of how Virb handles widgets. Shaun Andrews asked if I could detail the workflow for how Virb handles widget ordering, updating and additions seen below.

      Widgets listing page: http://cl.ly/image/003N0u0e0w29

      • Listing of all active widgets shown in the order they appear on your website.
      • Each widget has an identifying icon on the left along with a title and a short description.
      • When you hover over each item the icon on the left changes to an icon indicating that the item is draggable. The user can click and drag the widget to the position they would like it in.
      • There is a delete icon on the right allowing the user to remove the widget completely.
      • You can click a widget to go to a widget customization screen.
      • There is a button at the top that allows the user to add a new widget.

      Widgets customization view: http://cl.ly/image/2O1I1Q3n0M1x

      • When a users clicks the widget on the widgets main listing page they are taken to a customization page.
      • The customization page features all the unique settings for the widget.
      • “Back to widgets” button – Takes user back to the widgets listing page and does not save.
      • “Save” button – Saves changes but leaves you on the customization page.
      • “Save & Close” button – Saves changes and returns user to widgets listing page.

      Widgets addition modal: http://cl.ly/image/2q222R310r2T

      • When a user click the “New Widget” button on the widget listing page a modal opens with available widgets.
      • Once a widget is chosen the user is taken directly to the new widget’s customization page.

      I think Virb has a good flow and being that drag & drop is only used to order widgets and addition I think this work well paired with a vertical tab menu so you are only edit one “widget area” at a time.

    • shaunandrews 3:06 am on August 31, 2013 Permalink | Log in to Reply

      Here’s the (semi-working) tabbed prototype if anyone would like to play with it: https://github.com/shaunandrews/widgets-widgets-widgets

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

      Here is another mockup of the widgets area:
      http://easywebdesigntutorials.com/wordpress/widget-wordpress-mockups/
      Bottom line: visualizing the widget locations showing the full page. Using drag&drop And a + Add widget button. Multiple Widget Layout areas. Favorite Widgets. Etc.

  • lessbloat 11:37 am on August 26, 2013 Permalink | Log in to leave a Comment
    Tags:   

    DASH, Proposed project scope 

    Last week I introduced the idea of working to improve the default dashboard screen in the WordPress admin.

    Project leads

    I will be leading this project, and I’m excited to announce that @joen will be co-leading with me.

    Meeting time

    We’ll hold our first chat tomorrow at Tuesday, August 27th, 2:00pm UTC in #wordpress-ui. Please come if you’re interested in working on this with us. If you can’t make it, but would like to participate, please make a note in the comments below. We’ll plan on having a chat each Tuesday, and we’ll post a status update each Friday.

    Proposed scope

    My proposal for the dashboard screen redesign includes the following:

    Components that I’ll oversee:

    1) Move “Other WordPress News”, “WordPress Blog”, “Plugins”, an potentially “Incoming links” out of core into a plugin called “Dashboard Extras”.

    2) Remove the “columns” screen option, and instead use responsive CSS to determine the optimal number of columns to display.

    3) Transform “QuickPress” into “QuickDraft” changing the focus from posting to drafting new ideas quickly. Potentially merge the “Recent drafts” widget in with this one. Huge props to @melchoyce for coming up with this idea. Here’s a super rough mockup:

    4) Add a new “Quick Links” dashboard widget offering an easily customizable section for links you use all the time.

    Components that Joen will oversee:

    5) Add a new “Admin Activity” widget to the dashboard. This would allow you to see important logged in activity for your blog.

    6) “Right Now” widget re-imagined. We’ll see what we can do to make the “Right Now” section more insightful, and more comprehensive.

    Joen is already working on a v1 mockup of this stuff which he’ll post in the comments for feedback.

    Planning spreadsheet

    Here’s a link to the planning spreadsheet we’ll use over the course of the project to track our progress. I’ve done my best to break down each component into actionable items (they may change as needed). Each item lists what skills are required. Have a look at the list, and feel free to mention in the comments below which items you’d be interested in working on.

    What are your thoughts?

    Tell us what you think in the comments below.

     

    • Joen Asmussen 11:50 am on August 26, 2013 Permalink | Log in to Reply

      I’m super excited to work with you all to improve the dashboard experience. I’ve been sketching out and mocking up ideas for where to take the Right Now widget, and how it can coexist with a new Activity widget.

      Please consider this mockup for what it is: a rough draft. I find this way of mocking up helps me better feel how the various elements feel like in a cohesive whole. Don’t let that hold you from criticising elements. Nothing is set in stone.

      Right Now / Activity dashboard early mockup

      • In the mockup, “Right Now” is split into three snippets across the top of the screen.
      • The “Activity” part of this mockup is borrowed from Activity Logs, though we have yet to decide which plugin to model after or use.
      • The background flair is an idea for bringing some colors and fun into the dashboard, it would cycle through a couple of bundled lightweight illustrations.
      • Views and Reads are light-weight new statistics for the week.

      Overall we want to keep what’s useful to you: quick deep links to the most recent activity on your blog, hopefully expand upon that right in the dashboard. I look forward to your feedback.

      • Nick Halsey 8:19 pm on August 26, 2013 Permalink | Log in to Reply

        I like the background graphic idea, it reminds me of MS Office 2013′s graphics behind the “ribbon”, but more colorful.

      • paaljoachim 10:02 am on August 27, 2013 Permalink | Log in to Reply

        Very nice and clean Joen! I agree it is nice with a simple background. What about a small arrow next to the question mark. Click the arrow and see a drop down of available panel types and at the bottom of the drop down an add panel option. Draggable panels. Post/category feed panel. Video embed to share a tutorial video. CSS styling.

    • Japh 12:01 pm on August 26, 2013 Permalink | Log in to Reply

      Awesome! Would you mind updating the time with the shortcode so I can see in my local time without breaking my head? ;)

    • Lachlan MacPherson 12:42 pm on August 26, 2013 Permalink | Log in to Reply

      Really love the mock up and the overall direction of the new dashboard.

      It would be awesome if the “Activity” widget was also extendable to plugins so it could list things like “a sale was made” for ecommerce or “a back up was created”

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

      I won’t be able to make that timeslot, but as I’m mostly interested in testing and helping debug, I think that’s okay :) I can follow the summaries and logs, and such.

      @joen – I love that design! One thought to keep in mind is that plugins like Akismet add to the bottom of the right now box, so leaving some room for that, or sneakily moving them out may possibly be needed. I’ll run a scan of the plugins later today and see how many plugins that is. If its only a handful, that’s fine, we can contact them directly, but if its 100 then something will have to be thought up.

      • Joen Asmussen 1:22 pm on August 26, 2013 Permalink | Log in to Reply

        Excellent point, I’ll keep that in mind for the next set of mockup revisions!

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

          Just over 100 plugins are using some variation of “right_now_”

          Most use right_now_content_table_end which is not unexpected.

          • Joen Asmussen 7:23 am on August 28, 2013 Permalink | Log in to Reply

            Yep, if we do go down the route of splitting “Right Now” into smaller nuggets, we can probably find an area on the dash (if not in the current context) to put that plugin hook.

    • John Blackbourn (johnbillion) 1:20 pm on August 26, 2013 Permalink | Log in to Reply

      If an activity log is going to be implemented into core then it needs to be developed separately from the admin dashboard improvement project.

      An activity log is quite a major thing that needs to be planned and architected properly so it’s reliable, scalable and extensible. It’s also something that goes way beyond a dashboard widget.

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

      Hi, Just a few thoughts:
      1. add an option for a widget showing an iframe / stream – this would be good for developers showing their clients different kind of messages and notifications from their own studio.
      2. have the ability to remove widgets for all users from the admin (currently done only by plugin or via the functions file)

      Dan

    • Andrew Nacin 2:03 pm on August 26, 2013 Permalink | Log in to Reply

      Can this meeting be held in #wordpress-ui? Thanks.

    • Andrew Nacin 2:07 pm on August 26, 2013 Permalink | Log in to Reply

      Move “Other WordPress News”, “WordPress Blog”, “Plugins”, an potentially “Incoming links” out of core into a plugin called “Dashboard Extras”.

      Incoming Links should probably be re-imagined because the Google tool it uses is largely broken. But, it is very helpful to see generic pingback attempts to your site (that’s really all it is) and it would be nice if we could come up with our own way of presenting this to users.

      I thought “Plugins” was lame too, and we almost removed it a long while ago, but WP.org analytics showed a lot of activity coming from it. We should aim to make it better versus removing it.

      “Other WordPress News” and “WordPress Blog” should probably be re-imagined into a single combined news widget. I think this is a great way for users to see what is going on; is the only way many users notice beta releases, release announcements, and community initiatives; and drives pretty strong traffic (as in, people use it).

      • lessbloat 3:58 pm on August 26, 2013 Permalink | Log in to Reply

        I get that, but what percentage of users actually find value from these widgets? With millions of installs, there’s no doubt these links produce substantial traffic.

        I guess my question is, if we were designing WordPress from scratch today, would these widgets get the same real-estate as they do now? Would they even be included at all?

        If we’ve got to keep them, then, well… We’ve got to keep them. ;-)

        My preference would be to move them to a plugin where people could continue to use them is they liked.

        If they’ve got to stay, maybe we could:

        • Move “incoming links” into the new “Right Now” section.
        • Keep one RSS widget like you recommend, and combine those 2 feeds into one.
        • Hide the “Plugins” widget by default?

        Thoughts?

        • Brent Logan 6:42 pm on August 26, 2013 Permalink | Log in to Reply

          Please don’t combine items, like putting “incoming links” into “Right Now.” That makes it impossible to hide “incoming links” (broken and useless) while still showing “Right Now” (useful).

    • s3w47m88 4:25 pm on August 26, 2013 Permalink | Log in to Reply

      I’d like to see a Windows 8 Metro approach to the Dashboard Widgets in addition to the responsiveness. One problem my users and I experience is that some Widgets need to stretch wider or smaller than others. Giving them the ability to drag their width as users do with Windows 8′s “Tile’s” maintains the responsiveness without forcing users to “do it our way”.

      • Joen Asmussen 7:42 am on August 27, 2013 Permalink | Log in to Reply

        We’re definitely looking into making the dashboard fully responsive. It sounds like you’d like the ability to set the individual size of dashboard panels, correct? I’m interested in hearing some of the use-cases for that type of customization.

        • paaljoachim 9:32 am on August 27, 2013 Permalink | Log in to Reply

          What about dragging and dropping panels to create one column, two column, three column, layout etc based on what the user wants. So take a panel and drag it next to another to make another column. I am thinking that there could also be a drop down arrow on the top right of a panel to select which panel type to use.

          This could mean having one column as the first row with critical user info. As in how to do something in the dashboard (embeded video etc). Below the one column one could have other multiple panels for instance showing recent activity, recent visits – SEO, other news, RSS post – developer creates a post on his own site which will be spread out to where the developer has also added a grab post/category from url panel in the dashboard. This way the developer can share info with his clients in an easy way.

          But this can be up to the developer creating the site to make it user friendly and informative for the client as the client enters the backend.

          There could be CSS code easily accessible to style the panels.

    • mrwweb 5:22 pm on August 26, 2013 Permalink | Log in to Reply

      +1 on changing QuickPress to QuickDraft (or DraftPress!?). This would take that widget from something I hide in Screen Options to something I’d use every other time I log in.

    • Nick Halsey 8:34 pm on August 26, 2013 Permalink | Log in to Reply

      Looks like a great direction overall. 14:00 UTC is nasty for the western US, but I’ll try to make it. Interested in helping out regardless.

    • @mercime 1:47 am on August 28, 2013 Permalink | Log in to Reply

      +1 “Draft an Idea” to replace QuickPress is a great idea.
      I’ve been removing QuickPress in all installations since it allows posting without categorizing first :-)

  • Mel Choyce 9:45 pm on August 25, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    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.

← Older posts

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