Is AJAX the solution?

I would like to render content in a model as a 'folder tree' e.g.

- Group
   + Another Group
   Group Item <edit> <delete>
   Group Item <edit> <delete>
+ Another Group

etc..

My research suggests it might be possible to render such a list using
JavaScript and Rails AJAX capabilities by:

- fetching the list data as an XMLHttpRequest
- using JavaScript to render the top-level list (hiding lower level
elements intially)
- using JavaScript to open/close Groups

Does this approach make sense? Does anyone know of any available Rails
recipes or such?

Also I would like the <edit> link to render an appropriate update form
in place of the list and on submit, redisplay the list without fetching
and building the list again. Is this possible?

Many thanks.

I would like to render content in a model as a 'folder tree' e.g.

...

My research suggests it might be possible to render such a list using
JavaScript and Rails AJAX capabilities by:

<snip>

Have a very good look through what you get with the Rails AJAX
implementation, RJS templates and community free code.

There might be boiler plate code already in existence that does
what you want. Having experimented with RAW AJAX implementations
(and its not my skillset really) I became convinced that AJAX
implementaitons that hide the detail are the way to go, and the
Rails implementation seems to be the best.

Certainly tree views are especially common, even if I hate them
with a passion due to their misuse. To me 'tree view' means
boilerplate 'thinking' - developers too lazy to come up with a
proper GUI design.

Rant off.

Thanks. So what would be a better GUI design in your opinion??

I'm open to suggestions - thought about displaying a nested list with a
'considered' use of fonts. If I did this I'd like it to be in a
scrollable view - not sure how do a scrollable view within a page??

Thanks. So what would be a better GUI design in your opinion??

I can't know this without knowing your app properly. My main gripe
with tree views on web pages is historical. For a lot of their uses
tree views in web pages are very inappropriate, and their justification
is very poor:
- we want it to look 'sophisticated' like a regular application or cool
- our native UI version works this way
- it worked well in this other context, so its like 'universal' right?
- I found code on the internet that does it this way
- I can't think of any other way to organise hierarchical data

Just trees can easily break on the web, when they get either deep
or wide, and normally when you are picking trees it is because
the data they represent is either deep or wide. They also hit
scaling issues rapidly, and really the use-trees-by-default is a
mentality that I feel must be fought. You should *always* be
thinking about usability.

This does mean that I have to go the long way round to arrive
at an appropriate usage for trees, but that hasn't happened yet.

I'm open to suggestions - thought about displaying a nested list with a
'considered' use of fonts. If I did this I'd like it to be in a
scrollable view - not sure how do a scrollable view within a page??

You don't. Inner scrollbars are one of those 'other' desktop-thinking
UI elements that pushed into web pages too much. Your browser
already has a scrollbar, use that for your menu scrolling too (i.e.
don't scroll your menu independently of your main content.

Basically just scroll the page and your menu scrolls with the
content. In order to figure out what kind of menu you need, you
have to have a feel for the data, and a list is a better model,
but you need to limit its depth to one entry only. As for font use,
bear in mind that your font selections are limited anyway - the
user won't have them in a lot of cases. So vary different things
by font-family (serif/sans-serif etc.)

Have a good read of Jacob Nielsens stuff on Usability:
http://www.useit.com/

He kind of gets a bad rap for not being 'cool enough', but like all
adages, make sure you know the rules before you decide to
break them.

Its all nice being cool and such, and then you find that your users
want to be able to print stuff, or use their accessibility features. Or
maybe they don't use a $80 high precision mouse. Theres a school
of thought out there that when evaluating a UI you should use
inferior pointing equipment, like a stiff trackball.

I can't know this without knowing your app properly.

I want to allow the user to navigate a list of items which can each
have sub-items, and so on. It's not a menu. Against each item, I would
like to have icons to allow <edit> <create sub-item> <delete> etc. Plus
a button at the top/foot of list to add new items. I would like the
list to be the focus of attention on the page.

The list will be retrieved from a self-referencing table.

In the case where a user, for example, decides to edit an item the list
will be temporarily replaced with an entry/edit form. After changes,
ideally the list will be redisplayed without necessitating redundant
fetch to the database. I'm quite new to XHTML and CSS so not sure if
this is possible or just a pipe dream, or would require JavaScript.

You don't. Inner scrollbars are one of those 'other' desktop-thinking
UI elements that pushed into web pages too much. Your browser
already has a scrollbar, use that for your menu scrolling too (i.e.
don't scroll your menu independently of your main content.
Basically just scroll the page and your menu scrolls with the
content. In order to figure out what kind of menu you need, you
have to have a feel for the data, and a list is a better model,
but you need to limit its depth to one entry only. As for font use,
bear in mind that your font selections are limited anyway - the
user won't have them in a lot of cases. So vary different things
by font-family (serif/sans-serif etc.)

Take your point - perhaps I can 'fix' the layout stuff so that just the
list scrolls if necessary [by the way, I expect the list to grow
considerably but may be filtered]