Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I am not sure I understand why we really need a insert tab, fundamentally it creates a big container for 1/2 items in Drupal Core even outside of core, I do not see a lot of additional buttons added here the media module would likely go for one media button?
The reason I want to be extra critical of this, is because it adds quite some visual elements, interaction and height. We made the mistake with the text formats, making a good first look - but creating quite some overhead during actual long-term use and a incredibly cluttered element when you have several text area's.
The other argumentation is the fact that it allows for a "contextual" interaction. To quote Wimleers
First and foremost, they're *contextual*. Aloha is about showing just the actions that are possible in the current *context*.
Hence when you insert a link, a before then unexisting "Link" tab appears with the corresponding UI elements. The same applies to insert images
It's all about context. When the cursor is at a piece of text, it doesn't make sense to have the "remove link" button, right? If your cursor is at a piece of text, it is possible to format that link, but more likely, the user wants to change the link itself, hence the "Link" tab is activated by default. If you're editing an image, text formatting doesn't make sense at all.
However what I propose is that, the contextual interaction is is still done. We just don't have tabs, since other than tabbing out of the link contextual interaction they add little value. There are other ways to navigate out of the Link interaction in case you want to bold your link. E.g. A close link/icon? A suggestion below:
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | option2-insert.png | 202.61 KB | Bojhan |
| #6 | option3-insert.png | 137.95 KB | Bojhan |
| spark-close-out.png | 36.24 KB | Bojhan |
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedComment #2
tkoleary CreditAttribution: tkoleary commentedMy goal here was to have as few buttons in the bar at one time as possible but I'm open to this idea. Let me test it out.
Comment #3
Wim LeersThanks a lot for taking the time to write this up, Bojhan. We had already discussed this on IRC, but only now have I found the time to read what you wrote here.
My initial thought was: this could not work, because it could be that you'd want to navigate away from the Link tab to the Format tab or another tab. How could you then jump immediately to the right tab?
But then, I realized that the common case is most likely that there's only going to be a single other tab visible: the "Format" tab. That means we *can* make it smarter: jump to the context-specific buttons, and allow the user to go back to the "format" buttons (the "default" buttons almost?) through some interaction, such as the Close link you're proposing. In other words, your proposal may work as long as there are only two tabs.
However, that actually breaks down once you go to more advanced cases. E.g. on http://aloha-editor.org/ you can insert a table (causing the Table tab to appear), in a table cell you can insert a link (causing the Link tab to appear), and you can still format the link (i.e. the Format tab is also present) as well as insert more links or other things (i.e. the Insert tab is also present). So now you have four simultaneously visible tabs. How could that possibly work well in the interaction you're proposing?
I do agree that simplicity is key, and if possible, we should simplify, simplify, simplify. I have three proposals:
1) get rid of the contextual display of a set of buttons, and simply show/hide them depending on the context. The downside is that depending on the currently applicable contexts, a button could appear in different locations.
2) Instead of having a "Close" link, keep the tab paradigm, but make it only accessible indirectly. On the right hand side, add a button with strong visual presence called "Other actions" (or something similar). Once this is clicked, the user gets to see Format, Insert, Link, Table (only the relevant ones) as buttons (or some other type of styling) *inside* the Aloha toolbar instead of on top, once the user clicks any of them, the corresponding set of buttons will appear.
3) Keep the exact existing behavior, with the sole addition of hiding the tabs when only a single tab is active.
Comment #4
tkoleary CreditAttribution: tkoleary commentedI think that #2 is the best option. It combines smart contextual tools with the ability to override that automagical behavior if and also takes less real-estate. I was never a big fan of the tabs, mainly just following Aloha's patterns.
Comment #5
Bojhan CreditAttribution: Bojhan commentedHad a quick chat with @WimLeers. It all comes down to this usecase; How do you make a link bold that is placed in a table? Do you have to close your way out of link, table till you get to format? Or can you easily tab between the three options?
I agree that being able to tab between the tree options makes most sense, however what doesn't make sense is by default having a Format tab and a Insert tab with 2 options. I suggest we move the insert options into the normal format tab. And only expose the tabs when you actually do a contextual actions. We can even align these tabs to the right, so we don't take up more vertical space or cause jumping behaviour.
So basically 3) + moving picture / link from insert tab to the format tab.
Let me whip up a visual, not sure if we are all actually on the same page what the solutions mean.
Comment #6
Bojhan CreditAttribution: Bojhan commentedAlright so I tried to make it visual so we are on the same page what we are discussing, excuse me for missing icons/style of aloha I couldn't get it to install on D8.
Option 2
You have a "more actions" tab, that toggles buttons. These buttons than allow you to move to their respective buttons.
Option 3
You have no "tabs", only when you actually add a link - and then you use tabs to move out of the link tab, and/or move into other tabs.
I am not really convinced that there will be loads of options in the insert tab, by default there will be two and although this could grow exponentially. I don't think its very likely, we see a whole lot more options. WYSIWYG tend to be swamped with options, but aloha doesn't have that.
@WimLeers is this correct? It looks to me like option 3 is the most simplistic, but Kevin might be acting on more insights.
Comment #7
Wim LeersFor option 2, I'd imagined the "more actions" button to live inside the toolbar itself rather than it to sit on top. Other than that, it's precisely what I imagined.
Other than that, your interpretation matches mine.
Comment #8
Wim LeersFor option 2, I'd imagined the "more actions" button to live inside the toolbar itself rather than it to sit on top. Other than that, it's precisely what I imagined.
Other than that, your interpretation matches mine.
Comment #9
webchickWe discussed this in office hours today, and it was agreed by Bojhan, Wim, Kevin, and myself that this should be something we try and tackle after the initial commit. We should probably prototype + test this first also to make sure it continues to make sense, as the current implementation is usable.
Moving to a feature request so we can continue to discuss it.
Comment #10
webchickOops. Didn't mean to do that.
Comment #11
Wim Leers.
Comment #12
yoroy CreditAttribution: yoroy commentedI'm exploring http://spark.webchick.net/8.x/ and this is what immediately jumped out for me as well. The UI is quite compact, all the more a pity that it still spends 2 rows of tabs/buttons on exposing things.
Badly-disguised subscribe this comment is… and yeah, post-feature freeze is fine :-)
Comment #13
Wim LeersComment #14
Wim LeersComment #15
obrienmd CreditAttribution: obrienmd commentedBohjan's Option 3 from #6 is awesome! However, I think insert table should be first-level, and table/cell manipulation can be a level deep.