I think you'll need to write about 10x as many words for people to get what you're saying :D. What exact jquery effects are you suggesting? Please define what you'd change / have changed, and the benefit derived from it if it's not obvious.

I had a really hard time understanding this issue, but I think I've translated most of it now ;).

I don't think it's actually anything to do with jQuery specifically. Most of this is AJAX stuff, although some of it is pure server-side.

This is how I understand it..

1- Slicker site layout: admins can lay out blocks using drag and drop
2a- (Part of '1' really - you have to be able to remove stuff you add)
2b- ... but also disable without removing
3- The login page opens as an overlay over where you already are, rather than navigating you away
4a- (Same as '1' - has to work for page layout but also panel layout - in Composr it is all Comcode pages anyways)
4b- Not sure, possibly talking about adding content via an overlay, rather than getting taken through the CMS zone
5- Not sure.
6a- AJAX-based replying
6b- Inline editing of content
6c- Opening user info in overlays
7- Syndicating stuff from Facebook, to Composr, embedded in profile screens

My response...

1-

This is a *very* hard nut to crack. See my blog post: http://compo.sr/site/news/view/chris_grahams_blog/drag-and-drop-block.htm

I'd love to see a solution to this one actually, but it would need to be done very carefully.

Recently we've seen a big increase in the number of users who don't understand how to change block layout. Clearly these users haven't read the documentation or scanned the page for the obvious edit links, or dug through the Admin Zone to find the numerous places you can change it ;).
This implies that, if we want to keep these users on board (which may be kind of futile, as they probably are imagining a site that requires far more complex tasks to be achieved before they'll get it finished), that we need to actually have drag and drop layout in-situ (i.e. not behind any edit links at all). So that's worth bearing in mind.

2b- You can already put a Comcode 'staff_note' tag around what you don't want to be visible. I imagine a really good drag and drop block editor would have an "unused" box that you'd drag stuff in and out of.

3- In v8 already.

4b- I think trying to force everything into overlays is a mistake. It makes sense if what you are doing is not a completely separate task to where you're already at (e.g. logging in), but looping back through a page dedicated to what you're doing is much better architecturally (e.g. you can enforce session security), and probably also much more reliable (less complex behind-the-scenes Javascript required) and better usability because it puts focus onto the task at hand. Generally though the idea of providing multiple ways of doing things in Composr scares me (i.e. in this case having an overlay option, and an option to do via it's own screen via the CMS zone) -- it leads to an inconsistent UI, more complex code, a more complex admin navigation for the user to work their way around, and makes things harder to customise as there are more contexts you need to consider designing for.

6a- AJAX posting is coming in v8 for comment topics. For the forum, where the primacy is on the posts rather than some content, it's important to see new posts in context, so I think having the whole thing refresh so you see the true current state when you're done (i.e. with correct pagination) is okay. To be honest, yes, having AJAX posting would be slightly nicer, but only slightly, and I worry it could create other unforeseen issues if there's too much AJAX. For example it could make some templating tasks harder (e.g. doing zebra striping would not be so easy because the posts aren't being generated sequentially anymore - individual posts will come out of their own rendering pipelines). These kind of issues exist for comment topics too, but I think there is a very strong case for AJAX posting on comment topics - because refreshing a whole page of content just because you've commented on it is really messy by current standards.

6b- We have some, mostly for title fields shown on category screens. But I do think this is an example of a "leading the user down the garden path" kind of problem. There are fields that can't be edited visually because they may not have a visual representation, so the user needs to understand the edit form. I don't think it ultimately saves people time because a proper editor with all fields open for editing is probably what you need most of the time and this is already very quick and easy to bring up in Composr. I don't know, I do have to check I am not too used to "hard and old" ways of doing things, but when I think of it I don't see benefit from changing how we have it now, and it would definitely be a big job to change it - but then again I do appreciate making things slicker would seem more impressive to new users.

6c- We already have user info come up in tooltips in Conversr.

7- I would think if people want to view Facebook details for a member, they might as well just head off to Facebook to view it? I don't see an advantage in pulling it into Composr really. We definitely need to add a link to Facebook profiles as a default CPF, which is happening in v8. We are trying to improve Facebook integration in v8, but pushing content to Facebook makes more sense than pulling it IMO - pulling it takes it out of context.


I'm going to close this topic. Some of this stuff could be opened up in new issues, but it would need to be a lot more clear on what the intention is. The original issue posted here was very hard to read.