Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.

philwareham · 2016-09-01 22:23:22

I’ll revisit the Save button, duplicate links layout and see what I can do. The file list is staying on the left though, sorry.

The multi-edit checkboxes have been ranged right since before I took on the UI, but I do agree the would be consistently better on left,

phiw13 · 2016-09-02 00:59:42

Bloke wrote #300938:

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.

Indeed I see the same (why did I never test that before?)

User_Error "Illegal mix of collations for operation 'like'"
in /Users/username/Sites/txptest/textpattern/lib/txplib_db.php at line 405.
adminErrorHandler()
textpattern/lib/txplib_db.php:405 trigger_error()
textpattern/lib/txplib_db.php:1183 safe_query()
textpattern/include/txp_list.php:214 getThing()
textpattern/include/txp_list.php:60 list_list()
textpattern/index.php:211 include()

some answers to your Qs

Admin is in English
a Japanese word (it does”t matter which) I know both title and body of an article contain that word
Just go to Wikipedia search any worldwide relevant subject then from the side bar, click the language icons, select a non-latin language copy paste and your done. E.g: Apple. That article has lots of language choices.

PHP version: 5.5.36, MySQL: 5.6.21 (TXP beta3), according to diagnostics (high): Charset (default/config): latin1/utf8mb4

PS – I get the same error if the admin language is Japanese

phiw13 · 2016-09-02 01:35:56

Bloke wrote #300937:

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.

ditto me (and that button has been at the top for a long time…) I’d much prefer the “Publish/Save” button to be under the textarea(s) – visually. At least that button is in the tab chain, good for keyboard + screen reader users.

(…) but having the Save button at the top when it’s on the left would feel a little weird I guess.

If you can move only visually, that would be (eventually) OK . For your pleasure, try using the Preference panel from the keyboard. The tab chain is out of whack, the “save” button comes immediately after the navigation thingie. The saving grace there is that most form controls are either single-line inputs or checkbox/radios and selects. Focus, edit, then press “return/enter” will trigger the “save” button. Not so on the Write / Pages / Forms panels where the main action takes place inside a textarea.

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?

No, not really, for my personal copy of Sandspace theme, I put those on the left (LTR), public release of said theme matches Core though. It is just a two line change in the stylesheet, the HTML is already fine.

Now, onto those Create New and Duplicate links. (…) 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.

Put them before the first input field (“Form name” on the Forms panel), then float them to the right (left in RTL). In my mind, that is the action: you open the Forms panel, want to create a new form or duplicate an existing one that action should be near the top – one could argue that those 2 links ought to go in the side bar, I personally don’t think so, the sidebar is navigation, the main column is editing.
Example: this Sandspace mockup

——-

I really like how Beta 3 is shaping up, some rough edges with the tag builder notwithstanding.

subskie · 2016-09-02 05:17:37

Bloke wrote #300938:

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.

I see that error on my local OpenServer

Textpattern: 4.6.0-beta.2, PHP: 5.5.13, MySQL: 5.5.38-log, character_set_database: utf8, with a Russian language admin-side

as well as on a demo site (English admin-side, Textpattern: 4.6.0-beta.3 )

English Amelia – No results found.
Icelandic Ástþrúður – No results found.
Greek Αγάθη – User_Error “Illegal mix of collations for operation ‘like’”.
Russian Альбина – User_Error “Illegal mix of collations for operation ‘like’”.
Japanese 天照 – User_Error “Illegal mix of collations for operation ‘like’”.

Last edited by subskie (2016-09-02 05:23:11)

colak · 2016-09-02 06:07:03

The txp_img folder is excluded in the b3 archive.Is there a reason for that?

Bloke · 2016-09-02 08:28:54

phiw13 wrote #300941:

this Sandspace mockup

I like that! Very neat and collapses logically on mobile too. Maybe we could ~~steal~~ *ahem* ~~plagiarise~~ *cough* pay homage to that in Hive.

Failing that, note to self: install Sandspace in future.

Bloke · 2016-09-02 08:33:54

phiw13 wrote #300940:

User_Error "Illegal mix of collations for operation 'like'"... Charset (default/config): latin1/utf8mb4

Thanks for the info. I suspect the charset might be the issue and why I can’t replicate it on mine. For some reason your database appears to have different collations on some tables compared with the connection (or different collation on other tables joined together in the search query).

I wonder if the upgrade assumed you were using utf8, forced utf8mb4 on you, when you were actually previously using latin1 or something. Not sure, it’s not my area of expertise.

As for it not finding things in non-latin character sets, I’ll have to do some digging. It’s finding articles with titles containing such language strings for me…

EDIT: actually, could you please temporarily hack your textpattern/include/txp_list.php file. Find line 214ish (in beta.3) and change the line to read:

$total = getThing("SELECT COUNT(*) FROM $sql_from WHERE $criteria", 1);

Adding the ,1 on the end will dump the query it’s using to the page. So when you visit the Articles panel you’ll see it there. Running a search will show you what the query is trying to match. For example, my one says:

SELECT COUNT(*) FROM textpattern textpattern
        LEFT JOIN txp_category category1 ON category1.name = textpattern.Category1 AND category1.type = 'article'
        LEFT JOIN txp_category category2 ON category2.name = textpattern.Category2 AND category2.type = 'article'
        LEFT JOIN txp_section section ON section.name = textpattern.Section
        LEFT JOIN txp_users user ON user.name = textpattern.AuthorID WHERE textpattern.Title like '%льби%' or textpattern.Body like '%льби%' or textpattern.Excerpt like '%льби%'

and that matches my test article which has part of its title as Альбина. What does yours report? And does it give any more detailed error info if you run that query from phpMyAdmin? Does the output change / error go away if you alter the search locations to only include Title, Body and Excerpt?

Last edited by Bloke (2016-09-02 08:41:00)

testdeputy · 2016-09-02 10:15:58

fresh install, can’t get any further than admin languages page..?
seems related to line 237 of <snipped>textpattern-4.6.0-beta.3/textpattern/update/_to_4.6.0.php
table txp_token is not created…

User_Error "You have an error in your SQL syntax;
check the manual that corresponds to your MariaDB server version
for the right syntax to use near 'TYPE = MyISAM' at line 11"

in <snipped>/textpattern/lib/txplib_db.php at line 405.
textpattern/lib/txplib_misc.php:1677 adminErrorHandler()
updateErrorHandler()
textpattern/lib/txplib_db.php:405 trigger_error()
textpattern/lib/txplib_db.php:778 safe_query()
textpattern/update/_to_4.6.0.php:238 safe_create()
textpattern/update/_update.php:84 include()
textpattern/index.php:180 include()

Last edited by testdeputy (2016-09-02 10:29:31)

Bloke · 2016-09-02 10:54:39

testdeputy wrote #300947:

table txp_token is not created…

Sounds like it’s incorrectly identifying your MySQL version (MariaDB in your case) and using TYPE= instead of ENGINE= when creating tables.

Can you quickly hack your textpattern/lib/txplib_db.php please. Add this after line 213 (just after it allocates the $version value):

var_dump($version, intval($version[0]), preg_match('#^4\.(0\.[2-9]|(1[89]))|(1\.[2-9])#', $version));

Then refresh your admin side. You should see three values output near the top of the page. What are they?

Textpattern CMS

Textpattern CMS support forum

#13 2016-09-01 20:42:34

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#14 2016-09-01 22:02:14

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

GugUser wrote #300922:

#15 2016-09-01 22:07:34

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

subskie wrote #300934:

#16 2016-09-01 22:23:22

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#17 2016-09-02 00:59:42

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300938:

#18 2016-09-02 01:35:56

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300937:

#19 2016-09-02 05:17:37

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300938:

#20 2016-09-02 06:07:03

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#21 2016-09-02 08:28:54

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

phiw13 wrote #300941:

#22 2016-09-02 08:33:54

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

phiw13 wrote #300940:

#23 2016-09-02 10:15:58

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#24 2016-09-02 10:54:39

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

testdeputy wrote #300947:

Board footer