+selectors though, they are not selectable once overridden.
+
+C<part_picker> will register it's javascript for inclusion in the next header
+rendering. If you write a standard controller that only call C<render> once, it
+will just work. In case the header is generated in a different render call
+(multiple blocks, ajax, old C<bin/mozilla> style controllers) you need to
+include C<js/autocomplete_part.js> yourself.
+
+=back
+
+=head1 PART PICKER SPECIFICATION
+
+The following list of design goals were applied:
+
+=over 4
+
+=item *
+
+Parts should not be perceived by the user as distinct inputs of partnumber and
+description but as a single object
+
+=item *
+
+Easy to use without documentation for novice users
+
+=item *
+
+Fast to use with keyboard for experienced users
+
+=item *
+
+Possible to use without any keyboard interaction for mouse (or touchscreen)
+users
+
+=item *
+
+Must not leave the current page in event of ambiguity (cf. current select_item
+mechanism)
+
+=item *
+
+Should be useable with hand scanners or similar alternative keyboard devices
+
+=item *
+
+Should not require a feedback/check loop in the common case
+
+=item *
+
+Should not be constrained to exact matches
+
+=back
+
+The implementation consists of the following parts which will be referenced later:
+
+=over 4
+
+=item 1
+
+A hidden input (id input), used to hold the id of the selected part. The only
+input that gets submitted
+
+=item 2
+
+An input (dummy input) containing a description of the currently selected part,
+also used by the user to search for parts
+
+=item 3
+
+A jquery.autocomplete mechanism attached to the dummy field
+
+=item 4
+
+A popup layer for both feedback and input of additional data in case of
+ambiguity.
+
+=item 5
+
+An internal status of the part picker, indicating whether id input and dummy
+input are consistent. After leaving the dummy input the part picker must
+place itself in a consistent status.