Design guidelines for new features going forward

[smblott-github]

We get lots of requests for new features and/or commands.

To keep the Vimium feature set manageable (particularly for new users), we often say "no" if it is felt that the feature/command is likely to be of interest to a limited number of users.

It would be better if we had a way to incorporate more of these feature requests without impacting too greatly upon the core Vimium experience.

There appear to be two options...

Option A

#2312 adds a sendMessage command for messaging external components (other extensions or TamperMonkey scripts, or even the page itself). The idea is that users for whom X is a must-have feature can implement it themselves, and access it via Vimium's key-mapping infrastructure -- and possibly share it with other users.

This might work, but could become quite chaotic. Who maintains these external extensions? How do users find them? How are they documented? Can users trust them?

My sense is that this is not the direction to go.

Option B

Over the last year or so we've been adding "command options" to various commands, like this:

# Google custom search.
map sg Vomnibar.activate keyword=g

There are lots of feature requests knocking around that could be handled in this way.
#2298 (add a command to open specific URLs) could be implemented as follows (see #2318):

map a createTab http://edition.cnn.com/ http://www.bbc.co.uk/news

We could add a link-hints "hover" option via something like:

map gh LinkHints.activateMode hover

I myself run a version of Vimium with global and local marks flipped around (so lower-case letters are global marks). I just find it more useful that way. We could make lower-case global marks an option for all users like this:

map ' gotoMark global
map ` gotoMark local

The problem is that this could get out of hand too. The bar for a new command option is lower than that for a new command. However, at least we can document these features, either within Vimium or on the wiki, so the feature set is still clearly defined and managed. And we can add command options without impacting on the core Vimium UX (particularly for new users).

Conclusion

I think we should do more of Option B, going forward (and ditch Option A). However, input from others would be appreciated. (Particularly @philc).

[smblott-github]

Decision... We're going to ditch Option A and do more of Option B.

Issue... We need to find a way to:

• keep the UX clean and simple for new users,
• and nevertheless document commands with command options.