Buckets, Page Types

Ruby Apps Radiant CMS
1

I’ve been watching Radiant for the past few months. I think it’s a
spectacular piece of software with respect to the simplistic but
functional
UI.

Although I haven’t contributed anything to the project, I thought I
would
chime in with my $0.02. I have a project in mind for Radiant – using it
in
the grade-school education field. I know my audience pretty well. I
thought
their perspective might help frame your discussions about “images per
page
or per bucket” and selecting page content type.

Teachers / secretaries would … frankly … be totally dissatisfied
with
the idea of having to add a picture to a bucket before using it on a
site.
The arguments for DRY are valid. I embrace the concept of DRY. My
Ruby-based project at work has gained much from the tenants of the Ruby
language, and this one in particular. More than once we’ve come to a
major
fork in the development process, and the word “DRY” has made the
decision
for us.

With that said, there’s a point where you can be too DRY. If you’re
using a
“yes or no” set of radio buttons in two places on the site, that doesn’t
mean you should create a helper for it. Just put the code twice. It’s
going
to be OK. The ACM / Radiant mailing list / Bill Gates / Larry Page will
not
excommunicate you. Similarly, if someone uses a photo twice and I have
to
store it twice (or, intelligently, compare it’s signature to all
existing
objects and notice that it’s the same… but not ask the user anything
about
it… ) well then that seems fine, especially if it improves the user
experience.

No user wants to hear about DRY. Users like another Ruby tenant… “it
does
what you would expect.” They expect that if they’re editing a page, they
can
add an image from that page. (Of course, they also expect WYSIWYG, and
that
the image will be automatically resized and appear in the editor…)

One thing they wouldn’t necessarily expect, but would be thrilled to
have
access to, is a “clipart” section… your “bucket” … where they or
anyone
else could add “common” images.

So I think perusing both would be excellent

Also, on the “different pages” idea… the “New Page → Select Page
Type
→ Display specific editor” is exactly what I had in mind. Radio
buttons
and next. Specifically, here are the page types I currently plan to use:

  • Regular Page
  • Grouping Page ( Very similar to a regular page, but its purpose is to
    hold
    a group of similar objects, like “Meeting Minutes” or “Elementary
    Schools” -
    and actually I haven’t figured out in my head whether this is actually
    necessary or just an extra layer I can drop.)
  • Site ( templates will be on a “site” level for me instead of on a page
    level… also, main menus and users will be on a site level.)
  • Photo Gallery ( I was looking at Tableau Koalan & Surikaten )
  • Calendar (Google API? Who knows…)
  • Attachment (PDF, Word, Excel, etc.)
  • Link (OK this isn’t a page but it will make main menus work nicely.)

So, if this helps direct your thoughts toward something useful, great.
If
not, click “delete.” :slight_smile:

jw

I’m in total agreement on needing to have different interfaces for
different page types - but I would see the flow of page creation being:

New Page → Select Page Type → Display specific editor

Rather than have a selection of editors available directly on a page.

2

I am in TOTAL agreement with your feelings here. In fact the only
“disagreement” I would make is more of semantics and, if I understand
you correctly, we actually agree.

First, on many sites assets (especially images) have a 1:1 relationship
with pages – they aren’t reused. So if the user wants to think of the
asset as “living” on that page, great. When assets get reused, or like
you mentioned, one user creates/uploads pictures/clipart and another
user writes the content that uses it. then the user obviously is going
to think of the asset living somewhere else and being “attached.”

In my mind, I wouldn’t make a big deal about the “bucket” – at least
not to the user. “So, you want to add a picture? Browse your computer
(to pick and upload to the bucket and automatically attach) or browse
the site (to pick from the bucket and attach).”

So when you say:

Teachers / secretaries would … frankly … be totally
dissatisfied with the idea of having to add a picture to
a bucket before using it on a site.

I agree. The use case is “add image from my computer” or “add image
already on the site.” The bucket/public folder/repository is just the
technical solution.

By the way, I will mention this one more time. Many of the asset
management solutions sound only page centric. In the asset reuse
situation or where one user uploads pics for everyone to use, it would
be good to be able to confirm where or if each asset is used. That way
it is possible to actually “manage the assets.”

3

As to your page types, I was kind of surprised to see your “grouping
page.” I plan to develop an extension shortly for a project that might
line up with your grouping. I’ll share it here in case it actually is a
more generally usable concept than I thought.

I apologize in advance for all the lead-in…

I have a website that is collecting stats on various cities in the
region. Since these stats may be used on multiple pages and the data
changes from year to year, I plan on sticking them in the db and calling
them from custom tags within static pages.

For example:

\Cities (index page)
\City A (static content plus stats from db)
\Map (static content plus map built from db)
\Chart (static content plus charts from db)
\City B (static content plus stats from db)
\Map (static content plus map built from db)
\Chart (static content plus charts from db)
…

Essentially I’m grouping cities together here.

I’m planning to make an extension to set the property for each city page
based on choices within the db (i.e city=“City A”). It’s children would
inherit this property.

Now, I obviously need to build my own tags/extend radiant for each of
the dynamic pieces (stats, maps, and charts). That way, in the chart
page I could just insert <r:chart city=“current” />.

Why be this fancy? I have multiple categories (cities, counties, school
districts, etc.) – all of which can overlap in weird ways.

Now I’m wondering if it’s actually a unique need. I’d be happy to
develop a public extension if I thought anyone other than me would use
it. Any takers?

4

No user wants to hear about DRY. Users like another Ruby tenant…
“it does what you would expect.” They expect that if they’re editing
a page, they can add an image from that page. (Of course, they also
expect WYSIWYG, and that the image will be automatically resized and
appear in the editor…)

For another usecase showing why I want (well, need) images attached to
pages, have a look at http://www.thegroggysquirrel.com - You’ll see on
the front page and image linked to each article - I can do that just
from grabbing the first image associated with that page (which in many
cases isn’t actually displayed in that page, it’s just that it’s been
attached). The same thing can be seen at
http://www.thegroggysquirrel.com/comics - the page at /comics doesn’t
need to know anything other than the fact that it has some child pages
and it can happily pull down the images associated with each of the
pages and render them.

This could probably be achieved instead by choosing one image from the
list of images for rendering (in fact, I provide an option on the page
to select an image to be associated if there are multiple images), but
it’s been much more straightforward for the (not so computer savvy)
editors to simply upload their article, upload an associated image at
the same time and be done with it. Especially when I’ve currently got
826 attachments that would be living in that bucket to choose from -
giant buckets don’t scale.

Dan.

5

Especially when I’ve currently got
826 attachments that would be living in that bucket to choose from -
giant buckets don’t scale.

I think they call those ‘vats’. Now the question becomes, do you need
an asset bucket, an asset vat, or an asset tanker!

Sean

p.s. yes this post is tongue-in-cheek

6

You need to download Mephsito and try out their system: they have
many (not all) of these problems worked out. The Assets page lets you
search through everything with tags, titles or asset type, then drag
a small selection to a bucket. The bucket shows up when editing a
page, where you can attach it. It is very slick.

You can also upload an image while editing a page, directly into the
bucket. I think this covers most people worries, and gives you a
central place to edit, caption and tag the images/assets.

But this has been an interesting conversation and it is good to hear
so many ideas about this issue.

7

On Feb 24, 2007, at 7:14 PM, Chris P. wrote:

By the way, I will mention this one more time. Many of the asset
management solutions sound only page centric. In the asset reuse
situation or where one user uploads pics for everyone to use, it would
be good to be able to confirm where or if each asset is used. That
way
it is possible to actually “manage the assets.”

I think of Basecamp’s Messages (and other places where you can attach
files). I don’t think about it twice: if I have a file I want to
attach, I attach it. If I want to see what files there are, I go to
Files. If I want to reference a file in another place, I get the url
of the file and reference it. It’s a simple matter of programming…

adam williams (aiwilliams)

8

There are two Web-based tools I use frequently that illustrate this
dichotomy.

On the one hand I have my blog, which uses Typo. Assets are ‘global’.
Having uploaded an image I can use it anywhere.

By contrast I use TWiki for document management. Here the attachments
are
associated with a specific page (“topic”). This makes sense in context
because it is a content management system and the access controls for
each
page and project (“web”) need to apply. A document has, of necessity, a
:1
association with a page.

If Radiant were a Wiki I’d encourage the restriction to the binding of
the
asset to a page. But a CMS, used as a blog or as a management system
for a
business or,as I use it, for a club,the images MAY want to be reused in
various contexts. Having that ability will not stop them being used in
just-one-place. But restricting availability will limit what Radiant
can be
used for.

For example, it I were using Radiant for a product site I might want the
image of the box product on the front page as well as the product
comparison
page and the purchase page. Having to upload multiple copies of the
same
image would be both wasteful and annoying.

Chris P. said the following on 02/24/2007 07:14 PM:

I agree. The use case is “add image from my computer” or “add image
already on the site.” The bucket/public folder/repository is just the
technical solution.

By the way, I will mention this one more time. Many of the asset
management solutions sound only page centric. In the asset reuse
situation or where one user uploads pics for everyone to use, it would
be good to be able to confirm where or if each asset is used. That way
it is possible to actually “manage the assets.”

–
The improvement of our way of life is more important than
the spreading of it. If we make it satisfactory enough,
it will spread automatically. If we do not, no strength
of arms can permanently oppose it.
- Charles A. Lindbergh

9

For example, it I were using Radiant for a product site I
might want the
image of the box product on the front page as well as the
product comparison
page and the purchase page. Having to upload multiple copies
of the same
image would be both wasteful and annoying.

Using an image on multiple pages does not necessitate the uploading of
that image on each of those pages.

Using my part_attachments extension, on your main page and comparison
pages you could have:

<r:find url="/products/magic-monkey-bars">
<r:images:first>
<r:image transform=“thumbnail”/>
</r:images:first>
<r:content part=“summary”>
</r:product>

The image is linked to the product page, and when other pages want to
talk about that product, they can delegate the image lookups to that
other page. If the images were in a giant bucket, the above would need
to be something like:

<r:image name=“magic-monkey-bars”>
<r:find url="/products/magic-monkey-bars">
<r:content part=“summary”>
</r:find>

Speaking of DRY… I think I just repeated myself. Now, imagine that
instead of being a find for a specific product, what you were looking
for was a list of top ten products, or ten most recently added products
or some other grouping:

<r:top_ten_products:each>
<r:image ??? how does this tag find the image for the product ??? />
<r:content part=“summary”>
</r:top_ten_products:each>

Radiant provides a great mechanism for structured data - everything IS
in a global bucket that you can reference from any other page - that
bucket is providing a structure.

Dan.

10

Radiant provides a great mechanism for structured data - everything IS
in a global bucket that you can reference from any other page - that
bucket is providing a structure.

Further on that, my part_attachments extension already lets you
reference assets globally:

<r:image page="/products/monkey-bars" name=“kids-on-monkey-bars”/>

or

<r:image id=“247”/>

There would be nothing stopping you from taking my asset management code
and extending it with a second extension to change the interface to see
things as a bucket and hide the page ownership.

Dan.

11

Dan, thanks for your posts. You’ve given me the best example of a
user’s need for the asset to be seen as part of a page instead of in the
radiant vat™ (kudos to Sean).

To me this issue has nothing to do with where the asset is stored but
rather the interface and how simple and intuitive it is to the user.

In your case Dan, it is obvious that the user (you) needs a particular
image and that the image’s address is based on its use elsewhere.

In the case where an one user uploads 100 clip art images for other
users to use in their pages, the location (in the user’s mind, anyway)
is not related to where this image might already be used. In fact it
would be bad if both writer A and B use the same picture (B by reference
to A’s work) and then A went and changed theirs.

Similarly, in my case I upload a stock photo for use and, 100 pages
later, I write another piece that could also use it. I don’t remember
which page I put it on before and it would be “wrong” to describe the
picture as “belonging” to another page. So I’d just use <r:image
vat="/stock/set1" name=“myPic” />.

In either case, I don’t really care WHERE the picture sits – just that
the user can ask for it using the correct “address” (how they think
about or need it). Both addressing methods are clearly needed.

Like you said, it is all interface. Your extension could be extended to
add a vat™ view with organization, browsing, etc. A vat™ based
asset manager could allow for tags that reference the asset as
such-and-such-image-on-page-x.

Oh, and one other great point, Dan… A vat™ with too many items is
hard to manage. It needs to be organizable (I implied a folder
structure in my tag above but, of course, there are other ways). After
all, the vat™ can hold assets long before they are used in a live
work.

Finally, I’ll repeat my other concern. Regardless of implementation,
there is a valid need to track which pages use asset-x – not just which
assets are used in page-x. This issue is the one that may dictate
implementation (a central vat™ might make this easier).