Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
Re: Textpattern themes: a plan
Sorry, I’ve missed something; what about the file name conventions? Is that what we should use?
- Theme
- Pages
- abc_theme.default.txp
- Forms
- abc_theme.default.article.txp
- Pages
Last edited by NicolasGraph (2015-06-22 11:19:55)
Offline
Re: Textpattern themes: a plan
NicolasGraph wrote #291790:
what about the file name conventions?
I was thinking more like:
- themes
- abc_theme
- pages
- default.txp
- about.txp
- forms
- article.default.txp
- misc.footer.txp
- section.layout.txp
- styles
- cobalt.css
- pages
- smd_theme
- pages
- elastic.txp
- forms
- article.default.txp
…
- article.default.txp
- pages
- abc_theme
Deletion is then a simple case of removing the theme’s folder (after unassigning the theme assets from your Sections of course, or things’ll get messed up on your public site).
EDIT: .css extension for Stylesheets, duh.
Last edited by Bloke (2015-06-22 18:37:27)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Online
Re: Textpattern themes: a plan
I’m with Stef on this one. That is the directory structure I would want.
Offline
Re: Textpattern themes: a plan
philwareham wrote #291784:
Later today when I put the branch back on Textpattern’s GitHub repo – will let you know.
OK missed this – downloaded the latest from Github but its no different from before. Using 4.6dev on TXP Tips for access to the txp:author tag, so happy to give this a testing once you update on Github.
Offline
Re: Textpattern themes: a plan
I’d like to also point out to TXP fans out there that the grass is not necessarily greener on the other side. I wasted hours this morning on my wife’s Tumblr site trying to figure out why a paid theme did not load her Twitter feeds. She uses Tumblr because its easy to add content, but its not easy to change anything and the theme author’s help page leads to a 404.
Offline
Re: Textpattern themes: a plan
Bloke wrote #291791:
I was thinking more like:
- Themes
- abc_theme
- Pages
- default.txp
- about.txp
- Forms
- article.default.txp
- misc.footer.txp
- section.layout.txp
- Styles
- cobalt.txp
- smd_theme
- Pages
- elastic.txp
- Forms
- article.default.txp
…Deletion is then a simple case of removing the theme’s folder (after unassigning the theme assets from your Sections of course, or things’ll get messed up on your public site).
Great, even easier than I thought. I didn’t know if same form names in different themes could cause problems with the db.
Offline