Recent Updates Toggle Comment Threads | Keyboard Shortcuts
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
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:
Here’s a breakdown of HEX color changes:
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:
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!
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.
- Our goal: Migrate to using SVGs for Dashicons, rather than the font.
- We have a first-iteration mockup , which got some browser testing (it didn’t do so great).
- There’s another proposed implementation, which we’ll look into.
- If you have an opinion on using SVGs in a cross-browser way, please leave your feedback on these issues.
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.
Now that we’re ready to start making a plugin, this post will catch you up on some of the important things to read before diving in.
Wireframes and Flow Charts
The interactive wireframes will give you a pretty accurate visual overview of where we’re going with the project. Note that the wireframes are based on a large amount of research into how different platforms and applications handle image storage, upload, and editing.
The in-browser prototype is a skeleton representation of how we see the basics working. It isn’t perfect, but the basics are there. We’ve decided that at this point it’s best for us to move onto the plugin. However, @mor10 is doing some user testing on the prototype and we’ll use that feedback for refining the plugin.
if you’re interested in some more background reading that should give you insight into various decisions, these are some things worth looking at (this is not essential to read before getting started):
- WCSF progress report
- User pain points
- Paper sketches
- Background research (including Market analysis, personas, workflows, etc
The next step is to break the plugin down into discrete, achievable tasks. This should get things moving more quickly. we can use the Image Flow Github account. As soon as it’s in a usable state we’ll put the plugin in the repo so it’s easy to test and we can get feedback.
The regular meeting is at 17:30 UTC on Thursday.
I did five usability tests for theme switcher and sliding panels in the customizer.
- Users found the customizer very user-friendly overall.
- Expected clicking on a theme thumbnail to open a preview, not the details modal.
- Difficulty navigating back using the current 4.2-alpha design (pre-31289.diff).
- Expected clicking the “Save & Activate” button to not kick them to the front end.
- “Save & Publish” is clicked a lot more often for sliding panels.
- I asked two users (note small sample size) which navigation style they preferred, both picked accordion.
- 1406491a-usertesting.mp4 (17m5s)
- 1408362a-usertesting.mp4 (8m53s)
- 1408760a-usertesting.mp4 (7m58s)
- 1408936a-usertesting.mp4 (11m15s)
- 1414874a-usertesting.mp4 (15m35s)
Thanks everyone who attended the meeting last week (and apologies for my tardiness with the notes!).
We had a serious discussion about the current process. After discussion of the prototype, we decided that in its current state it’s ready for testing the basic flow. There are a few bits of polishing that need to be done:
- fixing the CSS on the back of the card
- ensuring that full-width images remain selected when browsing through the images
However, no more major development will be done on the prototype. We don’t think it is a good use of time to work on getting the editing features working. We’re going to start building the plugin and get the groundwork for that done while morten is testing.
Therefore, next week’s meeting will be dedicated to scoping out the next steps for the plugin and getting that process going.
- @mor10 to share his procedure for testing so that other members of the team can run tests too (complete
- fix selection issues when in full-width (complete
- fix styling issues on metadata screen (complete
(great job on getting everything complete before I even write up the notes 😀 😀 :D)
Thanks to everyone who attended the image editing meeting today. Here’s what we discussed:
- prototype: the prototype is progressing. You can see the current version here.
- @mor10 pointed out that the current version of the PT isn’t ready for testing. He has created a number of issues in the tracker to get the issues addressed
- we discussed the ease with which people can get involved with the project. We agreed that it would be better to break the scenarios out into discrete issues for each screen
- @siobhan to create a new list of issues for the devs to work on
- @mor10 to add issues he’s come across to github
- @mor10 to share his user testing process once it’s complete
The dev meeting is on Friday at 17:30 UTC for anyone who wants to join.
- SVG For Everybody was merged into github, the mockup can now be seen on IE9+
- Debate over creating a core set of Dashicons, and leaving any icons not used by core in a downloadable pack.
Dashicons “core set” Discussion
Started from Michael’s comment about applying the core philosophies to dashicons. If we can narrow our focus on only the core icons, any improvements and changes only need to happen on this smaller subset of icons. For current dashicons users, creating your own icons in SVG should be simple- or they can download the SVG they want from somewhere.
There was a lot of reluctance from the developers in attendance, I think because we use those icons
We left off the discussion at this: for backwards compatibility it’ll be best to keep all dashicons in core. This may change as we move to implement this in core, it’ll depend how we handle backcompat.
Since we haven’t made any final decision, any extra discussion should happen on the github issue for grouping icons.
- Note if/where icons are used on the google doc in this github issue.
- Continue working on the mockup: refine the grunt tasks, browser test.
We’ll meet again next week, February 12, 2015 18:00 UTC.