Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2016-09-01 18:31:17

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,634
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.

Offline

#12 2016-09-01 19:26:23

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,391

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.

Offline

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

subskie
New Member
Registered: 2016-09-01
Posts: 4

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,092
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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,

Offline

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,546
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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

Offline

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,546
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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.

Offline

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

subskie
New Member
Registered: 2016-09-01
Posts: 4

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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)

Offline

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

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 6,906
Website

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

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


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github

Offline

Board footer

Powered by FluxBB