Component Interface (API) design Guide [1]-issues to consider

* Return to Table of contents read other chapters: http://blog.csdn.net/cuibo1123/article/details/39894477

When developing a program, I often design reusable APIs that are typically for iOS (and sometimes on MacOS) and are mostly about GUI controls or a component of a view.

I've been designing dozens of API components over the years, including some Apple client programs, and I've learned a lot of things in the process. I also regularly publish open source components, and user feedback is helpful to me as well. I have compiled a set of guidelines for designing APIs to share with you.

This is an important topic, whether you are an open source contributor, or a team that writes modules for a large program, or simply writes your own software. Just like the first time an application launches a user experience, your API will be the first impression of your code quality, which can have a huge impact on whether someone else is using it (or discarding it).

The API is like a developer's user experience (UX). I am surprised that there is not much information in this regard, nor is there a popular platform devoted to this topic.

I'll use my recently released open source GUI component Mgtilemenu as an example to introduce some of the guidelines. You can read about Mgtilemenu's content if you like.

The ideal quality

The API is designed very similar to the user interface and user experience design. Your target audience has different needs and characteristics, but their goal is to complete a job. As a friendly, usable user interface (UI), you must try to get your API:

1: Intuitive (intuitive)

2: The Catholic (forgiving)

3: The same (frictionless)

Just as a software designed for people to use, we must consider the use case, we must ensure that users can easily make the most common, most needed things, and do not need unnecessary configuration. The default behavior should be useful and should be a reasonable choice. Second, the functionality of the software (or API) should be discoverable, allowing the user to deduce other uses from a known paradigm, just as the user interface is designed to conform to consistent user habits.

Interface

There are four main types of explicit interactions between developers and components:

1. Class interface (ClassInterface), the properties and methods exposed by the class.

2. Entrustment Agreement (Delegateprotocol), in the relevant place.

3. Data source Protocol (DATA-SOURCEPROTOCOL), as appropriate.

4. Notice of provision (notifications).

Every interaction we design should require the user to use it deliberately, not to make an implicit interaction call. In addition, you should consider two key questions:

0 What is control?

Control affects interfaces and class methods. The interface it affects is obvious, such as a button, or a slider. And the method it affects is determined by the code.

What kind of control is 0?

Which delegates and/or data sources, notifications it needs. If it is a new type of control, is it inherently similar to the existing control method? For example, outline view is a linear table. A Calendar control is a date selector. A collection of commands renders a menu, and so on.

Our core goal is to align it with existing components or models so that users can quickly figure out a strange control. Where possible (this is almost always possible), try to use (or imitate) the standard API. For some users who use these modules at the code level, familiarity and intuition are just as important.

Let's look at the application of the four explicit interaction methods mentioned earlier in the API.

Read the next section: http://blog.csdn.net/cuibo1123/article/details/39894477

－－－－－－－－－－－－－－－－－－－－－－－－－

" api Design "
Span style= "COLOR:WINDOWTEXT;" >        author : matt Gemmell
        original link : http:/ /mattgemmell.com/api-design/

The Chinese version is xoneday translate
        Welcome to Translator blog: Http://blog.xoneday.com        @xoneday one day

If this translation brings you help, I hope you can download my APP to support me:
watercress reading: https://itunes.apple.com/cn/app/id695492935
Memo Clip: https://itunes.apple.com/cn/app/id580552733

Memo Clip watercress Reading

* Reprint statement: Please do not delete the content of the author/translator information and Support section, if you do not accept this clause please do not reprint.

Component Interface (API) design Guide [1]-issues to consider