+ Make am MKWS/Fresco demo by embedding widgets in our Koha
+ installation. Get Wolfram to do this, and find out which parts
+ of the process are cumbersome for him.
+
+ Write about interesting new widgets on the Index Data blog.
+
+ Widget gallery
+ * Mainly a marketing thing on mkws.indexdata.com
+ * May also have a role in widget creation in MKAdmin
+
+ Architecture:
+ * Separate objects for each widget
+ * Translucent configuration
+ * Decouple using publish/subscribe
+ * Managed widgets held in the Torus
+ * 3rd party widget platforms
+
+ Write integration guides for various third-party CMSs.
+
+ In the widget builder, we want to expose capability
+ information (from ZeeRex or a Torus record) in a
+ human-consumable form: "this target can sort by recency", that
+ kind of thing.
+
+ Auto-widgets should be able to include limits (as a full set
+ of MK2-like widgets does in order to implement facets).
+
+ Auto-widgets should be able to include filters (as a full set
+ of MK2-like widgets does in order to implement the Target
+ facet). This can be used to implement target categories as
+ well as the current cruder target-selection-by-ID facility.
+
+ In the widget builder, we should be able to filter the targets
+ available to the widget on the basis of what requirements the
+ widget has, e.g. ability to sort by recency. The capability
+ facet in MKAdmin may suffice for this.
+
+ Check library selection by hostname works for MKWS.
+
+ The widget-builder widget (WBW) should have a Save button that
+ is customised by a callback, so that the widget in question
+ can (for example) be copied into the clipboard, pasted into a
+ nominated div, saved to a database or whatever.
+
+ Allow debug() to be customised by setting a callback function
+ that is passed the string rather than just giving it to
+ console.log().
+
+ Create a logging widget which displays the output of debug().
+
+ Add library selection by secret key as an alternative to
+ selection by user/pw. This is appropriate for
+ security-conscious customers to embed in their own CORS-aware
+ Apache2 configuration.
+
+
+*** MKAdmin ***
+
+ Superuser field should not be mandatory.
+
+ In end-user record, username and password should not be
+ mandatory any more. (Perhaps it should be mandatory to have at
+ least one of u/p, IP range, hostname, etc.)
+
+ Add an "Act As" link on the Edit Library page.
+
+ When making a new user-access record, default the displayName
+ to that of the ibrary that owns it.
+
+ Add a capability facet to MKAdmin. The right way to do this is
+ to refactor the current hardwiry facet code to be more
+ data-driven, then add a configuration element to include
+ capabilities as a facet.
+
+ Make MKAdmin able to filter target list on whether we have
+ access: that is, to targets that either are open-access or we
+ have credentials or an IP proxy for.
+
+ Provide "select all targets" to they can be added.
+
+ Add batch edit on all targets found by the current search.
+
+ We want a way to let customers change the Index Data branding
+ of the MKX front page, as well as the logo at top left of the
+ MasterKey UI itself. Along with that, we could let them change
+ CSS.
+
+ Indent second and subsequent lines of long facet names
+
+ Keep selected facets when narrowing by search, etc. NOT URGENT
+
+ Lose the search function and the A-Z list from the Categories
+ and User Access tabs.
+
+ Lose ALL the left panel options for the categories tab.
+
+ In the library list, rename "Act as this user" to "Act as".
+
+ We need only one add-new-field name/value pair at the bottom
+ of the screen, not three.
+
+
+*** MKAdmin-- ***