3 We need additional image-URL fields in our records -- in the
4 connector framework, in the Torus record's capabilities and
5 elsewhere. Figure out what's needed, and who needs to do it.
7 Can the IRSpy toroid be made to return a meaningful capability
10 Metasearch all targets and see what happens. Figure out why it
13 Get Charles to remove the testing proxy-IPs from open-access
16 Fix the Torus's timed refresh to run on its own in the
17 background, rather than waiting until the next time a request
19 refresh-time has expired.
24 Make a demo widget that displays an image, like the "From the
25 Digital Archive" panel of our Toronto Digital Library demo.
27 Make a widget demo that displays the top-hit full record
28 rather than a list of summary records. This can be used to
29 pull in Wikipedia text to make the bulk of a topic page.
31 Make an Amazon cover-art widget.
33 Do target selection by UDB rather than ZURL. Needs SP changes.
35 We will want a facets-only widget, e.g. to list top authors
37 Visualisation widgets e.g. pie-chart of authors, bar-graph of
38 records Generate embedded SVG? Does that even work?
40 Make am MKWS/Fresco demo by embedding widgets in our Koha
41 installation. Get Wolfram to do this, and find out which parts
42 of the process are cumbersome for him.
44 Write about interesting new widgets on the Index Data blog.
47 * Mainly a marketing thing on mkws.indexdata.com
48 * May also have a role in widget creation in MKAdmin
51 * Separate objects for each widget
52 * Translucent configuration
53 * Decouple using publish/subscribe
54 * Managed widgets held in the Torus
55 * 3rd party widget platforms
57 Write integration guides for various third-party CMSs.
59 In the widget builder, we want to expose capability
60 information (from ZeeRex or a Torus record) in a
61 human-consumable form: "this target can sort by recency", that
64 Auto-widgets should be able to include limits (as a full set
65 of MK2-like widgets does in order to implement facets).
67 Auto-widgets should be able to include filters (as a full set
68 of MK2-like widgets does in order to implement the Target
69 facet). This can be used to implement target categories as
70 well as the current cruder target-selection-by-ID facility.
72 In the widget builder, we should be able to filter the targets
73 available to the widget on the basis of what requirements the
74 widget has, e.g. ability to sort by recency. The capability
75 facet in MKAdmin may suffice for this.
77 Check library selection by hostname works for MKWS.
79 The widget-builder widget (WBW) should have a Save button that
80 is customised by a callback, so that the widget in question
81 can (for example) be copied into the clipboard, pasted into a
82 nominated div, saved to a database or whatever.
84 Allow debug() to be customised by setting a callback function
85 that is passed the string rather than just giving it to
88 Create a logging widget which displays the output of debug().
90 Add library selection by secret key as an alternative to
91 selection by user/pw. This is appropriate for
92 security-conscious customers to embed in their own CORS-aware
93 Apache2 configuration.
98 Add a capability facet to MKAdmin. The right way to do this is
99 to refactor the current hardwiry facet code to be more
100 data-driven, then add a configuration element to include
101 capabilities as a facet.
103 Make MKAdmin able to filter target list on whether we have
104 access: that is, to targets that either are open-access or we
105 have credentials or an IP proxy for.
107 Provide "select all targets" to they can be added.
109 Add batch edit on all targets found by the current search.
111 Superuser field should not be mandatory.
113 Add an "Act As" link on the Edit Library page.
115 When making a new user-access record, default the displayName
116 to that of the ibrary that owns it.
118 In end-user record, username and password should not be
119 mandatory any more. (Perhaps it should be mandatory to have at
120 least one of u/p, IP range, hostname, etc.)
122 We want a way to let customers change the Index Data branding
123 of the MKX front page, as well as the logo at top left of the
124 MasterKey UI itself. Along with that, we could let them change
127 Indent second and subsequent lines of long facet names
129 Keep selected facets when narrowing by search, etc. NOT URGENT
131 Lose the search function and the A-Z list from the Categories
132 and User Access tabs.
134 Lose ALL the left panel options for the categories tab.
136 In the library list, rename "Act as this user" to "Act as".
138 We need only one add-new-field name/value pair at the bottom
139 of the screen, not three.
144 Lose Target Origin and Type columns from list.
148 Remove "changed in last NUMBER days" from search form
150 Remove the the Edit facility and the New button from the
151 categories tab. Keep the category_id column, for some
152 reason. (Although I bet if I removed it neither Seb nor D
155 Make the User Access tab display the single end-user record
156 for editing immediately. Remove everything that doesn't need
159 Remove all help from MKAdmin until Seb sends help texts that
162 D will get back to me with a detailed specification of which
163 reports to include in the Reports tab.
165 In the target list, get rid of "Show record", make the target
166 title a link to the edit page, and discard the edit column
169 In the edit page, lose all the top icons.
171 D will give me a list of target fields to retain in the
172 MKAdmin-- edit page. It may be just target name, categories
175 BIG CHANGE: lose the edit-form distinction between inherited
176 and local values. Have a single column of editable values and
177 override only those that are actually changed.
179 Lose the Create Target facility (from left panel and bottom