Having to use 3 different browsers for both work and home for various purposes, I'm growing agitated that the user interfaces are all different despite having mostly the same tools: address bar, search bar, favorites, history, etc. This triggered the thought of standardizing user-side UI configurations into an XML file that could in theory be used by all three brands. The same technique or standard could perhaps be adopted by other tools, such as word processors and IDE's. (Most end users would ideally use a GUI to set or create these settings, but defining the XML first helps to standardize the options.)
I'll start with just the top and bottom menus and menu bars.
<toolbar groupName=[application's name or ID for the toolbar or option group] autoPopulate={(auto)/append/prepend/none} // see notes location={(top)/bottom/auto} leftLone={true/(false)} // "true" if this bar always starts a row rightLone={true/(false)} // "true" if this bar always ends a row maxWidth={[integer]/[percent%]/(auto)} overflow={(scroll)/more/error} // "more" would be a link to the right textSize={(auto)/small/medium/large} move={(confirm)/easy/lock} // "confirm" means a prompt confirms a move meta=[app-specific stuff] id=[optional reference ID for misc. tools] ><option...><divider...><option...>...</toolbar>
<option refName=[application's name or ID for the option] notFound=[(greyout)/hide/error/none] // what to do if refName not found or not applic. beforeUrl=[URL to run before application processes this option] // optional afterUrl=[URL to run after application processes this option] // optional target=[similar to HTML for HREF destinations, including "_blank"] // for above URL's title={(_auto)/[custom text]/_none} //"_auto" means the app decides iconSrc={[url]/(_auto)/_none} openType={(_auto)/popup/dialog} // see notes input={(_auto)/[integer width]/_none} // text box, see note list=[Pipe-separated list of pull-down options] // Example: "Off|On|Auto". See note. meta=[app-specific stuff] formButton=[Submit button title if we want group to serve as a form. See notes.] id=[optional reference ID for misc. tools] />
Notes
The items generally appear in the order defined, unless certain "autoPopulate" settings are used (described below).
Parenthesis surround the default.
"" is a thin separator or line between menu options.
I don't see any solid reason to distinguish between text menu bars and icon-based tool-bars other than tradition. One should be able to mix and match as needed. The title is used as a roll-over title if any icon is supplied or "inherited".
"groupName" is optional, but potentially allows one "inherit" automatic options, in conjunction with the "autoPopulate" attribute. "refName" for the "options" tag is not specific (dedicated) to a group name such that one does not have to group options by the vendor's default grouping. "autoPopulate" can optionally fill the group with its default options. "(auto)" means the ordering is defined by the application. "append" means those options explicitly defined are placed at the end of ordering and any non-app-defined options are also at the end. "Prepend" is the same, except at the front.
If one wants to hide an otherwise auto-populated option (above), then use the appropriate refName, and set title to "_none" and iconUrl to "_none".
"refName" for "options" tag is not required since we can optionally define our own URL "action" (beforeUrl and afterURL). If it's blank, then "notFound" defaults to "none". One can reference the same refName multiple times.
Some convention for relative references to icons should be provided so that fully qualified paths are not required. Not addressed here yet. Suggestions welcome.
An outer "" tag is perhaps in order. Not addressed here yet.
"Side" tool bars are not addressed here yet.
For "openType", "popup" is generally considered more compact than the full version, "dialog". The app doesn't necessarily have to respect this setting, it's merely a "suggestion" to the app.
The "input" attribute allows one to add an optional text input box. The value of the prompt (contents) is appended to the "beforeUrl" and "afterUrl" destinations (URL encoded), if given, with the URL attribute name of "value" as in "foo?value=123".
"list" is similar to "input" in that that it appends a parameter to the URL's, if given. The URL parameter name is "selected". The list drop-down appears after the input box, if given. For example, if one wanted to make their own custom multi-purpose search and address bar, they could do something like this:
<option title="Search" beforeUrl="www.myCustomSearch.php" input="30" list="Url|Google|Bing|desktop"/> // Example appearance: Search [Kilroy_____________] [Url|V] // "V" = down-arrow. User entered "Kilroy" // Example result: www.myCustomSearch.php?value=Kilroy&selected=Bing
Perhaps the vendor can have URL versions of some or all of their options so that the above "input" and "list" options can be used to send basic parameters to the app for slightly more complicated or advanced options. Hopefully they too would be standardized such that they work across vendors. For example, we could define an asterisk in "beforeUrl" and "afterUrl" to mean the browser's and/or window's default handler. The various URL parameters and tag(s) attribute values could be sent as URL parameters to give more potential info to use. (If you use an asterisk, then the usual behavior is not passed pass onto the application since a URL launch is doing it instead.)
The "formButton" attribute optionally allows the "toolbar" to serve as a form such that we can build some basic forms with such an interface. (Although being a form builder is not the primary purpose. We want to resist Feature Creep.) If "formButton" is set, then the usual individual option behavior is suppressed for options with inputs or lists, and the options' values are appended to the URL per typical GET behavior (POST not yet supported). List values get "_selected" appended to the URL attribute name to make sure they are unique per form. Thus, an option with a refName of "foo" would result in "...&foo_selected=Bing" for its drop-down list selection.
If the app has special doo-dads or widgets in options, then typically the input and list box goes after them. If the app's option by default already has an input box or drop-down list, then ideally it would cede definition of them to our option specifications (such as size or list content) rather than include both the vendor versions and our custom ones; but the vendor is not obligated to do that.
The vendor is expected to attempt to provide a reasonable approximation if an option even if the existing options not quite applicable. For example, some browsers use the address bar for the (Google) search bar also, and depends on what button one uses. Thus, the "search-engine" and "url-address" (refName's) implementation may be the same instance of the dual-purpose search bar. The standard is not asking vendors to change their entire product, only the primary menus and tool-bars.
--top
See original on c2.com 