UI À la carte #747

Closed
deliminator opened this Issue Oct 5, 2012 · 16 comments

4 participants

@deliminator

I've pushed the ui-a-la-carte branch. Currently it uses twitter bootstrap. But, I would like to make it as UI agnostic as possible.

The idea I have in mind is that the ui-a-la-carte plugin is a middleware between Aloha's UI needs and the actual UI implementation which is often application specific. This would be useful in two separate projects I'm working on, where the UI implementation is completely customized (I actually ripped the ui-a-la-carte plugin out of one of those projects).

I think Drupal would also benefit from this, so any suggestions are welcome.

@wimleers

First of all: cool name! :)

This is of great interest for those in #590, i.e. those who care about making Aloha Editor as accessible as possible. (Or http://drupal.org/node/1747930 on Drupal.org.)

From my call with @draftkraft:

Tried a different implementation of the AE menu/toolbar/UI:

  • You define the HTML elements for the UI, then attach events to this.
  • Seems more natural for web developers.
  • Makes it much easier to support all the ARIA stuff.
  • Will be published in the next 2 weeks on the blog.
  • Very confident: first experiments are very satisfying. So confident that wikidocs has been reimplemented on top of this (replacing common/ui with common/ui-a-la-carte).

Feedback/questions:

  • The entire UI is already defined in HTML: see the sample HTML
  • The JavaScript is a ZILLION TIMES SIMPLER now. Wow. Awesome! Great job!
  • This clearly allows one to have a "static toolbar" (as opposed to one that appears upon clicking). But does this also solve the problem of having multiple static toolbars? (I.e. issue #717.)
  • Can you explain how you envision this to make a11y (accessibility) improvements easier? I can see how it is much easier to do the "big picture" and "initial" a11y improvements. I do not yet see how this makes it easier to do the necessary dynamic ARIA role changes and so on easier, unless it simply is the significantly reduced amount of JavaScript that would indeed make this far more manageable.
  • Typing "Aloha" when inserting a link does not show the search results. It's clearly a TODO, but how do you envision this should work? In general, how do you envision the "JavaScripty/dynamic UI components" to work?
@deliminator

Thanks for your feedback.

I fixed the search results. The example link list was not loaded (I removed it from the link plugin to fix an issue you opened).

I think we can provide support for multiple static toolbars as part of the ui-a-la-carte plugin. I imagine this would be done via the multiplexing approach I mentioned in the other ticket, where the plugins see only one ui, and the ui-plugin actually manages multiple toolbars.

I have not put any thought into accessibility at all. I don't know how accessibility works, I admit it. But, defining your own HTML does give you additional flexibility that may make the process easier.

I should spend some time looking into the accessibility issue. It would be great if we could implement an accessibility layer that can be re-used by custom ui implementations.

@deliminator

To interface with an app-specific custom ui implementation, I imagine that we will use callbacks. If I remember correctly, only the boostrap tab js is currently used by the a-la-carte plugin. If you can replace the $(..).tab() call with a callback, you have already decoupled the current a-la-carte implementation 100% from the bootstrap js.

@wimleers

I fixed the search results.

Thanks. That answers my question of how you envision "dynamic UI components" to work. In essence: the same way as before.

I think we can provide support for multiple static toolbars as part of the ui-a-la-carte plugin. I imagine this would be done via the multiplexing approach I mentioned in the other ticket, where the plugins see only one ui, and the ui-plugin actually manages multiple toolbars.

This makes total sense to me.

I have not put any thought into accessibility at all. I don't know how accessibility works, I admit it. But, defining your own HTML does give you additional flexibility that may make the process easier.

That's my thinking as well, but I'm curious how @draftkraft sees this. He seems to have done quite a bit of research in this area.
Please know that I'm also no a11y expert by any means.

I should spend some time looking into the accessibility issue. It would be great if we could implement an accessibility layer that can be re-used by custom ui implementations.

That'd be splendid indeed. But I'm not sure if this is possible. If the UI works completely differently, then some a11y aspects may need to work differently. Simple things, such as enabling/disabling buttons, those can be done in a unified way I believe.

To interface with an app-specific custom ui implementation, I imagine that we will use callbacks.

What you have right now is: static HTML to start from, you bind events to it in your custom UI implementation. I'd imagine e.g. "the Drupal UI" should reimplement parts or most of common/ui-a-la-carte; that'll be much easier now anyway because there's so little JS left!

If I remember correctly, only the boostrap tab js is currently used by the a-la-carte plugin. If you can replace the $(..).tab() call with a callback, you have already decoupled the current a-la-carte implementation 100% from the bootstrap js.

So you're saying that callback would be used to decouple the UI logic from the UI component libraries that are used (e.g. jQuery UI Tabs, Bootstrap Tabs, Ponicorn Tabs, etc.)?

@mgifford

Interested in seeing a demo of this new interface. Great to hear that it's a Zillion times simpler. Something that doesn't happen often enough.

Generally with accessibility it's not a matter of setting up an accessibility layer as much as it is adding in the proper semantics to see that everyone can have access to a meaningful interface.

Great to see progress in this area though.

@deliminator deliminator was assigned Oct 13, 2012
@deliminator

I think the a la carte plugin should be the "abstract" parent of all ui plugins, and aloha should ship with two concrete implementations: ui-default and ui-bootstrap. Of course, a user should be able to use the a la carte plugin as the basis for his own custom ui as well.

In time Aloha can ship with even more UI framework integration - how about an ExtJs Aloha UI :-)

Not sure whether ui-default is a good name for the floating toolbar. Maybe ui-floating?

@wimleers

Sounds sensible to me :) "default" implies to me that it makes as few assumptions as possible.

@deliminator

"ui-default" is probably not a good name then. Maybe "ui-floating"? Or "ui-jqueryui"?

@wimleers

Oh yes, sorry to not state that more explicitly — I think "ui-floating" is fine. I don't think "ui-jqueryui" is a great name because it's very well possible that a non-floating UI also uses jQuery UI.

@wimleers

What is the plan for moving this forward?

@deliminator

No concrete plans yet.

Can we identify tasks to do?

  • create ui-bootstrap plugin and make alacarte plugin widget library agnostic
  • refactor the ui plugin to be based on the alacarte plugin

What other important tasks?

@wimleers

Maybe it makes more sense to first decouple the plug-ins from depending explicitly on common/ui, but only relying on something like common/ui-base? That would make it much easier to plug in a different UI implementation, thus also helping with the transition phase?

@wimleers

Out of curiosity: how do you plan to deal with per-editable configuration?

We've said this before:

I think we can provide support for multiple static toolbars as part of the ui-a-la-carte plugin. I imagine this would be done via the multiplexing approach I mentioned in the other ticket, where the plugins see only one ui, and the ui-plugin actually manages multiple toolbars.

But those static toolbars do not yet know which buttons are available to the editable they belong to, hence they may show more buttons than will actually be available, for example. So I think we may have been oversimplifying things there.

@deliminator

With the alacarte menu you would just not have the html that corresponds to the unavailable buttons. You may think "but then I have to duplicate the configuration in the format plugin as well as in the html", but that's not strictly true. You can always have a single place where you configure what buttons should be shown and which shouldn't, and then create the respective format plugin configuration as well as the html from that one place.

My subjective opinion is that Aloha should not have any complicated system for dealing with configuration. I think proving low-level API access to all aspects of the editor is better, even if that means that you have to write some code to integrate the editor.

Solving things through configuration is generally a bad idea in my opinion. The reason is that you can only do as much with configuration as the configuration allows / as much as the person that implemented the functionality has had forethought. The flexibility/configurability ration can often be - and is in the case of Aloha - very low. A low ratio means that every additional amount of configurability gives the user only little additional flexibility.

It is much easier to maintain a high flexibility/code ratio. A high ratio means that evey api function that you expose gives the user a much greater deal of flexibility.

@wimleers

I'm totally on the same page :)

With the alacarte menu you would just not have the html that corresponds to the unavailable buttons. You may think "but then I have to duplicate the configuration in the format plugin as well as in the html", but that's not strictly true. You can always have a single place where you configure what buttons should be shown and which shouldn't, and then create the respective format plugin configuration as well as the html from that one place.

This is the one thing I'm not quite understanding.

Imagine you have three editables that are Aloha-powered. The first two have the same configuration (by using the same class names, they share the same configuration, e.g. Aloha.settings.plugins.list.editables[".type-one"]), the third one has a completely different configuration (it uses another class name, e.g. Aloha.settings.plugins.list.editables[".type-two"]).

Imagine the first two don't support lists (<ul>, <ol>), the third one does. All three should show the (disabled) toolbar, only the first two should not have the corresponding buttons.

How does the paragraph you wrote that I quoted relate to this interpretation/view?

@deliminator

Some example code:

var buttons2 = ["insertLink", "formatBold", ....];
var buttons1 = ["insertList", "indentList", "insertLink", "formatBold", ....];

Aloha.settings.plugins.list.editables['.type-one'] = listConfig(buttons1);
Aloha.settings.plugins.list.editables['.type-two']  = listConfig(buttons2);

$('toolbar1').html(generateHtml(buttons1));
$('toolbar2').html(generateHtml(buttons1));
$('toolbar3').html(generateHtml(buttons2));

Now you only need to implement listConfig() and generateHtml().

@evo42 evo42 closed this Oct 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment