Discussion on whether and how adding a javascript framework to core would be beneficial has been in relatively broad terms. But the goal is not to add a javascript framework to core. The goal is to make Drupal easier and more pleasant to use. Adding a javascript framework *can* be a *tactic* towards achieving that goal.

We need to play around. Get some hands-on experience to see if the strategy of using a framework can get us to the goal faster, better.

So why not find some core interactions that particularly suffer from “each click is a roundtrip to the server” syndrome and come up with fun experiments on how those could be improved. And learn from that.

This would also give us examples for more UX designers to work on in a light weight manner.

This issue is just for collecting examples. I am curious to see what you can come up with. We can figure out the How part of this later, this is about the What.

Comments

yoroy created an issue. See original summary.

yoroy’s picture

- Adding a menu item to a menu
- Adding a field to a content type
- Install a new module
- …

webchick’s picture

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.)

yoroy’s picture

Sure, but the tasks all still similar right? People still need to get similar things done. I'm looking for examples of tasks, small scenarios that we can start exploring.

webchick’s picture

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.

Sutharsan’s picture

- 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

catch’s picture

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.

Crell’s picture

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

yoroy’s picture

I may not be using the right words. Maybe it's the page refreshes we want to have fewer of.

I'm looking for (the smallest relevant) examples that hit the overlap between "needs better ux" and "would benefit from a frontend framework".

My goal is to start exploring design solutions with these examples, which I think would make the discussion a bit more concrete and possibly more inspiring than referring to examples from other products.

catch’s picture

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.

tic2000’s picture

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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Thank you @tic2000 . I've been thinking that the flow for adding fields would be a good example as well (http://yoroy.com/pieces/example-current-inside-out-drupal-ux).

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

Thanks, this helps.

danigrrl’s picture

Issue summary: View changes

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

bdichgans’s picture

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

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.