Seems like this problem is always around in one guise or another. Is it all that different from using undocumented OS calls to improve your performance. I recall the early days of DOS when MS would warn developers about using such calls at their own risk. When my team was developing global data architecture designs for LexisNexis, we assumed from the start that we'd never know all the people who were using the data or all the ways it would be used. So we put effort into making sure our groundrules were public, easy to find and as clear as we could make them. - We made documentation of the data as clear and as easy to find as we could manage - We made clear to users that the data design could change - We made a public process for requesting, monitoring and commenting on proposed changes - And we made clear that users of the data were ultimately responsible for making sure that its evolution helped, rather than harmed, their products It was far from perfect and there were many complaints about the volume of changes. But on the whole, I think the approach intercepted a lot of potential problems that otherwise would have happened after the fact. Roger raises a really good point - if many users can access your service, you definitely have to assume, if it has value, it will be used for things you don't anticipate. Detective work to figure out what others are doing will help you evolve it to be increasingly useful. Making sure users understand their responsibilities when *using* your service, for whatever purpose, is equally important. /chet ----- Original Message ----- From: Roger L. Costello <costello@m...> To: xml-dev@l... At: 1/19 13:42:00 Hi Chin, I wrote: > Shortly after deploying the web service its logs > reveal that not only are banks using your web > service but also individuals planning holiday > trips abroad are using it! and I also wrote: > You also discover that some users are using your > web service not for the exchange rate information > but for getting today's date! Discovering these things about the users will certainly take detective work. Discovering that lone individuals (not just banks) are using the web service may be accomplished by looking up the IP addresses of the users. Historical usage may help fill in the puzzle pieces: when some individuals only invoke the web service once, or a few times it may suggest that they are using the web service for something other than financial transactions; when some individuals invoke the web service once a day, every day it may suggest that perhaps the exchange rate information isn't the most important information for them. Feedback mechanism such as email or blogs can be deployed alongside the web service to help discover the different ways that users are using the service. As I write this, the lesson I've learned is that it is important to have multiple ways of learning how users are using a web service. I see two broad categories: 1. Automated learning by analyzing the web service's profile logs. 2. Learning through social feeback mechanisms such as email and blogs. What other ways can a person deploying a web service discover how users are using the web service? /Roger ________________________________ From: Chin Chee-Kai [mailto:cheekai@s...] Sent: Sunday, January 18, 2009 9:42 PM To: Costello, Roger L. Cc: 'xml-dev@l...' Subject: Re: Meaning of "Design for the unanticipated user" Hi Roger, Nice summary and example! Just that for the conclusion, are you able to elaborate just a little further on how to "monitor your web service and note changes in usage"? I'm assuming you have some details and for the sake of conciseness, you've summarized them as "monitor and note". I'm keen to hear how one could know the subset of information being extracted from the contents of your web service, and the type of users accessing (other than IP address) when the web service is offered to unanticipated users. Thanks. -- Best Regards, Chin Chee-Kai Costello, Roger L. wrote: Hi Folks, ... Consequently, you need to monitor your web service and note changes in usage. This information will give you the knowledge of how to evolve your service to better accommodate your users. _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format