Plus/minus signs in expandable side menus [3373]

wet · 2010-08-05 16:21:14

r3373 introduces expand/collapse icons to the Classic admin theme. With some certain plugins installed, this looks a bit clumsy in the alignment dept.:

How should we deal with this: Abort, retry, ignore?

els · 2010-08-05 16:50:59

I vote for ignore. In a way, this shows clearly that the other lines are not core Txp. And anyway, the plugin links are the ones that look clumsy now ;)

maniar · 2010-08-05 18:14:30

No no, lets not completely ignore it. How about approaching it like the way WordPress does:

When full text is shown, the menu is drop-down. An arrow appears when hovered over the heading

When Iconified, the menu becomes flyout.

thebombsite · 2010-08-05 21:34:21

It’s up to plug-in authors to get into line with Textpattern, not the other way around, as I’ve been trying to teach Stef for the last few months. Plug-in authors should use existing Txp ids and classes and only create new ones when absolutely necessary. If they all did that we wouldn’t be asking such stupid questions Robert.

Also, though this is just an opinion, I don’t think plug-ins should be inserted into the middle of an existing menu like that. They should add themselves at the bottom. Probably wouldn’t look as bad then.

Last edited by thebombsite (2010-08-05 21:39:33)

Gocom · 2010-08-05 22:06:43

I don’t personally care if there even is a sign or not. Actually to me the sign wastes important space. Good thing that it’s in theme related.

thebombsite wrote:

Also, though this is just an opinion, I don’t think plug-ins should be inserted into the middle of an existing menu like that. They should add themselves at the bottom. Probably wouldn’t look as bad then.

Then why there are callback locations in any other position than at the bottom of the column ;-)

Plug-in authors should use existing Txp ids and classes and only create new ones when absolutely necessary. If they all did that we wouldn’t be asking such stupid questions Robert.

Plugins shouldn’t take inbuild IDs at all for customized display purposes. Everything that is build for custom purposes should be prefixed so that it doesn’t conflict with future changes.

Good example is #body. Say that someone took it to style the fields indentically to each other. The problem is that you can’t reuse the ID and reusing it conflicts with every plugin that tries to target that single ID.

Same with if and when you want to build custom panes. You can’t really use the IDs expect the ones that are used by the htmlshortcut functions (inputs mainly and #list). Why, you may ask? Because using the IDs for custom situations will conflict with themes. It would sound cool to take page-article and make the columns identical to write tab, but what happens when theme is applied.

Last edited by Gocom (2010-08-05 22:30:26)

Bloke · 2010-08-05 22:30:49

Ooh, nuts, didn’t think about that. That needs addressing; thanks for pointing it out, wet.

@Stuart: the problem is not one of whether plugins can fall into line with TXP, it’s the fundamental nature of that sidebar. Not all plugins that add stuff to the sidebar will have what I term ‘twisties’ — yet all of the existing things reveal other options when the link is clicked.

To make things look neater, would a negative left margin on the +/- symbol work better in the CSS so at least the left edges of all text items lined up, regardless of whether they revealed additional content or not?

Gocom · 2010-08-05 22:35:45

Bloke wrote:

To make things look neater, would a negative left margin on the +/- symbol work better in the CSS so at least the left edges of all text items lined up, regardless of whether they revealed additional content or not?

Browser support? The page is build using tables. Making items to go outside table cells might not be that easy, plus if the sign is just text, how can you know how width the char is. It would work for a custom theme build by 3rd party, but not with really with the default official theme.

Yet another column and rowspan? Lol.

Bloke · 2010-08-05 22:39:10

BY the way, this change only came about because of the alterations to the Forms tab. Having each group collapsible and having them all ‘closed’ to begin with caused a slight problem in terms of visual cue. We can’t open one group by default because the open/closed state is governed by a per-user pref and the absence of any open/closed pref means “closed”. So that either left:

Add some indicator
Reword the options to make it clearer they did something when clicked
Revert to the original method of a static list with the type adjacent to each item
Something else I’ve not thought of yet

All options are still available to us. If the consensus is that the collapsible nature of the Forms list is not viable then we can always reinstate the original behaviour at the expense of a tiny bit of screen real estate width. I don’t mind either way — it’s what works best for the majority of users that matters.

Last edited by Bloke (2010-08-05 22:41:46)

Bloke · 2010-08-05 22:40:44

Gocom wrote:

Browser support?

Oh yeah. Duh. Tables *sigh*

thebombsite · 2010-08-05 22:56:24

I am aware that they don’t all need to expand/collapse but it is a background-image so plug-in inserts could have the padding and disallow the image. That way they would line up but not have the +/- sign. Just means a bit of tinkering with the plug-ins methinks. Could be wrong. I’m sure everyone will let me know on that score.

Of course you could always switch the image to the right but I don’t think that looks so good.

Seems to me we are going one pace forward and 2 paces back. I’m all for the indicators but then I would be wouldn’t I? And don’t they come under a general heading of “accessibility”? If you are going to baulk now when an advance makes a few plug-in entries look odd what’s going to happen when Txp5 hits the streets? At least for the moment they still work.

Last edited by thebombsite (2010-08-05 23:00:38)

Gocom · 2010-08-05 23:02:51

thebombsite wrote:

I am aware that they don’t all need to expand/collapse but it is a background-image so plug-in inserts could have the padding and disallow the image. That way they would line up but not have the +/- sign. Just means a bit of tinkering with the plug-ins methinks. Could be wrong. I’m sure everyone will let me know on that score.

So that the plugins wouldn’t appear correctly on older versions of TXP and that they would look nice only on one theme?

thebombsite · 2010-08-05 23:15:12

Well I know of at least 4 themes that look nice but then I have updated mine (which will be the next problem) but I go back to my original point. If those entries carried the same classes/ids as the others they would get the new padding for current Txp versions and not get it for older ones. They just need to disallow the image.

Of course this is something that needed to be drummed into plug-in authors about 4 or 5 years ago. So for now, plug-ins are going to hold the core back. So be it. I’ll shut up.

Roll on Txp5. Can’t wait for the tears. ;)

Textpattern CMS

Textpattern CMS support forum

#1 2010-08-05 16:21:14

Plus/minus signs in expandable side menus [3373]

#2 2010-08-05 16:50:59

Re: Plus/minus signs in expandable side menus [3373]

#3 2010-08-05 18:14:30

Re: Plus/minus signs in expandable side menus [3373]

#4 2010-08-05 21:34:21

Re: Plus/minus signs in expandable side menus [3373]

#5 2010-08-05 22:06:43

Re: Plus/minus signs in expandable side menus [3373]

#6 2010-08-05 22:30:49

Re: Plus/minus signs in expandable side menus [3373]

#7 2010-08-05 22:35:45

Re: Plus/minus signs in expandable side menus [3373]

#8 2010-08-05 22:39:10

Re: Plus/minus signs in expandable side menus [3373]

#9 2010-08-05 22:40:44

Re: Plus/minus signs in expandable side menus [3373]

#10 2010-08-05 22:56:24

Re: Plus/minus signs in expandable side menus [3373]

#11 2010-08-05 23:02:51

Re: Plus/minus signs in expandable side menus [3373]

#12 2010-08-05 23:15:12

Re: Plus/minus signs in expandable side menus [3373]

Board footer