This week’s chat is happening Thursday 17:00 UTC
On this weeks agenda is currently empty with an open floor. We can deal with anything relating to 4.7 that comes up, or we can review some past tickets.
If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it.
See you in the #design channel in Slack!
This week’s chat is happening today, at 17:00UTC
On this weeks agenda:
If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it. See you in a bit in the #design channel in Slack!
This week’s chat is happening today, at 17:00UTC
On this weeks agenda includes a lot of Customizer tickets for us to dig into:
If anyone has other tickets the needs attention or anything else to chat about design wise, feel free to leave a comment with it on this post and join us. See you today in the #design channel in Slack!
thanks
We need your help to test the new experience to find, install and preview themes through the WordPress Customizer. The following user testing script you can follow yourself, but also we would love you to run this with anyone else you can. If you can do more than one test, please add a comment per user test to report back. This means we can be sure to get all the good things from each test.
User testing is a great thing to do and this test is a way you can start to explore that. There is a patch here at #37661 that is ready to apply and use in your testing. If you are unable to run this on others though, we are really interested in anyone giving us feedback by following the script.
Whilst we do need all results in by the end of this weekend, it would be great if you can run this test at a local WP meet-up or even contribution day. Here is the test and we’d as said like the results as a comment (one per test), but if you have any thoughts or find issues along the way; please let us know.
You can do this user test by video or text, if you’re videoing, please talk about your experience. If reporting, please write your answer down now.
Thanks for taking part in this new feature test. It’s exciting to get input and try and make this the best feature we can.
First up, we’d like to know some background questions just so we know how used to WordPress you are:
Now, the test itself:
If you do find any bugs please report them on the trac ticket here #37661 . If you are unable to do that, just drop a comment and including screenshots really helps.
There is some information on working with patches here: https://make.wordpress.org/core/handbook/tutorials/working-with-patches/#applying-a-patch
👍🏻
I have installed a theme before. I use WordPress 8 days a week. I’ve never actually used customizer to install a theme though!
Using Vagrant on Trunk, applied patch.
Easy. My eyes drifted PAST ‘Installed’ with it’s blue check mark and dropped right down to the search box, so it took me a moment to realize I’d looked too far. It’s possibly not notable enough as to what view I’m on.
Looking for `twenty-sixteen` didn’t work but `twenty sixteen` did. That was odd. I liked that I could see what I already had installed so nicely. I do wish that the theme that was active ALSO said it was installed. Yes, it should be obvious, but it wasn’t visually. Installed AND active.
I like that I can test out all my changes. I ran this and the current customizer in separate windows and this one is smoother.
It was strange that it was a blank screen until I clicked on filters. A message like “Select filters…” would be helpful if I was very new.
Overall it was good. There are some quirks to the views that are mostly around language.
I didn’t like that ‘save and activate’ keeps me IN customizer. I don’t know why, but I feel like it should be save and exit. This becomes save & publish once it’s active.
Also the message “You have unsaved changes that will be lost if you preview a new theme.” gives me one choice “Save & Publish.” But I didn’t like the theme and wanted to discard and delete it. That meant when I went to install another new theme, I got the warning about leaving the page. That message needs to be dismissible. “Yes, I know, I hated the theme, go away.” Only nicer 🙂
It was easier to make sure it was the theme you wanted, but not necessarily ‘easier’ since it gave me a lot more options to consider. It wasn’t HARDER and it felt less annoying.
Thanks!
I think the key takeaways here are:
I did a test with my husband. This was an test done with me reading out instructions. He isn’t a frequent WP user so a solid baseline. I have written down notes as he spoke through the test.
Can you tell us if you have installed a theme through WordPress before?
Do you use WordPress daily? Weekly or every so often?
Go to the Customizer. If you are looking for it, you would need to click the ‘Customize’ link in the toolbar and be logged in.
Once in the Customizer, please change your theme to a different theme installed on your site.
Clicked out of customizer using browser.
What was it like changing the theme?
Next up, please search for a theme and install it.
What was the experience like searching for a theme?
Please preview that theme.
What was the experience like previewing a theme?
Using the filters, please select a few and install a theme once you find one you like.
What was the experience like using filters?
Overall, what was the experience like using themes in Customizer?
This week’s chat is happening today, at 17:00UTC
On this weeks agenda:
If anyone has other tickets the needs attention or anything else to chat about design wise, feel free to leave a comment with it on this post and join us. See you today in the #design channel in Slack!
If we have time, I would also like us to look at #23348 – it’s older but could do with eyeballs.
Thanks for sharing the agenda Tammie. The time is a transit time for me in our time zone so I won’t be able to be there this week. Have fun! I look forward to the notes.
I ran four users through the new themes experience in the customizer (#37661) today. I sat with them for each test to take notes and hand them the test steps as they went (written on slips of paper). All of the testers are somewhat technical but not particularly experienced with WordPress; they all used Chrome on Mac with two on laptops and two on desktops (using their own devices). We started out with a clean install, then I added an import of posts from another site before the third test (the featured images didn’t carry over).
I’ve been living with this feature for the past two months, and also witnessed all of the tests directly, so independent analyses of the videos would be much appreciated in the comments.
There were no major issues that everyone had trouble with. However, each test revealed a few things that we should improve. Most of these items are unrelated to the feature at question – the new theme browser/installer – but they could all use thoughts and in some cases trac tickets. The biggest potential change to the feature at this point would be to add an additional notice about unsaved changes before opening the themes panel – I’m looking for opinions on whether that’s needed here. Also looking for thoughts on whether we need the install without previewing functionality, or if maybe it should only be available in the details modal?
It was interesting to see how different each test was, despite all of the testers being extremely demographically similar. A lot of this also stemmed from the variety of themes that they looked at. Several of the themes violate various theme review team guidelines, and I made a list that I’ll send to someone in the TRT to address, as unfortunately I still haven’t had time to go through and find ticket for all of them (cc @greenshady).
Each of the videos and the key takeaways from each individual test are available after the jump.
Test 2 asked for a way to see the theme with other content, but that’s already available outside the Customizer, and doesn’t really make sense inside the Customizer.
I see that all 4 tests were using full-screen windows. Other things show up when you use a window of average size such as 1024 or 1100.
It almost seems as if it would be best to keep the presentation of core options distinct and separate from theme options, in terms of understanding what will go away when the theme is switched.
The last test was on a partial window with the video cropped down to it. However, I should note that this was the one case where they didn’t use their own device; he was using a shared work desktop for that one.
The mix of options and theme mods gets a bit confusing here, particularly when themes move core settings (options) around to different sections.
@celloexpressions: Feel free to ping me with the list.
Thanks, @grapplerulrich took care of it.
Thanks for doing these user tests. I think it’s great you took the initiative here and not only ran these tests but also reported back so fully. There are some interesting findings in this.
I am slightly concerned though about the user base tested on. It seems (unless I’m wrong) they are all higher education based, this does infer some bias from the start. I would potentially like to see this expanded a little. It’s great we have the testing we do, lets be absolutely sure about bias though.
I also don’t see what you say for set up. Did you guide or was there a script they followed? I want to be sure as you say you did in person. Did anyone get guiding or was it totally self driven?
There is definitely bias in terms of the limited user base, which is a particular limitation with in-person testing. Fortunately they are all in/studying different career fields and have different levels of experience with WordPress, and different technical/web abilities in terms of familiarity with making sites, html/css, etc. The similarities are that they’re all in their lower-twenties, students or recent graduates from the same university, living in Los Angeles, CA, etc. If anyone has access to or can set up testing with other people, that would be a good way to validate or question the results.
Yes, the script was the “testing steps” at the bottom of the post, which I handed to them step by step after they’d finished the previous task and asked them to read aloud. There was a bit of direction from me in terms of at what point I had them go to the next step, since I had control over it. It may be better to leave it up to them in the future.
Other than that, I had them use their own device and preferred browser (all happened to be using Chrome on Mac), set up the screen recording, and got started. I definitely influenced them a bit by being there to comment/react to what they said, but I tried to minimize that and only jump in if we were getting too far off track (looking at elements that weren’t specifically being targeted for this test).
This week’s chat is happening tomorrow, at 17:00UTC
On this weeks agenda:
If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it. See you tomorrow in the #design channel in Slack!
First, #37806 could use feedback.
I’d also like to start getting some design feedback/participation on our efforts to improve the organization of the media library. Here are some thoughts to kick off discussion:
A potential approach for handling better organization of attachments is through taxonomy support. People can already register taxonomy support for media (and many do) but we don’t ship any taxonomy support registered out of the box.
1. Should we add default taxonomy for media or focus only on improving the UI of the library when people register their own?
– In the past, adding taxonomies has been a ‘wontfix’ but that was an earlier time. From a UI/UX perspective, do we still think that default tax support in the media library is plugin material?
– If yes, should we share ‘category’ and/or ‘post_tag’ terms or should we register a new distinct attachment taxonomy (or taxonomies), like `attachment_category`?
– If yes, do we turn this on by default, or make it optional via something like `add_theme_support()`?
2. Either way, we need to address #22938, fixing the UI in the media modal when hierarchical taxonomy support is added. Design feedback would be appreciated.
3. We should improve the UI for searching/filtering by taxonomy, whether registered by default or not. Design feedback there would be helpful as well.
This is the design chat summary on September 8. (Slack log).
In attendance was: myself, @hugobaeta, @helen, @melchoyce, @foliovision, @celloexpressions and @afercia.
It was a great and active chat! Thanks everyone for participating. Next week we’ll meeting at. See you on Thursday September 15th, 17:00 UTC!
This week’s chat is happening later today at 17:00UTC
We have no agenda but I have a few tickets we can look at from the archives 🙂
If anyone has other tickets the needs attention or other matter for the meeting, feel free to leave a comment with it. See you later today!
I’m looking into streamlining tools for the editor by moving more buttons to a contextual toolbar.
One flow that more and more people are getting used to, and seems like a pretty solid concept, is having a contextual inline formatting toolbar. This means that the bold, italic, link etc. buttons are (only) available when you select text.
What is your experience with this, positive and negative? Do you have any feedback on this from your users or clients using other software?
In my own experience, some of the positive sides are that:
Some of the negative sides are that:
I’m looking forward to read your comments.
I like this idea, particularly if the inline tools are specifically intended for non-block-level formatting. More experienced users can leverage this in conjunction with keyboard shortcuts and formatting shortcuts to apply formatting without selecting text. All users would understand that the tools are available when selecting text after first experiencing how it works, although we should run some user tests to investigate the discoverability (ie, ask a user to make something bold, insert a link, etc. and see if they try selecting text to bring up the tools).
My biggest concern is with mobile, where various platforms may not have great interfaces for selecting text. But the inline tools would probably work better than what we have now here anyway. Also of course, making sure that it’s accessible, although I imagine that the experience would be improved there as well.
If you can’t easily select text, it would indeed be hard right now as well, unless you just want to format a word. Even then, you still have to scroll a lot.
Regarding screen readers I can imagine we could make it even better than how it is now.
My concern for mobile is that some systems also have a contextual toolbar, but there are some not so ideal ways to work around that. One way is to offset ours, another is to position it at the top (bottom wouldn’t work with virtual keyboards). Yet another is trying to do something with the selection or focus. Suggestions are welcome. 🙂
Ella Iseulde, this a wonderful idea with one caveat: that it does not affect performance or compatibility. An additional formatting tool is probably not worth doing if it’s not lightweight. My suggestion would be to disable the code for platforms where it would either exert a significant performance penalty or would simply be awkward and out of place.
Like Nick and yourself, I agree that this should only be for non-block level formatting.
I especially like it if it means that the buttons which work inline do not appear in the toolbar. Redundancy would just be clutter.
My humble two cents. An inline editor toolbar feels like the right next choice, because you can always extend it with your favourite toolbar, or hooks.
Medium uses something like this, and there’s also a vanilla JS clone. https://github.com/yabwe/medium-editor
I like this idea, and it’s a big step toward front-end editing. That said, even with this tool inclusion I would keep the functionality in the main toolbar for a couple of reasons:
1. The tools are effectively hidden by default, meaning people will assume they are not there and have to discover them by accident.
2. There are use cases where the toolbar is a better place for the functionality.
3. How will this work with regards to accessibility?
Also, a question: The toolbar is often used to unstyle content (unbold text for example). This is typically done by placing the caret in a word, not highlighting the word. How will this work?
Yeah, a good strategy would be to keep the main toolbar and maybe have it more out of the way in small steps. For example, we could hide it on scroll down and show it on scroll up, instead of leaving it at the top at all times. If there’s a system to get data, we can see how many people use which for bold etc. And sure I don’t expect the main toolbar to go away entirely.
For screen readers I think you could announce the toolbar which would be even better than it currently is (I think). Moving the focus to the toolbar in an intuitive way is more difficult, but it would certainly not be harder. Maybe @afercia has some insights.
Not sure about removing styles. If it’s used so much in that way it can be left in the main toolbar. Otherwise it can be added in the contextual one if the selection contains such styles.
If we really need to duplicate the menu bar functionality, Morten and Iseulde, it seems to me we should not create triplicate functionality. Keyboard shortcuts are already duplicate (and the desirable additional interface as the keyboard shortcuts promote efficiency). If we move the bold italic, strikeout and link functionality into a contextual menu, wouldn’t it be better to free up that menu bar space for other block functionality?
Some people do use these tools when no text is selected, meaning to format the word containing the caret. Similarly keyboard shortcuts also work in this case.
I think I often hit one of these formatting buttons to start/stop formatting. Well, actually, I use the keyboard shortcuts to do this. I think I select text to format less frequently.
Same here. Mostly keyboard shortcuts to start/stop formatting, rarely the buttons, when I’m writing. While editing/revision, I use the buttons instead of shortcuts.
Pretty much same here. Keyboard shortcuts FTW. But I like this idea.
Re: Moving the focus to the toolbar in an intuitive way
I’ve seen other applications that just insert the toolbar in the tab order, not sure if it’s the best option but sounds like the more intuitive thing maybe. For sure it would require some research and user testing.
How do you think something like this can be made more accessible? Through keyboard shortcuts or with tab indexes to filter through the options available.
I thought long and hard before responding to try to get all my thoughts together. I spent quite a long time searching for existing user research but barely found any.
My first question: Particularly given the mobile concerns that probably prevent removing the B / i / link buttons from the toolbar, what’s the goal of adding this feature? Is it primarily about the distance required to move the mouse? Without understanding the driving problem this solves, this first struck me as a solution looking for a problem.
I also have a few concerns, none of which are all that original:
## Other thoughts
After the formatting shortcuts for bold and italic were dropped, is this seen as a new alternative to those? Will it be in addition? (i.e. we’ll have at least 4 ways to bold!)
——————-
I AM NOT A SCREEN READER USER but the idea of these being announced every time I select text sounds super annoying. I imagine most screen reader users use CTRL / CMD + B, etc. and so I’m not sure reading buttons aloud will help. But that’s my uninformed gut reaction.
——————-
re: @iseulde
> we could hide it on scroll down and show it on scroll up
See concerns about cognitive load above. See Also: “Maximize the Content-to-Chrome Ratio, Not the Amount of Content on Screen”
Reply
You must be logged in to post a comment.