The direction of Textpattern 5

maverick · 2011-01-27 17:08:27

When I first found Txp, I fell in love with the simplicity of the admin side, the paradigm (publishing/writer centric), and the tag language. I don’t even mind the tabs so much, though they are a bit dated and not as efficient as other themes available.

Part of the simplicity I like was having just three tabs at the top. Or four when plugins were installed. (Not counting the view site tab).

However, as time has passed, I have come to believe that we need to add/reorganize top level tabs to truly keep things simple and intuitive.

For example, I hate the extension tab with a passion.

As a catch-all for plugins, there isn’t even a pretense at clear functionality like “content” “presentation” or “administration”. The idea of having an entire tab showing in order to set a couple of preferences? What a waste. To have something development oriented like ied_plugin_composer mixed with a preference tab mixed with a tab that really belongs with content mixed — it’s like an overflowing junk drawer.

To remedy this, I would envision the home tab being expanded beyond it’s current state. I think it is a good place for dashboard tabs, the current write tab, and tabs for plugins like arc_admin_comment_preview.

I would add a new publishing tab for images (and files or links for that matter) would be a candidate for the home tab as well. Even better than individual “write-stye” publishing tabs for articles, images, files, links, etc. would be a new, single publishing tab with a js interface that offers common features like categories, tags, custom fields, etc. but can switch with a click from article to image to link to file.

In other words, the top level “home” tab is where I come to write, publish, and interact.

I would go one step further – at least on the home tab. There would be a way to easily add multiple sub-tabs which function like some of the new dashboard plugins – ie the new tabs would be able to parse txp tags and use textile. The back end would be incredibly customizable for a client’s needs then making it user-oriented and having easy control on access.

The current content tab would then be all about managing/administrating/organizing content. Articles, images, files, links would remain naturally. I would also add Users/Authors there. Yes, arguably they are part of administration, but they are also content to be managed. Especially in membership sites. smd_bio would fit well here, for example. So would plugins that enable ordering articles, tags and categories, etc.

I would love to see plugins consistently put their tabs in appropriate places. If it is a presentation enhancement, like cxc_templates, then on the presentation tab. If it is a preference, then on the admin -> preference tab (as some do). Or even a new admin -> “plugin preferences” if we want to separate core preference from plugin preferences.

The remaining plugins that don’t fit on any other tabs could remain quasi-logically under the extension tab.

just my 2 cents :)

redbot · 2011-01-27 17:25:19

Bloke wrote:

…To my knowledge, since the introduction of TXP 4.3.0, not one plugin (umm, well perhaps redbot’s: I’ve never used it) has capitalised on the ability to completely replace the Article image field with a hidden field + a flexible uploader. …

Exactly Bloke, maybe the plugin description isn’t clear enough as I continue to see similar requests but my plugin is just this:

lam_image_uploader + jmd_img_selector + bot_show_image+ multiple galleries per article+(from upcoming next release) drag’n‘drop sorting capability

BTW I hate to look so shamelessy self-promotional… this was not my intention and I did’t want to hijack this thread. It’s just to point out

jsoo · 2011-01-27 17:38:36

maverick wrote:

The idea of having an entire tab showing in order to set a couple of preferences? What a waste.

It is a waste, but that’s either plugin author laziness, or plugins that haven’t been updated to take advantage of the core plugin options feature introduced in 4.2.0. We can’t really prevent plugin authors from abusing the Extensions tab.

I like the general idea of putting extensions under the appropriate top-level tab, ~~or at least making that an option.~~ Edit: I guess it is an option already? Never done one myself, obviously :)

Last edited by jsoo (2011-01-27 17:41:44)

vurt · 2011-01-27 17:46:39

maniqui wrote:

When vurt asks for multiple image support for articles… If so, now we are talking on a simpler way for end-users to use images in a unstructured way, inside their article body, “mixed” within the paragraphs they write.

That’s what I was talking about.

But, imho, that’s not in the the realm of what TXP should care about on its most deeper, inner cogs.

It really was like a letter to Santa.

maverick · 2011-01-27 17:56:21

jsoo wrote:

We can’t really prevent plugin authors from abusing the Extensions tab.

Never done one myself

:) I’m not so much advocating forcing plugin authors as much as setting guidelines and expectations clearly in our documentation, on the forums, etc.

If I was going to do a plugin (which would mean learning php) I’d look at existing plugins, the example plugin/template, and then imitate it. I think all the example plugins I’ve looked at use the extension tab as an example. Most plugins use it. I’d think – that seems to be the Txp convention and do like-wise. But we could create a different expectation and eventually a new convention would emerge.

Many times I’ll edit the plugin to move it to the tab I want, but it is a pain when you update the plugin. (and I think it is Jukka who has a plugin I believe that creates a second link where you want it in addition to the extension tab – it helps with usability, but can’t help clean up the extension tab).

Bloke · 2011-01-27 18:04:26

maverick wrote:

I hate the extension tab with a passion.

I hear ya. Part of my wish list for TXP 5 was improving both the prefs screen (split Languages into its own tab, then say goodbye to Basic + Advanced separation and put the prefs into collapsible groups). One such group I’d like to see is ‘Plugins’. I intend to revamp the API so it becomes super easy to add prefs to this panel. Like, set them up in a structure similar to soo_prefs and call one function to add them to the panel. If we open up the prefs panel to all users and do more fine-grained access control within the tab, then plugins won’t need to use the Extensions tab just for prefs. They can show prefs and subsets of prefs to any groups of users they see fit.

I tried something like this this a while ago and it worked quite well; that may become the basis for how it’s done in TXP 5 but of course that was pre-MVC announcement so it’d need refactoring. Anyway, the sort of thing it created can be seen in this old skool mockup. First stab, really. Plenty of scope for improvement.

To remedy this, I would envision the home tab being expanded beyond it’s current state.

FYI, an undocumented feature of adding the Home tab to the core allows plugins to create new top level tabs. Prior to 4.3.0, new top level tabs could be created but they were always blank because the code wasn’t flexible enough to populate them. That changed in 4.3.0.

Now I hope that plugin authors won’t make their own tabs will nilly because that’ll just confuse things even further. Where I see this feature playing a role is when you want to customise the admin side for your clients. You could create a new top level tab and show it to certain priv levels. When the privs are revamped in TXP 5 and you can make your own groups, you could make a new group, hide a bunch of things from this group of people and add other stuff (you can do that now in fact, but you need to hack admin_config.php to add the role). And all this is achievable via an admin-side theme which is phenomenally powerful, especially when you consider that you could make a different theme per priv level in smd_admin_themes.

One thing that’s currently not possible — but I would like to consider for TXP 5 — is the ability to shuffle entire tabs around. Imagine, as you say, that you want to separate the content management tabs Categories, Images, Links and Files into their own top-level Management tab and shift some plugins alongside the Write and Articles tabs under the Content tab. I think that would be a desirable goal. Out of the box of course it resembles TXP as we know it, but I’d like to allow you to lay it out how it makes sense to your clients.

As I say, currently the structure is fixed and you can merely hide/show the various tabs or parts thereof. To be able to take the entire Images tab and move it somewhere else lock stock might be a huge boon to step over the conceptual difficulties you raise that some clients have.

Last edited by Bloke (2011-01-27 18:11:38)

hcgtv · 2011-01-27 18:11:44

maniqui wrote:

In general, I’m against on dumbing-down TXP.
Dumb-down TXP too much and it will become WP (the software and the audience).

Excuse the analogy, but it fits.

Debian was a notoriously difficult Linux distro to install, nobody wanted to tackle the non-gui command-line installer, it scared the hell out of would be users. Then came Ubuntu, which is based on Debian’s cutting edge branch, Sid, and more users were introduced to the apt-get world of Debian. Many years have passed and what we’re seeing are some users moving away from the safety of Ubuntu, and leaning towards the Zen way of Debian. These users, had it not been for Ubuntu, would probably be running Fedora or some other GUIed RPMed based installer distro. But Ubuntu turned them on to the beauty of apt-get, how with it you can build anything from a headless server to a full blown workstation, and keep it runnning through the years with security updates and new release upgrades with ease. They’ve decided to stick with Debian for all their future Linux needs.

You say Dumb-down, I say Educate-up ;)

Last edited by hcgtv (2011-01-27 18:27:56)

aswihart · 2011-01-27 18:42:00

Redbot’s image upload plugin rocks. I can’t even think of a significant alternative interface that is worth considering if one was to be put into the core program. As long as redbot stays around for Txp5, I don’t really care either way, but this kind of intuitive image management has to be available somehow. Stef, you should give it a spin, it gives you the popup image selector as a cut down version of the image tab like you described. Once there is a better HTML / CSS structure for the admin, people should be able to tailor the display of the pop-up and thumbnail display on the write tab to their heart’s content.

jpdupont · 2011-01-27 19:13:40

Is compatibility with 4.x series still a requirement ?

Part of my wishlist

unlimited categories for articles, images, files, links … + globals categories
section frontpage play like other sections (prefs, config, title, …)
section and sub-sections. Allow section order.
simplify the behavihor of sticky / live articles ?
at installation, choice of installation of the demo site or txt without any content
choice of removing all blogging stuff (allow pure CMS at install)
allow export/install of set of usual plugins.

Thanks to the devs and the txp community !

maniqui · 2011-01-27 19:23:12

hcgtv wrote:

(…)
You say Dumb-down, I say Educate-up ;)

Well said, Bert. You may think otherwise, but I believe we are saying two similar (if not the same) things with different words.

I certainly don’t know Debian/Ubuntu history as you, but let me know if this is true: Debian Sid empowered other Debian/Canonical developers to create Ubuntu, which is a “dumbed-down” Debian experience (more GUI, less CLI, we all like that at some point).
It’s not that Debian Sid was “dumbed down” for Canonical developers to let them create the Ubuntu experience. It’s the contrary: Debian Sid incorporated lot of dev tools (apt-get, aptitude, build-essentials, gnome, kde, I don’t know really) that empowered Canonical developers to create the Ubuntu desktop experience: a “dumbed-down”, user-friendly desktop experience. Even more, you can also have the CLI-only experience with Ubuntu server, which is very powerful, and also a “dumbed-down” version of Linux server administration.

I expect something similar for TXP5: to empower web developers (being them front-end developers or back-end/plugin developers), helping them to create a better TXP UX.
I don’t expect TXP5 devs to negotiate/lose not even a single binary digit of its superpowers and dumbing-down TXP itself (not the UX), just for attracting a secondary audience.
And sorry if that sounds too elitist.
On the other hand, I’m all for enabling non tech-savvy users to install TXP and also easily install themes, so they can educate themselves too.

Thus, I’m all for educating the client, empowering him with knowledge, and achieving a balance, a compromise.

The client ask for a WYSIWYG editor?
“No, my dear client, TXP doesn’t have that devil’s tool, but it has Textile, and although it’s not click-here tool, it brings you many advantages, my dear client. It outputs clean, semantic, HTML (renders nicely, and its yummier for crawlers). And no, it’s not complicated HTML geekery, so don’t be scared. You will love Textile, my dear client, once you learn to use it and use it a few times.”

The client insists on a WYSIWYG editor?
“OK, no problem, my dear client. You can haz clicky editor too (/me goes and install WYSIWYG plugin for TXP). But take into consideration that now you have less control on the output, and the output may be less semantic and less yummier for robots. There are some tricks to get better output with shiny WSYIWYG editor. Wanna learn?”

The client complains because WYSIWYG editor is still a complex too?
“No problem, my dear client. You still can learn: you can learn how to use Dreamweaver and FTP, to create your own webpages. Or even better, you can upload Word or PowerPoint documents and link to them. For money, I could even teach you how to do it, although I’m not excited about doing that, not even about GTFY.”

(I really hope I’m not hijacking this thread, we are still talking about TXP5, I think :) )

redbot · 2011-01-27 19:24:19

Just one request for me: sub-sections.
For the rest I trust you entirely

Bloke · 2011-01-27 19:30:37

aswihart wrote:

Redbot’s image upload plugin rocks. I can’t even think of a significant alternative interface that is worth considering if one was to be put into the core program.

Then maybe I should try it. Perhaps I’ll end up eating my words above!

Textpattern CMS

Textpattern CMS support forum

#49 2011-01-27 17:08:27

Re: The direction of Textpattern 5

#50 2011-01-27 17:25:19

Re: The direction of Textpattern 5

#51 2011-01-27 17:38:36

Re: The direction of Textpattern 5

#52 2011-01-27 17:46:39

Re: The direction of Textpattern 5

#53 2011-01-27 17:56:21

Re: The direction of Textpattern 5

#54 2011-01-27 18:04:26

Re: The direction of Textpattern 5

#55 2011-01-27 18:11:44

Re: The direction of Textpattern 5

#56 2011-01-27 18:42:00

Re: The direction of Textpattern 5

#57 2011-01-27 19:13:40

Re: The direction of Textpattern 5

#58 2011-01-27 19:23:12

Re: The direction of Textpattern 5

#59 2011-01-27 19:24:19

Re: The direction of Textpattern 5

#60 2011-01-27 19:30:37

Re: The direction of Textpattern 5

Board footer