Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern themes: a plan
Bloke wrote #291765:
Change the order? Sure, no sweat. If Phil agrees, it’s a one line switch in
txplib_head.php
.
I would prefer to keep the order as it currently is – don’t see any benefit in changing the order, it kind of logically goes that you would build pages, then forms, then style them.
Offline
Offline
Re: Textpattern themes: a plan
Bloke wrote #291636:
Perhaps we need a new name for that kind of thing to differentiate it from the comparatively simplistic skinning exercise I proposed at the top of the thread?
“Theme” has never been a good label for a presentational change only. The web design world should have never stopped using “skin”, which works perfectly, and could easily be gone back to since it’s not entirely invented. Theme implies more of a concept, like what your site is about. The subject. The focus.
That said, I don’t think it would be wise to call what Sacripant was talking about a “theme” either, because then it would just confuse the hell out of everyone. That’s more of a site type or genre, so a label for a given snapshot of something like that might be, oh, I don’t know … “package”, “stack”, “framework”, “recipe”, “kit”, “set”, “model”…? Something that implies a specific set of components that results in a given site type: e-commerc, blog, real estate, photo gallery, or what have you.
Bloke wrote #291654:
Do people read READMEs? ;-)
Do people read licenses and ToS? ;)
Offline
Re: Textpattern themes: a plan
Destry wrote #291773:
“Theme” has never been a good label for a presentational change only.
Yeah, it’s not a great word for all the reasons you state. My original smd_admin_themes plugin was called smd_admin_skin but I was advised to change it to fit in with what Txp was implementing as “Admin Themes”.
History, huh.
We could dare to be different and call them something else, but people coming from another CMS that uses the word “Themes” might search for Textpattern Theme Support or Txp Themes and come up empty.
Is it better to go for Skin and try to get it back in the zeitgeist, and just use Theme as a synonym for search engines?
I don’t think it would be wise to call what Sacripant was talking about a “theme” either
Also concur. I like “kit” or “package” as it implies something being built from the ground up. Some use “scaffold” but that, to me, is a temporary structure erected while something more permanent is put in place.
Do people read licenses and ToS? ;)
Not when they’re 63 pages long. I’m looking at you, Apple.
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
Re: Textpattern themes: a plan
Bloke wrote #291776:
We could dare to be different and call them something else, but people coming from another CMS that uses the word “Themes” might search for Textpattern Theme Support or Txp Themes and come up empty.
The term ‘themes’ is now common parlance for web users, so love it or hate it we need to adhere to it, unfortunately.
Offline
Re: Textpattern themes: a plan
Bloke wrote #291663:
Seems we backed the wrong horse by adding Keywords and not Meta Description all those years ago. Assuming meta description as a
<head>
tag is going to stay, even now Uncle Google is semantically aware and the tag is arguably superfluous.
As far as I’m aware, Google still uses the Description as text in search results to show what the document is about. It may not have any semantic value, but it does have incredible human/usability value, unlike Keywords. Descriptions are incredibly/hugely important in the content world. In fact, keywords are too, but more in the sense of “tags” as used in taxonomies, vocabulary, etc. Again, very important in content/IA fields.
That said, arc_meta is a great plugin that handles those meta items. IMO, there should be fewer specific UI fields in the core and more generic, which are handled with upcoming custom fields functionality. For example, instead of adding a “Description” field, just create a “Description” field from a custom field (or use arc_meta). Every time you add a specific field in the UI, the clutter factor increases and the usability factor declines.1
—-
1 The challenge, as always, is that two audience types need considered when thinking about UI changes: the designers that make sites for people (or themselves) and the customers that get the sites designers hand off to them. Textpattern has always been pretty good about bouncing development of the first type (folks here, for example), but not the latter, and the latter is where the real business is (i.e., really looking at Txp as a company tool to use). Any UX person worth their salt will tell you those end customer users are who you need to test things with. Unfortunately there’s no mechanism for that in this workflow outside of designers reporting back what customers think of a release (which is better than nothing). But that’s backwards, really, because the testing should happen during development, then the version release reflects that feedback. I realize that’s a whole different conversation and ball of wax; testing platforms, etc, etc. But just to say it.
Offline
Re: Textpattern themes: a plan
I’m planning on finding a way for users to choose which fields they show on control panels, so clutter isn’t a real concern for me going forward.
For now, I am advocating the additional of the Description field in the UI not least because it’s a fundamental and expected part of a CMS. This can be used for meta descriptions, Twitter Cards, Open Graph, whatever you want really. It should not be the realm of a plugin or a custom field (because we want to make barrier to entry as low as possible – if I had to explain to a potential theme users that they need to set up some custom field or a plugin install they will be lost).
Offline
Re: Textpattern themes: a plan
Destry wrote #291773:
“Theme” has never been a good label for a presentational change only. The web design world should have never stopped using “skin”, which works perfectly, and could easily be gone back to since it’s not entirely invented.
I came to Textpattern from NucleusCMS, I put together the “Skins” site, the project has sadly closed it’s doors.
As for the naming, taking into account the suggestions and directions thought of in this thread, I would go with:
- Themes
- Styles
- Pages
- Forms
- Templates
- Sections
- Styles
- Pages
- Forms
- Plugins
- Packages
- Textpattern
- Settings
- Articles
- Sections
- Styles
- Pages
- Forms
- Plugins
philwareham wrote #291766:
You mean like this?…
Yes, that’s what I mean, I like. When can I be a beta tester?
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Textpattern themes: a plan
hcgtv wrote #291782:
Yes, that’s what I mean, I like. When can I be a beta tester?
Later today when I put the branch back on Textpattern’s GitHub repo – will let you know.
Offline
Re: Textpattern themes: a plan
Destry wrote #291780:
instead of adding a “Description” field, just create a “Description” field from a custom field
Great input, thanks. Can I please redirect you elsewhere for further discussions on this topic. Ta.
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
Re: Textpattern themes: a plan
Edited for redirection control. Sorry.
Last edited by Destry (2015-06-22 10:55:06)
Offline
Re: Textpattern themes: a plan
hcgtv wrote #291782:
Themes … Templates… Packages
Hey, that’s a nice distinction. Where’s the damn Like button on this forum :-)
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