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 http://creativi.st/gallery )
- 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.”
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.