What does your client think of TXP, and how do you deal with that?

zem · 2007-04-27 01:01:56

the if_section’s, forms etc still need to be setup in pages

We’d love to improve Textpattern so those things aren’t necessary. Adding a new section should be just a case of creating it and choosing the correct template.

Thing is, we don’t know much detail about how designers build complex sites with Textpattern, and our questions about that in the past have gone unanswered. So: what’s stopping you from building templates that are reusable? Why exactly are you hard-coding section names into templates? What could we do to make that unnecessary?

FireFusion · 2007-04-27 06:15:26

zem wrote:

Thing is, we don’t know much detail about how designers build complex sites with Textpattern, and our questions about that in the past have gone unanswered. So: what’s stopping you from building templates that are reusable? Why exactly are you hard-coding section names into templates?

I’ll answer your question Zem.

A classic example is a site I’m building at the moment, perhaps it is a bit more complex than normal site. I’ve cut it down to get across the basic idea.

default

<h2><txp:title /></h2>
<txp:body />
</div>
<div id="content_secondary">
<txp:if_section name=" ,reference,sitemap"><txp:else /><h3><txp:section link="1" title="1" /></h3></txp:if_section>
<txp:output_form form="nav_secondary" />
<txp:excerpt />

nav_secondary

<txp:if_section name="events">
<ul id="nav_sub">
<txp:output_form form="mn_events" />
</ul>
</txp:if_section>
<txp:if_section name="books">
<ul id="nav_sub">
<txp:output_form form="mn_books" />
</ul>
</txp:if_section>
...

mn_books

<li><txp:article_custom category="basic_books" form="li_a_item" sort="Posted asc" limit="1" />
<txp:if_article_category name="basic_books"><ul><txp:article_custom sort="(custom_2+0)" offset="1" category="basic_books" form="li_sub_nav" /></ul></txp:if_article_category></li>
<li><txp:article_custom category="intermediate_books" form="li_a_item" sort="Posted asc" limit="1" />
<txp:if_article_category name="intermediate_books"><ul><txp:article_custom sort="(custom_2+0)" offset="1" category="intermediate_books" form="li_sub_nav" /></ul></txp:if_article_category></li>
<li><txp:article_custom category="advanced_books" form="li_a_item" sort="Posted asc" limit="1" /><txp:if_article_category name="advenced_books"><ul><txp:article_custom sort="(custom_2+0)" offset="1" category="advnced_books" form="li_sub_nav" /></ul></txp:if_article_category></li>

Last edited by FireFusion (2007-04-27 06:15:50)

maniqui · 2007-04-27 08:20:36

Clients should know that they can’t touch and modify each and every content/piece/chunk-of-code of a website without breaking it partially or totally.
Of course, they want to modify it, add new content, maybe a new section. It’s their site, they want to feel they really own it, and if the webmaster vanishes into other dimension, they won’t need to call 911 nor need to request a new web-developer to create a new site from scratch.

We all know that a well-coded site with web-standards should be, ideally, easily readable and comprehensible by any other web-developer that may pick-up and continue our work.
Also, a CMS like TxP shoud ideally give a total control over the content and the presentation of the site, and in fact, TxP really give us (developers) a nearly-100% control over those aspects.

So, web-standards and TxP goes hand-in-hand in the taks of making site’s maintenance (that is, updates in content and changes in design, add new functionality, etc) easier and painless.

Then it comes our client (a non-technical user) who wants to move things from here to there, add section, change colors, change sizes, etc. And then, things usually start to break.
HTML is structure, is like an skeleton or a building: you can’t easily add/remove elements to the structure without making minor (in the best case) or major changes.

Yes, they should be able to add a new article and things shouldn’t break at all. But, of course, before they do that, you (developer) have think about the article flow and did some information architecture.

But maybe adding a section isn’t that easy. In the most common case, when you (or your client) create a new section, you want it displayed to the section navigation menu.
In an horizontal menu this could become problematic if you didn’t leave enough room for new sections: an horizontal menu with many sections tends to break design.
Of course, you/client may not want to show the new section in a menu, but just have a section to put new content and make it accessible by other ways.

And also, as a rule that could be applied in most cases, if your client thinks he needs more (many) sections, maybe it’s time to rethink the site architecture.
Adding a new section could be compared to adding a new room to a house, but also, to dividing one room into two spaces (does that idea makes any sense? I leave it there, because it sounds smart and maybe, you can make some conclusions! ;) ).

zem wrote:

We’d love to improve Textpattern so those things aren’t necessary. Adding a new section should be just a case of creating it and choosing the correct template.

Thing is, we don’t know much detail about how designers build complex sites with Textpattern, and our questions about that in the past have gone unanswered.

I must admit that I have developed few sites in my life (but for most of them, I use TxP) and usually, I’m in charge of all the maintenance, so clients never worry about updating/changing/deleting/*breaking* things

Regarding this topic, I think there are at least two ways to think and develop a TxP site (and so, its templates): a developer-centered way and a client-centered way.
I will list some of the issues that are common in each case.

Developer-centered way

use a lot of if_section tags to reduce qty of page templates and forms
use of hard/hand-coded code because developer knows things doesn’t change automagically by just adding a new section.
so, these approach aren’t very flexible if the client wants to take control over some aspects of their site but don’t want to mess with code.

Client non-technical-user way

changes should be transparent for this user: they create a section, they choose a page template, they add some new content and voilà: there go to the front-end and the new section can be accessed through the navigation menu and the new content is there, nicely formatted.
in that case, you should create one (or many, for options and great flexibility) pages templates, so when your client creates a sections they can choose different pages templates: a two_columns_page_template, single_column_page_template, etc.

There you have a simple way for clients to create new sections and let them choose a section layout (page template) and, if you have done a good work in thinking possible different pages templates, they should find one that fits they needs.

So: what’s stopping you from building templates that are reusable? Why exactly are you hard-coding section names into templates? What could we do to make that unnecessary?

About adding a section to a automagically generated section navigation menu, I think TxP lacks of some flexibility.
There could be a way to re-arrange sections sorting and visibility in txp:section_list tag.
This could be managed directly from the Sections tab: there could be some ajaxy-arrows (or maybe a sort-by-number-in-input-field) to re-arrange section order, and then a checkbox to control visibility in the outputted menu (show/hide).

I think those last ideas had been already proposed and discussed previously.

Well, that’s all for now, excuse my english and any lack of sense in writing/ideas. Bye!

Last edited by maniqui (2007-04-27 08:23:23)

nardo · 2007-04-28 03:25:04

maniqui’s Two Ways – my experience too – not that they have to be radically different… but also have found that most clients that want control over their content end up getting you to do the inputting

image handling is always tricky to explain when providing a flexible number of insertion options (floated left/right, with/without captions, fixed sizes for fixed width columns, etc) … also the WRITE tab would benefit from customisation options for user-levels (basically removing from view what the client doesn’t need, also relabelling some textboxes but that is not so important)…

from the start – knowing the client’s mind would be helpful, but often they don’t know it themselves! that’s not a txp problem : )

more choices = more complexity

it’s not always appropriate but getting clients to use purpose-built tools like Flickr for photos, YouTube/Google Video for videos, etc – is not a bad idea – and pulling it into the site … benefits being the great user-centric tools for scaling/captioning pics, encoding video for web, etc + having content out in highly trafficked areas (bait)

nardo · 2007-04-28 03:26:15

PS the zem_events plugin is a great thing for clients!

Textpattern CMS

Textpattern CMS support forum

#13 2007-04-27 01:01:56

Re: What does your client think of TXP, and how do you deal with that?

#14 2007-04-27 06:15:26

Re: What does your client think of TXP, and how do you deal with that?

#15 2007-04-27 08:20:36

Re: What does your client think of TXP, and how do you deal with that?

#16 2007-04-28 03:25:04

Re: What does your client think of TXP, and how do you deal with that?

#17 2007-04-28 03:26:15

Re: What does your client think of TXP, and how do you deal with that?

Board footer