X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=TODO;h=f33ef96f27bde927fb79f82162461e2a480b01ec;hb=3465362833b175a4e4fbe6cdd4a6d63ddc031f3f;hp=1f0cc7c6572bc77650345be21ceee76ee95d0827;hpb=04bdb9210a8306ba0e40f0783c35d6f4f37ea507;p=mkws-moved-to-github.git diff --git a/TODO b/TODO index 1f0cc7c..f33ef96 100644 --- a/TODO +++ b/TODO @@ -1,89 +1,87 @@ -*** GENERAL *** - -We need additional image-URL fields in our records -- in the connector -framework, in the Torus record's capabilities and elsewhere. Figure -out what's needed, and who needs to do it. - -Can the IRSpy toroid be made to return a meaningful capability field? +*** MKWS *** -Metasearch all targets and see what happens. Figure out why it goes -wrong. + Architecture: separate objects for each widget -Get Charles to remove the testing proxy-IPs from open-access -databases. + Architecture: translucent configuration, with global values + shining through where a specific widget provides no local + value. -Fix the Torus's timed refresh to run on its own in the background, -rather than waiting until the next time a request is made after the -refresh-time has expired. + Architecture: decouple related elements using + publish/subscribe. (Jakub will probably do this.) + Architecture: managed widgets held in the Torus. Maybe. -*** MKWS *** + Architecture: "3rd party widget platforms". I seems to recall + I copied this off one of Seb's lists on the flipchart, but I + can't remember what it refers to. Can anyone? -Make a demo widget that displays an image, like the "From the Digital -Archive" panel of our Toronto Digital Library demo. + Allow debug() to be customised by setting a callback function + that is passed the string rather than just giving it to + console.log(). -Make a widget demo that displays the top-hit full record rather than a -list of summary records. This can be used to pull in Wikipedia text to -make the bulk of a topic page. + Create a logging widget which displays the output of debug(). -Make an Amazon cover-art widget. + Check that library selection (authentication) by hostname + works for MKWS. -Do target selection by UDB rather than ZURL. Needs SP changes. + 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. -We will want a facets-only widget, e.g. to list top authors + Auto-executing widgets should be able to specifying limits (as + a full set of MK2-like widgets does in order to implement + facets). -Visualisation widgets e.g. pie-chart of authors, bar-graph of records -Generate embedded SVG? Does that even work? + Auto-executing 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. -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. + Do target selection by UDB rather than ZURL. May need SP + changes, but we might already have the necessary functions. -Write about interesting new widgets on the Index Data blog. + We will want a facets-only widget, e.g. to list top authors -Widget gallery - Mainly a marketing thing on mkws.indexdata.com - May also have a role in widget creation in MKAdmin + Make a demo widget that displays an image, like the "From the + Digital Archive" panel of our Toronto Digital Library demo. -Architecture: - * Separate objects for each widget - * Translucent configuration - * Decouple using publish/subscribe - * Managed widgets held in the Torus - * 3rd party widget platforms + Make a widget demo that displays the top-hit full record + rather than a list of summary records. This can be used to + pull in Wikipedia text to make the bulk of a topic page. -Write integration guides for various third-party CMSs. + Make an Amazon cover-art widget. -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. + Visualisation widgets e.g. pie-chart of authors, bar-graph of + records Generate embedded SVG? Does that even work? -Auto-widgets should be able to include limits (as a full set of -MK2-like widgets does in order to implement facets). + 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. -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. + Write about interesting new widgets on the Index Data blog. -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. + Make a widget gallery as a marketing thing on + mkws.indexdata.com -Check library selection by hostname works for MKWS. + Maybe also use something like a widget gallery as part of the + widget-creation facility in MKAdmin. -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. + Write integration guides for various third-party CMSs. -Allow debug() to be customised by setting a callback function that is -passed the string rather than just giving it to console.log(). + In the widget builder (initially in MKAdmin and subsequently + in a widget-building widget), 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. -Create a logging widget which displays the output of debug(). + 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. -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. + 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.