Syntax of mv-bar

[LeaVerou]

Right now mv-bar accepts identifiers of three kinds:

• Absolute identifiers: this means the toolbar is restricted to these buttons ONLY, in that order. Example: mv-bar="edit save"
• Relative identifiers of two kinds:
  • Negative ones: The toolbar has whatever buttons it normally would have except these. Example: mv-bar="no-login"
  • Positive ones: The toolbar has whatever buttons it normally would have plus these. Mainly useful for optional buttons. Example: mv-bar="yes-export".

As you can see, while no-foo is nice and readable, yes-foo is super weird. Other options would be add-foo, but that conflicts with adding collection items. I'm thinking of switching to + and - for relative identifiers. However, that means the difference from absolute ones is much less visible. Compare:

mv-bar="no-save yes-clear yes-export no-login"

and

mv-bar="-save +clear +export -login"

Another drawback of the current syntax is that it would look super awkward with button names that actually start with no- or yes-.

Thoughts? Perhaps you can think of a better, completely different syntax?

Poll on Twitter

[eikishi01]

Hello,

I usually find the standard syntax for this kind of attributes always ending in a form like attr="option no-option", we're already familiar with the notion of the name being the positive version and the "no-name" being the negative option.

EX: mv-bar="no-save clear download no-login".

We can explore other options as well.

[LeaVerou]

@eikishi01 Exactly, however in this case we need to convey three states, as explained in the first post.

[eikishi01]

On syntax update idea, relative can be updated to use "with-" instead of "yes-" for a more comprehensive reading.

• Relative: mv-bar="no-save with-clear"

[LeaVerou]

Ah, that's interesting, @karger suggested the same thing earlier today. If multiple people had the same idea, it means it might be intuitive.

[LeaVerou]

I just had an idea about this!

While using relative and absolute values together is currently possible, it doesn’t make a ton of sense. Also, using relative positive values only makes sense on optional buttons.

What if the syntax for absolute and relative positive was the same, and we figured out which one it is based on whether the button is optional or not?
That's certainly the most natural syntax, as evidenced by @eikishi01’s first comment in this thread and many, many examples on the web.

The main drawback of this: It will not possible to have a toolbar with ONLY optional buttons (e.g. mv-bar="import export" will be interpreted as relative because both buttons are optional).

[eikishi01]

Ok, let's say, we have the available button declarations with an identifier of optional or not in mv code, then it checks for:

1. any optional button = relative

• mv-bar="clear edit"

2. Has "no-" = relative

• mv-bar="edit no-save clear"

3. NOT 1 or 2 = absolute

• mv-bar="edit save"

[eikishi01]

Forgot this:

• clear is optional
• edit, save are not optional

[LeaVerou]

any optional button = relative

That means you cannot have an absolute order that includes optional buttons, which is pretty common.
And it doesn’t solve the limitation I mentioned, you still can’t declare that you want a bar with ONLY optional buttons.

[LeaVerou]

Another idea @karger mentioned yesterday was using an "only" keyword to indicate this is absolute.
I think that could work combined with the heuristic I posted above.

So, to summarize:

1. If any no- term is used, the value is relative.
2. If all buttons used are optional, the value is relative
3. In any other case, the value is absolute.
4. If only is used as the first term, the value is absolute regardless of 1 and 2.

I'm not sure if only should just look like another identifier though. E.g. in `mv-bar="only import export", on one hand it reads nicely, on the other hand it might make someone wonder if there is an "Only" button.

If relative identifiers don't affect order (as is the case right now), I can't think of a reason why we might want to override the heuristic in the other way, i.e. force relative.

One downside is that both the author and anyone reading their markup, need to be aware of which buttons are optional to interpret the value of mv-bar...

Perhaps only should be mandatory. Then the algorithm becomes:

1. If value starts with "only", value is absolute.
2. Otherwise, value is relative.

The downside of that is backwards compatibility: Existing absolute values will now be interpreted as relative. But hopefully that shouldn't be a huge problem, since the buttons will still be there, just with some more added, and most uses of mv-bar are relative anyway.

Thoughts?

[kosirm]

Sorry, for me this looks even more complicated than before.
I would make it super simple:
Example:
-standard buttons list with names and order (A B C D)
-extra buttons (E F G)

Standard buttons list can be changed or reordered only if:
- names are specified
(and optionaly)
- extra buttons are added

mv-bar -all standard buttons in standard order
mv-bar(B A) -only B A standard buttons in that order
mv-bar(G E) -only G E extra buttons in that order
mv-bar(G E F D A) -G E F extra buttons in that order + D A standard buttons in that order
mv-bar(A B C D E F G) -standard buttons and extra buttons in that order

So the only rule would be: If you want to customize the mv-bar you have to specify the buttons in the order that you want to have them
I'm talking from user perspective :)

[LeaVerou]

@kosirm I’m a bit confused. Firstly, mv-bar is an attribute, not a function.

mv-bar -all standard buttons in standard order

You don't need to specify the attribute at all for that.

If you want to customize the mv-bar you have to specify the buttons in the order that you want to have them

You mean relative values should not be possible? So users should be aware of every button and list it if they just want to not have a login button? What happens if Mavo adds a new button in the future? This seems contrary to the needs of pretty much every other user I've talked to.

In any case, if you never want relative values, you can just always specify "only" and it what I'm proposing works exactly as you described... The fact that there's also a relative syntax supported shouldn't be an issue if you don't need it, right?

You are right though that the heuristic is a bit complicated. I edited my post above with a proposal to simplify things.

[kosirm]

It seems really stupid idea, I admit :)
Sorry about notation, I know it's not a function... I was thinking conceptually not gramaticaly.
On the other hand, there are not hundreds of buttons, just few of them.. .not so much to be aware of.
If button names could be replaced with meaningfull and easy to remember short notation (two-letter),
I would definetely choose absolute way. I just like to see what I get :)

What happens if Mavo adds a new button in the future?

If mavo adds new buttons and user customized mv-bar, it's his responsability to add new button, if he wants. I definetely wouldn't like to see some now button on mv-bar, which I didn't put there, when I upgrade mavo.

The fact that there's also a relative syntax supported shouldn't be an issue if you don't need it, right?

Sure!
But would be grateful if I could specify mv-bar with buttons in my prefered order without only, no, yes, etc.
Forgive me if I'm annoying.

[LeaVerou]

But would be grateful if I could specify mv-bar with buttons in my prefered order without only, no, yes, etc.

The "only" would be just in the beginning, not before every button, like mv-bar="only save edit clear".
Does that change your view?
no- is only needed in relative values, which you're not interested in.

Forgive me if I'm annoying.

Of course not! Feedback is welcome! However, we need to take all users feedback into account, and from the Mavos I've seen, it seems most uses of mv-bar are relative, not absolute.

[svgeesus]

I like the only at the start to clarify relative or absolute. I think it is better to make it mandatory, for absolute; thus the absence of only means relative and we know where we are without inspecting other values. This makes the rest of the syntax simpler.

Then no-foo is also clear, and foo is short and easy, without any yes-foo or add-foo or whatever.

[kosirm]

ONLY assumes meaning "Only these buttons". It doesn't presupposes any other meaning like relative or absolute, so it is redundant in case of absolute. no-foo, yes-foo, add-foo, etc. require from user to understand and remember set of rules, which is more demanding then remember list ot button names.
Next, I believe that user who customize bar would prefer to have possibility to set button order as well in which case absolute is the only way, as far as I understand.
So, my proposal is to leave absolute intact (for simplicity) and let user explicitly define relative with some keyword and then use some variation of "yes, no" syntax. Is this possible?

[LeaVerou]

ONLY assumes meaning "Only these buttons". It doesn't presupposes any other meaning like relative or absolute,

This is what absolute means! Only these buttons, in that order.

no-foo, yes-foo, add-foo, etc. require from user to understand and remember set of rules, which is more demanding then remember list of button names.

1. yes-foo/add-foo etc are gone with the current proposal.
2. Remember what rules? no-foo means "remove this button from the default buttons", foo means "add this button to the default buttons if it's not already there". Nothing to remember beyond button names.

Next, I believe that user who customize bar would prefer to have possibility to set button order as well in which case absolute is the only way, as far as I understand.

Yes, or entirely custom button elements inside a custom bar which is not relevant for this discussion. That doesn't change with this proposal, it's only the syntax we're discussing, not the functionality.

So, my proposal is to leave absolute intact (for simplicity) and let user explicitly define relative with some keyword and then use some variation of "yes, no" syntax. Is this possible?

So your disagreement basically boils down to "use a keyword for relative, not absolute". I don't see any particular simplicity benefit going one way or another. I understand that this is your primary use case so you're concerned about it becoming more verbose. However, most of the Mavos I see in the wild use relative values, so it would make sense to keep that shorter. And we're only talking about 6 characters here.

I’m wondering if with all the ideas that have been mentioned in the thread it's unclear what the current proposal is, which would explain comments like "require from user to understand and remember set of rules". Here it is again:

1. If specific set of buttons and order is desired, use only in the beginning of the value.
2. If just want to modify default set of buttons, use no- to remove and no prefix to add.

[kosirm]

Sorry for stealing your time, I wanted to be useful :)

If specific set of buttons and order is desired, use only in the beginning of the value.
If just want to modify default set of buttons, use no- to remove and no prefix to add.

Nicely put. Finally it settled in my mind, I can totaly accept that.

[LeaVerou]

We discussed this in our weekly F2F meeting today, and we resolved to a similar idea. The issue with my current proposal is that things like mv-bar="foo bar" look like absolute values, i.e. that the toolbar has only these values. So making those relative would be confusing.

So we decided the following:

1. If specific set of buttons and order is desired, just use those ids in mv-bar. This is also compatible with the current behavior.
2. If just want to modify default set of buttons, use with in the beginning, with no- to remove and no prefix to add. (with is not set in stone, just none of us could think of a better word. Other ideas were change, modify).

@kosirm this is basically the syntax you wanted too :)

I guess one issue is: What happens if someone forgets with but includes buttons with a no- prefix? I think the intent is clearly relative in that case, so we should treat it as such. @karger, thoughts?

[kosirm]

@LeaVerou Perfect!