Is AJAX the solution?

rubyonrails-talk
1

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.

2

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.

3

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??

4

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:

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.

5

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]