A couple of thoughts.
1) In general, isn't it the case that the site developer is going to
want to deal with content. When you're creating content, you're seldom
calling for the the part of some other page (I prefer to do this sort
of work in the the layout myself). I'm not sure exposing content in
this way is necessarily a good thing. At the very least, provide me a
configuration mechanism to restrict access (for example, restricting
certain things by user role?). Similarly, some snippets are really
only supposed to go into layouts and would do very bad things in
content (especially if you're in the bad habit of opening a tag in one
snippet and closing it in another).
2)Make it Extensible.
On 18-Nov-08, at 12:08 PM, Chris Parrish wrote:
Alright, since this post is already heading in this direction, I'll
throw out some ideas that I've been working on. These are getting
pretty refined in my mind and I'm looking into creating an extension
around them (possibly waiting for the new UI, we'll see)...
1. I think the textareas need to come with a toolbar above them (page
parts, snippets, layouts). These toolbars would be filter
specific.
2. All filters (including "none") would include the filter-selection
dropdown (this makes it clear to the user what is controlling the
toolbar content)
3. All filters (including "none") would include one or more
insert-site-item buttons. The goal here is to prevent the user
from having to remember radius tag names and their syntax (that's
"coder stuff") and instead make working with radius more like any
other gui application. The goal here is also to focus only on the
tags used for day-to-day editing (I'm not sure a button to walk
you through creating your site's navigation would be wise as it
would just be clutter most of the time and that task is more
technical in nature). Tag attributes could be handled graphically
and automatically inserted into the tag. For example:
* A "page properties" button would open up a properties
browser (and maybe showing the current page's properties as
examples). Items would include, title, slug, breadcrumb,
author, etc. Selecting one of these properties would insert
the appropriate tag (<r:title />, <r:slug /> etc) into the
content at the cursor's position.
* A "content" button would open up a browser for page and
snippet content. Here the user can look through the
existing items and select an existing snippet or page part.
Once selected, it would insert the appropriate tag (either
<r:find url="..."><r:content /></r:find> or <r:snippet
name="..." />) at the selected position.
* A "link" button would open a pages browser and allow the
user to select one of their pages. This would insert the
<r:link> tag appropriately.
* Asset extensions should plug in here to allow users to
browse assets and choose the one they want, select any
options, then insert the corresponding tag.
4. Each filter would have its own button set but they would have a
consistent "flavor" across filters. For example:
* Markdown would come with: bold, italics, bullet list,
numbered list, heading(s), insert link, insert image,
blockquote (something like
http://livepipe.net/control/textarea). The insert link
button should probably work together with the one mentioned
above to let the user select from their own pages or insert
an external link -- both formated for markdown.
* Textile would have something like Markdown (again, the
buttons look the same but they insert textile specific
elements).
I would welcome feedback or any collaborators.
-Chris
Jim Gay wrote:
On Nov 18, 2008, at 1:42 PM, Adam van den Hoven wrote:
You just hit on an interesting idea for an extension.
Frequently, people are going to reuse the same bits over and over.
Instead of making them go find it, what if we put a "scratchpad"
on the right hand side of the parts (which will consume some space
from the parts but that should be OK the visibility is important).
This will give them a place to retrieve commonly used bits and
then copy and paste them back into their content. Give it an easy
way to save new scratches without leaving the page (key to making
it useful). Provide a separate UI to "tweak" the scratch (edit,
give it a title and a description) and we can bootstrap a bunch of
scratches which will ease their entry into the world of "markup"
Adam
development has stalled on it, but the start of a browser extension
intends to add an area where things like this can be done:
http://github.com/saturnflyer/radiant-browser-extension/tree/master
there's nothing much there other than the interface, but my intent
is to provide a list of draggable snippets and allow extensions to
add their own stuff (such as page_attachments)
On 18-Nov-08, at 10:33 AM, Steven Southard wrote:
I think maybe you just need to take another approach with her.
Seems sometimes web development is more psychology then
programming. Does she just put her hand over her ears when you
say Markdown or Textile? I've had a client like that! She just
wants to make headers, paragraphs, and upload pictures right?
Keep working with her, tell here to take a few breaths, and
keeping reminding her that the filters are there to keep the
"technical stuff" out of her way.
My clients don't seem to mess with the snippets, tags, or css
classes that much. They just use the filters and maybe one tag
and some classes that they copy and past from where ever else it
was used on the site. It takes a bit for them to get the hang of
it but if they can see the simple patterns they'll be able to add
their content.
Steven
Indeed. Radiant's success can at least be partly attributed to it's
simplicity.
On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote:
Hi everyone,
I've used Radiant for more than 10 web sites during the past 1,5
years, and I really like it. Definitely the best CMS for Rails.
However, I have a client whose content editor is very frustrated
with the system. She can only just tolerate using Markup, and
she refuses to write any kind of HTML - Radius tags falls into
this category from her point of view. According to her, a proper
CMS would hide all this "technical stuff" and provide custom
forms for all types of content.
I know what the core team might answer: Radiant CMS was not
built for this woman. It was built for small sites and content
editors with a bit of technical insight. But Radiant is still
the most user-friendly CMS that exists for Rails, and I don't
really feel like coding PHP just get a more "advanced" UI, which
will suck anyway.
So my question is: How do the rest of you handle this? How do
you hide away "technical" stuff such as snippets, tags and css
classes? Do you:
- Use any of the WYSIWYG filters? (I've done this a few times,
it has its own problems)
- Build very specific custom layouts for all variants for pages?
- Use a generic templating interface such as radiant-templates-
extension to wrap everything up?
- Write custom extensions to wrap all kinds of "elements" nicely
in forms? (such as newsletters, spots, list of various items,
etc.)
Can Radiant be palatable for content editors such as my client,
or is it simply the wrong choice in this case?
It's tough to know how to handle it without a better understanding,
but I've had clients ask for WYSIWYG and had it only cause more
problems once they start using it.
I do as much as I can to handle the layout of content with CSS so
that entering the text stays simple. When clients want to start
moving things around and adding more complex HTML within the
content, I try to first find a way to simplify the content.
If she wants to pay you to create forms, then create the forms. I
think that as one goes down a path to make things simpler you may
find that it ends up being more complex. Abstracting out content
into forms may or may not do this.
I think that its reasonable that she not want to write HTML or
radius tags, but she may be adding more hoops for you and herself
to jump through when learning to type <r:snippet... might be a
simpler and less expensive solution.
I'm interested to see other responses.
-Jim
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
