Button discussion

[Adam Pritchard]

In the next release I've added a Markdown Toggle button. But I'm torn about the form it has taken (i.e., the form I've given it), so I would appreciate any feedback, positive or negative. 

Here's what it looks like in Chrome:

Note that it's a `pageAction`, so it appears in the address bar. It will only appear when an applicable field has focus.

And here's Firefox:

You can see both a pageAction button in the address bar and a browserAction button on the toolbar. Note that I've set the browserAction button to be hidden by default -- I added it via the toolbar button palette. Again, the pageAction will only show when an applicable field has focus.

So, the first question: 

Is using a pageAction button okay?

Pros:

• I like it (and used it) because it seems "correct": it is a page-level action, not browser level.
• Nine-tenths of the time when you're using your web browser, Markdown Here is not good for anything, so it shouldn't have permanent browser real estate.

Cons:

• Do most people know that those things are buttons? My informal poll of like three people suggests that they do not. What good is a button that no one knows is a button?

So, not a lot of points, but strong equivocal. To complicate things, in Chrome (unlike Firefox) you can't have both a pageAction and a browserAction -- gotta pick one.

Second question:

Should the button instead be in the email?

The original feature requester suggested that the button be put inline, rather than in the browser chrome. I fooled around with this for a while, but never got it working satisfactorily, so I put it aside an stuck with the less technically challenging in-chrome implementation.

But since then I've seen how Mailvelope does it:

...And it's pretty cool. (I see that my fatal mistake -- or one of them -- was trying to make the button element a child of the contenteditable, whereas Mailevelope makes it a sibling.) But is it too intrusive? It will certainly be a lot more complicated than a standard button, and will surely be a testing hassle (and may not work at all with Thunderbird/Postbox).

Is it worth it? Is it a lot better?

Again, any feedback welcome. Thanks in advance.

Adam

p.s.: I haven't shown Thunderbird, since it doesn't have the same pageAction question. Here's what it looks like:

Again, the toolbar button is not shown by default, but can be added by the user easily.

p.p.s.: If I steal Mailvelope's implementation, I'll have to switch to dual licensing MIT and GPL. But that shouldn't have any real effect on anyone.

[Casey Watts]

I think it should really be in the email.

It's possible to have multiple rich-text fields on a page, where each of them can be used with markdown-here. That alone is enough to warrant that tight textbox-association.

For example, the "new GMail compose experience" (one description here) can have multiple email compose windows open simultaneously, on the same page.

[Casey Watts]

But also I want to note that this isn't the highest priority change either.

I think many users will likely use the keyboard shortcut (My coworkers and I all do!)

For shorter-term, simpler implementation I think an in-browser button is a step forward at least. A lower barrier to use!

As to which one:

Browser button is better.

pageAction in the abstract is a great idea, but I always find its use a little jarring. And I agree it's not button-like at all, more just informational. Most people don't find browser buttons offensive in any way, especially since you can disable it from showing.

[Adam Pritchard]

I think it should really be in the email.
It's possible to have multiple rich-text fields on a page, where each of them can be used with markdown-here. That alone is enough to warrant that tight textbox-association.
For example, the "new GMail compose experience" (one description here) can have multiple email compose windows open simultaneously, on the same page.

I don't entirely understand your train of thought. Yes, there can be multiple rich-text fields on a page. But... how do you see that as incompatible with a pageAction/browserAction button? The button acts on the field that has focus. 

I mean, I think you're probably right in general -- the button in the field would be good. But I don't follow your logic.

pageAction in the abstract is a great idea, but I always find its use a little jarring. And I agree it's not button-like at all, more just informational. Most people don't find browser buttons offensive in any way, especially since you can disable it from showing.

:'(

I think that this conclusion is inescapable. Damn it. I guess I'd better change it...

For the record, I also asked about this on the UX StackExchange (just now -- no responses yet):

http://ux.stackexchange.com/questions/33987/browser-extensions-page-action-or-browser-action

[Adam Pritchard]

I also asked this on the UX StackExchange:
http://ux.stackexchange.com/questions/33987/browser-extensions-page-action-or-browser-action

And in the Chrome App and Extensions Development G+ community:
https://plus.google.com/u/0/112228900913862544865/posts/9HbUjid2UvV

Not many replies yet, but it seems to be going the same way as Casey's opinion.

This quote from the official browserAction documentation is worth repeating:

Don't use browser actions for features that make sense for only a few pages. Use page actions instead.

Uh huh.

I've committed changes go from pageAction to browserAction. (Conveniently, I could refer to the code from when I went to pageAction from browserAction. Ugh.)

[anti...@gmail.com]

Why not allow both or even all three variants?

As long as we want the buttons to be unobtrusive, we still need the user to place the button himself, so the user has to choose where it goes anyway. Why not allow to "place" it as a "pageAction" button too?

To me the "pageAction" seems a lot more logical, but I agree that not many users will know what this is. However, the same is true for keyboard shortcuts (where probably more users know them, but many wont remember the "exact" combination).

In combination with the context menu toggle, i would prefer the "pageAction". The toggle would be only a right-click away and it would be there whenever needed. I think that the pageAction could even be enabled by default, as it is very unobstrusive and also "informs" the user about the fact that markdown-here can be used in the selected field.

There's another firefox addon that puts a button next to the text-fields: https://addons.mozilla.org/de/firefox/addon/its-all-text/ (however i don't know its license)

PS: I'm the "original feature requester".

[Adam Pritchard]

Why not allow both or even all three variants?

Chrome does not allow an extension to have both a pageAction and a browserAction. (At least that's what trying and searching and reading has suggested to me. I'd be happy to be proven wrong.) Otherwise I would have put both -- I added both to Firefox.

If/when I implement the inline button it will be in addition to the other form(s) of the button, with the option to turn it off.

 

There's another firefox addon that puts a button next to the text-fields: https://addons.mozilla.org/de/firefox/addon/its-all-text/ (however i don't know its license)

Thanks for that link.

 

I hope I've convinced you that the design choices I made were the best that I/we could do. I tried to give users the most choices where possible, and where it's not possible I gave them what they're most likely to use.

[sh...@shawntalbert.com]

What is this keyboard shortcut? With Markdown being keyboard-centric I'm desperately looking for a keyboard shortcut to toggle markdown conversion rather than having to grab the mouse and right-click or move up to left-click the toolbar icon.

[Adam Pritchard]

The default keyboard shortcut is Ctrl+Alt+M. You can modify the shortcut from the Options page.

And, yeah, using the keyboard shortcut is the way to go.

Adam