Yes, this question was more about product definition than user interface
design. The user-interfaces would almost certainly quite different. Also, it
is not just a matter of two users A and B, but also C, D, E, etc. Using the
(hypothetical) example, the users would not just be Publishers and Authors,
but also Warehouse, Stores, Trucks, etc. as well as say Publishers from
indepent companies that could benefit from communicating with each other.
(The real example is from healthcare, but the details are gory)
I think the possible strategies are:
1 - Create an API so that software for Authors, Warehouses, Stores, and
Trucks can push and pull information our software for Publishers. In this
case, my main question is what sort of clout or incentive is necessary to
get existing vendors of software for Warehouses etc to care to support our
API? Or does it not matter?
2 - Create a free product and give it away to Warehouses etc., with the
benefit being improved communications with Publishers (would need to define
this better). But is it unfair that Publishers pay for the software, and
Warehouses get to use it for free? Also, even with a free product,
Warehouses may still resist using an additional system either due to
politics or just intertia.
3 - Identify the most popular software used by Warehouses, Stores, etc. and
explicitly integrate with them. We'd need to define the incentive for those
vendors in creating an open system. The problem is symmetrical in that
currently, Warehouse software vendors have created a half-baked system that
Publishers can use
4 - Get involved in a (drawn-out?) process to form or join an XML consortium
5 - Avoid connectivity features altogether and concentrate solely on an
inhouse product for Publishers
6 - Reorient the company to explicitly create a (possibly closed) platform
targeted at all the above customers. But that leads to the problem that Dave
alluded to--that there is no umbrella organization that can mandate that all
parties use the same product to communicate.
7 - Combinations of the above
Anyone have any experiences with any of the above strategies?
Eugene Chen | User Experience Research, Strategy and Design
mobile 415 336 1783 | fax 240 282 7452
web http://www.eugenechendesign.com | aim peastulip | skype eugene-chen
3 Letters sorta say it all for me when you have a problem like this one.
"Application Program Interface"
Well, to be more specific, I think that people have the right intentions
with the "2 interface" solution, but having spent the last 6 years doing
enterprise software it is almost impossible for one end of the supply-chain
to force another end of the supply chain to use the same tools. Obvious
exceptions are Wal-Mart. Bur for us mere mortals the best we can really hope
for is to create the right "on-ramps" and "off-ramps" for the correctly
mapped data structures.
The question is: on what principles to base the products
Strategically this leads to a question of which systems to
(subsume) vs. interface. And if to interace, then whether
should be one-way or two-way?