Remora and extensions

colak · 2009-10-03 05:59:25

I recently started using the remora theme and noticed that sub-tabs are still visible in the extentions area when the plugin offers multiple ‘pages’.

rss_admin_db_manager and mem_postmaster are two plugins I am using which demonstrate this behaviour.

The issue of course is minor but it would indeed be nice if there was a design uniformity throughout the back end.

This is not a plugin request but more of a discussion thread where I am inviting plugin authors and txp developers to join their forces for the improvement of the theming option.

Gocom · 2009-10-03 09:09:51

I say: plugins should be designed for the original classic theme in first priority. If a user uses an additional theme, that modifies the markup, then the user itself is responsible of taking care of the possibly errors.

Altho, plugin authors should also try to use standard ways to build their plugins (for example avoiding html output depend inserts), so that the plugins have high(er) changes to work with all themes that follow the guidelines.

colak · 2009-10-03 09:58:15

Gocom wrote:

I say: plugins should be designed for the original classic theme in first priority.

But isn’t the Remora an official theme now?

Gocom · 2009-10-03 15:09:11

colak wrote:

But isn’t the Remora an official theme now?

Is in the SVN and comes with the package, but the classic is always the classic. Like no Mustang is the Mustang like the original non-plastic series.

colak · 2009-10-03 15:55:59

A suggestion would be to have some standard established for those sub-tabs. THis could be a class which could easily be styled by the different themes.

TheEric · 2009-10-04 04:07:30

I still think the unstandardized theming (different markup per theme) is the dumbest things these devs have come up with. Whatever happened to consistency?

Bloke · 2009-10-04 05:51:05

colak wrote:

I recently started using the remora theme and noticed that sub-tabs are still visible in the extentions area when the plugin offers multiple ‘pages’.

I’m not quite sure what you mean here, sorry. I have rss_admin_db_manager installed and on my ‘Extensions’ dropdown list I see 3 separate items “DB Manager”, “Run SQL”, and “DB Backup” — the same three things I see as tabs in classic. I don’t see any sub-tabs in use. What am I missing?

If you mean sub-tabs like the ones on the Admin->Preferences page (“Basic”, “Advanced”, “Language”) then the issue becomes murky. A theme can only directly alter the header (aka pagetop) and footer (aka carver/version area) of the site, plus the CSS — pluggable_ui() callbacks and jQuery can of course be employed to do more, but that’s down to the theme author. As such, the bits “in between” the page header and footer will be rendered exactly as they always have; sub-tabs and all. If you want these bits to look different you’ll have to target them via CSS/jQuery.

some standard established for those sub-tabs. THis could be a class which could easily be styled by the different themes.

I wasn’t going to mention this publicly for a while but since it’s working quite well I’ll let you in on a secret: I’m gradually trawling through all the admin pages and applying consistent classes to all widgets across the admin side. It’s going to mean that plugin authors and themers can target items on the admin side more consistently and with less reliance on chains of descendent selectors, which will hopefully increase the resilience of plugins/themes if and when admin-side markup changes take place in future. If I’d been more on the ball this would have made it into 4.2.0.

TheEric wrote

Whatever happened to consistency?

Consistency and flexibility are often at odds with each other. Remember that not every theme is a publicly shared theme; some are made for a single client in order to customise their admin-side experience. In those instances a theme can go nuts and do what it likes to the back end header and footer as long as it still works with the plugins that the Publisher intends to use. Conversely, a public themer who wants wide compatibility would be well advised to not change any of the class names/IDs that are in place so the greatest number of people can use the theme without a hitch. The standardised class names will help immensely in this regard.

That said, programmatically altering the header and footer of a theme will rarely affect a plugin’s operation since everything a plugin does occurs in the bit between the header and footer. The only time you have to worry is if a plugin starts altering the tab bar via jQuery after the page has loaded — something that is not recommended, btw! For everything else there’s callbacks.

Either way you are not forced to use the header and footer alteration system at all. A CSS-only theme will leave the markup exactly as it is. If it’s based on classic you use the IDs/classes from classic in your theme’s CSS rules. Likewise if it’s based on Remora (or any other theme) you use those classes/IDs in your theme’s CSS. If someone switches theme to something else, other installed themes don’t care what markup is employed because they’re not being used.

Last edited by Bloke (2009-10-04 05:53:08)

colak · 2009-10-04 06:09:53

Bloke wrote:

I’m not quite sure what you mean here, sorry. I have rss_admin_db_manager installed and on my ‘Extensions’ dropdown list I see 3 separate items “DB Manager”, “Run SQL”, and “DB Backup” — the same three things I see as tabs in classic. I don’t see any sub-tabs in use. What am I missing?

Hi stef. You are so right and I am so wrong. I have 4 txp installs, one of which is using the classic theme which is what I was looking at. It is only mem_postmaster which presents the classic behaviour.

If you mean sub-tabs like the ones on the Admin->Preferences page (“Basic”, “Advanced”, “Language”) then the issue becomes murky. A theme can only directly alter the header (aka pagetop) and footer (aka carver/version area) of the site, plus the CSS — pluggable_ui() callbacks and jQuery can of course be employed to do more, but that’s down to the theme author. As such, the bits “in between” the page header and footer will be rendered exactly as they always have; sub-tabs and all. If you want these bits to look different you’ll have to target them via CSS/jQuery.

Couldn’t there be a sub-tab class?

some standard established for those sub-tabs. THis could be a class which could easily be styled by the different themes.

I wasn’t going to mention this publicly for a while but since it’s working quite well I’ll let you in on a secret: I’m gradually trawling through all the admin pages and applying consistent classes to all widgets across the admin side. It’s going to mean that plugin authors and themers can target items on the admin side more consistently and with less reliance on chains of descendent selectors, which will hopefully increase the resilience of plugins/themes if and when admin-side markup changes take place in future. If I’d been more on the ball this would have made it into 4.2.0.

pure coolness:)

wet · 2009-10-05 07:17:54

mem_postmaster uses tabs as third level menu, which is an area we do not have covered in a satisfactory form at all – see the quirky preferences subnavigation for a “native” sample of sheer ineptitude to get this right.

From an UX point of view, three levels and thus rows of tabs (or flyout menus if we adopted this principle to the Remora navigation model) are way too much. Open for suggestions…

uli · 2009-10-05 13:15:56

wet wrote

Open for suggestions…

For Classic I don’t see a way for a harmonic, organic extension into the third menu level.
That’s somewhat different in Remora where the submenus don’t really feel like submenus because the secondary level is graphically straight aligned with the primary level and therefore there’s no effort in accessing the second level. Thus the tertiary menu level in fact would feel like the secondary.

Glitches could happen when trying to turn off into such a third level. In order to alleviate this movement I’d propose an extended area of about 20 px around the second and third level menus where a mouseout event wouldn’t yet trigger a menu collapse. That way you’d have a “security zone” around the menus where you can move your mouse undeliberately or too quickly whithout the menus vanishing unwanted while navigating the pointer into a third level menu.
This is especially useful for extensions that add only one menu item as a submenu thus making it hard to move the pointer into these narrow zones.

Last edited by uli (2009-10-05 13:17:24)

Textpattern CMS

Textpattern CMS support forum

#1 2009-10-03 05:59:25

Remora and extensions

#2 2009-10-03 09:09:51

Re: Remora and extensions

#3 2009-10-03 09:58:15

Re: Remora and extensions

#4 2009-10-03 15:09:11

Re: Remora and extensions

#5 2009-10-03 15:55:59

Re: Remora and extensions

#6 2009-10-04 04:07:30

Re: Remora and extensions

#7 2009-10-04 05:51:05

Re: Remora and extensions

#8 2009-10-04 06:09:53

Re: Remora and extensions

#9 2009-10-05 07:17:54

Re: Remora and extensions

#10 2009-10-05 13:15:56

Re: Remora and extensions

Board footer