So how do you simplify it?
Just now, the fundamental approach to interaction design is simplicity. Because this method is too vague, we now use simplification as our goal and the object-oriented approach to design the interaction.
Object-facing methods have been used in software programming for a long time, and objects--so-called objects--are naturally consistent with the living environment around us. At the same time, because our interaction design often uses the existing control or the deformation of the control, it is more feasible to use the Object-oriented method to design the interaction between the emotional and the rational.
But the objects in the interaction design are not exactly the same as those in the program. For example, we don't pay attention to the many details of programming: for example, it derives from that object.
Here are the categories of objects we design:
First, we want to make it clear that our basic objects, visual objects, Interaction objects, and UI objects do not contain relationships to accommodate multiple interaction elements. In other words, an interaction object is not necessarily a visual object. They are related to the following:
A, visual objects, interaction objects, UI objects are basic objects
B, UI objects are visual objects
C, UI objects are interactive objects
Below we explain four kinds of interactive objects separately.
The names in the base object are used to mark different interaction objects. (Actually, for the convenience of our subsequent interactions, we also provide IDs as database indexes.) But this ID is actually attached, not the basic object must have attributes. Categories are used to mark the category of the base object. The category is one of the interactive objects we just talked about.
The visual object contains more attributes: The location information contains the values of the left and right sides of the intersection object (for example, in Windows is pixel). The state includes whether the object is available (Enabled) visible (visible), and so on. (such as the three-state button, the super-connected 4 states)
The most important flag of an interaction object is that it can respond to events. such as mouse events, keyboard events and other common. There are also custom events (people who are familiar with programming will associate custom messages). An interactive object can accept the user's commands and feedback commands through the response of an interactive event.
The reason we separate UI objects from interacting objects is that the interaction object does not need to care about some of the properties that the UI object cares about, such as color, font, shape, and so on (of course, not entirely unconcerned, but here to make it more important that the interaction design is not something like color, font, etc. intentionally).
Extended information includes a lot of content. such as pictures of multimedia buttons, animations and sounds, labels, text, and so on.
Before we rush to simplify this goal, let's learn how to use object methods to represent several common interaction elements.
Let's take a look at one of the most common windows.
We then represent a text label with the word Hello World in the last window.
From here we can see that the label is displayed in the previous window (window 1).
Next, we combine a practical example to illustrate how to design and measure the interaction design with object-oriented methods.
(General design methods are from the top and bottom and bottom two kinds.) A personal opinion is that when the overall design is not yet clear, it is better to be from the top. When the details are not clear, it is easier to explain the problem from the bottom up.
[User Requirements description] What we need is an app that can record daily text by date, with no more than 64K of text per day. You can view the contents of previous daily records. You can delete the contents of previous daily records.
Let's analyze the importance of user needs first. It is clear that the most important thing about this app is the diary of the user record. Of course, some people remember the diary only to remember (for example, in order to complete the homework students) some people remember the diary only for deletion (such as dedicated to the lover to write a diary and then lovelorn people), but most of the user's most commonly used function or read the diary. (This is my personal idea, everyone looks at the mess)
Then several schemes are formed:
 The new to old diary list is displayed in a table. Set up three functional areas, respectively, to write a diary, view the diary details, delete the function of the diary.
 take into account the need for users to quickly locate a diary day, set the date input bar. So the diary is hidden in the operation of the date input.
 If you take into account the need for users to view the diary in a long span of time, that is, to simplify the user's choice of days and years of operation, then the scheme is as follows:
Here I'll finish the interactive design document for the third scenario:
Above is our list of interactive objects. The hierarchical relationship between them expresses the subordination between them.
We can then look at the property settings for each object individually, for example, we look at the Table_daysnote properties (position, status, event, and so on). ）：
Now we define a few key tasks based on the [user requirements description] to test the efficiency of the model (this is mostly computer computing, not testing the user's subjective description).
Key task one: Find a diary of a certain date (10)
Key task two: Delete a certain number of fixed date diary (10)
Key task three: in the adjacent two months, continuously add a few diaries. (10)
After reckoning, the efficiency of our third scheme is as follows:
We can see from the comparison of the table that when the key task one of the data volume reached 500 (1-3 years of journaling), the relevant data into the standard distribution, the program 2 is the user clicks the mouse and switch the most times. Programme 3 is best. The same key task two has the same result. Probably because of our example design problem, the key task in the third 3 is also the winner. From this perspective, regardless of user subjective factors, then scheme three is the most efficient.
(Why use these data to calculate, and how much data to choose will affect the final result.) )