A list of interactions that could benefit from having a smart frontend framework

In my mind, adopting a front-end framework to help improve Drupal's usability is a lot less about enhancing the UIs we already have (which we already know have problems) and more about completely replacing our existing UIs with ones that are far more modern, responsive, and more correctly match end-user expectations (configure settings directly from the front-end, live preview, instant feedback with no page refreshes, etc.)

Well, but the problem with that is that for small scenarios, such as adding a menu to a menu item, there's no need for a front-end framework. Just use a dash of jQuery here and there.

But imagine if something like Views UI were flipped "outside in" and instead of being focused on a humongous list of inscrutable options was a preview of 10 items of your site's content laid out in teaser mode (or whatever). Then you further tweaked it from there by clicking on this widget here or that doohickey there to show 25 items instead of 10, show these two fields and hide that one, etc. and the preview instantly updates as these configuration changes are made. That's going to require a heck of a lot more than a dash of jQuery.

And if we ended up doing a similar thing for other major UIs (Field UI == graphical Data Model Builder + Form Builder, Block UI == Drag and Drop from front-end of site, etc.) that's where having a front-end framework starts to get really useful, because we can easily re-use the same interaction patterns across the product.

- Previewing edited content
- Auto save edited content
- Auto save configuration
- Building a page layout (= working with blocks & regions)
- Selecting a hierarchical taxonomy term from a large set
- Selecting a language when installing Drupal

+1 for adding a menu item

From the IS:

So why not find some core interactions that particularly suffer from “each click is a roundtrip to the server”

From #6:

- Auto save edited content
- Auto save configuration
- Selecting a hierarchical taxonomy term from a large set

These all involve a round-trip to the server, especially the last one unless the entire tree is loaded up-front, which runs into issues like #2673822: Improve performance of ajax callback where just preparing the initial page load can take seconds (literally in that case).

They don't require a full page refresh, an AJAX request might not need to be blocking, but client side rendering won't help with the need to communicate the information back and forth.

Per both catch and webchick, are we looking for examples to avoid a server connection, or a page refresh? Those are very different things.

The arguments in the other front-end framework issues have been around reducing both page refreshes and server round trips, so it's not the wrong words at all - the distinction hasn't been made very clear in the technical discussions either.

However the validity of reducing either very much depends on which page refreshes and server round-trips might get saved. We already have an AJAX framework (not perfect, but it exists and is fairly under-used in core) to remove full page refreshes, and some information can only be got from the server regardless of the specific mechanism for getting it to the client. So examples should really be things which require a completely different interaction - i.e. something where sorting out the IA and AJAX-ifying the interface isn't really viable.

Not that other things to work on are bad to have a list of, just needs a different issue title for those.

Some benefits of a framework are (and I talk here from an Angular point of view since I worked with that, by I imagine that Ember would be very much similar):

1. Data binding. When handling previews it's much easier to do live update of the preview with data binding. Sure, it can be done with jQuery, but you have to pretty much write the code for each field or page.

2. Routing. For a page like field administration, or views, allows to create for each section an url so the user can actually go back and forth. Of course would help here to not have views open everything in modals. This is also doable in jQuery, but not that easy to get right.

From what I searched, Backbone doesn't provide data binding in its "core". It needs another file. But it does provide routing. I don't know how flexible it is since I never used it.

But no matter what you will need round trips to the servers if you need something saved. What we can do is identify where we can reduce the number of trips.

I think in the Field UI there are places we could do that. After selecting the field type we can ask for number of items (cardinality), but also the label, how the field should be displayed in the form probably and even how it should be displayed in full view and save at the end.

Right now to do this you have to click to create a field. Get a full reload (or ajax reload with field ui ajax) which is a trip to the server to see the storage settings form. Another reload for the field settings form. Reload, click the form display, change and save. Reload, click and change display settings click to save. Reload. What is that, 8 trips? We can reduce that down to 3-4, and of those only the last one MAYBE to be a full reload and not just an AJAX one.

Sure this will require some changes in what we require from the server after the field creation, but that's an implementation discussion and as such not to be discussed in this issue.

It could make Drupal work offline better which can be a big accessibility boost in regions where internet connections are not that stable.

http://blog.planetargon.com/entries/go-offline-with-ember