Feedback to: Textpattern CMS 4.6.0 beta 3 released

philwareham · 2016-09-01 07:54:16

Please provide any feedback related to Textpattern 4.6.0 beta 3 released.

Check this opening post before raising an issue, because all fixes that have been applied will be listed below, thanks.

gaekwad · 2016-09-01 10:15:36

Nice one, Phil!

Demo site updated: textpattern.co/demo

jonathanbrickman0000 · 2016-09-01 11:54:03

Looking great!

J.E.B.

GugUser · 2016-09-01 14:21:22

Hm, I’m a little surprised. Why the page and form tabs was changed? Why the “All page” and form type blocks are on the left? And worse, why the Save button, “Create new form” and “duplicate” are on the bottom?

That seems to me to be a step backwards, I don’t like it. That was much better in beta 2.

Very helpful are “Expand all” and “Collapse all”. Nevertheless, not would it be possible to have only one toogle “button” for this function?

But all in all, many thanks for all the other improvements and refinements. Is a great work.

philwareham · 2016-09-01 14:31:44

GugUser wrote #300922:

Hm, I’m a little surprised. Why the page and form tabs was changed? Why the “All page” and form type blocks are on the left? And worse, why the Save button, “Create new form” and “duplicate” are on the bottom?

For accessibility reasons. The tab flow and HTML structure is now improved for screen readers and keyboard navigation, plus when using mobile devices the page/form file list is now displayed first the code which is better UX.

The combined expand all/collapse all is a fair point though. Maybe I’ll refactor for v4.7.

hcgtv · 2016-09-01 15:14:26

philwareham wrote #300923:

For accessibility reasons. The tab flow and HTML structure is now improved for screen readers and keyboard navigation, plus when using mobile devices the page/form file list is now displayed first the code which is better UX.

I could understand that logic for the Write tab, but if you’re working on Pages and Forms, for more than just a quick change, you’re on a laptop.

Beta 2, with the Hive (Flat Neutral) theme, was just about perfect.

philwareham · 2016-09-01 15:18:24

hcgtv wrote #300924:

I could understand that logic for the Write tab, but if you’re working on Pages and Forms, for more than just a quick change, you’re on a laptop.

Yes, it’s more to do with doing the tab/screen reader flow right. The mobile flow is just a happy aside of that.

hcgtv · 2016-09-01 17:22:26

philwareham wrote #300925:

Yes, it’s more to do with doing the tab/screen reader flow right. The mobile flow is just a happy aside of that.

From a conversation on StackExchange – How to design an IDE?

1. Identify the different types of users.
2. For each of them, identify what they need to do.
3. Also identify what their goals and aims in using the application.
4. Then identify what their motivations and drivers are.
5. For each task, considering their motivations and aims, identify a process to let them do this.
6. As each process is developed, see how it fits in with others.
7. Once complete, assess the whole lot of tasks against the users goals and motivations, and make sure they can all achieve what they want.
8. Build the system.
9. Test with the actual users.
10. Readjust the design bearing in mind what the users have said.

My thoughts are that the Presentation admin screens are like an IDE, it’s a different animal compared to the Content screens, and as such should be treated with the intended audience in mind. Now if your interaction with the backend Pages and Forms is limited because you use a flat file approach and hang out in your Text Editor/FTP Client, then it’s not an IDE for you, it’s purpose is only for quick changes. I live in the Presentation screens, multiple tabs opened in Firefox, it’s quicker for me, and I’ve tried the flat file approach.

My sites are simple, if I want to make wholesale changes throughout my presence, it’s a simple process of cut and paste between browser tabs. I am your intended audience, I am the one you’re trying to sell on Textpattern, because it’s easier to develop and maintain sites compared to WordPress. We’re not competing with Sublime Text.

“A rising tide lifts all boats”, is all I can say if you’re taking my comments from a hey, aren’t you forking?

philwareham · 2016-09-01 18:00:02

I have my IDE set up with file list on left, editor on the right, so in that sense it’s exactly the same.

jpdupont · 2016-09-01 18:20:15

I find that the new presentation makes them inconsistent things. “Publish” is over (write tab), but “Save” is at the bottom (other tabs). Some links above, others below. The beta 2 was in my opinion better organized. The lists of links on the left now do not bother me. For my part, I would like all links and buttons back on top.

hcgtv · 2016-09-01 18:31:17

jpdupont wrote #300929:

For my part, I would like all links and buttons back on top.

Yeah, full screen the Pages and Forms, drops downs for everything else.

@Phil, desktop IDEs let you click the left or right hand menus off.

GugUser · 2016-09-01 19:26:23

jpdupont wrote #300929:

I find that the new presentation makes them inconsistent things. “Publish” is over (write tab), but “Save” is at the bottom (other tabs). Some links above, others below. The beta 2 was in my opinion better organized. (…) For my part, I would like all links and buttons back on top.

The same for me.

subskie · 2016-09-01 20:42:34

Search article in Articles tab gives an error when you try to search for non-latin word.

Bloke · 2016-09-01 22:02:14

GugUser wrote #300922:

why the Save button, “Create new form” and “duplicate” are on the bottom?

I can understand the logic flow and the screen reader argument. I don’t use one so I’m probably gonna annoy those that do. Apologies in advance.

From my own publishing processes, I still can’t quite get used to the Save button being where it is on the Write panel. I still find myself occasionally scrolling down to find it, but its new location is gradually seeping into my muscle memory, largely because it was consistent with the other Presentation panels that had the Save button up-top. No longer, which leaves my poor old brain having to adjust to two different things again. I struggle on small screens, because the Write panel Save button is then halfway down the page and my fingers automatically scroll to the top now, only to then not find it. Grrrr.

Mobile experience on the Write panel notwithstanding, I did kinda prefer the Save button at the top of the Presentation panels, as the consistency was starting to gel with my workflow. The left or right position of the list doesn’t bother me too much, but having the Save button at the top when it’s on the left would feel a little weird I guess. In some ways, on small-form devices, I prefer that the list appears first. It makes perfect sense:

Step 1: Choose which form to work on.
Step 2: Find it below the list.
Step 3: Edit.
Step 4: Save.

It’s logical. On desktop… well, less so. On desktop I want to Write First. It’s the Txp mantra: content on the left, tweak things and make adjustments on the right, even if it’s not completely logical. The good thing about flexbox is we can actually have both chunks of mobile/desktop cake. Could we switch the order only on larger screens? What do you think, Phil?

The other thing that strikes me as odd in the Forms panel is the location of the multi-select checkboxes. Everywhere else they’re on the left and the with-selected tool is immediately below, implying they’re related. If you go tablet/mobile and have a full-width content list, the checkboxes are ranged right, but the with-selected dropdown remains on the left beneath the list. A broken relationship, perhaps? It wasn’t ideal when the list came second on the page, but seems more obviously disconnected now it’s first on-screen. Or is it just me?

Now, onto those Create New and Duplicate links. I hadn’t really noticed, but looking at it closer they do actually look a trifle odd kind of out on a limb at the bottom of the window, imo. I never paid much attention while beta.3 was being prepped as I was focusing on the tag builder. Since we have the new Tools area in inputLabel(), does it make sense to put those links near the tag builder link? Keep them all above the textarea? After all, logically you’re creating a new (blank) textarea or duplicating the content of the textarea. Granted, it might cause a problem on small factor screens, as the links would wrap, which’d look a bit crummy. Not sure how to solve that one.

This is why I’m not a designer. This stuff is hard. But something doesn’t feel quite right and I’m not convinced it’s just the old muscle memory problem or a knee-jerk reaction to change. At least, I don’t think it is. Might just need a few more days with it.

“Expand all” and “Collapse all”. Nevertheless, not would it be possible to have only one toogle “button” for this function?

We could, yes. We’d have to lose the icon I guess, as it’d be strange to toggle the icon via JavaScript to either show an up or a down arrow when some of the panels may have been subsequently opened/closed by hand. For the same reason we wouldn’t be able to toggle the wording, so it’d be fixed text like:

Expand/collapse all

And in that case, how do you know what the next click will do? If you have Form types Misc and Section open and you click the link, what does it do? Expand them all? Collapse them all? The user has no way of knowing, which is bad UX. If we were to try and toggle the wording, it has to start somewhere. Let’s say we chose Expand All; upgraders would also see that. If they had all of the groups open already, clicking that link appears to “do nothing”, then the text changes to Collapse All and the second click “does something”. Again, it’s a poor user experience. Separate links bypasses all the ambiguity. It’s very clear. But it takes up more space and adds clutter, which I agree could be reduced somehow.

We could add a single link that pops up a choice of whether to expand or collapse. Smaller on-screen footprint, bypasses ambiguity, but requires two clicks/taps. Not perfect either. And this is the same throughout the design process.

Taking a step back and looking at the project as a whole, it’s all a compromise — the biggest of which is where to draw the line at core functionality vs allowing plugins to fill the gaps — and comes back to what Bert said. Design needs to take the majority of users into account and cater to them, allowing them to solve problems quickly and efficiently. If the major reason for making the workflow less intuitive for a large batch of users is to satisfy screen readers, that’s (a bit) like writing website content that panders to search engines at the expense of copywriting for human consumption. Perhaps that’s not a very good analogy, but I’m tired. I’m not saying it isn’t important to satisfy one group as far as possible, for me it’s striking the balance between the varying user bases to get the job done, and sometimes that comes at the expense of a less-than-perfect experience for each set of users.

I’m all about the 80/20. If Txp gives users of screen readers an 80% good experience, with a slight annoyance that it reads the Save button out of sequence, and also enables 80% of desktop or keyboard users to get stuff done faster, even if it’s not visually perfect or the most logical button flow, and enables 80% of mobile users to work seamlessly on their sites without endless scrolling, then that’s a first-rate outcome in my book. Tipping the balance towards 100% perfection in favor of one group of users — even if it’s noble and just — is going to negatively impact other groups. My goal is to allow the remaining 20% in each camp enough customisation through plugins and hooks to tweak the workflow higher than the out-of-the-box 80% to suit.

At the moment, beta.3 has a lot going for it, but after spending some time playing, does feel slightly clunkier in places compared with beta.2. Like we’re running at 65-70% for desktop users or something. As I say, I can’t speak for screen reader or predominantly keyboard users, and I’m no designer and know it’s hard to balance. Maybe it just takes time to get used to. But maybe not. Maybe we can do better and give a higher all-round experience for the varying groups, even if it’s not perfect for all concerned.

Bloke · 2016-09-01 22:07:34

subskie wrote #300934:

Search article in Articles tab gives an error when you try to search for non-latin word.

Thank you for the report. Can you please supply some more context:

What language is your admin side in?
What are you searching for, so I can copy the same characters and try to reproduce it?
Do you have an example article title or two that I could also create on my development site to test for matches?

Also, some more info about your environment — PHP / MySQL version, table and column collation if you know it, and so forth would be helpful. Thanks.

Textpattern CMS support forum

#1 2016-09-01 07:54:16