WordPress.org

Make WordPress Design

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 4:58 pm on September 17, 2015 Permalink |  

    Potential UI/UX projects in core 

    It’s not uncommon for both existing and potential contributors to feel like they don’t know what to work on. Let’s try listing a few UI/UX items that have come up on wishlists in this post, both as a temporal call for interested parties and to reference later. If you’re interested or have another frequently-requested item in mind, sound off in the comments or join us in the #design channel in the Make WordPress Slack.

    When changing UX, it’s important to be running user tests and surveys. These can be done lo-fi, such as with index cards or a questionnaire, or as high fidelity as using a functioning plugin and a user testing service. It’s also important to assume that it will take multiple iterations to get there and to avoid becoming too attached to a single approach.

    Publishing UX

    When running user tests for post formats during the 3.6 release cycle, one of the most striking observations was that a majority of users had a hard time locating the Publish button at all. Because it’s typically in the top right, it’s possible it’s not on the screen, and is very disconnected from the general content workflow of writing and then publishing. The most common idea is to put the buttons in the bottom bar of the editor, since it pins and makes sense within a writing flow. There are, as always, other considerations to make, such as post types without an editor or various post statuses (another problem in the current box – you can’t actually have a private draft, because it’s the same field in the database). This project would likely involve multiple approaches, storyboards, mock ups, and lots of user testing through all stages.

    Comment Management Overhaul

    A lot of strides have been and are being made in the Comment API behind the scenes, but we still have a generally dated comment moderation experience, from the list to the edit screen to the moderation screen shown when following a link from notification emails. This is a good project for a team to brainstorm on before attacking: What does a good comment management experience need? How do we accomplish that within WordPress?

    There are also some smaller tasks that could be tackled, such as UI improvements. For instance, right now comments are presented with an interface that is very similar to post editing and without much context. What if comments looked and felt like comments while editing (showing an avatar, a better general layout, etc.)? What kind of contextual information would be helpful to show?

    Small screen flow

    The admin adapts fairly well to small screens. There are some places where what’s critical or important on a given screen is overwhelmed by other items. Some particular offenders are the theme/plugin/media filters, filtering and navigation on content lists, and the additional buttons that often appear next to the “Add Media” button above the editor. The content in those areas stacks up and pushes down the primary content below, sometimes completely off the initial screen. We want UI to direct user focus to what they want or need to be doing, and these particular visual components are major offenders against that.

    Tickets: #32558 for the filter bar, #29989 for the media and related buttons.

     
    • Tom Ryan 6:13 pm on September 17, 2015 Permalink | Log in to Reply

      Much of WordPress’ future potential growth will come from new users and the current interface is unnecessarily arcane in many areas (It’s not anyone’s fault, it’s just evolved that way). Here are a few UX areas that could use some help in WP:

      1. Menu Hierarchy – Need a top to bottom review of menu consistency throughout WordPress. The original menu structure was developed when WordPress was mainly a blogging platform. It’s very cumbersome when you are trying to develop a full blown site in WP, rather than just publishing a blog post.

      2. Nested Menuing System – The current menu system breaks down after you get more than one level deep. Then yous have the Customizer, which has a completely different menuing system. This has lead developers to create their own menu systems, which makes the WP UX inconsistent from theme to theme. WordPress needs to provide theme and plug in developers a way to do all of their interface within the WP menu system, rather than having to create their own.

      3. Menu Consistency – This is a related to #2 above. WP has the top menu bar, the admin menus and the Customizer menus, which all feel like they are completely different products. Many of the settings overlap and make no sense to end users.

      4. Integrate “Page Preview” Into the Interface — Currently the Customizer is essentially the “page preview” feature of WP.. Rather than being integral to the main interface, it jolts you into a completely different interface, which overlaps in functionality with other areas of WP. There are ways to integrate the Customizer functionality into the main interface so that it WP becomes a more cohesive product.

      5. Settings Organization — Ensure better consistency of how to adjust settings. Sometimes plugin developers will put their settings under Settings, sometimes it will be in a new top level menu. Sometimes you can get to settings from the plug ins page, sometimes you can’t. Many of the WP core settings have the same issues. There should be a more clear delineation between standard settings and setting added by plug ins. It often hard to find the settings you wan to change because the Settings menu is so large and not organized into core and plug in settings.

      Currently, using WP to create and manage web sites is a “less than delightful experience” The changes above would really go a long way to clear up some of the cruft and make the WP interface easier to work with.

      I’m not a developer, but I would be happy to help with the process in any way I can.

      • allstar 4:10 pm on September 18, 2015 Permalink | Log in to Reply

        Just as you have inactive widgets it would be nice to have inactive menu items as well. There is some overlap when you start to look at Menus and Widgets, both have locations, active, inactive and order. Differences being static-sih individual menu items versus a widget’s instance
        functionality and linear widgets versus multidimensional menus.

        I’m stating something I see in an effort to be constructive. I know a merge would be difficult and an overlap of functionality complicated but it offers a possibility of having similar interfaces and for new people less learning can only be good.

      • dlouwe 12:25 am on September 19, 2015 Permalink | Log in to Reply

        A personal pain point somewhat related to #2 is the method for removing menu items. One or two items are simple to remove, but trying to remove 5+ is a tedious nightmare. A way to bulk delete menu items would save so many headaches.

        Also in regards to #5, this is likely something that would need to be put into the plugin submission guidelines and enforced by the plugin review team, rather than something implemented in core. I can’t imagine a good way to prevent plugins from modifying the admin menu however they please, so this kind of organization would need to happen at the community level.

    • raulalgo 6:36 pm on September 17, 2015 Permalink | Log in to Reply

      Hi,

      I’m fairly new here but I’ve been willing to collaborate for a while. I’m UX designer with big experience on mobile and long time user of WordPress.

      I’ll be happy to give a go at some elements on that list.

      Is there any priority among them?

      • sanit.tmg 9:58 am on September 19, 2015 Permalink | Log in to Reply

        hello sir… i am an IT student.. and i wanna learn about this word press but iv’e tried all videos, tutorials and much more but haven’t got my answers… sir will you plzz answer my questions sirr?

    • Cătălin Dogaru 7:12 pm on September 17, 2015 Permalink | Log in to Reply

      Hey,

      I would be interested in working on #22058 (alternative UI for the Background Image section in the Customizer) and #23120 (provide visual feedback on saving widgets). Some progress has already been made, it would be interesting to take things further.

    • Stephen Rider 1:42 pm on September 18, 2015 Permalink | Log in to Reply

      In response to Tom Ryan:
      You have a lot of good ideas, but I would have to strongly disagree with separating plugin settings from Core settings. I got involved with WP back around v2 or so, and at that time there was a widely accepted idea that plugin settings should all go under the Plugins menu. It was a huge mess. A few people (myself included) began championing the idea that plugins should me integrated cleanly. The best interface for a plugin is to be made in a way that you might not realize it isn’t Core.

      I totally agree with you that plugins should consistently link to their own Settings screens (if they exist) from their entry in the Plugins page. I believe I wrote the first tutorial about how to do that back in 2008: http://striderweb.com/nerdaphernalia/2008/06/wp-use-action-links/

      It would be nice to have some consistency, but at the same time I would hate to bind developers’ hands. It’s more a question of education.

      • Tom Ryan 5:37 pm on September 18, 2015 Permalink | Log in to Reply

        Thanks for your feed back Stephen!

        With respect to separating out plugin-added options, here is the issue I’m trying to address: The WP interface can look VERY different from site to site, depending on which plugins are installed. This makes the WP interface non-standardized and hard to find the things you use on a regular basis. I can understand your point about making the plugin integration seamless, but often settings are all over the place for no good reason. I have one theme that requires 5 other plugins and my top level menu is a mess of options I never use.

        Here is an example of a very a simple interface tweak that could help quite a bit: List all the core Settings items first, then a line, then list all the additional plugin settings below that line. That way, it’s still on the same menu, but you can always find the core WP items in the same place.

        By the way, many of the plugins I use should not be top level item; once they are set up, I only need to access them occasionally. It would be better if they were more like the themes page where you could see icons, for the installed plugins and click on them to configure them.. Maybe to have the best of both worlds, you could include a checkbox to enable the user to add a plug in to the top level menus. That would keep the top level WP menu clean by default, but allow users to include it in the top WP menu if they need to access it frequently.

    • Morten Rand-Hendriksen 4:11 pm on September 18, 2015 Permalink | Log in to Reply

      There’s also the ImageFlow project which looks to change the experience of adding and editing images.

    • FolioVision 4:53 pm on September 18, 2015 Permalink | Log in to Reply

      Hi Helen,

      Thanks for the suggestions. We’ve written a plugin for front end comment moderation (and now caching) called Thoughtful Comments. It works with all themes. We’d be happy to help add front end moderation to WordPress. I’ll take a look at backend moderation and see what might might be improved there.

      Hi Tom/Stephen,

      Plugin settings really must be put back into the Settings Menu and the Tools Menu. Each plugin demanding a top level menu item for itself is totally out of control and make most client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where necessary) a Tools entry.

      Forcing plugins to link to their own setting pages would be very helpful. I’d love to bind developers hands as consistency is the hallmark of great UI (think Mac OS 7 to 9 and Apple OS X vs Linux/Windows). Adding a requirement to consistently link to setting pages would make me very happy.

      Alec Kinnear

      • Tom Ryan 5:44 pm on September 18, 2015 Permalink | Log in to Reply

        > Each plugin demanding a top level menu item for itself is totally out of control and make most
        > client sites look almost unusable now. 90% of plugins can get by with a Settings entry and (where
        > necessary) a Tools entry.

        Thanks Alec, I agree with you 100%!

        If you think it looks bad as WP developer, can you imagine what it’s like for someone trying to come up to speed on WP for the first time? The WP learning curve is way to steep and long at this point.

        I’m hoping that the UX group will be able to address many of these issues to make WP a more accessible and easy/fun to use product.

    • fredhead 9:56 pm on September 21, 2015 Permalink | Log in to Reply

      I’d be interested to participate in the Publishing UX exercise. From my experience, in most cases simply floating the Publish button at the top as I scroll down the add/edit screen would work wonders for me. I hate having to always scroll up and up just to save my edits.

      FWIW, as a user and someone who sets up WP sites for other people, I totally agree with the discussion about adding flexibility to the WP core navigation as well as the need to provide more guidance about using Settings and Tools as the default location for plugin settings and functionality. The number of top level menus for lightly used plugins is way out of control in my experience and view.

    • th23 8:18 am on September 22, 2015 Permalink | Log in to Reply

      Really great to see, that the team is always looking how to (further) improve the user experience and interface :-)

      I just yesterday submitted an idea on how to optimize the flow creating / editing a gallery – based on some feedback/ observation of a few friends using and struggeling a bit with finding their way around:
      https://core.trac.wordpress.org/ticket/33950

      In case somebody can point me to what to do next, I am happy to contribute!

  • lessbloat 2:24 pm on July 31, 2015 Permalink |  

    Calling all designers 

    With a location and date officially announced for WordCamp US (Philadelphia, December 4th–6th), it’s time to start thinking about design for the event.

    We’d like to include the entire WP community in this call for designers. If you’re interested, please continue reading:

    Concept proposals

    For those designers interested, we’d like to see a rough design proposal:

    Deliverables
    We’d like to see:

    1. Branding concept (logo, colors, typography for the event)
    2. Attendee badge design concept (dimensions: 4in x 3in)

    NOTE: Please free to submit designs in whatever fidelity you have time for (from sketches to pixel perfect mockups).

    Deadline for proposals
    Aug 10, Noon (PDT)

    Submissions
    To submit a proposal, please ping me privately on Slack (lessbloat is my username) including a link to your proposed design concepts.

    Questions

    When will I hear back?
    We’d like to get started relatively quickly. Please give us a week or so to sort through proposals after the the 10th. Note: I will reply to everyone who submits a proposal (whether you’re selected or not).

    What specific things would I be responsible for designing?
    If you’re selected, you’d design the following:

    • Branding
    • Badges
    • Signage (to be used on location)
    • Website design
    • T-shirts/Swag

    Will I be compensated for my work?
    Unlike most other conferences that charge hundreds or even thousands of dollars to attend, WordCamps tries very hard to keep attendance fees at a bare minimum. We do this by relying heavily on our amazing volunteers. That said, while you won’t receive financial compensation, this is a high profile event, and your work will be seen by everyone in attendance.

    Anything else I should consider?
    It might be helpful to check out the WordPress.org design handbook, specifically the sections on identity, colors, and typography.

    Additional questions?
    Please feel free to ask additional questions in the comments below, in the #design Slack channel, or via a private ping to me in Slack (lessbloat). Thanks!

     
    • lessbloat 9:01 pm on July 31, 2015 Permalink | Log in to Reply

      Two follow up answers from pings I received:

      1) Someone asked about the following sentence:

      That said, while you won’t receive financial compensation, this is a high profile event, and your work will be seen by everyone in attendance.

      Please know that I did not mean this in a “you won’t get paid, but you can add it to your portfolio” sort of way. Though now that I re-read it, I can see how it would come across that way, especially in my use of the words “high profile”. I feel bad. That sort of sentiment is gross.

      To clarify, what I meant to say was, this is volunteer work. The design work done for most WordCamps is done by volunteers. Since it’s volunteer work, naturally you won’t get paid. That said, if you have the time, and inclination to work on this, it should be a pretty great event, and plenty of people in attendance will benefit from your work.

      2) Someone asked if the could apply by submitting a portfolio site, instead of spending time to create proposal/concept designs (rather than spend time on a design with the chance that they might not be selected).

      Yep, that works too. If you’re interested in applying, and you’ve got a strong design portfolio that you feel represents your work well, please feel free to just shoot me a link to it.

      I hope that clears these things up. :-) Let me know if you have any additional questions or concerns. Thanks!

  • Stephane Daury (stephdau) 6:13 pm on June 25, 2015 Permalink |  

    Core UI Chat, June 25th 2015, WC EU edition 

    Today’s chat did not really happen, for the best of reasons, since most of the regular contributors are currently making their way to the massive WordCamp Europe 2015. The good news is that many Core UI related chats are expected to take place there, as many gather in person.

    Since I ran the meeting for similar reasons last week, I figured I’d post a quick summary of what happened since then in Core UI Land instead.

    Tickets with notable UI-related commits

    #28820, #32213, #32015, #32325, #21845, #30157, #31336, and #31216

    Some active tickets

    • #32346 is being discussed
    • #29906 is alive and well, nearing commit state (needs testing)
    • #32395 got a brand new patch, needs testing
    • #16434 is seeing some patches and chatter
    • #30902 is on fire!
    • #19257 was set to fixed; #30729 got punted to a future release, and #31240 looks like it might as well

    Looking stalled, could use some help, with beta 1 approaching

    #31654, #32398, #26550, #29958, #32152, #32493, #29158, #30154, and #31655

    Main recommendations for commits this week

    I’ve chatted with the accessibility group about a series of List Table and accessibility ticket they have, and I’ve recommended they tag them as commit ASAP. They are all, IMHO, in good shape to be considered. They’ve also clearly been abundantly discussed, iterated upon, etc. Some commit-time tweaks might be required, but nothing I’d consider related to the actual functionality.

     
  • Kelly Dwan 7:04 pm on May 28, 2015 Permalink |
    Tags:   

    Dashicons Returned!

    We’re meeting every Thursday at 18:30 UTC (2:30 ET) in #design-dashicons, after the #design meeting. As a reminder, our goal is to switch Dashicons to a collection of SVGs, rather than a font.

    Slack Archive

    We discussed

    To Do

    • Continue working on the feature plugin, starting with identifying code for all current icons
    • Write up the announcement. We have an outline, any help writing the full post in the next week would be much appreciated. Otherwise we might just post an outline :)

    As always, check in to #design-dashicons if you want to help out! We’ll meet again Thursday, June 6, 2015 14:30 UTC-4

     
  • designsimply 4:13 pm on May 27, 2015 Permalink |
    Tags: , ,   

    User Testing for Customizer Menus 

    Following are testing tasks/questions, my initial walkthrough of the plugin at this stage, and some feedback with blockers separated from nitpicks. I will post testing videos in the comments as they come in.

    Please reply to each comment with the biggest takeaway you learn from the video if you watch any of them. Thank you!

    Tasks

    Intro: You have a blog about travel, and you would like to setup a custom menu for your blog.

    1. Log in with username ******* and password *******
    2. Go to Appearance > Customize and then click on Menus.
    3. Add a new menu named “Main Menu.”
    4. Add all of the pages already saved on the site to the menu.
    5. Reverse the order of the menu items.
    6. Set the “Main Menu” as the primary menu so it shows in the live preview.
    7. Add the “Travel” category to the menu.
    8. Move “Travel” so it is a child of the first item in the list.
    9. Add a link to Twitter and make it a submenu item next to Travel.
    10. Move Travel and Twitter from the first item so they are submenu items under the About page. Save changes.
    11. Create a new menu for social media with at least one social media link in it and add it to the sidebar.
    12. There is a way to use advanced menu settings to enable descriptions for menu items. Try to find it and add a description for the “About” page.

    Questions

    • Would you recommend this feature to a friend who needs to create menus on their website?
    • Have you used WordPress before? If yes, have you used the Menus feature inside the WordPress dashboard before?

    (More …)

     
    • designsimply 7:09 pm on May 27, 2015 Permalink | Log in to Reply

      Test 1

      If you watch the video, please post a comment with your takeaways as a reply here. Thank you!

      JavaScript required to play Core Customizer Menus 001.

    • designsimply 2:12 am on May 31, 2015 Permalink | Log in to Reply

      Discussed questions/nitpicks in Slack.

      Resulting tickets raised in GitHub:

      1. 52 – Make item ordering based on usage instead of a random order
      2. 53 – Help people who try to add menu items before they have created content
      3. 54 – Shorten “Currently set to:” to “Current:”
      4. 55 – Use a gear icon for advanced settings toggle instead of the screen options icon
      5. 56 – Unclutter the “Reorder” view by using more streamlined arrow icons
      6. 57 – Cannot delete new menus previously set to a menu location
      7. 58 – Duplicate “Home” page items could be confusing
      8. 59 – Update the menus panel description to make it more clear menus are for already-published content
    • designsimply 11:13 pm on June 22, 2015 Permalink | Log in to Reply

      Test 2 (done May 27, posting it here for reference)

      JavaScript required to play Core Customizer Menus 002.

      • designsimply 11:16 pm on June 22, 2015 Permalink | Log in to Reply

        Notes from https://wordpress.slack.com/archives/core-customize/p1434420874000649

        • She misses the “+ Add Items” completely when asked to add pages to the menu. Missing the step to add pages kind of messes up the rest of the test. :)
        • Preview looks fast/good!
        • There are some weird cursor artifacts that I haven’t seen before (might have just been a video/recording/playback problem, but should watch out for more).
        • The red outline as a notice that you need to fill in the “Link Text” field worked nicely.
        • She doesn’t seem to have any trouble creating submenus, very cool.
        • Testing note: I might need to clarify the last step to specify they should look for advanced menu settings within the menus panel (if that’s not too big of a hint).
    • designsimply 11:24 am on June 23, 2015 Permalink | Log in to Reply

      Test 3
      (WP 4.3-alpha-32909 + 32678.2.diff)

      JavaScript required to play Core Customizer Menus 003.

      If you take the time to watch this user testing video, thank you! Please reply below with one or two of the most important takeaways you found while watching the video.

      Testing note: I’ve figured out that sometimes a tester from usertesting.com starts a test and then stops in the middle (for whatever reason). If that happens, then a main menu is already present when it shouldn’t be as the next tester starts. I’m not sure what to do about that except to say it’s just something that happens and something to be aware of when evaluating tests, and it happened in this test.

      • Konstantin Obenland 12:22 pm on June 23, 2015 Permalink | Log in to Reply

        The bug you opened about duplicate menu names is important. Loosing a created menu that way is bad.

        When she tried to find the twitter link that first time, I kept thinking that the average user probably differentiates between a “common” link, and posts/pages on their site. I’m pretty sure they don’t realize that the whole menu experience is just a fancy way to create links to their own posts/pages.

        Overall it seems like she felt comfortable with the feature. I think if you take away instructions and have users that are on a mission, this will be really fluid and easy to manage.

        Not once was it mentioned that the left sidebar was too small or it felt cramped, either.

      • Stephen Edgar 12:52 pm on June 23, 2015 Permalink | Log in to Reply

        Moving on past the “main menu” already existed stuff…

        • At the 10:20 mark user is searching for the next 40 seconds a way to close the add new posts/pages/category etc panel, cannot find it, gives up by clicking `reorder` and that closes the panel

        • At 12:50, again looking for some type of “close” action out of the current view and clicks the `x` on the Travel Category and deletes this menu item

        • At 13:10, looking for the “close” panel option again, cannot find, clicks “add item” to close the panel

        • The _arrow directional_ reorder navigation does not appear intuitive to the user, resorts to exiting and using drag-n-drop

        • At 15:15 clicks _Save & Publish_, and the reorder arrow navigation action/option stays enabled, shouldn’t this reorder action/option now be closed/finished because the user has _saved and published_?

        • At 16:05 a new menu is about to be created, but for the previous ~30 seconds user clicked various items but essentially no changes were made to the existing “main menu” though the button is displaying as “save & publish”, shouldn’t this remain in the “saved” state as no changes have been made to the menu that need saving?

        • At 17:10 user looks to expand the “about” item to add a description but due to the issue above at 15:15 the “reorder” action/option is still in play so the intuitiveness of clicking something to expand it is missing, at 17:26 user clicks “done” that closes the “reorder” action/option, at 18:30 user ends up where they should have at 17:10, clicks “about” and it expands as per what was originally expected.

    • designsimply 11:27 pm on June 23, 2015 Permalink | Log in to Reply

      Test 4
      (WP 4.3-alpha-32909 + 32678.2.diff)

      JavaScript required to play Core Customizer Menus 004.

      If you take the time to watch this user testing video, thank you!

      Please reply to this comment with the most important takeaways you found after watching the video.

      • Nick Halsey 10:49 pm on June 27, 2015 Permalink | Log in to Reply

        Notes:

        • Redundancy is important – if one thing fails (ex. drag & drop), it’s good that we have an alternate approach available (reorder buttons) – taking inspiration from structural engineering here
        • If we have a bug, the user will think they’re doing something wrong (ex. preview fails to load changes) – we need to be very careful with this
        • We should probably debounce the partial refresh a bit when editing ex. a menu item title or description. Constant refreshing while typing gets pretty distracting
        • Our screen options approach here seemed much easier to find for the tester than they are in the admin, based on several user tests that have been done in the past
        • Overall the tester seemed to enjoy the experience and was able to find things with some clicking around. Generally had a positive reaction once they found something, and only really got “stuck” when running into bugs with the preview and drag & drop
    • Stephen Edgar 1:13 am on June 24, 2015 Permalink | Log in to Reply

      • 6:53 “This is a very complicated reversing method” Initially tried to drag’n’drop to reorder the menu items but couldn’t, also tester notes would prefer drag’n’drop, throughout the remainder of the this users testing tester never tries again to use drag’n’drop to reorder menu items

      Some similarity with the reorder vs drag’n’drop notes I added for the previous test

  • Helen Hou-Sandi 6:43 pm on May 11, 2015 Permalink  

    I’ll be kicking off weekly core UI meetings again, starting this Thursday, May 14, 2015 13:00 UTC-4 in the #design Slack channel.

     
  • Siobhan 5:21 pm on April 16, 2015 Permalink
    Tags:   

    Just a reminder that the image flow meeting is now on Thursday at 20:00 UTC. That’s:

    • 21:00 London
    • 16:00 EST
    • 13:00 PST
     
  • Hugo Baeta 7:59 pm on April 5, 2015 Permalink
    Tags: 4.2, colors   

    Default Admin Color Scheme Update 

    Earlier in the 4.2 cycle, I opened a ticket proposing changes to the default color scheme for wp-admin. After much consideration and a few changes, it is being brought into core. I’d like to explain the changes made, and the reason for them in this post!

    This started as part of an exercise to document the colors used by core for the Design Handbook (work in progress). My instinct to iterate on the colors and try to make them more harmonious kicked in, and so I ran an experiment that resulted in this:

    color-changes-chart

    Here’s a breakdown of HEX color changes:

    Grays
    Old New
    #111111 #191e23
    #222222 #23282d
    #333333 #32373c
    #4b4b4b #464b50
    #888888 #82878c
    #aaaaaa #a0a5aa
    #bbbbbb #b4b9be
    Blues
    Old New
    #0074a2 #0073aa
    #2ea2cc #00a0d2
    #45bbe6 #00b9eb

    In essence, the grays were given a slight blue hue, and the for the blues I removed the red channel almost completely, for a purer blue. In both cases, I attempted to keep the value of the colors (lightness/darkness), so the change would be as seamless as possible, while giving the admin a new sense of refinement and identity.

    @iammattthomas commented on the ticket, summarizing this change quite eloquently:

    My subjective feeling is that the shift in colors is so slight, it doesn’t really change the feeling we intended to convey with the original MP6 colors. If anything, it makes the grays look more intentional, a color palette designed to work harmoniously rather than pairing a signature shade of blue with a lot of neutral grays.

     

    And here’s a side-by-side comparison of the old (left) and new (right) colors in use on the admin:

    color-wpadmin

    I believe this updated color scheme can still be iterated upon, specially regarding concerns of contrast and accessibility (that weren’t addressed in this round, but are certainly a priority for the next release cycle).

    I’d love to hear your thoughts!

     
  • Siobhan 5:52 pm on April 2, 2015 Permalink
    Tags:   

    Image Flow Update 2nd April 

    Thanks everyone who attended the meeting this week. Note that in future the meetings will be at 16:30 UTC, i.e. normal time for everyone now that daylight savings has happened.

    Here’s what we discussed:

    1. Feedback – there’s a lot of feedback scattered around which we need to get into one place so we can make sure it’s properly addressed. We have a Google Doc here which we’ll consolidate it into.
    2. @teamadesign has tried an edited flow with the metadata first. It’s available for testing should anyone want to.
    3. Once @wonderboymusic is caught up on where we are, we’ll start ploughing forward with the plugin.

    Actions

    • @siobhan to pull together feedback from UT videos, make/ui post, and boren notes
    • @teamadesign to review feedback in Slack channel
     
  • Kelly Dwan 7:09 pm on March 19, 2015 Permalink
    Tags:   

    Dashicons 3/19 Notes 

    Slack Archive

    We Discussed

    To Do

    Next week, we’ll have a discussion to confirm what approach we should take, and how to get there. If you want to join in, that’ll be March 26th, at 18:00 UTC in #design-dashicons.

     
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