Our paper on “Mica” from the 2006 IEEE Symposium on Visual Languages and Human-Centric Computing, VL/HCCO6 [1] presented a prototype tool that helped programmers use a description of desired functionality to find specific relevant API classes and methods. Mica worked by using the Google Web APIs to find pages relating to a given query, and then using a list of known API classes and methods to recognize and aggregate the API-relevant words contained in the result pages. Mica used weighted word frequencies to find the API-relevant words correlated with the search and displayed the most relevant words alongside regular web search results. We had observed that when programmers create new software or add functionality to existing software, a common and often difficult task is that of using libraries, toolkits and SDKs to achieve the desired functionality. Internet search engines, in particular Google, have emerged as new and effective tools for this task, providing quick access to a large collection of tutorials and example code. However, our observations of how programmers used these resources revealed problems and inefficiencies in their use as programming tools. Mica was the first of long series of tools that we built as part of the “Natural Programming Project” [2] to help programmers more easily use APIs. We speculate that the impact of the Mica paper is because: ·The problem of helping users find and use the right API from a growing number of available options has become increasingly relevant. ·The data that comes from other developers' experience, found and ranked through web search, continues to be an invaluable starting point for finding and figuring out how to use APIs. · The strategy of extracting and displaying relevant information alongside Google search results has proven effective. Since Mica came out Google and Bing have started to support this pattern for movies, people, events, and many other pieces of information, although not yet APIs. ·That sweet logo!

We present Apatite, a new tool that aids users in learning and understanding a complex API by visualizing the common associations between its various components. Current object-oriented API documentation is usually navigated in a fixed tree structure, starting with a package and then filtering by a specific class. For large APIs, this scheme is overly restrictive, because it prevents users from locating a particular action without first knowing which class it belongs to. Apatite's design instead enables users to search across any level of an API's hierarchy. This is made possible by the introduction of a novel interaction technique that presents popular items from multiple categories simultaneously, determining their relevance by approximating the strength of their association using search engine data. The design of Apatite was refined through iterative usability testing, and it has been released publicly as a web application.

In the past decade there has been spectacular growth in the number and size of third-party libraries, frameworks, toolkits and other Application Programming Interfaces (APIs) available to modern software developers. However, the time-saving advantages of code re-use are commonly hampered by the difficulty in finding the correct methods for a given task among the thousands of irrelevant ones. We have developed a tool called Apatite that helps address this issue by letting programmers browse APIs by viewing associations between their components. Apatite indicates which items of an API are popular in different contexts and allows browsing by initially selecting verbs (methods and actions) in addition to classes and packages. The associations are calculated by leveraging existing search engine data and source code, and verbs are identified by parsing the documentation descriptions. Apatite is available on the web and is being used by developers worldwide on a regular basis.

Calcite is a new Eclipse plugin that helps address the difficulty of understanding and correctly using an API. Calcite finds the most popular ways to instantiate a given class or interface by using code examples. To allow the users to easily add these object instantiations to their code, Calcite adds items to the popup completion menu that will insert the appropriate code into the user's program. Calcite also uses crowd sourcing to add to the menu instructions in the form of comments that help the user perform functions that people have identified as missing from the API. In a user study, Calcite improved users' success rate by 40%.

Jadeite is a new Javadoc-like API documentation system that takes advantage of multiple users' aggregate experience to reduce difficulties that programmers have learning new APIs. Previous studies have shown that programmers often guessed that certain classes or methods should exist, and looked for these in the API. Jadeite's ldquoplaceholdersrdquo let users add new ldquopretendrdquo classes or methods that are displayed in the actual API documentation, and can be annotated with the appropriate APIs to use instead. Since studies showed that programmers had difficulty finding the right classes from long lists in documentation, Jadeite takes advantage of usage statistics to display commonly used classes more prominently. Programmers had difficulty discovering how to instantiate objects, so Jadeite uses a large corpus of sample code to automatically the most common ways to construct an instance of any given class. An evaluation showed that programmers were about three times faster at performing common tasks with Jadeite than with standard Javadoc.

To better understand what makes Application Programming Interfaces (APIs) hard to use and how to improve them, recent research has begun studying programmers' strategies and use of APIs. It was found that method placement --- on which class or classes a method is placed --- can have large usability impact in object-oriented APIs. This was because programmers often start their exploration of an API from one "main" object, and were slower finding other objects that were not referenced in the methods of the main object. For example, while mailServer.send(mailMessage) might make sense, if programmers often begin their API explorations from the MailMessage class, then this makes it harder to find the MailServer class than the alternative mailMessage.send(mailServer). This is interesting because many real APIs place methods essential to common objects on other, helper objects. Alternate versions of three different APIs were compared, and it was found that programmers gravitated toward the same starting classes and were dramatically faster --- between 2 to 11 times --- combining multiple objects when a method on the starting class referred to the other class.

An important part of many programming tasks is the use of libraries and other forms of Application Programming Interfaces (APIs). Programming via web services using a Service-Oriented Architecture (SOA) is an emerging form of API usage. Web services in a business context (called enterprise SOA or E-SOA) add additional complexity in terms of the number of the services, the variety of internal data structures, and service interdependencies. After altering existing Human-Computer Interaction (HC[) methodologies to address the unique context of software development for SOA, we evaluated a large E-SOA API and identified many usability challenges. Prominent results include difficulties developers encountered while assembling data structures in web service parameters, cycles of errors due to unclear control parameters within data structures, and difficulties with understanding long identifier names. We recommend a tolerance for unspecified objects in automatically-generated web service proxy code, consistent data structures in parame ters across services, and encoding optional namespace schemes into WSDL files.

As software grows more complex, software developers' productivity is increasingly defined by their ability to effectively reuse code. Even APIs (application programming interfaces) and other code explicitly intended for reuse are often difficult and time consuming for developers to use. This paper describes the user-centered design and evaluation process we evolved in redesigning SAP's BRFplus - a business rules engine, whose API was created for platform development, but which is now also increasingly being used by application developers - even though it was not initially designed with their specific needs in mind. Our API redesign attempts to take both the initial as well as the new emergent user requirements into account. A usability evaluation of our proposed changes to the API suggests that our user-centered design process was successful in helping to create an API that significantly improved users' productivity and better matches the different users' needs.

The usability of software APIs is an important and infrequently researched topic. A user study comparing the usability of the factory pattern and constructors in API designs found highly significant results indicating that factories are detrimental to API usability in several varied situations. The results showed that users require significantly more time (p = 0.005) to construct an object with a factory than with a constructor while performing both context-sensitive and context- free tasks. These results suggest that the use of factories can and should be avoided in many cases where other techniques, such as constructors or class clusters, can be used instead.

The usability of APIs is increasingly important to programmer productivity. Based on experience with usability studies of specific APIs, techniques were explored for studying the usability of design choices common to many APIs. A comparative study was performed to assess how professional programmers use APIs with required parameters in objects' constructors as opposed to parameterless "default" constructors. It was hypothesized that required parameters would create more usable and self- documenting APIs by guiding programmers toward the correct use of objects and preventing errors. However, in the study, it was found that, contrary to expectations, programmers strongly preferred and were more effective with APIs that did not require constructor parameters. Participants' behavior was analyzed using the cognitive dimensions framework, and revealing that required constructor parameters interfere with common learning strategies, causing undesirable premature commitment.

When creating new application programming interfaces (APIs), designers must make many decisions. These decisions affect the quality of the resulting APIs in terms of performance (such as speed and memory usage), power (expressiveness, extensibility and evolvability) and usability (learnability, productivity and error prevention). Experienced API designers have written recommendations on how to design APIs, offering their opinions on various API design decisions. Additionally, empirical research has begun to measure the usability tradeoffs of specific design decisions. While previous work has offered specific suggestions, there has not been a clear description of the design space of all possible API design decisions, or the quality attributes that these decisions affect. This paper puts existing API design recommendations into context by mapping out the space of API design decisions and API quality attributes.

Using APIs is a common and often difficult task for developers. Successful API designs can guide users of an API and reduce their dependence on documentation; however API design is far from a science. Usability lab studies have been shown to be successful at improving the usability of specific APIs; however these are expensive and not always possible to run for every API. This paper describes an approach to generalize from studies of specific APIs to investigate the usability impact of design choices that commonly arise in the creation of APIs. Based on these results we will inform the design of many new APIs. A preliminary usability study of whether or not to require constructor parameters confirms our belief that the answer to common design decisions is not always obvious, and making the wrong choice can have a strong negative impact on usability for large groups of API users

Because software libraries are numerous and large, learning how to use them is a common and problematic task for experienced programmers and novices alike. Internet search engines such as Google have emerged as important resources to help programmers successfully use APIs. However, observations of programmers using Web search have revealed problems and inefficiencies in their use. We present a new prototype search tool called Mica that augments standard Web search results to help programmers find the right API classes and methods given a description of the desired functionality, and help programmers find examples when they already know which methods to use. Mica works by using the Google Web APIs to find relevant pages, and then analyzing the content of those pages to extract the most relevant programming terms and to classify the type of each result

A problem arising in many types of programming is that of learning the correct terminology and finding the correct API methods needed to accomplish a task. Most programming support tools are inefficient at supporting this type of learning, although Internet resources such as Google have emerged as useful new tools for this task. We propose a new tool that will analyze large repositories of text and code and use this to find the most relevant keywords and code for any given search query.

We present Citrine, a system that extends the widespread copy-and-paste interaction technique with intelligent transformations, making it useful in more situations. Citrine uses text parsing to find the structure in copied text and allows users to paste the structured information, which might have many pieces, in a single paste operation. For example, using Citrine, a user can copy the text of a meeting request and add it to the Outlook calendar with a single paste. In applications such as Excel, users can teach Citrine by example how to copy and paste data by showing it which fields go into which columns, and can use this to copy or paste many items at a time in a user-defined manner. Citrine can be used with a wide variety of applications and types of data and can be easily extended to work with more. It currently includes parsers that recognize contact information, calendar appointments and bibliographic citations. It works with Internet Explorer, Outlook, Excel, Palm Desktop, EndNote and other applications. Citrine is available to download on the internet.