On Wed, Sep 23, 2009 at 4:26 PM, John W. Long <m...@johnwlong.com> wrote:
> On Sep 23, 2009, at 3:26 PM, Jim Gay wrote:
>> Users don't care about keeping the database clean. Developers might
>> care, but regular content editors just want to know where to put their
>> content. And the problem with deleting a page part is that the user
>> needs to remember what it was called to successfully recreate it and
>> have it appear in the layout.
> True, but it's developers/designers that make a decisions about using either
> if_content or unless_blank, not the users.

Yes, but the functions of the application guide the behavior of
developers and users. I've said that this is already possible with
extensions, but the behavior of if_content causes confusion as I've
mentioned previously.

> It depends on how strongly you want to discourage it's use.

So how will Radiant (or John Long) be discouraging its use? Would the
documentation in the tag reference say that?

>> Maybe. It's not the addition of a tag or attribute that I'm after,
>> it's the purposeful, intuitive naming of tags and the correction of
>> ones that aren't quite right: if_url and if_content being examples.
> I think that it is hear that I again have to point to ruby. The principle of
> "least surprise" does not mean that it is your "least surprise", it's
> matz's.

Couldn't you argue that we should keep the behavior of if_url based on that?

New users, as I have found, will be surprised by the behavior of
if_content. It can be learned, but to me, content is text not page
parts; so I think it could be better by behaving differently. When I
think of content on a website, I don't think of visual sections or
blocks where things might appear (which is how it behaves when used in
a layout), I think of the text and imagery.

I'd rather not need to do <r:if_content
part="my_part"><r:unless_blank>... all the time just to allow users to
keep their easy-to-understand-and-remember places to put text.

>> In the same way intuitive for you doesn't necessarily mean intuitive for me
> or others.

True; I'm making that same point. Although if_content is intuitive to
you, it is not intuitive to me and to some of my users.
Your opinion is obvious that page parts are content, but I don't agree
(and I don't think the Radiant interface encourages that idea). I have
experienced questions from people using if_content where they expected
"content" in the if_content tag to mean text. Changing the interface,
could possibly solve that discrepancy between our

> Actually, it would be cool to see a list of all of the existing page part
> names on the "add part" dialog. Click on a name to fill in the the part
> name. Type to filter the list.
> Would that solve the problem?

Yes, if it stored names of parts that used to exist. Suppose there is
one page that has a "widget_x" part. A user may delete it and try to
recreate it later and they would either need to recall that it is not
"WidgetX" or some other variation, or the list of parts would need to
contain "widget_x" even though it may not exist anymore on any page.

Does that make sense?

My initial thought was that it would be just for the current page, but
then it would be a pain to find part names of parent pages, so a
site-wide list would be much better.

I envision your suggestion like the 'suggest a friend' interface on facebook.

Jim Gay
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to